Skip to main content
Most responsible-AI commitments are written before anything runs. They describe how a system should behave — fairly, transparently, with a person able to intervene. Operationally, those commitments divide into kinds, and the division decides what can ever be shown to a third party. Some are statements of intent: they describe a disposition, and the only way to check them is to inspect the system, test it, or trust the organisation that wrote them. Some are evidenceable at execution time: at the moment a specific decision is made, a record can be produced showing the claim held for that decision, and checked later by someone who was not there. This page is about the second kind, and about being precise regarding how narrow it is.
MeshQu is currently available for research, evaluation and design-partner deployments. Production availability and support commitments are agreed per engagement.

​
Three shapes, not two

The intent/evidence split is the useful one, but a straight binary hides a third shape: commitments that are genuinely evidenceable, by a different artefact, at a different time. Calling those “intent” would be wrong. A commitment in the first two rows is not weaker than one in the last three. It is a different claim, and reaching for a decision-time record to support it is a category error that produces confident-looking evidence for something nobody measured.

​
What a Decision Receipt evidences

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. Taken one at a time, and with the status of each mechanic grounded in the Receipt Reference status matrix (§15):
  • The policy in force. The version of the ruleset that actually evaluated this decision, frozen and bound to the record — not the version that happened to be current when someone last read the policy document. Snapshot replay is implemented: the same inputs against the same snapshot reproduce the same result.
  • The decision context supplied. The inputs the calling application submitted, bound by hash. MeshQu hashes what it is given; that the submitted references and hashes are truthful remains a property of the caller, not of the receipt (Decision Assurance).
  • The outcome recorded. The verdict the policy produced. MeshQu returns a verdict and the calling application owns enforcement (Integration Patterns), so the receipt evidences what was decided, not what was subsequently done about it.
  • The integrity information. Offline integrity and signature verification are implemented (§15) and run without contacting MeshQu at all.
Tamper evidence is two checks together. A content edit leaves the Ed25519 signature valid — the signature covers the stored integrity hash, which the edit did not touch — and it is the integrity check that binds the content and catches it. Rewriting the hash to paper over the edit then fails the signature. Never attribute edit-detection to the signature alone. Integrity and Hashing has the primitives; Verifying a Receipt Offline has the honest two-step demo. The field-level contract — every field, what each one binds, the ten verification sub-claims — belongs to the Receipt Reference, and the five-rung assurance ladder belongs to Decision Assurance and the Trust Model. This page does not restate either.

​
What a Decision Receipt does not evidence

This is the load-bearing section. Read it before writing anything public that rests a responsible-AI claim on a receipt.
  • Fairness. A receipt evidences that a decision was evaluated against a particular ruleset. Whether that ruleset encodes a defensible standard of fairness is a question about the policy, answered by whoever wrote and approved it — not by the artefact that records its use.
  • Accuracy. Nothing in the record establishes that the inputs described the world correctly. The receipt binds the context that was supplied; it cannot bind the context that was true.
  • Model behaviour. Where a model produced a recommendation upstream of a governed decision, the receipt evidences the decision, not the model — no account of how the model reached its output, or how it behaves on any other input.
  • The correctness of the decision. Verification proves issuance and integrity, never correctness. A passing verdict means these bytes are mathematically consistent and were signed by the key they claim. It does not mean the decision was right, the inputs truthful, or any external requirement discharged.
  • The identity of the actor. MeshQu records and cryptographically binds whatever actor identifier the calling system supplies; it does not authenticate actor identities against an identity provider (Actor Attribution). Of the actor fields, only actor.id is inside the integrity hash — type (human or automated), role and authority are display annotations. So a receipt evidences which actor the calling system claimed, bound such that the claim cannot be altered afterwards. It does not evidence who or what actually acted. The safe term is Actor, not “Approver”: the receipt records who acted, not necessarily who approved (§16).
This is why the accountability row in the table above reads partly. Binding an unverified claim is still worth doing — it converts a mutable log line into something that cannot be edited after the outcome is known — but it is a narrower thing than attribution, and describing it as attribution is the single easiest way to overstate a receipt.

​
Evidence mechanics, and what the organisation still owns

The same split Decision Assurance draws between implemented mechanics and deployment responsibilities applies to responsible-AI claims, and it falls in a place people find unintuitive. Carried by the artefact — implemented, checked by the offline verifier, statuses source-grounded in §15: Owned by the organisation — no release delivers these, and none of them becomes evidenceable because a receipt exists: The remaining gap here is organisational, not unfinished receipt structure — the same conclusion the assurance ladder reaches from the other direction.

​
Using the distinction

When a responsible-AI commitment is drafted, the practical question is which of the three shapes it has, and therefore what would satisfy someone who did not take it on trust. A commitment that is evidenceable at execution time is worth phrasing so its evidence can actually be produced and checked. One that is not should say plainly what would satisfy it — an evaluation, an inspection, an audit of the ruleset — rather than borrowing the credibility of a record that answers a different question. The failure this page exists to prevent is the quiet substitution: describing an intent-shaped or evaluation-shaped commitment as though a decision-time record discharged it. The record is narrow, and its value comes from being exactly as narrow as it says.

​
See also