Commitments are written in the abstract and tested in the particular. This is about which of them still mean something when the question is about one decision, taken on one date, by someone who has no reason to take your word for it.
Responsible AI governance sets commitments about how AI systems treat people. Which of those can be evidenced for a particular decision, and which can only be asserted, is settled at the moment that decision executes.
Responsible AI governance is the part of an AI programme that answers to people outside it. It is where an organisation writes down what it owes the people its systems make decisions about: that a use is appropriate, that an outcome can be explained, that a person can intervene, that someone is accountable, and that a decision can be challenged.
Nearly all of the work sits away from the decision itself. Before it: use assessment, evaluation, model documentation, review and sign-off. After it: monitoring, sampling, incident review, periodic reporting. Both halves are real, and a serious programme needs both.
The commitments are not about programmes, though. They are about individual outcomes — this applicant, this claim, this account. So the operational test of responsible AI governance is narrower than the apparatus that produces it: when someone asks about one decision, on one date, what is there to show them, and can they check it without taking your word for anything? This page is about that question, and about which commitments can actually answer it.
Most responsible-AI evidence describes a system: how it was built, how it was tested, how it behaves across a population. That evidence is the right shape for the question it answers, and producing it is real work.
A challenge is almost never about the population. It is about one case, and the material that exists about that case was written by systems built for something else — throughput, reconciliation, debugging. These are the places where a commitment made in the abstract turns out to have no artefact behind it in the particular.
Aggregate evidence does not narrow to a case
An evaluation report describes behaviour across a distribution. It cannot be resolved down to the one decision somebody is disputing, and treating it as though it can is how a defensible-in-aggregate system gets defended against an individual complaint.
The rule that applied is inferred afterwards
Policies are versioned in one system and decisions are recorded in another. Joining them later produces a plausible account of which version governed a decision, not a record of it.
Explanations are produced when the question is asked
An explanation generated on request describes the system as it is now. The decision was taken under whatever was in force then, and nothing in the pipeline forces those two to agree.
Oversight is recorded as a role, not as an act
Sign-off establishes that a person was accountable for a class of decisions. It rarely establishes what was in front of them at the moment one of those decisions was actually taken.
Volume outruns review
Sampling and periodic review scale with reviewer time. Automated decision volume does not, and the difference between the two is where the unevidenced cases sit.
The record has to leave your systems
Whatever reaches a complainant, an adviser or an outside reviewer has to stand up away from your infrastructure. If checking it means logging into your console, the check and the claim have the same author.
MeshQu fits at the point a decision is assessed against a ratified policy. It is called with the context of the decision and the ruleset 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.
Read against a list of responsible-AI commitments, that artefact is narrow, and the narrowness is the whole of its value. It does not evidence that a decision was fair, that a model behaved, or that the outcome was the right one. It evidences that this decision was taken under this rule, with this context, and that the record has not changed since. 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.
Which ruleset governed a decision is recorded, not reconstructed
A snapshot of the policy that applied is taken as the decision is evaluated, and its digest is bound into the record'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 decision can be re-run against the snapshot it was made under
Replay re-evaluates the recorded context against the frozen snapshot: the same inputs and the same snapshot produce the same result. That is a narrower thing than an explanation, and unlike an explanation it can be repeated by someone else.
Receipt Reference §15 — snapshot replay, Implemented
The record checks out without contacting MeshQu
Integrity and signature checks run against key material supplied to the verifier, never against a value carried inside the record being checked. The party asking does not have to come through you, or through us, to check it.
Receipt Reference §15 — offline integrity and signature verification, Implemented
The material relied on is bound by digest and stays where it lives
The record binds digests of the evidence relied on, and custodian signatures over them where an external system supplies one. The content itself stays in the system that holds it; evidencing a decision does not mean moving a case file.
Receipt Reference §5 (Evidence Manifest), §17 trap 1
One decision can be handed over on its own
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
Records can be anchored outside your own infrastructure
An anchored record is verifiable offline against a pinned log key, without contacting the log. What that buys is a check on the existence of the record that does not run through the organisation holding it.
Receipt Reference §6 (Transparency Anchor), §15 — Rekor anchoring and offline SET verification, both Implemented
The counterpart below carries this at length, and its equivalent section is the one worth reading before anyone rests a responsible-AI claim on a receipt. The short version is here because a page that introduces an artefact and leaves the limits one click away has decided which half the reader is more likely to see.
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.
It does not evidence fairness
The record shows that a decision was evaluated against a particular ruleset. Whether that ruleset encodes a defensible standard is a question about the ruleset, answered by whoever wrote and ratified it — not by the artefact that records its use.
It does not evidence accuracy
Nothing in the record establishes that the inputs described the world correctly. It binds the context that was supplied; it cannot bind the context that was true.
It says nothing about the model
Where a model produced a recommendation upstream of a governed decision, the record evidences the decision and not the model — no account of how the output was reached, and none of how the system behaves on any other input.
Most responsible-AI commitments are not of this kind
A commitment about how a system was built, or how it behaves across a population, is evidenced by an evaluation, a test report or an inspection — a different artefact, at a different time. Reaching for a decision-time record to support one produces confident-looking evidence for something nobody measured.
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.
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.
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.
Actor attribution (opens in a new tab)
What the human-or-automated field records, and the trust model around an identity the integrator supplies rather than one MeshQu establishes.
Verifying offline (opens in a new tab)
The two-step integrity and signature check, and what each step settles on its own.
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.
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 the commitments are written and the thing you cannot produce is the evidence for one of them, on one decision, that is the conversation worth having.
2 records
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 core banking platform reconstructs decisions after the fact; a provable decision is captured at execution instead, as a single signed…