[Alerting][Docs] Reformatting rule types docs (#101420)

* Reformatting rule types docs

* Apply suggestions from code review

Co-authored-by: gchaps <[email protected]>

* Restructure geo rule page

* Apply suggestions from code review

Co-authored-by: gchaps <[email protected]>

* PR fixes

Co-authored-by: gchaps <[email protected]>

docs/user/alerting/index.asciidoc

@@ -3,6 +3,5 @@ include::alerting-setup.asciidoc[]
 include::create-and-manage-rules.asciidoc[]
 include::defining-rules.asciidoc[]
 include::rule-management.asciidoc[]
-include::stack-rules.asciidoc[]
-include::domain-specific-rules.asciidoc[]
+include::rule-types.asciidoc[]
 include::alerting-troubleshooting.asciidoc[]

docs/user/alerting/rule-types.asciidoc

@@ -0,0 +1,56 @@
+[role="xpack"]
+[[rule-types]]
+== Rule types
+
+A rule is a set of <<alerting-concepts-conditions, conditions>>, <<alerting-concepts-scheduling, schedules>>, and <<alerting-concepts-actions, actions>> that enable notifications. {kib} provides two types of rules:  rules specific to the Elastic Stack and rules specific to a domain.
+
+[NOTE]
+==============================================
+Some rule types are subscription features, while others are free features.
+For a comparison of the Elastic subscription levels,
+see {subscriptions}[the subscription page].
+==============================================
+
+[float]
+[[stack-rules]]
+=== Stack rules
+
+<<alert-management, Stack rules>> are built into {kib}.  To access the *Stack Rules* feature and create and edit rules, users require the `all` privilege. See <<kibana-feature-privileges, feature privileges>> for more information.
+
+[cols="2*<"]
+|===
+
+| <<rule-type-index-threshold>>
+| Aggregate field values from documents using {es} queries, compare them to threshold values, and schedule actions to run when the thresholds are met.
+
+| <<rule-type-es-query>>
+| Run a user-configured {es} query, compare the number of matches to a configured threshold, and schedule actions to run when the threshold condition is met.
+
+|===
+
+[float]
+[[domain-specific-rules]]
+=== Domain rules
+
+Domain rules are registered by *Observability*, *Security*, <<maps, Maps>> and <<xpack-ml, Machine Learning>>.
+
+[cols="2*<"]
+|===
+
+| {observability-guide}/create-alerts.html[Observability rules]
+| Detect complex conditions in the *Logs*, *Metrics*, and *Uptime* apps.
+
+| {security-guide}/prebuilt-rules.html[Security rules]
+| Detect suspicous source events with pre-built or custom rules and create alerts when a rule’s conditions are met.
+
+| <<geo-alerting, Maps rules>>
+| Run an {es} query to determine if any documents are currently contained in any boundaries from a specified boundary index and generate alerts when a rule's conditions are met.
+
+| {ml-docs}/ml-configuring-alerts.html[{ml-cap} rules] beta:[]
+| Run scheduled checks on an anomaly detection job to detect anomalies with certain conditions. If an anomaly meets the conditions, an alert is created and the associated action is triggered.
+
+|===
+
+include::rule-types/index-threshold.asciidoc[]
+include::rule-types/es-query.asciidoc[]
+include::rule-types/geo-rule-types.asciidoc[]

docs/user/alerting/map-rules/geo-rule-types.asciidoc → docs/user/alerting/rule-types/geo-rule-types.asciidoc

@@ -1,16 +1,14 @@
 [role="xpack"]
 [[geo-alerting]]
-=== Geo rule type
+=== Tracking containment
 
-Alerting now includes one additional stack rule: <<rule-type-tracking-containment>>.
-
-As with other stack rules, you need `all` access to the *Stack Rules* feature
-to be able to create and edit a geo rule.
-See <<kibana-feature-privileges, feature privileges>> for more information on configuring roles that provide access to this feature. 
+<<maps, Maps>> offers the Tracking containment rule type which runs an {es} query over indices to determine whether any
+documents are currently contained within any boundaries from the specified boundary index.
+In the event that an entity is contained within a boundary, an alert may be generated.
 
 [float]
-==== Geo alerting requirements
-To create a *Tracking containment* rule, the following requirements must be present:
+==== Requirements
+To create a Tracking containment rule, the following requirements must be present:
 
 - *Tracks index or index pattern*: An index containing a `geo_point` field, `date` field,
 and some form of entity identifier. An entity identifier is a `keyword` or `number`
@@ -29,22 +27,12 @@ than the current time minus the amount of the interval. If data older than
 `now - <current interval>` is ingested, it won't trigger a rule.
 
 [float]
-==== Creating a geo rule
-Click the *Create* button in the <<create-and-manage-rules, rule management UI>>.
-Complete the <<defining-rules-general-details, general rule details>>.
-
-[role="screenshot"]
-image::user/alerting/images/alert-types-tracking-select.png[Choosing a tracking rule type]
+==== Create the rule
 
-[float]
-[[rule-type-tracking-containment]]
-==== Tracking containment
-The Tracking containment rule type runs an {es} query over indices, determining if any
-documents are currently contained within any boundaries from the specified boundary index.
-In the event that an entity is contained within a boundary, an alert may be generated.
+Fill in the <<defining-rules-general-details, rule details>>, then select Tracking containment.
 
 [float]
-===== Defining the conditions
+==== Define the conditions
 Tracking containment rules have 3 clauses that define the condition to detect,
 as well as 2 Kuery bars used to provide additional filtering context for each of the indices.
 
@@ -61,6 +49,9 @@ Index (Boundary):: This clause requires an *index or index pattern*, a *`geo_sha
 identifying boundaries, and an optional *Human-readable boundary name* for better alerting
 messages.
 
+[float]
+==== Add action
+
 Conditions for how a rule is tracked can be specified uniquely for each individual action.
 A rule can be triggered either when a containment condition is met or when an entity
 is no longer contained.