Merge branch 'main' into use-version-variables

Author: colleenmcginnis

.github/CODEOWNERS

@@ -47,8 +47,6 @@
 /solutions/observability/get-started/       @elastic/ski-docs
 /solutions/search/                          @elastic/developer-docs
 /solutions/security/                        @elastic/experience-docs
-/solutions/security/get-started/            @elastic/ingest-docs @elastic/experience-docs
-/solutions/security/cloud/                  @elastic/ingest-docs
 
 /troubleshoot/                              @elastic/docs
 /troubleshoot/deployments/                  @elastic/admin-docs

deploy-manage/autoscaling/trained-model-autoscaling.md

@@ -22,11 +22,13 @@ There are two ways to enable autoscaling:
 * through APIs by enabling adaptive allocations
 * in {{kib}} by enabling adaptive resources
 
+For {{serverless-short}} projects, trained model autoscaling is automatically enabled and cannot be disabled.
+
 ::::{important}
 To fully leverage model autoscaling in {{ech}}, {{ece}}, and {{eck}}, it is highly recommended to enable [{{es}} deployment autoscaling](../../deploy-manage/autoscaling.md).
 ::::
 
-Trained model autoscaling is available for {{serverless-short}}, {{ech}}, {{ece}}, and {{eck}} deployments. In serverless deployments, processing power is managed differently across Search, Observability, and Security projects, which impacts their costs and resource limits.
+Trained model autoscaling is available for {{serverless-short}}, {{ech}}, {{ece}}, and {{eck}} deployments. In {{serverless-short}} projects, processing power is managed differently across Search, Observability, and Security projects, which impacts their costs and resource limits.
 
 :::{admonition} Trained model auto-scaling for self-managed deployments
 The available resources of self-managed deployments are static, so trained model autoscaling is not applicable. However, available resources are still segmented based on the settings described in this section.
@@ -54,10 +56,6 @@ You can enable adaptive allocations by using:
 
 If the new allocations fit on the current {{ml}} nodes, they are immediately started. If more resource capacity is needed for creating new model allocations, then your {{ml}} node will be scaled up if {{ml}} autoscaling is enabled to provide enough resources for the new allocation. The number of model allocations can be scaled down to 0. They cannot be scaled up to more than 32 allocations, unless you explicitly set the maximum number of allocations to more. Adaptive allocations must be set up independently for each deployment and [{{infer}} endpoint](https://www.elastic.co/docs/api/doc/elasticsearch/group/endpoint-inference).
 
-:::{note}
-When you create inference endpoints on {{serverless-short}} using {{kib}}, adaptive allocations are automatically turned on, and there is no option to disable them.
-:::
-
 ### Optimizing for typical use cases [optimizing-for-typical-use-cases]
 
 You can optimize your model deployment for typical use cases, such as search and ingest. When you optimize for ingest, the throughput will be higher, which increases the number of {{infer}} requests that can be performed in parallel. When you optimize for search, the latency will be lower during search processes.
@@ -73,16 +71,16 @@ You can choose from three levels of resource usage for your trained model deploy
 
 Refer to the tables in the [Model deployment resource matrix](#model-deployment-resource-matrix) section to find out the settings for the level you selected.
 
-:::{image} /deploy-manage/images/machine-learning-ml-nlp-deployment-id-elser-v2.png
+The image below shows the process of starting a trained model on an {{ech}} deployment. In {{serverless-short}} projects, the **Adaptive resources** toggle is not available when starting trained model deployments, as adaptive allocations are always enabled and cannot be disabled.
+
+:::{image} /deploy-manage/images/ml-nlp-deployment-id-elser.png
 :alt: ELSER deployment with adaptive resources enabled.
 :screenshot:
 :width: 500px
 :::
 
 In {{serverless-full}}, Search projects are given access to more processing resources, while Security and Observability projects have lower limits. This difference is reflected in the UI configuration: Search projects have higher resource limits compared to Security and Observability projects to accommodate their more complex operations.
 
-On {{serverless-short}}, adaptive allocations are automatically enabled for all project types.
-
 ## Model deployment resource matrix [model-deployment-resource-matrix]
 
 The used resources for trained model deployments depend on three factors:
@@ -100,10 +98,6 @@ If you use a self-managed cluster or ECK, vCPUs level ranges are derived from th
 
 The following tables show you the number of allocations, threads, and vCPUs available in ECE and ECH when adaptive resources are enabled or disabled.
 
-::::{note}
-On {{serverless-short}}, adaptive allocations are automatically enabled for all project types. However, the "Adaptive resources" control is not displayed in {{kib}} for Observability and Security projects.
-::::
-
 ### Ingest optimized
 
 In case of ingest-optimized deployments, we maximize the number of model allocations.

deploy-manage/images/machine-learning-ml-nlp-deployment-id-elser-v2.png

@@ -22,7 +22,7 @@ products:
 
 Some settings are sensitive, and relying on filesystem permissions to protect their values is not sufficient. For this use case, {{es}} and {{kib}} provide secure keystores to store sensitive configuration values such as passwords, API keys, and tokens.
 
-Secure settings are often referred to as **keystore settings**, since they must be added to the product-specific keystore rather than the standard [`elasticsearch.yml` or `kibana.yml files](/deploy-manage/stack-settings.md). Unlike regular settings, they are encrypted and protected at rest, and they cannot be read or modified through the usual configuration files or environment variables.
+Secure settings are often referred to as **keystore settings**, since they must be added to the product-specific keystore rather than the standard [`elasticsearch.yml` or `kibana.yml` files](/deploy-manage/stack-settings.md). Unlike regular settings, they are encrypted and protected at rest, and they cannot be read or modified through the usual configuration files or environment variables.
 
 Keystore settings must be handled using a specific tool or method depending on the deployment type. The following table summarizes how {{es}} and {{kib}} keystores are supported and managed across different deployment models:
 

deploy-manage/images/ml-nlp-deployment-id-elser.png

@@ -16,7 +16,7 @@ You can deploy a model multiple times by assigning a unique deployment ID when s
 
 You can optimize your deplyoment for typical use cases, such as search and ingest. When you optimize for ingest, the throughput will be higher, which increases the number of {{infer}} requests that can be performed in parallel. When you optimize for search, the latency will be lower during search processes. When you have dedicated deployments for different purposes, you ensure that the search speed remains unaffected by ingest workloads, and vice versa. Having separate deployments for search and ingest mitigates performance issues resulting from interactions between the two, which can be hard to diagnose.
 
-:::{image} /explore-analyze/images/machine-learning-ml-nlp-deployment-id-elser-v2.png
+:::{image} /explore-analyze/images/ml-nlp-deployment-id-elser.png
 :alt: Model deployment on the Trained Models UI.
 :screenshot:
 :::

deploy-manage/security/secure-settings.md

@@ -107,7 +107,7 @@ You can also download and deploy ELSER either from **{{ml-app}}** > **Trained Mo
 3. After the download is finished, start the deployment by clicking the **Start deployment** button.
 4. Provide a deployment ID, select the priority, and set the number of allocations and threads per allocation values.
 
-    :::{image} /explore-analyze/images/machine-learning-ml-nlp-deployment-id-elser-v2.png
+    :::{image} /explore-analyze/images/ml-nlp-deployment-id-elser.png
     :alt: Deploying ELSER
     :screenshot:
     :::

explore-analyze/images/machine-learning-ml-nlp-deployment-id-elser-v2.png

@@ -25,6 +25,12 @@ Use the `field` API to access document fields:
 field('my_field').get(<default_value>)
 ```
 
+Alternatively use the shortcut of `$` to get a field.
+
+```painless
+$('my_field', <default_value>)
+```
+
 This API fundamentally changes how you access documents in Painless. Previously, you had to access the `doc` map with the field name that you wanted to access:
 
 ```painless
@@ -77,7 +83,6 @@ ZonedDateTime end = field('end').get(null);
 return start == null || end == null ? -1 : ChronoUnit.MILLIS.between(start, end)
 ```
 
-
 ## Supported mapped field types [_supported_mapped_field_types] 
 
 The following table indicates the mapped field types that the `field` API supports. For each supported type, values are listed that are returned by the `field` API (from the `get` and `as<Type>` methods) and the `doc` map (from the `getValue` and `get` methods).
@@ -112,3 +117,20 @@ The `fields` API currently doesn’t support some fields, but you can still acce
 | `wildcard` | `String` | - | `String` | `String` |
 | `flattened` | `String` | - | `String` | `String` |
 
+## Manipulation of the fields data
+
+The field API provides a `set(<value>)` operation that will take the field name and create the necessary structure. Calling this inside an ingest pipelines script processor context:
+
+```painless
+field("foo.bar").set("abc")
+```
+
+leads to the generation of this JSON representation.
+
+```json
+{
+  "foo": {
+    "bar": "abc"
+  }
+}
+```