The envelope is the top-level compatibility boundary for the entire standard. If two systems agree on envelope semantics, they can exchange and verify receipts even when implementation stacks differ.

Required Fields

  • spec: identifies the standard (name, version).
  • id: globally unique receipt identifier (urn:uuid:<uuid>).
  • type: category/kind/version tuple for domain classification.
  • timestamp: issuance and lifecycle timestamps.
  • payload: core business content (intent, subject, scope, optional outcomes).
  • signatures: one or more detached cryptographic assertions.

Optional Fields

  • hashChain: sequence-level tamper-evidence linkage metadata.
  • extensions: namespaced custom data (reverse.domain convention).

Envelope Invariants

  • Producers MUST populate all required top-level fields.
  • Verifiers SHOULD reject envelopes missing required fields or with invalid formats.
  • Unknown extension namespaces MUST be preserved during relay/storage.
  • Signature generation MUST use the sanitized envelope view defined in Signatures.

Minimal Shape

{
  "spec": { "name": "reciprium-receipt", "version": "1.0.0" },
  "id": "urn:uuid:...",
  "type": {
    "category": "infrastructure",
    "kind": "terraform",
    "version": "v1"
  },
  "timestamp": { "issuedAt": "2026-02-24T00:00:00Z" },
  "payload": { "intent": {}, "subject": {}, "scope": {} },
  "signatures": []
}

When chaining is enabled, include hashChain metadata:

{
  "hashChain": {
    "chainId": "default",
    "sequence": 1,
    "hash": {},
    "prevHash": {}
  }
}

Reference contract: v1/schema/envelope.json

Related: Hash Chain