Receipt chain semantics.

How audit evidence travels and verifies end-to-end, without a shared log, a blockchain, or a central arbiter.

Every operation in SLF produces a signed bilateral artifact called a Receipt SLF. Receipts are the first-class output of the operation, its audited result, returned to both parties, persisted in the user's substrate, and verifiable by any future auditor without coordinating with any central party.

That is the load-bearing claim. The rest of this page is what makes it true, what makes it hard, and what's still open.

Each receipt envelope carries the same thing whether the operation was a credential issuance, a grant invocation, a substrate read, a write-back, or a revocation:

• A reference to the operation being audited, including substrate, lens, frame, and the grant that authorized the frame.
• The actor and audience DIDs, who acted, who received.
• Disclosed fields by path only, not the data itself. The data lives in substrate; receipts describe what crossed the bridge.
• Redacted fields with reason codes, a record of what was not disclosed and why a gate refused it.
• Gates evaluated, with the vocabulary version each gate referenced and its evaluation result. This is the audit spine.
• Signatures from the parties, in one of two negotiable modes (described below).

The recursive elegance, from the architecture doc: "A Receipt is itself an SLF (the architecture describes itself in its own terms, recursive by design)." A receipt has its own substrate (the prior operation), its own lens (the audit context), its own frame (the act of attestation). Every protocol mechanism that works for ordinary SLFs, signing, verifying, gate evaluation, chaining, works for receipts.

This matters because the same query primitives users have for inspecting their own substrate apply to receipts. Users can ask: "What did this provider disclose to other parties under my standing grant last month, and against which gates?" The receipt chain answers the question without anyone running a central log.

Receipts ship in two first-class modes. The protocol does not pick a winner.

v1, counter-signed. Both parties sign the receipt and both retain a copy. Maximum cryptographic non-repudiation. Either party can prove what happened by producing their copy and re-verifying the signatures. The trade-off is permanence: the receipt is a permanent discoverable record of a disclosure, which creates legal-liability exposure under regimes like GDPR Article 5(1)(c) data-minimization. A provider may not want to keep counter-signed records of every disclosure forever.

v2, zero-knowledge attestation. The counter-party produces a zero-knowledge proof that gates were evaluated correctly and the operation was honored under its constraints, but without retaining the disclosure detail. The user keeps their evidence; the counter-party keeps proof-of-correctness without retention burden. The trade-off is computational load, ZK proofs are expensive, and dependency on a viable ZK circuit governance regime for gate-evaluation predicates.

Parties negotiate at discovery time. A supported_receipt_modes field declares what each side can honor; the user can require v2 for sensitive operations, the provider can decline counter-parties whose mode the provider cannot legally retain. Mode negotiation is the operation's first audited decision; it is itself captured in the receipt that the operation produces.

The dual specification is a v0.5 hardening response to two independent premortem investigations that each converged on bilateral-retention as the kill vector: one from regulators-rule-receipts-noncompliant, one from receipts-as-liability. The protocol's answer to "which mode is right?" is: the parties decide, and the answer is auditable.

Receipts chain via content-addressed prior-hash references. Each receipt computes its own hash over a canonical serialization (SHA-256 over RFC 8785 canonical JSON). The prev_hash field points to the hash of the predecessor receipt in the chain, or None for a genesis receipt. A chain is therefore an append-only structure where any tampering at any link breaks the hash linkage of every subsequent link.

Verification is mechanical:

1. Walk the chain from genesis to tip.
2. At each link, recompute the SHA-256 hash of the canonical receipt bytes.
3. Confirm the next receipt's prev_hash matches the just-computed hash.
4. Verify the signatures on each receipt (actor and audience counter-signatures for v1; actor signature plus ZK verifier output for v2).
5. Verify each receipt's gate-evaluation result against the gate vocabulary version it cited.

If any step fails, the auditor knows which link broke and what kind of failure occurred, hash mismatch (tampering), signature failure (forgery or key rotation gap), gate-evaluation failure (vocabulary drift or constraint violation).

A simplified envelope, schematic only:

// Receipt SLF, illustrative shape, not normative
{
  "slf": {
    "substrate": "{ ref to the operation being audited }",
    "lens":      "{ subject, role, jurisdiction at attestation time }",
    "frame":     "{ actor, audience, moment, authorized_by_grant }"
  },
  "outcome":         "disclosed | refused | revoked | ...",
  "disclosed_fields": [ "claim.diagnosis", "claim.date" ],
  "redacted_fields":  [ { "path": "claim.note", "reason": "g:hipaa:minimum_necessary" } ],
  "gates_evaluated":  [ { "vocab": "hipaa@1.4", "id": "minimum_necessary", "result": "pass" } ],
  "prev_hash":        "sha256:7c4f...e2",
  "signatures": {
    "actor":    "ed25519:...",
    "audience": "ed25519:...   // v1 counter-signed mode"
    // or:
    "zk_proof": "groth16:...   // v2 attestation mode"
  }
}

The chain mechanics now run, in two implementations. slf-core's conformance suite demonstrates receipt-chain integrity directly: a skipped or mutated receipt is caught, and the suite runs green. The Phase 1 recovery prototype (a Cargo workspace called spa-recovery) exercises the same verification on the Sovereign Personal Agent recovery path, where a fresh agent with no prior state replays a chain from disk and either returns Ok for an untampered chain or Err identifying the broken link when a single byte has been altered. That is what "verifiable end-to-end" means at the implementation layer.

An example. A patient grants a pharmacy a standing read-and-cache grant over their immunization record. The pharmacy fills a prescription, which requires confirming the immunization status, then surfaces a claim to the patient's payer. The payer routes the claim to a provider for prior-authorization review. Three organizations, four receipts.

1. Patient → Pharmacy. Pharmacy reads under the standing grant. Gates evaluated: HIPAA minimum-necessary, state pharmacy-practice rule, the patient's no-further-disclosure restriction on note fields. Receipt R₁ emitted. prev_hash: None.
2. Pharmacy → Payer. Pharmacy discloses a de-identified summary. Gates: HIPAA disclosure-purpose, payer-jurisdiction (US-NY) acceptance. Receipt R₂ emitted, with prev_hash pointing to R₁.
3. Payer → Provider. Payer forwards prior-auth question. Provider is in a different jurisdiction. Gates: subject-jurisdiction US-NY, audience-jurisdiction US-VT, both gate sets respected. Receipt R₃.
4. Provider → Payer. Provider returns an authorization decision. Receipt R₄.

Each party holds the receipts they participated in. Nobody holds all four except the patient, whose substrate accumulates the chain. Six months later, the patient's regulator subpoenas evidence of compliance. The chain is produced. Hashes are recomputed. Signatures verify. The auditor walks from R₄ back to R₁ and reads, at each hop, which gates were evaluated and against which vocabulary version.

The auditor never needs the pharmacy's internal database, the payer's claims system, or the provider's prior-auth tool. The receipt chain is sufficient. That is the "without a shared log" claim made operational.

A difficult case the model must answer: there is no central arbiter. If Alice and Bob disagree about what a receipt said, they cannot appeal to a neutral third-party log because none exists. This is a design choice, not an oversight: the protocol is chain-neutral and does not depend on any distributed-ledger or central authority.

The mitigations stack, but do not eliminate the problem:

• Canonical serialization ensures both parties can independently recompute the receipt's hash and detect any post-hoc alteration of either copy.
• Bilateral signatures bind the parties; forging a counter-signed receipt requires compromising the counter-party's key.
• Rating systems (a steward-operated trust list) catch repeated misbehavior across many counter-parties, not individual disputes, but pattern misconduct that drops a provider's trust tier.
• Receipt data-minimization means the dispute surface is "what gates were evaluated against what field paths," not "what data did you actually disclose."

For most disputes, this is enough. For a single-shot bad-faith dispute between two parties with no prior history and no rating signal, there is no automatic resolution. The protocol prevents many disputes by making the audit deterministic; it does not eliminate human disagreement about meaning, and it does not pretend to.

The v2 attestation mode depends on infrastructure that does not exist yet: a governance regime for the zero-knowledge circuits that evaluate gates. The architecture's stated answer is that a neutral steward will curate the core circuits and domain bodies (healthcare standards organizations, financial-services bodies, government identity authorities) will bring their own circuits for their own gate vocabularies. The open qualifier: no domain body has signed up yet.

This matters for three reasons. First, ZK circuits are non-trivial cryptographic engineering, and the load is substantial. Second, when a regulation changes, a new GDPR interpretation, a new HIPAA rule, the circuit that evaluates compliance must change with it, on a timeline regulators can audit. Third, who decides what constitutes a correct gate-evaluation circuit? An attacker who controls circuit governance can make any disclosure look compliant.

The page should not pretend this is solved. v2 is a first-class specified mode that depends on a vocabulary registry, a circuit registry, and a domain-body steward network. The first exists; the second is sketched; the third has zero current commitments. Implementations that ship v1 today are betting that v2 will mature on the timeline they need. That bet may or may not pay out.

The receipt model addresses disputes over what a receipt said. A distinct threat is receipt suppression: a counterparty that never emits its signed receipt at all. Against a holder that fully controls the data and simply withholds its copy, bilateral signatures and canonical serialization offer limited protection. The bilateral model assumes participation; receipt non-emission is non-participation.

Receipt-as-precondition. The primary defense flips the incentive. Rather than treating a receipt as a logging obligation the holder may or may not honor, make a valid receipt the thing the beneficiary of the operation needs to complete the transaction.

• Spec (MUST): An audience receiving disclosed data MUST refuse to accept or act on that data unless it arrives with a valid, counter-signable receipt. A holder that practices receipt suppression produces data the audience cannot use. Non-emission now costs the discloser the transaction rather than only the audit trail.
• v0 deployment guidance (SHOULD): Audience refusal SHOULD be implemented where the receiving party is SLF-aware. The ecosystem gap is named: this precondition depends on a network of SLF-aware audiences willing to enforce refusal. Until that network exists, the precondition operates as a deployment choice, not an ambient guarantee.

For T1+ high-stakes flows, receipts or their hashes may optionally be appended to a user-controlled or steward-run transparency log, following the certificate-transparency pattern. Non-emission for a known operation becomes detectable when the user has independent signal the operation occurred. The base protocol is chain-neutral and carries no dependency on any distributed ledger or central authority; the witness is a deployment option for T1+ flows, not a base protocol requirement.

The residual: the protocol cannot force a self-interested party that fully controls both the data and the action to emit a receipt for a covert disclosure. What it can do is make the useful, completable, repeatable path require a receipt, so non-emission costs the non-emitter the transaction, a lower trust tier, and future grants. The threat model deep-dive covers receipt non-emission and gate-skip as named adversaries with a full tier-by-tier treatment.

• Regulators do not require these receipts. Regulators describe outcomes, not protocols. EU AI Act Article 86's right to explanation is subsidiary to GDPR Article 22 and does not mandate structured decision traces or bilateral retention.
• Receipts do not eliminate liability. They shift it from "did you store the data?" to "did you gate it correctly?" The burden on the provider does not disappear; it changes shape.
• v2 is not production-ready. The mode is specified. The governance infrastructure is not built. Implementations should plan for v1 today, v2 on a multi-year horizon.
• The Phase 1 prototype is not a production proof. It validates the chain mechanics on a reference implementation. Production claims wait on Phase 2.
• Bilateral receipts do not eliminate the need for arbiters. They eliminate the need for a protocol-operated central log. Dispute resolution still happens, via rating systems and post-hoc audit, and still sometimes by lawyers.
• The two-field jurisdiction model resolves detection, not conflict. A user in transit, an audience lying about jurisdiction, two jurisdictions imposing mutually incompatible obligations on the same fact, these remain open, and the protocol's answer is "fail closed."
• A party can refuse to emit its receipt. The bilateral model assumes both sides return a signed receipt. A counterparty that suppresses its half does not erase the user's: the user's side records the request and the missing counter-signature, so non-emission reads as non-completion, and the user's runtime can treat an unreceipted operation as denied and disclose nothing further. The protocol cannot force an honest receipt from a party that never participates; it can only make silence into evidence.

If you are reading this with an audit, regulatory, or implementation lens and the seams look wrong, if a claim is overstated, a tension is missing, a counter-claim is weak, that is the feedback the draft needs. Contact details are in the header above. Push back.