[Experimental] Introducing the New Alerting Experience in Kibana

**What the feature is (as Title)**
New Alerting Experience in Kibana

Note: This is an experimental release. Capabilities will expand over time; not every existing alerting feature is available on day one.

**Value proposition**
The New Alerting Experience in Kibana is a ground-up redesign of how Kibana defines, evaluates, and acts on alerts. Instead of choosing from many rule types, users express alert logic in ES|QL. Alert state is stored as searchable, append-only data with full history, not just the latest status. The experimental release introduces this new model in Kibana so teams can try it early, give feedback, and start building on a simpler, more flexible foundation.

Today's alerting in Kibana is fragmented: many rule types, different configuration models, limited alert history, and action logic tightly coupled to individual rules. That makes it hard to author consistent alerts, investigate what happened over time, correlate signals across rules, and separate meaningful incidents from noise.

The New Alerting Experience addresses this by making ES|QL the single language for alert logic and treating alerts as first-class, query-able data. Teams get:

- One model, not many rule types: express thresholds, absence checks, correlations, and more completely in ES|QL..
- Full alert history: every rule evaluation is retained and searchable.
- Smarter triggering: delayed triggers reduce flapping from transient spikes; custom recovery conditions let recovery differ from firing logic.
- Transparent no-data behaviour: explicit handling when data stops arriving
- Richer alert operations: assign, acknowledge, deactivate, conditional snooze, and more.
- Action policies separate from rules : one policy can drive notifications for many rules, so alerts are not automatically noise.
- Detection vs alert mode: keep low-signal rules as searchable data without paging on-call.
- Rules on rules: higher-level alerts that correlate across other rules using alert history data.
- Agentic workflows: assisted rule creation and editing, action policy setup, and workflow destination configuration.

**Expected outcome**

Teams can move from rule-type-driven alerting to a single ES|QL-based workflow where incidents are easier to trust, investigate, and act on. On-call engineers spend less time chasing false positives and silent recoveries, and more time resolving real problems, because alerts fire when conditions truly matter, recover when work is actually done, and stay visible when data stops arriving. Operators can search full alert history to understand what happened over time and platform owners can separate signal from noise by routing only the alerts that need attention while keeping lower-confidence findings available for analysis. The experimental release gives users an early path to simpler rule authoring, more consistent notification behaviour, and faster triage.