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 describe how decisions should be made. Execution proof is the separate artefact that shows a particular decision was made that way — produced as it executes, and checkable by someone who was not there.
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.
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 decision
Policies 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 governance
A 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 asked
An 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 ones
Sign-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 review
Sampling 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.
MeshQu evaluates a decision against the ratified policy that applies and records the outcome with the supplied context.
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.
It does not prove that the inputs were true, that the decision was correct or that the action was carried out.
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.
MeshQu is currently available for research, evaluation and design-partner deployments. Production availability and support commitments are agreed per engagement.
The policy in force is frozen at decision time and bound into the record
A 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 MeshQu
Integrity 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 under
Replay 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 separately
Where export is enabled for your deployment, a self-contained verification bundle carries the receipt, policy snapshot and material needed for an offline check with separately trusted keys. 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 held
The 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 log
An 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
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 edit
The 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 actor
The 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 honesty
An 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 receipt
Low-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 material
A 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 implemented
Offline 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 product noun in full — the fields, the bundle format and its ten sub-claims. This page introduces it; that page owns it.
Decision assurance — what an offline verifier proves today (opens in a new tab)
The assurance ladder, the trust roots it rests on, and what still requires trusting MeshQu.
Verifying offline (opens in a new tab)
The two-step integrity and signature check, and what each step settles.
Actor attribution (opens in a new tab)
The human-or-automated schema field, and the trust model around an identity the integrator supplies.
Run a verification against a receipt you were handed (opens in a new tab)
The verifier that trusts production keys. The walkthrough on this site runs against demo trust roots.
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.
3 records
Category
Category
AI explainability shows how a model behaved. It does not show which policy, threshold and model version were in force when the decision was…
A UK retail bank does not lack AI policy. It lacks decision proof for one cleared payment when an FCA review picks it out of a sample eight…
