Skip to content

Proposal: processing receipts (signed, value-free provenance manifests) #71

Description

@mazzasaverio

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:

  1. Canonical serialization (sorted keys, fixed number formatting) so digests are reproducible across platforms.
  2. 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.
  3. 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

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions