Why automation programs stall after the first bad action
Most orchestration programs are suspended not because automation failed technically but because one action produced a business impact nobody had authorized. Recovery of trust after that event takes quarters.
The preventable cause is uniform treatment: playbooks with wildly different blast radius and reversibility governed by the same approval model.
Fidelity classes
Classify every playbook by two axes — detection fidelity and action reversibility — and let the class determine autonomy. Enrichment runs freely. Reversible containment on a single asset runs unattended above a fidelity threshold. Irreversible or multi-asset actions require named approval, always.
- Class A: read-only enrichment and evidence collection, always unattended
- Class B: reversible, single-asset containment, unattended above 95% precision on 30-day trailing data
- Class C: multi-asset or service-affecting, approval required with a two-minute target response
- Class D: irreversible or data-destructive, dual authorization and post-action review
Blast radius limits are configuration, not convention
Every playbook declares maximum affected assets, allowed target scopes, and rate limits per window. A detection error should be able to isolate one workstation, never an availability zone.
Circuit breakers halt execution when the action rate exceeds the historical baseline, which is the cheapest available protection against a detection regression turning into an outage.
Metrics that govern the catalog
Track precision, time saved per execution, reversal rate and business impact incidents per playbook. Promotion, constraint and retirement decisions are made monthly from those four numbers, not from author preference.
- Precision on trailing 30 days, per playbook, published
- Reversal rate above threshold triggers automatic demotion
- Time saved measured against the manual baseline it replaced
