[Alerting V2] Document 9.6 GA without version-split experimental content

deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md

@@ -80,7 +80,7 @@ In role management, features are organized into the following groups.
 | Group | What it contains |
 | --- | --- |
 | **Analytics** | Privileges for the features you use to explore and visualize data. Refer to [Privileges in the Analytics group](#kibana-privileges-analytics). |
-| **Universal Alerting** {applies_to}`serverless: ga` {applies_to}`stack: experimental =9.5, ga 9.6+` | Privileges for {{alerting-v2-system}}. Refer to [Configure access to {{alerting-v2-system}}](/explore-analyze/alerting/esql/manage/configure-access.md). <br><br> {applies_to}`stack: experimental =9.5` In 9.5, this group is called **Alerting V2**. Before 9.5.4, it's called **Alerting**. |
+| **Universal Alerting** {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` | Privileges for {{alerting-v2-system}}. Refer to [Configure access to {{alerting-v2-system}}](/explore-analyze/alerting/esql/manage/configure-access.md). |
 | **Elasticsearch** | Privileges for {{es}} features. |
 | **Observability** | Privileges for Elastic {{observability}} features. Refer to [Observability {{kib}} privileges](/solutions/observability/get-started/observability-kibana-privileges.md). |
 | **Security** | Privileges for {{elastic-sec}} features. Refer to [Security {{kib}} privileges](/solutions/security/manage/security-kibana-privileges.md). |

explore-analyze/alerting.md

@@ -18,19 +18,19 @@ description: Watch your data and respond to conditions automatically with Elasti
 
 Elastic alerting helps you watch your data and respond when something needs attention, whether that is a metric crossing a limit, an asset leaving an area on a map, or an unusual pattern in your time series. You set the conditions and how people should be notified. Elastic runs the checks for you.
 
-Elastic offers three alerting systems. If you're not sure which fits your situation, refer to [Compare alerting systems](alerting/compare-alerting-systems.md).
+Elastic offers more than one alerting system, and which ones you can use depends on your deployment type and version. If you're not sure which fits your situation, refer to [Compare alerting systems](alerting/compare-alerting-systems.md).
 
 ## {{alerting-v2-system-cap}}
 
 ```{applies_to}
 serverless: ga
-stack: ga 9.6+, experimental =9.5
+stack: ga 9.6+
 ```
 
 You write an {{esql}} query that defines what to watch for, decide whether matches are tracked as [alerts](alerting/esql/alerts.md) or recorded as rule events for later analysis, and control notifications through action policies that handle routing, frequency, and notification batching. {{alerting-v2-system-cap}} also adds alert lifecycle tracking, per-series snooze, queryable rule event history, and rules that can correlate those events for escalation. It is a strong fit when you want full control over what data travels with each detection and how your team is notified.
 
 :::{note}
-{{alerting-v2-system-cap}} runs next to {{alerting-v1-system}} on {{serverless-full}} and {{stack}} 9.5 and later. You don't have to move everything at once. You can copy or rebuild rules when you're ready, and your existing {{alerting-v1-system}} rules won't be affected.
+{{alerting-v2-system-cap}} runs next to {{alerting-v1-system}}, so you don't have to move everything at once. You can copy or rebuild rules when you're ready, and your existing {{alerting-v1-system}} rules won't be affected.
 :::
 
 [Get started with {{alerting-v2-system}} →](alerting/esql/system-overview.md)

explore-analyze/alerting/alerts.md

@@ -18,7 +18,7 @@ description: "Kibana Classic Alerting uses rules to check your data on a schedul
 {{alerting-v1-system-cap}} lets you define rules that check your data on a schedule, create alerts when conditions are met, and trigger actions through connectors (email, Slack, webhooks, and more). It is available on all deployments.
 
 :::{note}
-:applies_to: {"serverless": "ga", "stack": "ga 9.6+, experimental =9.5"}
+:applies_to: {"serverless": "ga", "stack": "ga 9.6+"}
 Looking for {{alerting-v2-system}}? Refer to the [{{alerting-v2-system-cap}} overview](esql/system-overview.md) instead. The two systems are separate, so APIs and instructions for one don't apply to the other.
 :::
 

explore-analyze/alerting/compare-alerting-systems.md

@@ -13,22 +13,22 @@ description: Compare Kibana Classic Alerting, Kibana Universal Alerting, and Wat
 
 # Compare alerting systems [compare-alerting-systems]
 
-Elastic offers three alerting systems, each suited to different use cases and workflows. Use this page to compare them by goal, feature, and availability.
+Elastic offers more than one alerting system, each suited to different use cases and workflows. Use this page to compare them by goal, feature, and availability.
 
 :::{note}
-{{elastic-sec}} has its own detection rules, separate from these three systems. For threat detection, refer to [Detections and alerts](/solutions/security/detect-and-alert.md).
+{{elastic-sec}} has its own detection rules, separate from these alerting systems. For threat detection, refer to [Detections and alerts](/solutions/security/detect-and-alert.md).
 :::
 
 ## Select by use case
 
 | Goal | Suggested system | Availability |
 |---|---|---|
 | Monitor metrics, logs, or uptime with ready-made rules and no query language | [{{alerting-v1-system-cap}}](alerts.md) | {applies_to}`serverless: ga` {applies_to}`stack: ga` |
-| Write {{esql}} to define exactly what to detect and what data each rule event carries | [{{alerting-v2-system-cap}}](esql/system-overview.md) | {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+, experimental =9.5` |
-| Record matches as rule events with `type: signal` for later analysis, without sending notifications | [{{alerting-v2-system-cap}}](esql/system-overview.md) | {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+, experimental =9.5` |
-| Query rule event history in Discover or build dashboards from rule event data | [{{alerting-v2-system-cap}}](esql/system-overview.md) | {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+, experimental =9.5` |
-| Manage notification routing, grouping, and throttling in one place, reusable across rules | [{{alerting-v2-system-cap}}](esql/system-overview.md) | {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+, experimental =9.5` |
-| Build highly custom notification logic with reusable, configurable workflows | [{{alerting-v2-system-cap}}](esql/system-overview.md) | {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+, experimental =9.5` |
+| Write {{esql}} to define exactly what to detect and what data each rule event carries | [{{alerting-v2-system-cap}}](esql/system-overview.md) | {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` |
+| Record matches as rule events with `type: signal` for later analysis, without sending notifications | [{{alerting-v2-system-cap}}](esql/system-overview.md) | {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` |
+| Query rule event history in Discover or build dashboards from rule event data | [{{alerting-v2-system-cap}}](esql/system-overview.md) | {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` |
+| Manage notification routing, grouping, and throttling in one place, reusable across rules | [{{alerting-v2-system-cap}}](esql/system-overview.md) | {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` |
+| Build highly custom notification logic with reusable, configurable workflows | [{{alerting-v2-system-cap}}](esql/system-overview.md) | {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` |
 | Build highly custom logic with scripting and chained inputs | [Watcher](watcher.md) | {applies_to}`stack: ga` {applies_to}`serverless: unavailable` |
 
 ## Compare at a glance
@@ -41,4 +41,4 @@ Elastic offers three alerting systems, each suited to different use cases and wo
 | **Notifications** | Configured per action on each rule | [Action policies](esql/notifications-actions.md) invoke reusable workflows, which send the notification; policies support throttling and conditions | Action-level throttling and conditions |
 | **Noise reduction** | Snooze per rule or per alert, maintenance windows | Acknowledge or deactivate per alert, per-series snooze, maintenance windows, match condition routing in [action policies](esql/action-policies/reduce-notification-noise.md) | Action conditions and throttling |
 | **Available on {{serverless-full}}** | Yes | Yes, {applies_to}`serverless: ga` | No |
-| **Available on {{stack}}** | Yes | Yes, {applies_to}`stack: ga 9.6+, experimental =9.5` | Yes |
+| **Available on {{stack}}** | Yes | Yes, {applies_to}`stack: ga 9.6+` | Yes |

explore-analyze/alerting/esql/action-policies/about-action-policies.md

@@ -1,7 +1,7 @@
 ---
 navigation_title: About action policies
 applies_to:
-  stack: ga 9.6+, experimental =9.5
+  stack: ga 9.6+
   serverless: ga
 products:
   - id: kibana
@@ -27,7 +27,7 @@ Because of that separation, a single action policy can apply to alerts from many
 
 To narrow which alerts an action policy applies to, set its [scope](create-configure-action-policy.md#matcher). An action policy with an empty scope applies to every eligible alert in the space.
 
-{applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` To apply an action policy to specific rules, give the policy and those rules the same [routing tag](create-configure-action-policy.md#routing-tags). A policy applies to alerts from every rule that has at least one of its routing tags, including rules you tag after you create the policy. The link doesn't depend on the rule's ID, name, or rule tags. You can rename a rule or reorganize its rule tags without changing which policies apply.
+To apply an action policy to specific rules, give the policy and those rules the same [routing tag](create-configure-action-policy.md#routing-tags). A policy applies to alerts from every rule that has at least one of its routing tags, including rules you tag after you create the policy. The link doesn't depend on the rule's ID, name, or rule tags. You can rename a rule or reorganize its rule tags without changing which policies apply.
 
 ## How action policies gate alerts [action-policy-gates]
 
@@ -36,8 +36,7 @@ A workflow runs only when the alert passes every gate. {{kib}} checks the gates
 | Gate | What it checks |
 |------|----------------|
 | Alert eligibility | Whether the alert is acknowledged, snoozed, resolved, or in a maintenance window. Any of these stops it. |
-| Policy scope {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` | Whether the alert's rule has at least one of the policy's [routing tags](create-configure-action-policy.md#routing-tags), and whether the alert matches the policy's [KQL](../../../query-filter/languages/kql.md) expression. If the policy has both, the alert has to pass both. An empty scope passes every eligible alert in the space. |
-| Match conditions {applies_to}`stack: removed 9.6+, experimental =9.5` {applies_to}`serverless: unavailable` | Whether the alert matches the policy's [KQL](../../../query-filter/languages/kql.md) expression. An empty expression passes every eligible alert in the space. |
+| Policy scope | Whether the alert's rule has at least one of the policy's [routing tags](create-configure-action-policy.md#routing-tags), and whether the alert matches the policy's [KQL](../../../query-filter/languages/kql.md) expression. If the policy has both, the alert has to pass both. An empty scope passes every eligible alert in the space. |
 | Frequency | Whether a workflow already ran for the alert's notification group within the policy's frequency interval. If it did, the alert waits. |
 
 If any gate stops the alert, {{kib}} doesn't invoke a workflow for that action policy. Multiple action policies can apply to the same alert, and {{kib}} checks the gates separately for each one, with no precedence or merging between them.

explore-analyze/alerting/esql/action-policies/action-policy-reference.md

@@ -1,7 +1,7 @@
 ---
 navigation_title: Action policy reference
 applies_to:
-  stack: ga 9.6+, experimental =9.5
+  stack: ga 9.6+
   serverless: ga
 products:
   - id: kibana
@@ -18,43 +18,17 @@ Use the following fields in the **Match conditions** expression to filter which
 
 | Field | Description | Example |
 |---|---|---|
-| `alert_id` {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` | Unique identifier of the alert. | `alert_id: "alert-001"` <br> Match a specific alert by ID. |
-| `episode_id` {applies_to}`stack: experimental =9.5` | Unique identifier of the alert. Replaced by `alert_id` in later versions. | `episode_id: "ep-001"` <br> Match a specific alert by ID. |
-| `alert_status` {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` | Current lifecycle status of the alert. One of `inactive`, `pending`, `active`, or `recovering`. | `alert_status: "active"` <br> Match only active alerts. |
-| `episode_status` {applies_to}`stack: experimental =9.5` | Current lifecycle status of the alert. Replaced by `alert_status` in later versions. | `episode_status: "active"` <br> Match only active alerts. |
+| `alert_id` | Unique identifier of the alert. | `alert_id: "alert-001"` <br> Match a specific alert by ID. |
+| `alert_status` | Current lifecycle status of the alert. One of `inactive`, `pending`, `active`, or `recovering`. | `alert_status: "active"` <br> Match only active alerts. |
 | `severity` | Current severity level. One of `info`, `low`, `medium`, `high`, or `critical`. Populated when the rule's {{esql}} query includes a `severity` column. Not set during recovery, so a severity-scoped policy applies only to open alerts. Severity can change during an alert without reopening it. The action policy picks up the new value on the next dispatcher cycle. For how to configure severity in a rule, refer to [Severity](../rules/configure-rule-severity.md). | `severity: "critical" OR severity: "high"` <br> Route high-priority alerts to a dedicated workflow. |
 | `group_hash` | Stable hash identifying the alert series the alert belongs to. | `group_hash: "abc123"` <br> Match all alerts in a specific alert series. |
 | `last_event_timestamp` | ISO 8601 timestamp of the most recent event recorded for the alert. | `last_event_timestamp > "2026-01-01"` <br> Match alerts with activity after a specific date. |
 | `data.*` | Dynamic payload fields sent by the rule. Available fields depend on the rule type and configuration. Use for rule-specific fields not covered by the standard fields in this table. | `data.host.name: "web-01"` <br> Match alerts from a specific host in a host-based rule. |
 
 :::{note}
-:applies_to: {"serverless": "ga", "stack": "ga 9.6+"}
 To apply a policy to alerts from a set of rules, give the policy and those rules the same routing tag. **Match conditions** can't select alerts by the rule's ID, name, or tags. To learn more, refer to [Apply the policy to alerts from specific rules](create-configure-action-policy.md#routing-tags).
 :::
 
-### Rule fields [action-policy-matcher-rule-fields]
-```{applies_to}
-stack: removed 9.6+, experimental =9.5
-serverless: unavailable
-```
-
-In addition to the alert fields, you can use the following fields in the **Match conditions** expression to select alerts by the rule that produced them.
-
-| Field | Description | Example |
-|---|---|---|
-| `rule.id` | Unique identifier of the rule that generated the alert. | `rule.id: "rule-001"` <br> Match alerts from one specific rule. |
-| `rule.name` | Display name of the rule. | `rule.name: "High CPU"` <br> Match alerts from rules with this display name. |
-| `rule.tags` | Tags attached to the rule. | `rule.tags: "payment-service"` <br> Match alerts from all rules with this tag. |
-
-:::{important}
-When you upgrade to a later version, action policies whose **Match conditions** use `rule.id`, `rule.name`, `rule.tags`, `episode_id`, or `episode_status` no longer select the alerts you expect. {{kib}} keeps the expression and doesn't show an error. A condition such as `rule.tags: "checkout"` stops matching any alert, so the policy stops invoking its workflows. A negated condition such as `NOT rule.tags: "checkout"` matches every alert.
-
-To fix these policies after you upgrade:
-
-1. Add the same routing tag to each policy and to its rules.
-2. Replace `episode_id` and `episode_status` with `alert_id` and `alert_status`.
-:::
-
 ## Notify per options [action-policy-notification-grouping]
 
 Controls how the action policy batches alerts before invoking a workflow.

explore-analyze/alerting/esql/action-policies/common-action-policy-scenarios.md

@@ -1,7 +1,7 @@
 ---
 navigation_title: Examples and common scenarios
 applies_to:
-  stack: ga 9.6+, experimental =9.5
+  stack: ga 9.6+
   serverless: ga
 products:
   - id: kibana