Approval Gate Timeout and Auto-Revoke Design Prompt

You are a senior platform engineer who has seen an approved-but-not-yet-run action execute hours later against a situation that had completely changed.

I will provide:
- The automation the gate protects and how the approval is requested/granted
- Who approves, through what channel, and how a decision is recorded
- How long the action stays valid after approval, and what can change in that window
- What happens today when no one responds

Your job:

1. **Pending timeout** — define how long a request waits for a human before it auto-escalates or auto-denies, so a forgotten request for [ACTION] doesn't block or silently leak.
2. **Approval expiry** — give a granted approval a TTL, after which the action must be re-approved; justify the window against how fast the underlying state changes.
3. **Re-validation at execution** — require the automation to re-check preconditions at run time (not just at approval time), so an approval granted against old facts doesn't fire against new ones.
4. **Auto-revoke triggers** — revoke a pending or granted approval when a relevant condition flips (new deploy, incident declared, freeze window), cancelling the action.
5. **Default-safe on timeout** — choose deny-on-timeout for destructive actions and justify any case where allow-on-timeout is acceptable.
6. **Audit and notification** — record every grant, expiry, revoke, and timeout with who/what/when, and notify the requester on each transition.

Output as: a state machine for the approval lifecycle, a timeout/expiry config table per action class, and the execution-time re-validation checklist.

Default destructive actions to deny-on-timeout and re-validate preconditions immediately before execution; the dangerous case isn't the approval that's denied, it's the stale 'yes' that fires against a world that moved on.

Why this prompt works

Approval gates are usually built around the moment of decision — request, notify, click approve — and stop thinking right there. The prompt’s contribution is to treat the approval as a perishable artifact rather than a permanent fact. An approval is a snapshot of a human’s judgment against the state of the world at one instant. The danger isn’t the request that gets denied; it’s the stale “yes” that fires hours later against a world that moved on — a teardown approved before an incident was declared, a deploy approved before a freeze began. By demanding an explicit TTL on granted approvals and re-validation of preconditions at execution time, the prompt makes the gate check current reality, not a remembered one.

The timeout behavior is where the prompt enforces safe defaults that teams routinely get backwards. A forgotten approval request must resolve to something, and for destructive actions that something has to be deny-on-timeout. Allow-on-timeout means inattention silently authorizes the very action the gate exists to guard — the gate becomes a delay, not a control. The prompt forces this to be a conscious, justified choice per action class rather than an accidental default inherited from whatever framework is in use.

Auto-revoke triggers complete the picture by letting external events invalidate an in-flight approval. When a new deploy lands or a freeze window opens, any pending or granted approval tied to the old context should be revoked, not left armed. The model can draft the lifecycle state machine and config table quickly, but you verify the load-bearing case: confirm that an approval granted, then left to age past its TTL or across a state change, is actually re-validated and refused at execution. That’s the test that proves the gate guards the action, not merely the click.