Trust Receipts

1. Abstract

AI systems are making consequential decisions in production environments — approving loans, drafting clinical notes, generating legal analysis — without leaving evidence that anyone other than the vendor can verify. Logs are mutable, vendor-controlled, and not independently checkable. This whitepaper specifies the Trust Receipt: a cryptographically signed, hash-chained record of an AI interaction that any third party can verify without contacting the producer.

We define the receipt structure, the canonicalization scheme (RFC 8785), the signing protocol (Ed25519, RFC 8032), the chaining semantics, and the content-mode options that preserve privacy while retaining proof value. We describe an open verification SDK (MIT licensed) that allows independent verification without vendor involvement, and we are explicit about what the protocol does not protect against.

2. Motivation: Logs Aren't Evidence

AI systems are moving into production environments where decisions carry legal risk, financial impact, and regulatory exposure. The current state of the art for evidence is one of three things:

• application logs in vendor-controlled databases
• screenshots and customer support tickets
• internal dashboards owned by the operator

None of these are independently verifiable. They can be edited, redacted, or lost. A regulator, auditor, or counterparty has no cryptographic basis to trust that the record they are shown is the record that was produced.

The Trust Receipt protocol takes the position that:

Every consequential AI interaction should produce an artifact that can be verified by a party who does not trust, and does not need to communicate with, the producer of the interaction.

This is the same standard already applied to network communication (TLS), software execution (code signing), and financial transactions (digital signatures). The Trust Receipt extends it to AI execution.

3. Design Goals

1. Independent verifiability. A third party can verify a receipt using only the receipt itself, the public key of the signer, and a published specification. No contact with the producer is required.
2. Tamper evidence. Any modification of any field in a verified receipt causes verification to fail.
3. Sequence integrity. Receipts are linked into a chain such that deletion, insertion, or reordering is detectable.
4. Privacy preservation. The protocol supports modes in which prompt and response content are not stored in the receipt itself, so that receipts can be produced in regulated environments without exporting sensitive content.
5. Provider agnosticism. The receipt format is independent of any particular model, vendor, or deployment topology.
6. Operational portability. Signing may be performed by local keys, by an HSM- or KMS-backed signer, or by an external signing service over a well-defined HTTP contract.

4. Why Trust Receipts Are Different

SONATE does not replace model-level safety work, documentation standards, or provenance systems. It adds the missing evidence layer: a signed artifact that records what the AI system was asked, what it returned, and how governance policy was applied at the time of the interaction.

The result is a narrower but stronger claim: SONATE does not say that an AI answer was correct. It proves which answer was produced, which governance result was attached, and whether the evidence has been changed since signing.

5. Receipt Structure

A Trust Receipt is a JSON object containing, at minimum:

{
  "receipt_id":   "sha256:7e1d4c2d...",
  "input_hash":   "sha256:8b1a9...",
  "output_hash":  "sha256:f44c2...",
  "policy_result": "pass / 94",
  "signer":       "did:sonate:tenant:42",
  "timestamp":    "2026-05-24T03:18:11Z",
  "linked_hash":  "prev:f8609618...",
  "signature":    "Ed25519:4f84a8b9..."
}

Field semantics:

Additional fields (e.g. anchoring metadata, signer discovery endpoint) are permitted and become part of the canonicalized payload over which the signature is computed.

6. Binding Receipts to Governance Outcomes

A Trust Receipt is not only a cryptographic envelope around prompt and response hashes. In SONATE deployments, it also binds the interaction to a governance outcome produced by the policy kernel. This is where the receipt layer connects to constitutional scoring, domain safeguards, and operator review workflows.

The minimal policy_result field may be expanded into structured governance metadata such as:

{
  "policy_result": {
    "status": "PASS | PARTIAL | FAIL",
    "score": 0.94,
    "policy_version": "2.0.0",
    "evaluator_version": "kernel-v0.1",
    "constitutional_scores": {
      "consent_architecture": 0.91,
      "inspection_mandate": 0.88,
      "continuous_validation": 0.93,
      "ethical_override": 0.96,
      "right_to_disconnect": 0.90,
      "moral_recognition": 0.94
    },
    "domain_packs": ["investor_communications"],
    "rules_triggered": ["investor.causality_validation"],
    "safe_reframe_detected": true,
    "human_review_required": false
  }
}

This binding is deliberately strict. For example, a response that refuses a harmful request, a response that partially complies but adds safeguards, and a response that fully complies with policy should not collapse into the same audit label. The receipt preserves those distinctions so compliance review can inspect not just the text, but the policy path that produced the outcome.

7. Canonicalization

Canonicalization is the process of producing a deterministic byte representation of the receipt so that signing and verification produce stable results independent of implementation details (key ordering, whitespace, Unicode normalization).

Trust Receipts use JSON Canonicalization Scheme (JCS), RFC 8785. JCS specifies:

• UTF-8 encoding
• Lexicographic ordering of object keys
• Number serialization per ECMAScript
• No insignificant whitespace
• Defined string escaping rules

Any independent implementation that conforms to RFC 8785 will produce the same canonical bytes for a given receipt. This is what makes verification deterministic across implementations.

8. Signing

Trust Receipts are signed with Ed25519 (RFC 8032). Ed25519 is chosen because it is:

• deterministic — the same key and message always produce the same signature
• fast in both signing and verification
• resistant to common implementation pitfalls (e.g. nonce reuse)
• widely supported across cryptographic libraries

8.1 Signer abstraction

The signing operation is abstracted behind a signer interface. Implementations may use:

• Local keys — for development and self-hosted deployments
• Vault- or KMS-backed signers — for production deployments where private keys must not leave the HSM/KMS boundary
• External HTTP signer — for deployments that delegate signing to a separate service with its own audit trail and access controls

Signer identity, discovery endpoint, and the public key advertised for verification are part of the receipt's provenance and are surfaced by the verification SDK so that a verifier can confirm which signer produced the receipt and where its public key originated.

9. Hash Chaining

Each receipt references the receipt_id of the prior receipt in the chain via the linked_hash field. This produces a tamper-evident sequence with the following properties:

• Insertion detection. Inserting a receipt requires recomputing the chain forward from that point, which changes every subsequent linked_hash and invalidates every subsequent signature.
• Deletion detection. Deleting a receipt creates a gap visible to any verifier inspecting the chain sequence.
• Reordering detection. Receipts cannot be reordered without breaking the linkage.

Chaining provides integrity across time, not just per-record. A verifier inspecting a chain segment can confirm that no receipt in the segment has been added, removed, or moved since signing.

10. Content Modes

The protocol defines two content modes for handling the prompt and response payloads:

10.1 Hash-only mode (default)

Prompt and response content are hashed into the receipt via input_hash and output_hash, but the content itself is not included in the receipt. The receipt proves that a specific interaction occurred without exposing what the interaction said.

This mode is the default for production deployments in regulated industries (healthcare, legal, finance) where prompt and response content may contain PHI, PII, or privileged material that must not be exported to a verification surface.

10.2 Full-content mode

Prompt and response content are canonicalized and included in the receipt directly. This mode is available where policy and retention requirements allow.

10.3 Detached content archive

In hash-only mode, the underlying prompt/response content may be archived separately under tenant-scoped access controls. Retrieval is gated, logged, and produces its own audit trail. The receipt remains independently verifiable whether or not the archived content is accessed.

11. Verification Protocol

A verifier performs the following steps to confirm a receipt:

1. Schema check. Confirm the receipt structurally conforms to the published Trust Receipt schema.
2. Canonicalization. Produce the JCS (RFC 8785) canonical bytes of the receipt, excluding the signature field.
3. Signature check. Verify the Ed25519 signature against the canonical bytes using the public key associated with the signer identifier.
4. Chain check. If verifying a sequence, confirm that each receipt's linked_hash matches the prior receipt's receipt_id.
5. Receipt ID check. Recompute the SHA-256 over the canonicalized receipt (less signature) and confirm it matches the stated receipt_id.

Any step failing causes overall verification to fail. The open SDK (@sonate/verify-sdk, MIT licensed) implements this protocol and surfaces a structured result indicating which check failed and why.

Verification does not require contact with the producer of the receipt. The only external requirement is access to the signer's public key, which may be embedded in the receipt's signer reference or retrieved from a public discovery endpoint specified in the receipt's provenance.

12. Adoption & Integration Patterns

Trust Receipts are designed to fit existing enterprise control planes rather than requiring a new standalone audit stack. A receipt can be emitted at the AI gateway, stored in the customer environment, exported to compliance systems, and verified by an external party without granting that party access to the production platform.

Example regulatory mappings are deployment-specific, but the receipt primitive maps naturally to common governance requirements:

• NIST AI RMF. Supports govern, map, measure, and manage workflows by preserving signed evidence of model use and policy decisions.
• EU AI Act auditability expectations. Provides immutable records of high-risk AI interactions, including timestamps, signer identity, and governance outcomes.
• ISO/IEC 42001 AI management systems. Supplies verifiable evidence for operational controls, incident review, and continual improvement.

In practice, SONATE can be introduced first as an evidentiary layer around a narrow high-risk workflow, then expanded into broader policy enforcement and monitoring as customer governance maturity increases.

13. Threat Model

It is important to be explicit about what Trust Receipts do and do not protect against.

13.1 What the protocol protects against

• Post-hoc tampering. A receipt cannot be modified after signing without verification failing.
• Sequence tampering. Receipts cannot be inserted, deleted, or reordered without breaking the chain.
• Vendor self-attestation. The vendor cannot claim that a different interaction occurred than the one signed.
• Repudiation by signer. The signer cannot deny producing a signed receipt for which the signature verifies under their public key.

13.2 What the protocol does not protect against

• Compromise of the signing key. If a signer's private key is stolen, an attacker can produce receipts that verify. Key custody is out of protocol scope; HSM/KMS-backed signers mitigate this operationally.
• Incorrect input. A receipt proves what was signed. It does not prove that what was signed accurately reflects what the AI system actually did. Producer integrity at the gateway level is a separate concern.
• Wholesale chain withholding. A producer can refuse to surface any chain at all. The protocol provides tamper-evidence over chains that are surfaced; it does not compel disclosure.
• Semantic correctness of policy decisions. The receipt records what the policy engine decided. It does not validate whether the policy engine decided correctly.

Operators should treat Trust Receipts as a foundational evidence primitive, not as a complete governance solution. Receipts compose with other controls (access management, policy review, model evaluation) to form a defensible audit posture.

14. Open vs Proprietary

The protocol is designed so that the parts required for independent verification are open, while the operational platform that produces receipts at scale remains proprietary.

A consumer of receipts is never required to use the proprietary platform to verify a receipt. This is the design principle that distinguishes Trust Receipts from vendor-controlled audit logs.

15. Limitations & Future Work

The protocol as specified has the following known limitations:

• Anchoring. External anchoring of chain heads (e.g. to public transparency logs or blockchain timestamps) is implemented as an optional workflow but is not yet a required part of the protocol. This is on the near-term roadmap.
• Multi-party signatures. The current specification supports a single signer per receipt. Threshold or multi-party signing schemes for high-stakes decisions are under research.
• Policy-language standardization. The policy_result field format is deployment-defined. A standard taxonomy for governance outcomes is exploratory.
• Receipt revocation. Receipts are immutable by design; key revocation handling for compromised signers is a deployment concern, not a protocol-level mechanism.

The Feature Maturity Matrix maintained in the SONATE platform repository separates Production-Core protocol elements (those described above) from Beta and Research capabilities (drift detection, dashboards, autonomous reasoning) so that product claims remain aligned with what is defensibly proven.

16. References

1. Josefsson, S. & Liusvaara, I. (2017). Edwards-Curve Digital Signature Algorithm (EdDSA). RFC 8032.
2. Rundgren, A., Jordan, B. & Erdtman, S. (2020). JSON Canonicalization Scheme (JCS). RFC 8785.
3. Eastlake, D. & Hansen, T. (2011). US Secure Hash Algorithms (SHA-2 family). RFC 6234.
4. Newton, R. & Hardt, D. (2015). The OAuth 2.0 Authorization Framework. RFC 6749. (Referenced for delegated signer authorization.)
5. W3C. (2022). Decentralized Identifiers (DIDs) v1.0. W3C Recommendation. (Referenced for signer identifier format.)
6. SONATE Platform Repository. github.com/s8ken/yseeku-platform
7. Trust Receipt Specification v1. docs/TRUST_RECEIPT_SPECIFICATION_v1.md
8. Feature Maturity Matrix. docs/FEATURE_MATURITY_MATRIX.md