Skip to main content

Decision Receipts: what the record contains

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 verifiable afterwards with the necessary verification material and trusted keys. It records the policy in force, relevant decision context, the outcome and integrity information needed to check 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.

In more detail

One receipt covers one recorded assessment and the policy version and context that governed it. The rules come from the policy; the receipt description is the policy in force, rules checked, decision context and outcome. It makes no claim about the outcome for each individual rule or the evidence for each rule. A later review, a second assessment and the final decision can be linked to the first; they are not later events folded into the original signed receipt. In the illustrative Northgate story, a missing tax registration certificate triggers review, the certificate is supplied and the assessment is run again, and Jordan Davis is shown as the actor on the final call with a recorded rationale. This is illustrative data. Who acted and any displayed role are recorded as supplied by the customer systems; they are not independently authenticated by MeshQu. Source documents stay with their custodian, while the supplied context, evidence references and digests can be bound to the record. Where export is enabled, a receipt and policy snapshot can be exported for offline verification with the necessary material and trusted keys. Integrity and signature checks work together to detect changes to bound content; a valid signature alone does not prove the content is unchanged.

Limits

  • It does not prove that the inputs were true, that the decision was correct or that the action was carried out.

  • The rules come from the approved policy. This receipt description makes no claim about the outcome for each individual rule or the evidence for each rule in the signed record.

  • The receipt records the policy assessment; it does not explain an AI model's internal reasoning.

  • For API integrations, the actor identifier is supplied by the calling application and is not independently authenticated. Role and authority are display annotations, not identity assurance.

  • The record does not establish which model, version or configuration produced a result.

  • Later reviews and assessments are separate linked records, not additions inside the original signed receipt.

  • Offline verification requires the necessary material and trusted keys. Bundle export must be enabled for the deployment; it is not assumed available.

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

Where it applies

  • Give a reviewer the policy version, rules checked, relevant context and outcome recorded for an assessment.

  • Follow linked assessments, a review trigger and a final recorded call without reconstructing the sequence from memory.

  • Keep sensitive source material with its custodian while binding references and digests to the recorded assessment.

  • Where export is enabled, provide the receipt and policy snapshot for an offline check with the required verification material and separately trusted keys.

Sources

Related answers

Next step

Map a decision

Read more on meshqu.com/receipts

Updated Machine-readableAll reviewed answers