First draft

docs/detections/rules-ui-create.asciidoc

@@ -311,7 +311,7 @@ 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 an ES|QL rule with a non-aggregating query contain the fields returned by the query and all fields in the source event document.
 
 Here is an example non-aggregating query:
 [source,esql]
@@ -376,14 +376,15 @@ NOTE: The `max_signals` default value is 100. You can modify it using the <<rule
 
 - 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. 
 
+- If your {esql} query creates new fields that aren’t in the query’s source index, they can be added to the rule’s <<rule-ui-advanced-params,custom highlighted fields>>.
+
 [float]
 [[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>>. 
-- 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>>.
 
 [float]
 [[rule-ui-basic-params]]