The Approval Outlives the Approver

The moment

A withdrawal is approved on Tuesday by two authorized officers. It is scheduled to release on Thursday.

On Wednesday, one of the approvers is offboarded. Access revoked, account suspended, credentials invalidated — the organization does everything right, and does it promptly.

On Thursday, the release opens anyway.

Nothing malfunctioned. The release system asked the only question it was built to ask — was this approved? — and the answer was yes. The approval record is real, complete, and correctly signed. It is also a record of an authority that no longer exists.

Why the approval record cannot catch this

An approval captures who held authority at the moment of signing. It does not subscribe to that authority's future. When the approver's status changes, nothing reaches back into the approval record to amend it — and nothing should. The record is history, and history is allowed to stand.

The failure is not in the record. It is in the assumption that the record answers a present-tense question. "Was this approved" and "does the authority behind this approval still hold" are different questions, evaluated against different objects at different times. Most release systems only ask the first.

What actually drifts

Authority drift is not exotic. It is produced routinely by ordinary operations:

An approver leaves the company between approval and release. A role change narrows someone's signing scope. A credential is rotated or suspended during a security review. A delegation expires. A dual-control pair is broken because one of the two signers is no longer valid — while the other remains, and the record shows both signatures.

Every one of these is invisible to a system that treats approval as a durable permission. And the longer the gap between approval and release — batch schedules, settlement windows, compliance holds — the more room the drift has.

What re-binding checks at the release moment

The structural answer is not a better approval. It is a second evaluation, performed when the release actually opens, against the world as it is at that moment.

For authority specifically, the check is direct: at the release moment, re-verify the current standing of every authority the approval relies on — not just the requester, but each approver in the chain. If the action required two approvers, both must still be valid now. One lapsed credential breaks the execution binding, even if the historical approval remains intact.

In our reference implementation, this check is bound to the external withdrawal release path. If either approver's credential is no longer valid at release time, the release does not open: the system refuses before execution, preserves the withdrawal state un-executed, and records the refusal — at the moment of the decision — with the evidence that justified it. Note what is being judged here: the execution event, not the person. The question is never whether the departed approver was trustworthy. The question is whether this specific release still carries valid authority at the moment it opens.

What the evidence must show afterward

When a regulator or an internal review asks why a release did or did not open, the answer cannot be reconstructed from an approval trail alone — the trail only proves the past. What the review needs is a record of the present-tense decision: what the authority state was at the release moment, which check failed or held, and what outcome followed.

That record has to be generated when the decision is made, not assembled afterward. Evidence reconstructed after an incident inherits every ambiguity the incident created.

The question for your stack

Take your highest-value release path and ask one question of it: if an approver's credential is invalidated one hour before a scheduled release, does anything in the path notice?

If the honest answer is no — the approval record would carry the release through — then the gap is structural, not procedural. More approvals will not close it. A re-binding check at the release moment will.