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, typically 1–5 KB, 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 that makes any later revision detectable. The questions you ask it are accordingly different.

What You Are Holding

Below is a real signed receipt, generated by SONATE's live public demo endpoint and embedded here unmodified. It is not an illustration: you can copy this JSON, paste it into the public verifier at yseeku.com/verify, and watch every check pass — then change any character and watch verification fail. (It was issued by the demo signer, so the response text is a placeholder; the cryptography and governance evaluation are the real production path.)

{
  "version": "2.2.0",
  "timestamp": "2026-07-14T09:51:25.784Z",
  "session_id": "demo-1784022685784-f1cdf380",
  "agent_did": "did:web:yseeku.com:agents:demo-agent",
  "human_did": "did:web:yseeku.com:users:demo",
  "policy_version": "1.0.0",
  "kernel_version": "kernel-v0.1",
  "kernel_policy_version": "v1-kernel-primary",
  "kernel_policy_hash": "b2013a81811c9500195c4e71457442093b8101d9003ca47b02fe96d8e2033e36",
  "mode": "constitutional",
  "demo_mode": true,
  "evaluated_by": "heuristic",
  "interaction": {
    "prompt": "Summarise this customer complaint for our remediation team: I was charged twice for my June subscription, contacted support twice with no response, and want a refund plus confirmation the duplicate billing is fixed.",
    "response": "This is a demo response for: \"Summarise this customer complaint for our remediation team: I was charged twice for my June subscrip\". In a production environment, this would be a real AI-generated response that gets evaluated for trust compliance.",
    "prompt_hash": "add8d9c09143cd60e7c7b830a591022aa17299f2cbdb5a914d51ce995b0386f6",
    "response_hash": "c7f36e9c2c2e63b2005771224eae719f0cb37a77a155ac673d5c691a880fb189",
    "model": "demo-model"
  },
  "governance": {
    "status": "PASS",
    "overall_trust_score": 90,
    "risk_tier": {
      "level": 1,
      "label": "ADVISORY",
      "description": "Tier 1 advisory: no blocking control is required, but evidence remains available for audit.",
      "drivers": [],
      "frameworkMappings": [
        "SONATE: receipt-backed decision evidence",
        "NIST AI RMF: GOV 1.1 governance policies and accountability",
        "ISO/IEC 42001: 6.1 risk and opportunity planning"
      ]
    },
    "requires_human_review": false,
    "recommended_enforcement": "none",
    "recommended_actions": [],
    "confidence": 0.9500000000000001,
    "kernel_version": "kernel-v0.1",
    "kernel_policy_version": "v1-kernel-primary",
    "kernel_policy_hash": "b2013a81811c9500195c4e71457442093b8101d9003ca47b02fe96d8e2033e36",
    "summary": "Kernel confirmed PASS without deterministic overrides.",
    "response_assessment": "The response remained constitutionally acceptable under SONATE governance review.",
    "prompt_risk_summary": "No domain-specific risk pattern was identified beyond the baseline constitutional review.",
    "principles": {
      "CONSENT_ARCHITECTURE": 9,
      "INSPECTION_MANDATE": 9,
      "CONTINUOUS_VALIDATION": 9,
      "ETHICAL_OVERRIDE": 9,
      "RIGHT_TO_DISCONNECT": 9,
      "MORAL_RECOGNITION": 9
    },
    "rules_fired": [],
    "source_contributions": {
      "llmJudge": 1,
      "semanticJudge": 0,
      "deterministicPolicy": 0,
      "calculator": 0,
      "systemState": 0
    },
    "evaluated_by": "heuristic",
    "system_state_assumptions": {
      "hasExplicitConsent": true,
      "consentMechanism": "click-through",
      "receiptPlanned": true,
      "receiptVerifiable": true,
      "auditLogExists": true,
      "hasOverrideButton": true,
      "hasExitButton": true,
      "noExitPenalty": true,
      "canDeleteData": true,
      "humanInLoop": true
    },
    "advisory": {
      "method": "heuristic",
      "proposed_principles": {
        "CONSENT_ARCHITECTURE": 9,
        "INSPECTION_MANDATE": 9,
        "CONTINUOUS_VALIDATION": 9,
        "ETHICAL_OVERRIDE": 9,
        "RIGHT_TO_DISCONNECT": 9,
        "MORAL_RECOGNITION": 9
      },
      "note": "Advisory signals are computed by a lightweight keyword heuristic in the public demo, not the production LLM judge. They are non-deterministic inputs and do not override the deterministic kernel result."
    }
  },
  "chain": {
    "previous_hash": "GENESIS",
    "chain_hash": "c3614086f78c532303debe71dacbe30f7cfef1d306e98403c3eb4cdfdb973171",
    "chain_length": 1
  },
  "id": "553422b5042eddea59995918da609502ba4b0be0c35ce2125663d55c3d6dc80a",
  "signature": {
    "algorithm": "Ed25519",
    "value": "36eb8a12e21583f8cba329f6c0c8a9f0501fef9a6b8fae1f3300950e6a9aec0591fd97e7e3ecbe5153fad03f07bb947bc93054800f79651fe69ef665b22c6105",
    "key_version": "v1",
    "timestamp_signed": "2026-07-14T09:51:25.825Z",
    "public_key": "741f8d7fe0400962d92e36bcaa14a760460cc2ce743a1676858883dd3dfc3351"
  }
}

Verify it yourself: paste the JSON into the in-browser verifier at yseeku.com/verify (no account, no server trust required), or run it through the open-source SDK — npm install @sonate/verify-sdk. The signing key should always be cross-checked against an independently published copy; SONATE publishes its key at yseeku.com/.well-known/sonate-pubkey.

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. Removing or inserting a receipt breaks continuity against any previously retained receipt or anchored chain head. Reconstructing a replacement chain would require control of the signing key — and would still be detectable by comparison with that earlier evidence. That is the integrity guarantee, and its boundary.

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 id match what you compute by re-canonicalising and hashing the body? Do interaction.prompt_hash and interaction.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 chain.previous_hash point at a receipt you can find, and does that receipt's chain.chain_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 block and id. Canonicalise the rest with RFC 8785. Hash with SHA-256. Compare against the stated id.
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 interaction.prompt_hash and interaction.response_hash.
5. Walk the chain. For each receipt in the session, confirm chain.previous_hash equals the previous receipt's chain.chain_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('@sonate/verify-sdk');
const receipt = require('./receipt.json'); // the receipt above

const result = await verify(receipt, receipt.signature.public_key);
console.log(result.valid); // true — and false if you change any byte

// In production, never trust the key embedded in the receipt alone:
// cross-check it against https://www.yseeku.com/.well-known/sonate-pubkey

Reading the Trust Score

Once you are satisfied the receipt is authentic, intact, and in order, the governance block (telemetry, in platform-issued receipts) tells you what the policy engine concluded 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 deployment weights CONSENT more heavily than a finance deployment, which weights INSPECTION more heavily. The policy identity fields make this auditable — policy_version, kernel_policy_version, and kernel_policy_hash pin the exact ruleset (you can see all three in the receipt above). They sit inside the signed body, so none 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.