Context
Software supply chain went through exactly this arc: after the 2021 incidents, "we build securely" stopped being acceptable and SBOM/SLSA-style machine-verifiable evidence became a procurement requirement. Data privacy is earlier on the same curve: the EU AI Act brings record-keeping obligations, EDPB guidance asks for demonstrable safeguards, and auditors are starting to ask not "do you redact?" but "prove that this artifact went through redaction, with which policy, when".
The engine already computes everything an auditor needs (statistics, detector provenance, policy, versions) under the safe-report invariant. What is missing is a canonical, portable, verifiable artifact.
Proposal
A processing receipt: a canonical JSON manifest emitted alongside any processing result, containing only value-free facts:
- digest of the source and of the output (whole-artifact hashes, no spans);
- digest of the effective policy and the engine + detector/backends versions;
- detection statistics per entity type (counts only) and transformation mode;
- timestamp and an optional caller-supplied context label.
Plus:
- Canonical serialization (sorted keys, fixed number formatting) so digests are reproducible across platforms.
- Optional integrity tag: HMAC over the canonical form with a caller key (stdlib-only, fits the zero-dependency core); asymmetric signatures stay caller-side or in a narrow extra.
- A verifier:
pseudonymize verify-receipt <file> <receipt> recomputes digests and checks the tag, so a third party can validate that this output came from this input under this policy.
Order-of-effects reasoning
- First order: teams satisfy record-keeping obligations with a generated artifact instead of a wiki page.
- Second order: receipts make privacy processing composable across teams: a data consumer can require a receipt instead of trusting a producer's word.
- Third order: "receipt required" becomes a data-exchange norm the way SBOMs did for software; insurers and auditors consume them.
- Fourth order: whoever ships the reference format first defines it; a library is bought or displaced, a format with a verifier is not.
The safe-report principle is what makes this credible: a receipt from a tool that can leak matched values into reports would be worthless as evidence.
🤖 Generated with Claude Code
https://claude.ai/code/session_012JiX3zWeEC28kmy5KmAXvf
Context
Software supply chain went through exactly this arc: after the 2021 incidents, "we build securely" stopped being acceptable and SBOM/SLSA-style machine-verifiable evidence became a procurement requirement. Data privacy is earlier on the same curve: the EU AI Act brings record-keeping obligations, EDPB guidance asks for demonstrable safeguards, and auditors are starting to ask not "do you redact?" but "prove that this artifact went through redaction, with which policy, when".
The engine already computes everything an auditor needs (statistics, detector provenance, policy, versions) under the safe-report invariant. What is missing is a canonical, portable, verifiable artifact.
Proposal
A processing receipt: a canonical JSON manifest emitted alongside any processing result, containing only value-free facts:
Plus:
pseudonymize verify-receipt <file> <receipt>recomputes digests and checks the tag, so a third party can validate that this output came from this input under this policy.Order-of-effects reasoning
The safe-report principle is what makes this credible: a receipt from a tool that can leak matched values into reports would be worthless as evidence.
🤖 Generated with Claude Code
https://claude.ai/code/session_012JiX3zWeEC28kmy5KmAXvf