Most of a governance stack records what was decided about a system. This is about the record of a decision itself — written as it executes, and checkable by someone outside the organisation that wrote it.
AI governance platforms record how AI systems are governed. Execution proof is a separate artefact, produced as a governed decision executes and checkable by a third party who has no account on your systems.
From the MeshQu knowledge base
What is in a Decision Receipt, and what does it prove?
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.
Machine-readableAI governance platforms are how an organisation runs its AI programme: an inventory of systems, risk classification, control libraries, review and approval workflow, monitoring, and the reporting that comes out of the far end. An evaluation usually compares coverage, workflow fit, and how much of the reporting arrives without someone assembling it by hand.
They share one property that rarely appears on a comparison grid. What they hold is a record about a system, a control or a period, and most of it is gathered on a cycle — before something goes live, or after a period closes. That is the right shape for governing a programme. It is a different shape from evidence about one decision, on one date, that someone outside the organisation can check for themselves.
MeshQu is not one of these platforms, and this page is not an argument for swapping one out. It does one thing at one point in the path: the moment a governed decision executes. What follows is what that produces, what is implemented today, and what it does not do — so an evaluation can put it in the right box quickly, including the box marked not now.
Most of an evaluation is about fit: does it cover our systems, does it match how we already work, how much of the reporting comes out on its own. Those questions have good answers in this category, and comparing them is well-trodden work.
One question tends to be left until a challenge actually arrives, and it is the question this page is about. When someone outside the organisation disputes a specific decision — not the programme, the decision — what can you hand them, and can they check it without taking your word for anything?
Whether the person asking can check it without trusting you
A report is only as good as the party that produced it. If checking it means logging into your system or accepting your export, the check and the claim have the same author.
Which rule was actually applied, on that decision
Approvals and control libraries establish what was permitted for a class of use. They rarely establish which version of a ruleset a specific decision was measured against — that is usually inferred afterwards, from two systems that were versioned separately.
Whether the record was written at the time or assembled later
Material gathered when the question is asked can be accurate and still not be the same artefact as a record written as the decision executed. The difference is what a dispute turns on.
What you can hand to someone who has no account with you
Auditors, counterparties and counsel do not get a seat in your console. Whatever they receive has to stand up away from your infrastructure, on its own.
Who becomes the custodian of the underlying material
A tool that ingests the case file inherits its retention, access and privacy obligations. That is a real cost of adopting one, and it belongs in the comparison rather than in the implementation.
A page written to be evaluated has every incentive to keep this block short. It is here in full for the same reason the research pages carry a limitations section: an evaluator who finds a limit later, on their own, has learned something worse than the limit.
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.
This does not run a governance programme, and does not replace one
System inventory, risk classification, impact assessment, review workflow, monitoring and reporting are work a programme still does, and none of it is what this artefact is. If those are the gaps in your stack, this is not the thing that fills them.
Independent trust is a property of a deployment, not a feature to switch on
The top of the assurance ladder is reached through how trust roots are distributed and how signing keys are governed — arrangements agreed per engagement rather than anything the artefact carries. The counterpart below has the ladder in full.
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.
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.
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.
MeshQu sits underneath whatever you already run, at the point a decision is evaluated. It is called with the context of the decision and the policy that applies, and it returns an outcome and a record.
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.
The record is the deliverable, and it travels. A third party checks it with a verifier and published keys rather than an account on your systems, which is where most of an evaluation's harder questions end up. That is what execution proof means here, and it is where MeshQu sits: the execution-proof layer of AI governance.
Every line below is listed as Implemented in the Receipt Reference status matrix, and each carries that matrix's own public-claim guidance beside it.
MeshQu is currently available for research, evaluation and design-partner deployments. Production availability and support commitments are agreed per engagement.
signing
The public half of the signing key is published, so a verifier resolves it out of band rather than trusting a value carried inside the record it is checking.
offline-verification
Integrity and signature checks run where the recipient is. No call to MeshQu, no account on your systems, and no vendor in the loop at the moment something is being scrutinised.
snapshot-replay
The ruleset that applied is frozen as the decision is evaluated and bound into the record, so the decision can be re-run against it: the same inputs and the same snapshot produce the same result.
verification-bundle
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 a single pass or fail, and material that is absent is reported as not applicable rather than as a soft pass.
evidence-manifest
The material relied on is bound by digest, with custodian signatures where an external system supplies them. The content itself stays in the system that holds it, which keeps the custody question out of the adoption decision.
approval-lineage
Which policy version was ratified, and that the rules evaluated are the ones that version carried. The ratifier's keys reach the verifier separately, which is what keeps that check independent of whoever operates the system.
chain-seal
Where decisions form a sequence, a seal lets a reviewer establish that the set they were given is the whole set rather than a favourable selection from it.
rekor-anchoring
An anchor places the record in a public transparency log, which puts the existence of the record outside your own infrastructure and outside your control.
offline-set-verification
The anchor is checked against a pinned log key. A recipient does not have to reach the log, or be online, to check it.
MeshQu does not replace the AI governance platform you already run. Each class below records something real, and the row says what it records before it says what it does not produce — a comparison that only states the gap is not a comparison.
The pattern across them is structural rather than a shortcoming. What each class holds is about a system, a control or a period, and it is gathered on a cycle. What none of them produces is an artefact about one decision, written as that decision executes, that still stands up after it leaves your infrastructure.
Records: Model inventory, risk tier, validation results, approval to deploy, and the monitoring thresholds a system runs under.
Gap: The unit of record is the system. A single decision that system made cannot be lifted out and checked on its own terms by someone outside.
Records: Controls, owners, attestations, and the evidence assembled for a review cycle or an audit.
Gap: Evidence is gathered when it is asked for. What it does not contain is a record written at the moment of the decision, in a form the person asking can check without you.
Records: Rule evaluation at runtime — the gate that actually ran, and the result it returned.
Gap: The result is usually a log entry. The version of the ruleset that produced it is rarely bound to it in a form a third party can check without reaching into the operator's systems.
Records: What a system did, in order, with timestamps: requests, responses, state transitions, errors.
Gap: A log shows that a code path ran. It does not carry the rule that authorised the outcome, and checking it means trusting the pipeline that wrote it.
Records: An independent opinion on a process, formed from sampling, walkthroughs and interviews.
Gap: The opinion is about the process, formed after the fact and from a sample. It does not attach to the individual decision a challenge is actually about.
The product noun in full — the fields, the bundle format and its ten sub-claims. This page quotes the definition and links; that page owns it.
The status matrix the capability list above is read from (opens in a new tab)
Section 15 of the Receipt Reference: what is implemented, and what is planned and therefore absent from this page.
Trust model (opens in a new tab)
The same ladder at length, and the trust boundaries an evaluation should be testing.
Verifying offline (opens in a new tab)
The two-step integrity and signature check, and what each step settles on its own.
Security and data handling (opens in a new tab)
What MeshQu holds and what it does not — the custody question, answered where it is owned.
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 comparing this category and the execution-evidence question is the one nobody on the shortlist answers, that is the conversation worth having. Bring a decision you would not want to defend from a log.
2 records
Category
Policy-as-code evaluates a decision against the rules in force now. Showing which rules applied six months ago means capturing the decision…
A core banking platform reconstructs decisions after the fact; a provable decision is captured at execution instead, as a single signed…