On March 3, a bank’s credit risk committee approves version 4 of its consumer lending policy for an automated underwriting system. The approval is minuted. The committee owns that authority; the system applies the rules.
On June 12, after a reorganization, a reconstituted committee supersedes that approval and authorizes version 5, which tightens the debt-to-income ceiling. One service misses the change and keeps evaluating applications against version 4.
Every decision that service makes between June 12 and the day someone notices is signed. Every signature verifies. Every record correctly names version 4 as the policy that decided. Nothing in any individual record is false — and nothing in any individual record tells you those decisions were made under authority that no longer existed.
That scenario is illustrative, but every part of it happens in real institutions. Committees are reconstituted. Delegations expire. Approvals are superseded. Deployments drift.
When an auditor asks whether a decision was authorized, “the signature is valid” answers a different question.
A signature proves the record wasn’t changed. That’s all it proves.
A cryptographic signature on a decision record is strong assurance about one thing: the bytes you are holding are the bytes that were signed. If anyone alters the verdict, the timestamp or the policy version afterward, verification fails.
But a signature is only as meaningful as what the record asserts. If a record says “policy version 4 decided this, under authority granted by the credit risk committee,” the signature proves that assertion was not edited. It does not prove the assertion was true at the moment it was made. The design notes for the verifier we built put it plainly:
Verifying the record’s signature proves the assertion was not altered. It does not, on its own, prove the assertion was true.
For most AI governance evidence today, that gap is invisible, because the record makes no authority assertion at all. It says what the verdict was. Sometimes it says which policy version ran. It almost never says who was entitled to approve that policy, or whether that entitlement was still in force.
Four questions a consequential AI decision should answer
- Did the action satisfy the policy? The verdict, and the rules that produced it.
- Which policy decided, and is the record intact? The exact policy version, bound into the signature so it cannot be swapped afterward.
- Who authorized that policy? The institution or office that owns authority over the rule set, and the person who issued the authorization.
- Was that authorization still in force at the moment of decision? Not revoked, not superseded, not expired, not overdue for reaffirmation — at that instant, not today.
The first question is what most AI governance tooling is built to answer. The second is where serious decision evidence starts. The third and fourth are how institutions already reason about human decisions — and they are the questions an examiner, an internal audit function or opposing counsel will eventually ask about machine ones.
Authority over the rules is institutional, and it changes
Regulated organizations do not let rules approve themselves. Credit policy is approved by a credit committee. A model’s use in a decision process is signed off by a model risk function. Delegation-of-authority matrices say which office may approve what, and up to which limit.
And that authority moves. Committees are reconstituted. Delegations carry expiry dates. Approvals are superseded when a policy is revised. Some authorizations must be reaffirmed on a schedule and lapse if nobody does. Occasionally authority is revoked outright, effective immediately.
Human processes absorb this through minutes, attestations and periodic review. An automated system applying rules thousands of times a day needs the same facts in machine-checkable form — or it will keep executing on authority that ended weeks ago, and produce impeccable evidence while doing it.
What EVE models: the institutional mandate
In EVE, that authority is a first-class record called a mandate. For one tenant and one policy set, a mandate states:
- which institution or office owns the authority, and which principal issued this authorization;
- which policy pack version it authorizes;
- when it takes effect and, if it does, when it ends;
- when it must be reaffirmed to stay current.
Every mandate has a lifecycle status: DRAFT, ACTIVE, SUPERSEDED, REVOKED, EXPIRED or RETIRED. Only ACTIVE can authorize a decision. That is an explicit allow-list rather than a list of forbidden states, so a status added later cannot quietly start authorizing anything.
History is append-only
A mandate is never edited. Revoking it, superseding it, reaffirming it or retiring it each adds a new signed generation that links to the digest of the generation before it. The original authorization is still there, exactly as it was while it was in force; what changes is that a later generation records what happened to it and when.
That structure is what lets the system answer “what was true on June 20?” and not only “what is true now?” It also means two approvers acting at the same moment cannot both extend the chain. Each change is a compare-and-swap against the current head: one succeeds, and the other has to re-read what just happened before it can try again.
The person who drafts a mandate cannot activate it
Separation of duties is enforced by the mandate lifecycle itself: the principal who drafted a mandate is refused when they try to activate it. We deliberately did not rely on role permissions for this. A permission can say what a role may do; it cannot say “but not the same person who proposed it.” Without that rule, anyone holding a role that can both draft and activate could mint self-approved institutional authority.
Current at the moment of decision, not at the moment you ask
A mandate is always resolved as of the decision timestamp. Two rules follow, and both matter in practice:
- Authority cannot be granted retroactively. A generation issued after a decision cannot authorize it, even if it would have.
- A revocation that took effect before a decision defeats it, even if the system making the decision had not yet heard about the revocation.
When a mandate does not authorize a decision, the result carries a specific, stable reason rather than a generic failure:
| Reason | What it means at the decision time |
|---|---|
MANDATE_NOT_FOUND | No mandate authorizes this policy set for this tenant |
MANDATE_NOT_YET_EFFECTIVE | The mandate had not yet taken effect |
MANDATE_EXPIRED | The mandate’s authority had ended |
MANDATE_REVOKED | A revocation had taken effect |
MANDATE_SUPERSEDED | A newer authorization had replaced the one being relied on |
MANDATE_REAFFIRMATION_REQUIRED | The mandate’s reaffirmation was overdue |
MANDATE_POLICY_MISMATCH | The policy pack that ran is not a version the mandate in force authorizes |
Back to the opening example. From June 12, the stale service’s decisions no longer resolve to authorizing mandates: the authority in force covers version 5, and version 4 ran, so each one resolves to MANDATE_POLICY_MISMATCH. With enforcement enabled for that tenant, they would be blocked before execution. In observation mode they would proceed — and every one would carry evidence that the policy it applied was no longer the one authorized.
What goes into the signed decision record
When mandate resolution runs for a decision, its result is written into the decision record as a dedicated block and bound into the signature alongside the verdict. The block identifies the mandate and the exact generation that governed, its status and effective window, the authority owner and issuer, its reaffirmation state, and a digest of the mandate’s resolved state at that instant.
Three design choices are worth calling out.
It contains nothing the caller supplied. The block is built entirely from EVE’s own resolution of the mandate chain. A client cannot assert its way into an authorized result.
It cannot be configured away. Records that carry a mandate block use their own record schema tier, and no deployment-level audit-schema setting removes it. If the gate produced a mandate result, the signature covers it.
“Policy version” means four different things, so it gets four names. Early in this work a single policy_version field meant the governance ruleset fingerprint in one place and the executable policy pack version in another — two unrelated values an auditor had no way to reconcile. The record now separates them:
| Field | Answers |
|---|---|
executed_policy_pack_version | Which policy pack actually evaluated the action? |
authorized_policy_pack_version | Which policy pack version did the mandate authorize? |
policy_pack_version_match | Were those the same? |
governance_ruleset_fingerprint | Which governance ruleset was in force for this decision? |
Checking it without asking EVE
Evidence you can only check by asking the system that produced it is a statement, not evidence. So the mandate claim in a decision record is designed to be verified offline.
For a given decision time, EVE produces a signed mandate state proof: the mandate’s full chain of generations as of that timestamp. Given the decision record, that proof and EVE’s published public key, a verifier with no network access and no dependency on EVE establishes ten facts independently:
- The decision record’s signature is valid.
- The action evidence in it is untampered.
- The record names a specific mandate and version.
- That mandate record is authentic, generation by generation.
- The mandate was effective at the decision time.
- It had not been revoked at that time.
- It had not been superseded at that time.
- Its reaffirmation was current at that time.
- The issuer was named and authorized.
- The policy version that ran was one the mandate authorized.
A record can pass the first two checks and fail the seventh. That combination is exactly the case this exists to catch: an authentic, untampered record of a decision made under authority that had already been replaced.
A detail that decides whether “independent” is true
Offline verification only means something if a verifier written in a different language reaches the same answer. Mandate records are hashed over RFC 8785 JSON canonicalization, and RFC 8785 specifies exactly how numbers must be written: the way ECMAScript’s Number.prototype.toString writes them. Python’s default float formatting disagrees in a few ranges — it writes 1e-06 where the standard requires 0.000001, and 1e+20 where it requires 100000000000000000000.
One differing byte means a different digest, and a different digest means a correct verifier in another language would report a genuine record as tampered. We found that gap while building the verifier, replaced the formatting with the ECMAScript algorithm itself, and pinned both the service and the standalone verification code to the same RFC 8785 test vectors.
Turning it on without breaking every tenant
A mandatory mandate requirement has an obvious failure mode: on the day it ships, no tenant has a mandate yet, so every decision would fail. So the gate is staged, and it is staged per tenant:
| Mode | What happens |
|---|---|
| Off | The default. Nothing is resolved and nothing is recorded. |
| Shadow | The mandate is resolved and its result is bound into the signed record, but an invalid mandate never changes the outcome. |
| Compare | Shadow, plus an explicit record whenever the mandate gate would have changed the outcome — the signal an operator needs before enforcing. |
| Enforce | An invalid mandate blocks. So does being unable to determine mandate state: a store outage produces a signed block, not a silent pass. |
Enforcement cannot be switched on for everyone with a single setting. It requires both the enforcement mode and an explicit list of enrolled tenants — and that list scopes the whole ladder, so observing one tenant leaves every other tenant off. A kill switch disarms the gate with a configuration change — no code change or rebuild.
Where this stands
Institutional mandate currency is enforced in production on the CoreGuard decision path — including the /v1/decisions/evaluate API — for enrolled tenants: a decision whose governing policy has no mandate current at the decision time is blocked before execution, with a signed record naming the reason. Enrollment is per tenant, and the capability ships off by default for any deployment that has not enabled it. It does not yet cover EVE’s agent tool-execution or MCP authorization paths. A decision record makes a mandate claim only when mandate resolution ran for it; a record without the mandate block makes no authority claim.
Where EVE fits
EVE CoreGuard evaluates a proposed AI action against deterministic, versioned policy before it executes and returns an explicit disposition. EVE Proof makes that decision verifiable afterward. Mandate currency extends the same record from what was decided, under which rules to who was entitled to set those rules — and whether they still were.
That last question tends to get asked late: in an exam, an audit or a dispute, when the only thing left to consult is the record.
Inspect a real signed decision certificate and verify it offline at the verification portal, or read the evidence architecture at EVE Proof. If you run AI decisions under committee-approved or delegated policy and want to see what mandate evidence would show on your own traffic, talk to us about a shadow evaluation.
Frequently asked questions
What is mandate currency?
Mandate currency is whether the institutional authority behind an AI decision’s rules was still in force at the exact moment the decision was made — not revoked, superseded, expired or overdue for reaffirmation. A valid signature proves a record is intact; mandate currency is what shows the rules it applied were still authorized.
How is this different from policy versioning?
Policy versioning records which rules ran. It says nothing about whether anyone was still entitled to approve those rules. A decision can be correctly signed and correctly versioned and still have been made under an approval that was superseded the week before.
How is this different from revoking an AI agent’s permissions?
Revoking a permission stops an actor from reaching a system, and its hard problem is the seconds between a check and the use it authorizes. Mandate currency concerns the authority behind the policy a decision applied, which usually changes over weeks or months — and it has to be provable after the fact, as of the decision time.
Can an auditor verify a mandate claim without trusting EVE?
That is the design goal. With the decision record, a signed mandate state proof for the decision time and EVE’s published public key, a verifier can recompute every check offline — including whether the mandate had been revoked or superseded at that moment — with no network access.
Does enabling mandates block existing traffic?
For an enrolled tenant in enforce mode, yes — that is the point: a decision without a current mandate is blocked, fail-closed. Enrollment is explicit and per tenant, and the gate can be staged before it enforces: shadow records the mandate result without affecting outcomes, and compare flags each decision the gate would have changed, so a tenant can confirm every policy set has a mandate first. A kill switch disarms the gate with a configuration change — no code change or rebuild.
What happens if mandate state can’t be determined?
In enforce mode the decision fails closed: it is blocked with a signed record carrying the reason MANDATE_STORE_UNAVAILABLE. In shadow or compare mode the outcome is unaffected and the unavailability is recorded.