AI governance frameworks: where execution proof fits

A framework describes how decisions should be made. Whether a particular decision was made that way is a different question, and it is answered by a different artefact.

AI governance frameworks are how an organisation writes down the way decisions involving AI will be made: which uses are permitted, who is accountable, what has to be reviewed before a system goes live, and what has to be recorded once it is running. They are governance in the ordinary sense — structure, roles, obligations, escalation.

Almost all of that structure sits either side of the decision itself. Before it: risk classification, impact assessment, model documentation, sign-off. After it: logs, monitoring, incident review, periodic audit. Both halves are real work, and a serious programme needs both.

The moment a consequential decision actually executes is the one point where a framework's commitments have to be true at the same time — the policy that applied, the context that was supplied, the outcome that followed. It is also the point at which, in most organisations, nothing is written down in a form an outside party can check. This page is about that moment, and about the kind of artefact it takes to account for it.

What a framework has to account for

Every commitment in a framework eventually resolves to the same request, made by someone outside the team that wrote it: show me that this happened, on this decision, on this date.

Answering it usually means assembling material after the fact, from systems that were not built to answer it. The result can be a convincing account. What it cannot be is an account the person asking can check without trusting the party that assembled it — and not having to take that on trust is the reason they are asking.

The policy in force is rarely recorded with the decisionPolicies are versioned in one system and decisions are recorded in another. Joining them afterwards is an inference about which version applied, not a record of it.
Logs describe system behaviour, not governanceA log line shows that a code path ran. It does not carry the rule that authorised the outcome, or the material that was relied on to reach it.
Explanations are generated when the question is askedAn explanation produced on request describes how a model behaves now. It is not a record of what was in force then, and the two can differ without anyone noticing.
Approval records govern classes of decisions, not individual onesSign-off establishes that a use was permitted. It does not establish which policy version a specific decision was measured against.
Where decisions are automated, volume outruns reviewSampling and periodic review scale with reviewer time. The number of decisions does not, and the difference between the two is where the unevidenced cases sit.

Where execution proof fits

MeshQu produces one artefact, at one moment: the moment a governed decision executes.

A Decision Receipt is a signed, replayable record of how a consequential decision was made, created at the moment it happens and independently verifiable afterwards. It records the policy in force, relevant decision context, the outcome and the integrity information needed to determine later whether the signed record has changed.

That is deliberately narrow. It does not describe how decisions should be made — a framework does that, and this artefact does not replace one. It is evidence that a particular decision was made the way the framework says, produced as the decision executes rather than reconstructed afterwards, and checkable by a third party. That is what execution proof means here, and it is where MeshQu sits: the execution-proof layer of AI governance.

The policy in force is frozen at decision time and bound into the recordA snapshot of the policy that applied is taken as the decision is evaluated, and its digest is bound into the receipt's integrity hash. The decision and the rule it was measured against cannot drift apart afterwards.Receipt Reference §3 (Policy Snapshot), §14 (what is and is not bound)
The record verifies offline, without contacting MeshQuIntegrity and signature checks run against key material supplied to the verifier, never against a value carried inside the receipt.Receipt Reference §15 — offline integrity and signature verification, Implemented
The decision can be re-evaluated against the snapshot it was made underReplay re-runs the recorded context against the frozen policy snapshot: the same inputs and the same snapshot produce the same result.Receipt Reference §15 — snapshot replay, Implemented
The proof is portable, and it reports its parts separatelyA self-contained verification bundle carries what a third party needs in order to check the decision. A bundle verification reports ten sub-claims individually rather than collapsing them into one pass or fail, and material that is absent is reported as not applicable rather than as a soft pass.Receipt Reference §10 (Verification Bundle), §15; DEMO_VERIFICATION_BUNDLE in src/lib/fixtures
Evidence is bound by reference, not heldThe receipt binds digests of the evidence relied on, and custodian signatures over them where an external system supplies one. The evidence content stays where it lives; MeshQu does not store it.Receipt Reference §5 (Evidence Manifest), §17 trap 1
Records can be anchored to a public transparency logAn anchored receipt is verifiable offline against a pinned log key, without contacting the log.Receipt Reference §6 (Transparency Anchor), §15 — Rekor anchoring and offline SET verification, both Implemented

What this does not prove

The paper this page routes into states six limitations of its own. A page like this one has no business presenting a cleaner picture than the argument it is built on, so the limits that bear on a framework programme are here rather than at the end of a PDF.

Verification proves issuance and integrity. It never proves the decision was correct.A passing check says the record was issued under a known key and has not changed since. It says nothing about whether the policy was right, the inputs were true, or the outcome was the one that should have been reached. Correctness stays a separate question, for policy validation and model risk management.
A valid signature alone does not detect an editThe signature covers the integrity hash rather than the content, and the integrity hash is what binds the content. It is the two checks together that make tampering evident.
MeshQu does not authenticate the actorThe schema records whether a decision was taken by a human or by an automated system. Who or what acted is context the integrator supplies; the receipt records that it was supplied, not that it was true.
Signing establishes non-repudiation, not honestyAn organisation holding its own signing key can sign whatever it chooses to sign. Receipts become load-bearing through the obligation to emit one for every decision in scope, and through external anchoring — both governance choices rather than properties of the artefact.
Not every decision warrants a receiptLow-stakes, reversible, uncontested decisions do not warrant the cost of signing and storage. The artefact is for decisions that can be challenged.
A receipt is itself sensitive materialA signed record of a consequential decision about a person is regulated personal data. Storage, access control and retention still have to be engineered; receipts constrain what is captured, they do not remove the privacy surface.
Live inclusion-proof verification against a co-signed witness is not implementedOffline verification against a pinned log key is. Nothing on this page is described as available unless the Receipt Reference status matrix lists it as Implemented.

The authoritative source

The white paper owns the argument this page introduces: why governance sits before the decision and after it, why the leading candidates cannot reach the moment of execution by construction, and what a decision-level artefact would have to be. It carries the DOI, the survey evidence and the six limitations. This page is the way in; the paper is the case.

Read The Decision Proof Gap

Elsewhere on this site

Explainability Is Not Proof
AI explainability tools — SHAP, feature importance, local explanations — describe how a model behaved. They do not prove the decision was right at the time.
The Problem Isn't Policy. It's Proof.
Tier-one banks do not lack AI policy. They lack the ability to prove a single decision when an FCA letter arrives eight months later. Governance is tested one decision at a time.

Next step

If you are writing or reviewing a framework and the execution-time evidence question is the one you cannot answer, that is the conversation worth having.

Start a conversation

Availability

MeshQu is currently available for research, evaluation and design-partner deployments. Production availability and support commitments are agreed per engagement.