[Request][8.14] improved ES|QL investigation (highlighted) fields

docs/detections/rules-ui-create.asciidoc

@@ -289,7 +289,9 @@ TIP: Click the help icon (image:images/esql-ref-button.png[Click the ES|QL help
 [[esql-agg-query]]
 ===== Aggregating query 
 
-Aggregating queries use {ref}/esql-functions-operators.html#esql-agg-functions[`STATS...BY`] functions to aggregate source event data. Alerts generated by an {esql} rule with an aggregating query only contain the fields returned by the query.
+Aggregating queries use {ref}/esql-functions-operators.html#esql-agg-functions[`STATS...BY`] functions to aggregate source event data. Alerts generated by a rule with an aggregating query only contain the source event fields that the {esql} query returns and new fields that the query creates.
+
+NOTE: New fields don't exist in the source index that the query is searching. Instead, they're created when the query runs, and you can access them in the details of any alerts that are generated. For example, if you use the {ref}/esql-commands.html#esql-stats-by[`STATS...BY`] function to create a column with aggregated values, the column is created when the query runs, and is added as a new field to any alerts that are generated by the rule. 
 
 Here is an example aggregating query:
 
@@ -311,7 +313,9 @@ NOTE: Rules that use aggregating queries might create duplicate alerts. This can
 [float]
 [[esql-non-agg-query]]
 ===== Non-aggregating query 
-Non-aggregating queries doesn't use `STATS...BY` functions and doesn't aggregate source event data. Alerts generated by an {esql} rule with a non-aggregating query only contain the fields returned by the query.
+Non-aggregating queries don't use `STATS...BY` functions and don't aggregate source event data. Alerts generated by a non-aggregating query contain source event fields that the query returns, new fields the query creates, and all other fields in the source event document. 
+
+NOTE: New fields don't exist in the source index that the query is searching. Instead, they're created when the query runs, and you can access them in the details of any alerts that are generated. For example, if you use the {ref}/esql-commands.html#esql-eval[`EVAL`] command to append new columns with calculated values, the columns are created when the query runs, and are added as new fields to any alerts that are generated by the rule.
 
 Here is an example non-aggregating query:
 [source,esql]
@@ -378,12 +382,15 @@ NOTE: The `max_signals` default value is 100. You can modify it using the <<rule
 
 [float]
 [[esql-rule-limitations]]
-==== {esql} rule limitations  
+==== {esql} rule limitations 
 
-The {esql} rule has the following limitations:
+If your {esql} query creates new fields that aren’t part of the ECS schema, they won’t be mapped to the alerts index and you can't search or filter for them from the Alerts table. As a workaround, create <<runtime-fields,runtime fields>>. 
+
+[float]
+[[custom-highlighted-esql-fields]]
+==== Highlight fields returned by the {esql} rule query 
 
-- If your {esql} query creates new fields that aren’t part of the ECS schema, they won’t be mapped to the alerts index and you can't search or filter for them from the Alerts table. As a workaround, create <<runtime-fields,runtime fields>>. 
-- If your {esql} query creates new fields that aren’t in the query’s source index, they can’t be added to the rule’s <<rule-ui-advanced-params,custom highlighted fields>>.
+When configuring an {esql} rule's **<<rule-ui-advanced-params,Custom highlighted fields>>**, you can specify any source event fields and new fields that the rule's aggregating or non-aggregating query returns. This can help ensure that returned fields are visible in the alert details flyout while you're investigating alerts.   
 
 [float]
 [[rule-ui-basic-params]]