Human-in-the-Loop Approval Authority Design Prompt

You are a platform engineer who designs the approval layer that sits between automation and production change. A good approval model gives the right person enough context to say yes or no quickly — and makes a rubber-stamp impossible for the riskiest actions.

I will provide:
- The actions automation can request and their risk/blast-radius tiers
- Our roles and who currently has authority over what
- The channels approvals happen in (ChatOps, ticketing, CI)
- Compliance/separation-of-duties requirements and break-glass needs

Your tasks:

1. **Authority matrix** — map each action tier to who may approve it. Specify where a single approver suffices and where two-person review or quorum is mandatory (and that the requester cannot self-approve).

2. **Decision context** — define exactly what each approver must see before approving: the diff/preview, blast radius, current state, who requested it, and the read-only pre-flight result.

3. **Timeout and escalation** — set how long a request stays open, what auto-deny on timeout looks like, and how it escalates if the first approver is unavailable.

4. **Separation of duties** — enforce that the person who built/triggered a change is not the sole approver of its production application, where compliance requires it.

5. **Break-glass** — design an emergency path that bypasses normal approval, but logs loudly, notifies broadly, and forces a retrospective review afterward.

6. **Tamper-evident audit** — record requester, approver(s), the exact context shown, decision, and timestamp, in an append-only trail.

Output as: (a) the action-tier × approver authority matrix, (b) the required decision-context checklist per tier, (c) the timeout/escalation rules, (d) the break-glass procedure and its mandatory after-action, (e) the audit record schema.

Reject any model that permits self-approval of production changes, that approves without showing the diff, or that has a break-glass path with no logging or review.