What is inside a .hvr receipt file.
A Hivemind receipt (.hvr) is a self-contained binary envelope built on IETF SCITT, COSE_Sign1, and RFC 9162 Merkle trees.
Every tool call can be evaluated against your policy and recorded whether executed or Blocked by rule.
| Field inside the receipt | Meaning | Example value |
|---|---|---|
action_id & issued_at |
Time-ordered identifier and UTC timestamp when the action was evaluated | 01M67A0W24WR3815YQV3E8ADT5 · 2026-10-30T21:04:01Z |
agent & principal |
Workload identity of the agent and salted SHA-256 commitment of the acting subject | spiffe://vectors.example/agent/1 · sha256:36d0f5407143b94853b826992599a6462e31d691952941b4488816c3e266107d |
operation |
Tool or API method called, risk tier, and SHA-256 digest of the canonical request | mcp · tools/call:refund · financial |
disposition |
Policy evaluation outcome: executed or Blocked by rule | executed or blocked (neutral/halted state) |
effect |
Downstream confirmation level (W0 to W3) |
confirmed · sha256:2a343547091f92a6a12687792817f4d35d8271654c86342670671e7c3386cca6 |
privacy |
Salted SHA-256 commitment and per-subject key deletion (crypto-shredding) envelope reference | io.hivemind.disclosure.default |
W-Level Confirmation Scale (W0 to W3).
Every W-level label across the site and verifier reads from this single canonical definition table (window.HR_W_LEVELS).
| Level | Classification | Definition |
|---|---|---|
| W0 | Dispatched | Tool call sent by the agent; no external validation or receipt. |
| W1 | Validated, not confirmed | Payload syntax or schema checked (such as PEPPOL or FatturaPA XML), without counterparty delivery receipt. |
| W2 | Counterparty-confirmed | Signed webhook, DKIM/ARC email receipt, or XMLDSig-signed bank confirmation (camt.054 / pain.002). |
| W3 | W2 + qualified seal/timestamp | W2 evidence plus a qualified electronic seal or qualified timestamp over that evidence. |
Standards and model-checking coverage.
All cryptographic and model-checking numbers below cite reproducible artifacts in the open-source receipts-spec/ and receipts-verify/ trees.
SCITT, COSE_Sign1 & ML-DSA-65
Receipts use media type application/vnd.hivemind.receipt+cose (.hvr), compatible with IETF SCITT (RFC 9943), COSE_Sign1 (RFC 9052), RFC 9162 Merkle trees, and C2SP tlog-checkpoint. Hypereum-operated keys (log checkpoint/receipt keys and Hivemind AX issuer keys) require EdDSA (-8) only; customer issuer statements verify against the registered algorithm list (EdDSA, ES256, ES384). The NIST FIPS 204 ML-DSA-65 implementation passes ACVP (180/180 ACVP test vectors via receipts-verify/vectors/acvp-mldsa65/run-acvp.mjs over sigGen-internalProjection.json and sigVer-internalProjection.json) but is not enabled in .hvr.
BBS on BLS12-381-SHA-256
Selective field disclosure implements draft-irtf-cfrg-bbs-signatures-09 on BLS12-381-SHA-256 (45/45 IETF fixtures passed: 10 keypair + 10 sign + 25 proof via receipts-verify/vectors/bbs-draft09/run-bbs-fixtures.mjs).
TLA+ TLC & mutation suite
Safety invariants on HivemindReceipts.tla are checked by the TLA+ TLC model checker (receipts-spec/spec/HivemindReceipts.tla, receipts-spec/spec/HivemindReceipts.cfg, receipts-spec/spec/tlc-output.txt, and killed-mutant specifications in receipts-spec/spec/mutants/).