[Alerting V2] Experimental Rule Sequence Builder

# Experimental Rule Sequence Builder

## Summary

The Rule Sequence Builder is an experimental feature in Alerting v2 that enables users to create multi-step rules by chaining together existing alert and signal rules in a temporal sequence. This allows monitoring of events that occur across multiple stages over time.

## New Feature: Sequence Builder

* **Location**: Stack Management > Rules > Create rule > "Build a sequence"
* **Status**: Experimental (marked with an "Experimental" badge)
* **Purpose**: Create rules that fire when multiple events occur in a specific order within defined time windows
* **User Benefit**: Monitor temporal patterns (e.g., "error logged followed by service restart within 5 minutes") without writing custom ES|QL queries
* **Output**: Generated sequence rules are always alert rules with recovery tracking

## Key Capabilities

#### Building Sequences

* **Multi-step sequences**: Chain 2+ rules together in a temporal sequence
* **Drag-and-drop interface**: Add rules from the available rules list to the canvas
* **Step operators**:
* **OR step**: Any rule in the step can satisfy the step condition (displayed as stacked nodes)
* **AND step**: All rules in the step must fire within the hop window timeframe (displayed with "All of" badge)
* **Hop windows**: Define maximum time allowed between consecutive steps (e.g., "5 minutes", "1 hour")
* **Correlation**: Correlate sequence across entities (e.g., same `host.name`, `user.name`) when all rules share identical grouping fields in the same order

#### Rule Types Support

* **Alert rules** (`kind: alert`): Standard rules with recovery events (`status: recovered`)
* **Signal rules** (`kind: signal`): Observation-only rules without explicit recovery events (`status: breached` only)
* **Mixed sequences**: Combine both alert and signal rules in a single sequence

#### Recovery Configuration

* **Alert Condition tab**: Define the breach sequence
* **Recovery Condition tab**: Configure when the sequence alert should recover
* **Recovery modes**:
* **Last step** (default): Sequence recovers when the final step recovers
* **All steps**: Sequence recovers when all steps recover
* **Custom**: Select specific steps to track for recovery (click steps to toggle)
* **Visual indicators**: Green outlines and "Tracks recovery" badge overlays show which steps drive recovery

#### Recovery Semantics

* **OR steps with multiple rules**: Uses "any-in, all-out" logic
* Sequence breaches if ANY rule in the OR step fires
* Step recovers only when ALL rules in the OR step have recovered (or become stale for signal rules)
* **Signal rule recovery**: Based on staleness — a signal step recovers when no `status: breached` events appear within the hop window duration
* **Alert rule recovery**: Based on explicit `status: recovered` events

## How It Works

#### Query Generation

The sequence builder generates two ES|QL queries against the `.rule-events` data stream:

1. **Breach query**: Identifies when the sequence pattern matches
* Uses multi-stage STATS aggregation with hop window constraints
* Groups by `group_hash` (correlated) or `sequence_group` (uncorrelated)
* Excludes matches where recovery conditions are already met (mutual exclusivity)

2. **Recovery query**: Identifies when tracked steps have recovered
* For alert rules: checks if latest event has `status == "recovered"`
* For signal rules: checks if no `status == "breached"` events exist within the staleness window (hop window duration)

#### Correlation Behavior

* **Correlated sequences**: All rules must share identical grouping fields in identical order
* Uses server-side `group_hash` computation (order-sensitive)
* Example: All rules group by `["host.name", "user.name"]` in that exact order
* **Uncorrelated sequences**: Rules have different or no grouping fields
* Matches pattern regardless of entity values
* Uses default `sequence_group = "default"`