Authority as a time-bound system
Authority is not a static property of identity. It is a time-bound claim that must remain replayable if it is to be trusted.
Most systems treat authority as static. A user has a role, the role has permissions, the action is allowed. The question that actually matters is different: did this actor have the authority to perform this action at this exact point in time?
That question introduces a distinction most architectures never make: between current authority and historical authority. Confuse them and the system keeps working after the authority behind it has already lapsed.
At this moment
Permitted
—
Denied
—
Authority is not a label attached to a person. It is a validity window attached to a claim.
Carbon markets make this failure particularly visible. Authorisation of credits involves bounded approvals, delegated signing rights, multi-party verification, and audit obligations that stretch across jurisdictions and time. The actors change. The windows close. The records must survive scrutiny months or years after the fact.
That makes carbon a useful proving ground. But the underlying problem is not specific to carbon. It appears anywhere approvals, delegated rights, audit obligations, or regulated actions depend on who was entitled to act at a given moment. Financial settlement. Clinical trials. Procurement. Supply chain attestation. Government licensing. The domain changes. The failure mode does not.
Where real systems fail quietly
Not through dramatic compromise. Through ordinary continuation.
Here is one way it happens. A programme director delegates signing authority to a regional approver on 11 May. The delegation window closes on the 18th. On the 17th, the approver submits a budget approval. Valid. Two days later, a countersignature is submitted against that same approval. The delegation expired sixteen hours earlier. No replacement grant was issued.
The countersignature is recorded. The process moves forward. The funds are released. Three months later, an external audit asks for the authority chain behind the release. It does not exist. The delegation had lapsed. The countersignature was recorded under authority that had already expired. Nobody noticed because the system never checked.
That is not an edge case. That is the default failure mode of every system that treats authority as static. The gap between recorded action and valid authority is where trust rots — not through breach, but through continuation under stale legitimacy.
Event Stream
Authority State
The event happened. That does not mean it was valid.
Treating authority as a time-bound system changes what the model must represent. A grant is not a relationship between two parties. It is a claim with a beginning, often with an end, sometimes with conditions, and sometimes with dependency on another grant above it.
Once you model that honestly, the old permission model looks naive. It assumes stability where the real world contains turnover, substitution, emergency access, temporary delegation, absence, expiry, and exception.
Static permission systems are clean because they ignore the thing that makes them hard.
Time.
Authority is not owned in isolation. It is inherited through chains that can expire.
Authority is about accountability
When someone acts in a serious system, you need to know four things.
Who acted.
What they did.
When they did it.
Why they were entitled to do it then.
Most systems can answer the first three after some effort. The fourth is where they become evasive.
Sometimes because the answer is buried in emails. Sometimes because someone updated a group after the fact and the historical state is gone. Sometimes because the system was never designed to preserve the authority context of the action at all.
That is not a minor omission. That is the difference between enforceable process and theatre. If the authority state at the time of action cannot be replayed, then what you have is not evidence. It is a retrospective guess dressed as a record.
That may be enough for an internal dashboard.
It is not enough for regulation.
It is not enough for dispute.
It is not enough for trust between parties who do not already know each other.
Action
Release funds for Project A
Authority worth trusting must be replayable at the moment it mattered.
What this demands from the architecture
Without the following properties, the system is not preserving authority. It is reconstructing it after the fact. And reconstruction is not evidence. It is a retrospective guess that changes depending on when you ask.
Authority must be versioned over time.
Delegation must be explicit, not implied.
Expiry must be a native condition, not a manual cleanup.
Revocation must be traceable.
Historical validity must be queryable at any past moment.
Actions that depend on authority must carry a reference to the authority state that made them valid at the time they were taken. Without that binding, the same action can look valid today and invalid tomorrow. That is not a trustworthy record. That is a moving interpretation.
Which brings the earlier distinction into sharp focus. A serious system must answer two separate questions.
Current authority: can this actor act now?
Historical authority: was this actor entitled to act then?
Confuse those two and your audit trail is not a proof. It is a story that changes depending on when you read it.
Current authority
Temporary Approver
Delegation window closed. No active grant.
Historical authority at 21 May, 09:17
Temporary Approver
Delegation active. Full chain to board authority intact.
The same actor. Two different truths. Both correct.
Current validity and historical validity are not the same question.
The shortcut is always the same. Treat authority as static. Patch the exceptions later. Hope the process holds.
It does not.
If your system cannot answer whether someone was entitled to act at the exact moment they acted, then it does not model authority. It simulates it.
Carbon makes this failure easy to see because the actors, windows, and audit obligations are explicit. But the same structural problem appears wherever authority, money, risk, approvals, compliance, or machine actions depend on who was entitled to act at a specific moment. The domain changes. The failure does not.
In production
Authority Trail — Provable authority for carbon markets
These principles are not theoretical. Authority Trail implements time-bound authority chains, delegation windows, and replayable verification for carbon credit authorisation.
Facing these design challenges in your own systems?
Continue the discussion