Approval Is Time-Bound Consent
Why execution eligibility must be re-bound to the current state
In many systems, approval is treated as governance.
When an action is approved — by a person, by a policy engine, by a workflow tool — the approval is filed, timestamped, and accepted as the governance artifact for that action. If the action later goes wrong, the first question asked is usually “was it approved.” If the answer is yes, the audit narrative considers the governance layer satisfied.
This is a category error. Approval is not the governance layer. Approval is a record of consent at a moment in time. The governance question is whether that consent still binds the present state when the action actually opens.
This essay is the second entry in FO Lens. The first entry fixed the unit of governance as executable exposure. This entry fixes the temporal property of approval.
Approval has a timestamp. Execution has a present.
Every approval carries a time. The approval was given at 10:14. The action executes at 10:47. Between those two moments, the world does not pause.
In thirty-three minutes, authority can be revoked. A signing officer can lose access. A counterparty can be flagged. A system can enter maintenance mode. A regulatory condition can change. A dependency that was healthy can fail. A target balance can move. A policy can be updated. None of these changes will retroactively erase the 10:14 approval. The approval remains a valid record. But it was a record of a state that no longer exists.
When the action opens at 10:47, the governance question is not “did the approval happen.” The governance question is “does the approval still describe the present.”
Most current systems answer the first question. Very few answer the second.
Why this is not a documentation problem
It is tempting to treat the gap between approval and execution as a paperwork issue — something that better logging, better policy versioning, or more granular timestamps could close. It cannot. The gap is not informational. It is structural.
The structural reason is simple. An approval is a statement about a request. An execution is a statement about the world. These two statements are evaluated against different objects. The request is fixed; the world is not.
A documentation upgrade can make the approval trail more legible. It cannot make the approval re-bind itself to a state it never observed.
The only thing that can re-bind approval to current state is a second evaluation — performed at the moment of execution, against the world as it is at that moment, not as it was when the request was filed.
This second evaluation is what execution eligibility means.
Three properties that approval does not carry forward
When an approval is filed at 10:14, three properties are captured in that approval: the authority that granted it, the state assumed by the request, and the conditions believed to be in effect.
By 10:47, none of these properties are guaranteed to still be true.
Authority is not carried forward by the approval. The authority that granted the approval exists at the moment of granting. Its continued existence at the moment of execution must be verified separately. An approver who was authorized at 10:14 may not be authorized at 10:47. The approval does not know this.
State is not carried forward by the approval. The state of the target system at 10:14 was the implicit basis of the approval — but the approval does not store that state. It stores the decision, not the conditions under which the decision was made. By 10:47, the system may have moved. The approval does not move with it.
Conditions are not carried forward by the approval. The surrounding operational conditions — timing windows, dependency health, policy versions, escalation triggers — were aligned at 10:14. The approval did not capture which alignments mattered. At 10:47, any of them may have drifted.
Approval, in other words, is a snapshot. Execution requires a live signal.
What execution eligibility actually requires
Execution eligibility is not a more rigorous approval. It is a different artifact, evaluated at a different moment, against a different question.
At the moment execution opens, the system must determine whether the action is still admissible — not whether it was admissible at the time of approval, but whether it is admissible now. This determination requires:
A check that the requesting authority is still in force at the moment of execution. A check that the target state still matches the assumptions of the request. A check that the surrounding conditions are still aligned with what the action depends on. A check that the approval itself has not expired, been narrowed, or been superseded.
If any of these checks fail, the action does not open — regardless of how valid the original approval remains as a record.
This is what it means for execution eligibility to be current binding. The binding is not to a past decision. The binding is to a present condition.
Why the distinction matters more now
The distinction between time-bound consent and current binding has always existed in safety-critical operations. In railway operations, a dispatch order alone is not the same as a live permission to proceed. At the moment a signal opens, the route must still be checked against present conditions such as track occupancy, switch position, and route conflicts. The dispatch order is consent. The interlocking is current binding.
What is new is that the same gap is now opening across systems that were never designed with this distinction in mind. AI agents take action on the basis of historical permissions. Workflow tools execute approved tasks against state that may have changed. Automated pipelines treat policy snapshots as if they were policy guarantees.
In each case, the approval is real. The approval is not the problem. The problem is the assumption that approval is sufficient — that consent given at one moment binds an action that opens at another.
The cost of that assumption used to be limited by the slowness of execution. Humans in the loop introduced delay, and delay allowed drift to be noticed. As systems automate the path from approval to execution, that delay disappears. The drift remains. What changes is whether anything is positioned to catch it.
Closing
Approval is a real artifact. It captures consent, accountability, and intention. It belongs in the audit trail. It belongs in the regulatory record. It belongs in the governance story.
But it does not belong in the role it is currently asked to play.
Approval is being asked to govern execution. It cannot. Approval is time-bound consent. Execution eligibility is current binding. These are two different artifacts, evaluated at two different moments, against two different objects.
Governance that conflates them is governance that mistakes a record of the past for a guarantee of the present.
A valid approval is not a valid execution. The world between them is what makes the difference.