How it works
Where the model is, and where it is not
The rule is one line and everything else follows from it: the model proposes; deterministic code decides and executes. A saved rule has to give the same answer twice. If a language model sits in the execution path, it cannot.
Code, always
- Correlation and deduplication
- Flap detection and suppression
- Thresholds and anomaly detection
- Routing, escalation and on-call
- SLA computation
- Policy evaluation at the gate
- Remediation execution
- Verification of the result
- Every number in a report
Where a model earns its place
- Free text or speech into structured fields
- A noisy timeline into a readable review draft
- A question into a structured query, which code then runs
- Knowledge retrieval and answer synthesis
- Drafting stakeholder updates
- Explaining why a correlation was made
Every entry in an incident timeline records which of the two produced it — human, rule, connector, or model — so a review can state that a correlation came from rule R-14 and a summary came from a model, rather than asking anyone to take a policy document on trust.
The gate
Automation is the easy half. What decides whether it is safe to point at a production estate is the object in front of it: every action carries a class, and the class determines who may approve it.
| Class | Examples | Unattended? |
|---|---|---|
| 0 Read-only | Fetch logs, run a diagnostic query, describe a resource | Opt-in |
| 1 Safe and reversible | Restart a stuck service, clear a cache, expand a filesystem within quota | Opt-in, per CI |
| 2 Stateful change | Scale a service, change configuration, re-run a pipeline | Approval required |
| 3 Sensitive | Anything touching data, access, secrets or production networking | Human, and two-person for a named subset |
Note that class 1 is opt-in and starts empty. Restarting a stuck service reads as harmless and is not: it drops in-flight work and can mask a deadlock that then recurs. Unattended execution is granted per action and per configuration item by a person, or it does not happen.
Verification
An action that cannot state a machine-checkable success condition before it runs is not eligible to run unattended. This is enforced by a database constraint rather than a code path, for an unglamorous reason: under deadline pressure “mandatory” becomes optional unless something refuses to store the row.
The condition is also read from a source independent of the action itself. A playbook reporting changed: true is evidence that the playbook ran. It is not evidence that the service recovered.
What the demo data can and cannot show
The demo environment is generated by a seeded generator, so it is reproducible and regenerable. It contains a real dependency graph, correlated storms, and changes that precede incidents — which means the reporting question “which changes preceded our P1s” has a genuine, discoverable answer.
It is worth being blunt about what that proves. Seeded data validates plumbing and can never validate analytics — the relationship is discoverable because the generator planted it. Finding it demonstrates that the query engine works. It is not evidence about how often changes cause incidents anywhere in the real world, and no number taken from a demo environment should ever be quoted as though it were.