Why Approvals Age
A decision that was valid when someone approved it is not automatically valid when consequences run.
Most teams assume: approval happened, therefore execution is safe. In practice, authority changes, policies change, and context changes. A valid decision earlier is not automatically valid now — continuation requires fresh authorization at consequence time.
The assumption everyone makes
When a human approves an invoice, a refund, or an agent action, organizations treat that moment as closure. The workflow moves on. The automation resumes. The payment runs. The record updates.
The implicit contract is simple: someone with authority said yes, so the downstream system can proceed indefinitely — or at least until someone explicitly cancels.
That contract breaks the moment execution is separated from approval by time, retries, or changed circumstances.
What actually changes
Between approval and consequence, real systems encounter:
- Queue delays and orchestrator retries
- Revoked roles, expired delegations, or updated policy versions
- Changed balances, entitlements, or client status
- Compensation events that require a new authorization boundary
- Human pauses that resume hours or days later
None of these invalidate the fact that approval occurred. They do invalidate the assumption that approval alone is still sufficient permission.
Governance vs continuity
Governance answers: what was approved, by whom, under which policy, at what time. That record matters for audit and accountability.
Authorization continuity answers a different question: is this action still authorized when consequences occur?
An approval is evidence of a past decision. It is not, by itself, proof that execution remains authorized now.
What continuation requires
Teams that take continuity seriously treat execution as its own governance moment — especially on retries, resumes, and compensation paths. Before a consequence binds, they ask whether authority still holds under current policy and context.
That does not mean re-approving every trivial action. It means recognizing that time, retries, and changed context are not neutral — they are governance events.
The practical lesson: design automations so continuation is explicit, not assumed. If your workflow can pause, retry, or resume, your authorization model must survive that gap — not pretend the gap never happened.
Questions worth asking your team
- What can change between our approval step and our consequence step?
- Do retries reuse the original approval without checking current authority?
- When a workflow resumes after a human pause, do we treat that as a new authorization boundary?
- Can we explain to a client why an action ran — or did not run — at execution time, not only at approval time?
FAQ
What does it mean for an approval to age?
An approval ages when the authority, policy, or operational context that made the decision valid at approval time no longer holds at execution time.
Why is approval alone not enough for safe execution?
Approval captures intent at a point in time. Execution happens later. Treating an earlier approval as permanent permission skips whether the action is still authorized now.
What is authorization continuity?
Checking whether an action remains authorized when consequences occur — not only when someone first approved it.
Authorization Continuity Lessons · Week 1 of 6
Next in the series: why retries are governance events — not infrastructure noise.
Explore governance resources