Vitalii's input

docs/detections/alert-suppression.asciidoc

@@ -42,13 +42,13 @@ You can configure alert suppression when you create or edit a supported rule typ
 If you specify a field with multiple values, alerts with that field are handled as follows:
 
 * **Custom query or threshold rules:** A group of alerts is created for each value. For example, if you suppress alerts by `destination.ip` of `[127.0.0.1, 127.0.0.2, 127.0.0.3]`, alerts will be suppressed separately for each value of `127.0.0.1`, `127.0.0.2`, and `127.0.0.3`. 
-* **Indicator match rule, event correlation (non-sequence queries only), new terms, or {esql} rule:** Alerts with the specified field name and identical array values are grouped together. For example, if you suppress alerts by `destination.ip` of `[127.0.0.1, 127.0.0.2, 127.0.0.3]`, alerts with the entire array are grouped and only one alert is created for the group.
+* **Indicator match rule, event correlation (non-sequence queries only), new terms, {esql}, or {ml} rule:** Alerts with the specified field name and identical array values are grouped together. For example, if you suppress alerts by `destination.ip` of `[127.0.0.1, 127.0.0.2, 127.0.0.3]`, alerts with the entire array are grouped and only one alert is created for the group.
 
 ======
 
 . If available, select how often to create alerts for duplicate events:
 +
-NOTE: Both options are available for custom query, indicator match, event correlation, and new terms rules. Threshold rules only have the *Per time period* option.
+NOTE: Both options are available for custom query, indicator match, event correlation, new terms, {esql}, and {ml} rules. Threshold rules only have the *Per time period* option.
 +
 --
 * *Per rule execution*: Create an alert each time the rule runs and meets its criteria.

docs/detections/rules-ui-create.asciidoc

@@ -471,7 +471,7 @@ If the `LIMIT` value and **Max alerts per run** value are different, the rule us
 
 - When writing an aggregating query, use the {ref}/esql-commands.html#esql-stats-by[`STATS...BY`] command with fields that you want to search and filter for after alerts are created. For example, using the `host.name`, `user.name`, `process.name` fields with the `BY` operator of the `STATS...BY` command returns these fields in alert documents, and allows you to search and filter for them from the Alerts table. 
 
-- When configuring alert suppression on a non-aggregating query, avoid sorting alerts by descending `@timestamp` order. Doing so can impact the number of alerts that are suppressed, especially if the number of alerts generated is higher than the maximum number of alerts the rule can create when it runs.
+- When configuring alert suppression on a non-aggregating query, we recommend sorting results by ascending `@timestamp` order. Doing so ensures that alerts are properly suppressed, especially if the number of alerts generated is higher than the **Max alerts per run** value.
 
 [float]
 [[esql-rule-limitations]]

docs/serverless/alerts/alert-suppression.mdx

@@ -44,14 +44,14 @@ You can configure alert suppression when you create or edit a supported rule typ
     If you specify a field with multiple values, alerts with that field are handled as follows:
 
     * **Custom query or threshold rules:** Alerts are grouped by each unique value. For example, if you suppress alerts by `destination.ip` of `[127.0.0.1, 127.0.0.2, 127.0.0.3]`, alerts will be suppressed separately for each value of `127.0.0.1`, `127.0.0.2`, and `127.0.0.3`. 
-    * **Indicator match, event correlation (non-sequence queries only), new terms, or ((esql)) rule:** Alerts with the specified field name and identical array values are grouped together. For example, if you suppress alerts by `destination.ip` of `[127.0.0.1, 127.0.0.2, 127.0.0.3]`, alerts with the entire array are grouped and only one alert is created for the group. 
+    * **Indicator match, event correlation (non-sequence queries only), new terms, ((esql)), or ((ml)) rule:** Alerts with the specified field name and identical array values are grouped together. For example, if you suppress alerts by `destination.ip` of `[127.0.0.1, 127.0.0.2, 127.0.0.3]`, alerts with the entire array are grouped and only one alert is created for the group. 
 
     </DocCallOut>
 
 1. If available, select how often to create alerts for duplicate events:
 
      <DocCallOut title="NOTE">
-     Both options are available for custom query, indicator match, event correlation, and new terms rules. Threshold rules only have the **Per time period** option. 
+     Both options are available for custom query, indicator match, event correlation, new terms, ((esql)), and ((ml)) rules. Threshold rules only have the **Per time period** option. 
      </DocCallOut>
 
     * **Per rule execution**: Create an alert each time the rule runs and an event meets its criteria. 

docs/serverless/rules/rules-ui-create.mdx

@@ -504,7 +504,7 @@ When writing your query, consider the following:
 
 - When writing an aggregating query, use the [`STATS...BY`](((ref))/esql-commands.html#esql-stats-by) command with fields that you want to search and filter for after alerts are created. For example, using the `host.name`, `user.name`, `process.name` fields with the `BY` operator of the `STATS...BY` command returns these fields in alert documents, and allows you to search and filter for them from the Alerts table. 
 
-- When configuring alert suppression on a non-aggregating query, avoid sorting alerts by descending `@timestamp` order. Doing so can impact the number of alerts that are suppressed, especially if the number of alerts generated is higher than the maximum number of alerts the rule can create when it runs.
+-- When configuring alert suppression on a non-aggregating query, we recommend sorting results by ascending `@timestamp` order. Doing so ensures that alerts are properly suppressed, especially if the number of alerts generated is higher than the **Max alerts per run** value.
 
 <div id="esql-rule-limitations"></div>