Responsible AI governance: what can be shown about one decision

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 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.

Where a commitment meets a case

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 caseAn 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 afterwardsPolicies 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 askedAn 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 actSign-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 reviewSampling 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 systemsWhatever 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.

What a decision-time record can carry

MeshQu does one thing, at the point where a commitment either held or did not: the moment a governed decision executes. 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.

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.

Which ruleset governed a decision is recorded, not reconstructedA 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 underReplay 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 MeshQuIntegrity 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 livesThe 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 ownA self-contained verification bundle carries what a third party needs in order to check a single 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
Records can be anchored outside your own infrastructureAn 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

What this does not prove

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 fairnessThe 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 accuracyNothing 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 modelWhere 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 kindA 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 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.
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.
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.

The authoritative source

The docs page owns the distinction this page routes into: the shapes a responsible-AI commitment can take, which of them a decision-time record can support at all, and the full account of what a Decision Receipt does not evidence. This page is the way in, in the category's own language; that page is where the split is drawn and where it is applied.

Read Responsible AI: Evidence and Intent

Elsewhere on this site

AI governance frameworks: where execution proof fits
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 policy: what it can commit to at the moment of decision
An AI governance policy states how decisions involving AI will be made. Some of what it states is assertable in advance; a few clauses can be shown to have held for a particular decision afterwards. Knowing which is which is what makes the document answerable.
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.
What a Decision Looks Like When You Can Actually Prove It
A core banking platform reconstructs decisions after the fact. Here is what one looks like when the reconstruction is not needed — captured at execution as a single, signed artefact.

Next step

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.

Start a conversation

Availability

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