How to Read a Trust Receipt

Somewhere — in a compliance review, a customer dispute, a regulator's request, an internal investigation — you are going to be handed a trust receipt and asked what it says. This article is the field guide for that moment.

A trust receipt is a small JSON document, usually under a kilobyte, that records a single AI interaction. You do not need a cryptography degree to read one. You need to know where each piece of evidence lives, what it proves, and what it deliberately does not prove.

Treat the receipt as a witness statement, not as a log file.

A log file is something a system writes about itself. A receipt is something a system signs in a way it cannot quietly revise later. The questions you ask it are accordingly different.

What You Are Holding

Below is a real signed receipt from a SONATE-generated interaction, lightly trimmed. Every receipt you encounter follows the same shape, though field names may vary by implementation.

{
  "version": "2.2",
  "id": "rcpt_550e8400e29b41d4a716446655440000",
  "timestamp": "2026-06-13T10:30:00.000Z",
  "session_id": "sess_abc123def456",
  "agent_id": "claude-3-haiku-20240307",
  "prompt_hash": "sha256:a1b2c3d4...",
  "response_hash": "sha256:q1r2s3t4...",
  "telemetry": {
    "sonate_principles": {
      "CONSENT_ARCHITECTURE": 9,
      "INSPECTION_MANDATE": 8,
      "CONTINUOUS_VALIDATION": 8,
      "ETHICAL_OVERRIDE": 9,
      "RIGHT_TO_DISCONNECT": 7,
      "MORAL_RECOGNITION": 8
    },
    "overall_trust_score": 82,
    "trust_status": "PASS",
    "weight_source": "healthcare",
    "weight_policy_id": "policy-healthcare-v2.1"
  },
  "prev_receipt_hash": "sha256:g1h2i3j4...",
  "receipt_hash": "sha256:v1w2x3y4...",
  "signature": "sig_ed25519:fd280b6f...",
  "public_key": "pub_ed25519:MCowBQYDK2VwAyEA..."
}

It looks dense. Read it in four field groups and it becomes simple.

Group 1: Identity

These fields tell you what happened and where.

Group 2: Content fingerprints

These are not the prompt and response themselves. They are SHA-256 hashes — fixed-length fingerprints of the original content.

The receipt does not need to contain the prompt or response for this to be useful. As long as the content exists somewhere — in your evidence vault, a tenant-scoped archive, a regulator's exhibit folder — you can re-hash it and match.

Group 3: Chain

These fields place the receipt in time, relative to other receipts.

Together they form a linked list. To remove or insert a receipt anywhere in the chain you would have to recompute every subsequent hash and re-sign every signature. That is the integrity guarantee.

Group 4: Attestation

These fields cover what the system asserted about the interaction at the time, and the cryptographic proof that nothing has changed since.

The Three Questions a Receipt Answers

When you are asked to evaluate a receipt, you are really asking three questions in order. Each one builds on the previous.

1. Is it authentic? Does the signature verify against a public key you trust? If not, stop here — nothing else this document says is reliable.
2. Is it intact? Does the receipt_hash match what you compute by re-canonicalising the body? Do the prompt_hash and response_hash match the content on file? If any of these fail, the receipt has been tampered with, or the content has.
3. Is it in order? Does prev_receipt_hash point at a receipt you can find, and does that receipt's receipt_hash match the value quoted here? If receipts in the chain are missing, the gap itself is evidence.

A receipt that fails any one of these three checks is not just unhelpful. It is itself a finding.

How to Verify One Yourself

Modern receipts are designed for zero-backend verification. The receipt and the public key are everything you need — no server call, no proprietary tool. The operator checklist used inside the platform runs in this order:

1. Recompute the body hash. Strip the signature, receipt_hash, and public_key fields. Canonicalise the rest with RFC 8785. Hash with SHA-256. Compare against the stated receipt_hash.
2. Verify the signature. Pass the canonical body bytes and the signature to Ed25519 verify, using the stated public key.
3. Confirm the key. Check the public_key against an independently trusted source — a published key directory, a signer discovery endpoint, a regulator-held copy. The receipt should never be the only place the key lives.
4. Re-hash the prompt and response. If you have the prompt and response on file, SHA-256 them and confirm they match prompt_hash and response_hash.
5. Walk the chain. For each receipt in the session, confirm prev_receipt_hash equals the previous receipt's receipt_hash. A missing or mismatched link is a finding.

If steps one and two pass, the receipt is exactly the artefact the signer committed to. If they fail, something between signing and reading has changed — even by a single byte. Most teams will hand these steps to an internal tool or a verification service rather than running them by hand; the point is that they can be run by anyone, against the same receipt, and arrive at the same answer.

const { verify } = require('crypto');
const fs = require('fs');

const receipt = JSON.parse(fs.readFileSync('receipt.json', 'utf8'));

const message = Buffer.from(receipt.self_hash, 'hex');
const signature = Buffer.from(receipt.signature_base64, 'base64');
const publicKey = receipt.public_key_pem;

const isValid = verify(null, message, publicKey, signature);

console.log('signature_valid', isValid);

Reading the Trust Score

Once you are satisfied the receipt is authentic, intact, and in order, the telemetry block tells you what the governance layer thought about the interaction at the time.

Different governance systems use different principles. The example below uses SONATE's governance model — six principle scores, each from 0 to 10:

These six are combined into an overall_trust_score (0–100) using a set of principle_weights. The weights are not the same across industries: a healthcare receipt weights CONSENT more heavily than a finance receipt, which weights INSPECTION more heavily. Two fields make these weights auditable — weight_source names the policy (“healthcare”, “finance”, etc.) and weight_policy_id pins the exact version. Both sit inside the signed body, so neither can be silently changed after the fact.

The trust_status field then summarises the result:

• PASS — overall score ≥ 70, no critical failures
• PARTIAL — overall score ≥ 40, no critical failures
• FAIL — overall score < 40, or a critical principle (CONSENT or ETHICAL_OVERRIDE) scored 0

A FAIL on a critical principle vetoes the overall score regardless of the others. If you see PASS, scan the principle scores anyway; some receipts pass on aggregate while sitting low on a specific principle you care about.

What a Broken Receipt Tells You

A clean PASS is not the only useful outcome. Failures are evidence in their own right.

The most useful thing about a verifiable receipt is what it tells you when it fails.

What a Receipt Does Not Prove

It is just as important to be clear about what a receipt cannot do.

A receipt does not prove that the AI's response was correct, fair, or made in good faith. Cryptography cannot see inside a model's reasoning. A flawless cryptographic chain attached to a wrong answer is still a wrong answer — but at least now you can prove what was said, by which system, at which moment.

A receipt does not prove the prompt or response was appropriate. It only proves that this prompt and this response, in this order, came from this system. Whether either should have been produced is a separate question for human review.

A receipt does not replace policy, audit, or oversight. It makes them enforceable.

Reading the Receipt In Practice

When a regulator asks for evidence, the receipt is what you hand over. When a customer disputes a decision, the receipt is what answers the dispute. When an internal investigation runs, the receipt is where it starts — and, if integrity is maintained, where it can end.

Reading one well is a finite skill. Identify the four field groups. Ask the three questions in order. If anything fails, treat the failure itself as the finding. If everything passes, read the trust score with attention to the principle scores and the weighting policy that produced them.

Once verifiable receipts become common, the absence of one may itself become a governance concern.

That is the shift. The receipt is not the audit. The receipt is what makes the audit possible.

The question is not whether the AI can be trusted. The question is whether what it did can be proven.