Approval Is Not Execution Eligibility
Why an approved action can stop being the action that was approved
An approval captures a past decision context. It does not prove that the action remains eligible to execute now.
That single distinction carries more operational weight than it appears to. Most systems treat approval as a durable permission: once granted, the action may run whenever it reaches the execution surface. But approval is a record of a moment — and execution happens in a different moment.
Approval captures a moment
When an action is approved, the approval encodes a decision context at T0: who held authority, what the object of the action was, what conditions surrounded it, what the operating environment looked like. The approval is accurate about that moment. It makes no claim about any later one. Nothing in the approval re-checks the world.
Execution happens later
The value release, the access grant, the deployment, the workflow action — these occur at T+1. Between T0 and T+1, the world does not pause. Authority can be revoked, narrowed, or expire. The state of the referenced object can change. Conditions the approval implicitly relied on — incident status, risk signals, counterparty standing — can shift. The operating environment itself can move.
I wrote earlier that approval is time-bound consent while execution eligibility is current binding. This note takes that one step further: what exactly breaks when the binding fails?
The action can lose its identity
What breaks is not the approval. The approval remains a true record of what was decided. What breaks is the identity of the action.
If the object changes materially, if the authority basis lapses, if the risk class shifts, if a condition the approval depended on no longer holds — then the thing now proposed for execution is no longer the thing that was approved. It has the same label, the same request ID, perhaps the same amount and destination. But it is a different action wearing the approved action’s name.
Seen this way, the execution gap is not a timing inconvenience. It is an identity problem. The question at the execution boundary is not “was this approved?” — the log will always say yes. The question is “is this still the same action that was approved?”
Repair is the wrong instinct
The common fix is repair: route the drifted action back to a human, get a fresh sign-off, proceed. Re-authorization has its place, but as the primary mechanism it reproduces the original flaw. A new approval is another T0 — another snapshot that begins aging the moment it is made. If the structure treats approval as the thing that makes execution legitimate, then every repair just resets the same clock and reopens the same gap.
The deeper issue is not whether someone approves again. It is whether the proposed execution still belongs to the approved action at all. Re-authorization is useful when it evaluates a new action as new. It becomes weak when it is used to preserve the fiction that the old action still holds.
Expiry rather than repair
A cleaner principle: approvals should expire when the action’s identity materially changes.
Small deltas can allow continuation — the binding holds, the action opens. Material deltas should not trigger a patch-and-proceed cycle; they should void the prior approval outright, because the action it authorized no longer exists. What exists is a new action, and a new action requires a new approval basis — evaluated fresh, not inherited.
Expiry is not a punishment for drift. It is an honest acknowledgment that consent was given to something that is no longer on the table.
Re-binding at the execution boundary
The structural consequence: the moment an action becomes executable is a decision point of its own, and it needs its own check. Not a repeat of the approval — a re-binding. At the execution boundary, four things are evaluated against the present:
Current authority — does the actor still hold the permission the approval assumed?
Current state — is the object of the action still in the state the approval assumed?
Current conditions — are the surrounding signals still within the bounds the approval relied on?
Current operating environment — is the system context the action will run in still the one it was approved for?
If the quartet holds, the action opens and it is still, verifiably, the approved action. If any axis has drifted materially, the binding fails — and the outcome is expiry, hold, narrowing, or escalation, each recorded as evidence at the moment of the decision rather than reconstructed after it.
Approval is history. Execution eligibility is current.
Why this matters now
Most AI governance effort concentrates on decisions: model behavior, policy compliance, review processes, audit trails. All necessary. But a growing share of real failures appears somewhere else — at the point where an approved output becomes an executable action, and the world it was approved in has already moved.
Autonomous and semi-autonomous chains have stretched the distance between human approval and machine execution while compressing the time between trigger and effect. In that environment, a system can be fully auditable and still ungoverned at the only moment that matters. The log records what happened. It does not decide whether the action should have opened.
Execution governance sits at that boundary. Its unit of analysis is not the decision and not the model — it is the execution event, and whether that event, now, is still the one that was approved.