Reciprium receipts are cryptographically verifiable records of operational mutations across infrastructure, data, access, configuration, and security domains.

What a Receipt Captures

Every receipt envelope includes:

  • Contract identity: spec name/version and receipt type metadata.
  • Intent context: what was authorized and what artifact was approved.
  • Actor context: principal/session/client identities and optional delegates.
  • Scope context: target path, resources, and constraints.
  • Outcome evidence: optional execution and verification sections.
  • Integrity metadata: signatures and optional hash-chain linkage.

Design Goals

  1. Portable verification: a verifier can validate structure, signatures, and integrity metadata without querying the original control plane.
  2. Interoperability: consistent semantics across JSON Schema, CDDL, Protobuf, and SDK implementations.
  3. Extensibility without drift: strict core contract plus namespaced extensions.
  4. Auditable trust signaling: explicit verification outcomes and clear threat boundaries.

Non-Goals

  • Reciprium does not force one storage backend.
  • Reciprium does not define a global PKI policy for all deployments.
  • Reciprium does not claim independent publication guarantees from hash chaining alone.

Lifecycle at a Glance

  1. Build envelope (intent, subject, scope).
  2. Execute mutation and add execution evidence.
  3. Run checks and add verification assertions.
  4. Canonicalize and sign using v1 signature rules.
  5. Optionally chain with hashChain metadata.
  6. Store and relay while preserving unknown extensions.

Continue with Envelope for the exact boundary contract.