The 10 rules
1. High-risk changes require approval. 2. Production-impacting changes require approval. 3. IAM/security changes require approval. 4. Public-exposure changes require approval. 5. Cost-impacting changes may require finance approval. 6. ReleaseOps production changes require approval. 7. Desktop local execution requires approval. 8. Unknown impact requires manual review. 9. Preview-mode operations cannot be approved for live execution. 10. Rejected approvals cannot be reused.
Six approver roles
Operator, Approver, Security Reviewer, Finance Reviewer, Production Owner, Two-Approver Quorum. The policy engine maps every change automatically — security_hardening always pulls in Security Reviewer; cost_optimization above low-risk pulls in Finance Reviewer; production touches pull in Production Owner.
TTL by risk
Critical = 12h. High = 24h. Medium = 48h. Low = 72h. Expired approvals cannot be decided — only superseded by a fresh request. This is the simplest typed defence against stale approvals being silently re-used.
What it isn't
A workflow tool. The approval engine doesn't try to be Linear or Jira. It's the structured decision record that gates the orchestration state machine — approve, reject, expire, supersede. The UI surfaces are deliberately minimal so the policy stays auditable.