Receipt Format

Synopsis

ChioReceipt binds a request, the kernel's decision or observation, and the execution context into one signed, content-addressed record. The same record carries guard evidence, delivery commitments, spending authority, and settlement metadata. The format is chio.receipt.v1, a schema name with no matching top-level schema or version field. The wire record is flat, its schema rejects unknown top-level fields, and signing rebuilds this nested payload from those fields:

id = SHA-256(canonical_json(ChioReceiptIdInput))

signed payload = {
  id,
  body: ChioReceiptIdInput,
  bbs_signature?           // included when present
}

signature = sign(canonical_json(signed payload))

The smallest complete record is the allowed call that the first-call example captured from the installed chio. The inspector recomputes its id and parameter hash from the receipt alone.

// schema: chio.receipt.v1
pub struct ChioReceipt {
    pub id: String,
    pub timestamp: u64,
    pub capability_id: String,
    pub tool_server: String,
    pub tool_name: String,
    pub action: ToolCallAction,
    pub decision: Option<Decision>,  // omitted when None
    pub receipt_kind: ReceiptKind,
    pub boundary_class: BoundaryClass,
    pub observation_outcome: Option<ObservationOutcome>,  // omitted when None
    pub tool_origin: ToolOrigin,
    pub redaction_mode: RedactionMode,
    pub actor_chain: Vec<ActorRef>,  // omitted when empty
    pub content_hash: String,
    pub policy_hash: String,
    pub evidence: Vec<GuardEvidence>,  // omitted when empty
    pub metadata: Option<serde_json::Value>,  // omitted when None
    pub trust_level: TrustLevel,
    pub tenant_id: Option<String>,  // omitted when None
    pub bbs_projection_version: Option<String>,  // omitted when None
    pub kernel_key: PublicKey,
    pub bbs_signature: Option<BbsReceiptSignature>,  // omitted when None
    pub algorithm: Option<SigningAlgorithm>,  // omitted when None or ed25519
    pub signature: Signature,
}

ChioReceipt fields

The record has 24 fields. 20 enter the id preimage, and 22 can fall under the signed payload, counting optional BBS material. Optional fields leave the wire under their serialization rules, and the receipt kind adds requirements of its own.

id

timestamp

capability_id

tool_server

tool_name

action

decision

receipt_kind

boundary_class

observation_outcome

tool_origin

redaction_mode

actor_chain

content_hash

policy_hash

evidence

metadata

trust_level

tenant_id

bbs_projection_version

kernel_key

bbs_signature

algorithm

signature

Field relationships

Validate related fields together. The record schema states their wire requirements; the Rust signing and verification paths enforce the signed semantics.

receipt_kind, boundary_class, trust_level

Match one of the three semantic pairings. Mediated records carry a decision; trace and advisory records carry an observation outcome.

bbs_projection_version, bbs_signature

Both present or both absent. The version is chio.bbs-projection.receipt.v1. The version enters the id; the BBS material falls under the outer signature.

algorithm, signature

verify_signature_with_floor returns AlgorithmMismatch when the hint disagrees with the signature material. Plain verify_signature ignores the envelope hint.

content_hash, supplied output

The kernel hashes the original canonical content preimage before signing: canonical JSON for a value output, the per-chunk digest preimage for a stream, canonical null for an empty output. An independent check of the output commitment needs that preimage.

Decision

Decision is an internally tagged enum. The tag field is verdict, and variant names serialize in snake_case.

The specification keeps cancelled and incomplete outcomes as distinct verdicts, separate from any error state.

The refused call the first-call example captured records its reason in decision.reason. Its guard is kernel, and the receipt carries no evidence entries: capability-scope validation refused the call before the guard pipeline ran.

$ chio --receipt-db .chio/receipts.db --session-db "$(mktemp -d)/admission.db" check \
    --policy ./policy.yaml --server hello --tool drop_tables --params '{}'

verdict:    DENY
tool:       drop_tables
server:     hello
reason:     requested tool drop_tables on server hello is not in capability scope
receipt_id: 28b6e2576ca2ccbd031e769d8d2bd504317161115a600f27771a7f932307a284
policy:     69e943b96e9ce64d0264bb56bf8930e77bd4e68adf68fcf1395790dae03e6b55
source:     0d35135e8b19230b7aa42b0cc5982579450f5dc4a0280822e8b339e7786d2296
mode:       preflight
fixture:    false

WARN chio_kernel::kernel::evaluation::async_evaluation_core message=capability rejected request_id=check-001 reason=requested tool drop_tables on server hello is not in capability scope

ToolCallAction

The action the kernel evaluated.

ToolCallAction::from_parameters computes parameter_hash as the SHA-256 of the RFC 8785 canonical JSON of parameters, and verify_hash recomputes it. The schema fixes the hash at 64 lowercase hex characters. The receipt inspectors under Synopsis and Decision recompute it from the captured receipts.

GuardEvidence

One entry per guard that evaluated the call. The evidence array leaves the wire when it is empty, so the two captured receipts carry none.

Signed semantic fields

Six enums classify what a receipt claims. Each serializes in snake_case, and each value is under the signature.

ReceiptKind

BoundaryClass

ObservationOutcome

ToolOrigin

RedactionMode

TrustLevel

Semantic pairings

validate_decision and validate_signable_semantics accept exactly these combinations, and the record schema states the same rule as conditional requirements.

is_authorized is true only for mediated_decision with prevent, no observation outcome, and an allow decision. ChioReceipt::is_allowed adds trust_level == mediated.

result_label renders that case as Authorized. A trace record is Observed and an advisory record Advisory; any other mediated decision is Allowed, Denied, Cancelled, or Incomplete, and a mediated record with no decision is Invalid. Trace and advisory records are evidence, never authorization.

Kernel metadata blocks

The kernel writes its typed blocks under reserved top-level metadata keys. Each producer applies its merge or collision rule before signing. A verifier checks the block's typed contract and trusts the enclosing receipt's signer; the key's presence alone carries no authority.

The admission terminal enforces the collision rejection for delivery_contract, finding_delivery, and finding_recovery. The allow path merges attribution after caller metadata, with the last write winning on each nested key. The keys chio-core-types declares, read from its constants:

Two reserved keys in the specification are defined outside those constants. original_metadata is written by the signing path when a caller passed a non-object metadata value: the value moves under that key before the nonce is inserted. admission_operation is ADMISSION_RECEIPT_METADATA_KEY with schema ADMISSION_RECEIPT_SCHEMA, declared in the kernel's admission module. Keys outside the reserved set, such as the receipt_context block the captured receipts carry, have no typed reader in chio-core-types.

admission_operation

A durable governed call carries an admission_operation block with schema chio.admission-receipt.v1. It binds the signed receipt to the admission operation and request namespace, the terminal projection and dispatch state, trusted time, the coordinator lease and store fence, the retained dispatch commit, and the optional tool outcome. Unknown fields and unsupported schema versions fail closed.

The typed writer is AdmissionReceiptMetadataV1, declared deny_unknown_fields. The wire contract is admission-metadata.schema.json, which requires every field below.

projected_state takes the wire name of one of the 18 states of AdmissionOperationState, 7 of them terminal. The allow receipt under Synopsis carries this block with projected_state completed.

delivery_contract

A digest-constrained governed call carries a delivery_contract block with schema chio.delivery-contract.v1: the expected_digest the grant fixed in advance, the observed_digest of the delivered output, both canonical lowercase 64-character hex SHA-256, and a result of matched or mismatched. The block appears only when the exercised grant carried an output-digest constraint: matched accompanies an Allow, and mismatched accompanies the persisted zero-charge Deny. The enclosing receipt authenticates the block, which carries no signature of its own.

The typed struct is DeliveryContract, declared deny_unknown_fields. On a mismatch, observed_digest is a domain-separated commitment keyed by the expected digest, and the delivered output digest stays in privileged durable outcome evidence. DeliveryContract::validate checks the pinned schema and both hex digests and leaves result as recorded; ChioReceipt::delivery_contract reads the block. Delivery contract covers the digest comparison behind it.

finding_delivery

A reveal admitted under a provider-signed finding purchase marker carries a finding_delivery block beside the generic one, schema chio.finding.delivery.v1. It names the finding_id and listing_id the sale was admitted under, the kernel-proved transform_profile, the digest_check and media_type_check comparisons, the settlement_mode the admitted selector named, the canonical SHA-256 digests of the accepted-bid and venue-admission envelopes, and the authoritative reservation_id, purchase_intent_id, and authoritative_payment_operation_id. Every field derives from kernel-verified state, never from a caller-asserted value, and the block appears only when the purchase context arrived through verified signed records.

The struct is FindingDelivery. Its enums: transform_profile is identity; digest_check is matched or mismatched; media_type_check is matched, mismatched, or not_evaluated; settlement_mode is local_reversible_hold. An optional status_proof carries the kernel-verified non-inclusion evidence for the delivered finding: feed_id, key_domain_nonce (the fixed constant 3318287169837494), map_epoch, status_epoch_artifact_sha256, proof_sha256, root_hash, and non_inclusion_checked_at.

A no-charge redelivery under a recovery grant carries finding_recovery instead, schema chio.finding.recovery.v1, with recovery_id, finding_id, original_capability_id, original_delivery_receipt_id, and purchase_key.

budget_authority

A monetary receipt carries a budget_authority block with the budget hold lineage. The typed reader is FinancialBudgetAuthorityReceiptMetadata: guarantee_level, authority_profile, metering_profile, hold_id, optional budget_term, optional authority ({ authority_id, lease_id, lease_epoch }), authorize (optional event_id and budget_commit_index, exposure_units, committed_cost_units_after), and optional terminal (disposition, the same event fields, exposure_units, realized_spend_units, committed_cost_units_after).

The kernel writes the block in two shapes. The store profile alone (guarantee_level, authority_profile, metering_profile) comes from budget_backend_receipt_metadata. A charge writes the full lineage through budget_execution_receipt_metadata, which also adds invocation_capture when a quota was captured and, when an execution nonce was presented, execution_nonce_id and mediated_spend.profile. The typed reader skips keys it does not declare, and ChioReceipt::financial_budget_authority_metadata reads the block. Authoritative Spend covers the checks over this block and the execution nonce.

Other reserved keys

• attribution: ReceiptAttributionMetadata, with the capability's subject_key and issuer_key, delegation_depth, and grant_index when the request resolved to one grant. The kernel writes it on every allow and deny it signs from a capability. Both captured receipts carry it.
• chio_receipt_signing_nonce: bound by bind_receipt_signing_nonce before the id is computed, as Receipt id and signing describes.
• financial and governed_transaction: the two sections that follow.
• channel: ChannelReceiptMetadataV1, camelCase and deny_unknown_fields, with schema pinned to chio.channel.receipt-metadata.v1, channelId, openDigest, reservationId, reservationDigest (each 64 lowercase hex), sequence (a positive I-JSON integer), and settlementMode channelized.

Financial metadata

For an allow receipt under a monetary grant, the kernel serializes FinancialReceiptMetadata under the financial key. A refusal caused by budget exhaustion carries attempted_cost with the cost that would have been charged. ChioReceipt::financial_metadata reads the block.

The struct documents three invariants the kernel upholds when it builds the block, beyond what the type system checks: cost_charged <= budget_total; budget_remaining reflects the post-charge balance at write time and may be a best-effort snapshot at read time under an HA split; and on a refusal cost_charged is 0 and attempted_cost holds the rejected cost.

SettlementStatus

OracleConversionEvidence

The cross-currency conversion evidence under financial.oracle_evidence. The struct is deny_unknown_fields, its schema is the constant chio.oracle-conversion-evidence.v1, and its field names and types are the contract, with no per-field doc comments.

Governed transaction metadata

A request that carried a governed intent gets a governed_transaction block holding the intent identifiers and the approval, commerce, metering, runtime-assurance, call-chain, and autonomy evidence the kernel verified. The struct is GovernedTransactionReceiptMetadata; the kernel assembles it in governed_request_metadata and reads it back through ChioReceipt::governed_transaction_metadata.

intent_idString

Governed transaction intent identifier.

intent_hashString

Canonical intent hash used for approval-token binding.

purposeString

Human or policy-readable purpose.

server_idString

Target tool server from the intent.

tool_nameString

Target tool name from the intent.

max_amountOption<MonetaryAmount>

Explicit spend bound carried on the intent: { units, currency } in minor units.

commerceOption<GovernedCommerceReceiptMetadata>

Seller-scoped commerce approval evidence: seller, shared_payment_token_id, optional settlement_destination_ref.

metered_billingOption<MeteredBillingReceiptMetadata>

camelCase: settlementMode, quote, optional maxBilledUnits, optional usageEvidence (evidenceKind, evidenceId, observedUnits, optional evidenceSha256). The kernel writes no usage evidence at signing time.

approvalOption<GovernedApprovalReceiptMetadata>

token_id, approver_key (hex), optional approval_artifact_digest, approved. A threshold-approval proposal fills it with the proposal id and the policy authority key.

runtime_assuranceOption<RuntimeAssuranceReceiptMetadata>

camelCase: schema, optional verifierFamily, tier (the tier accepted after any verifier trust-policy rebinding), verifier, evidenceSha256, optional workloadIdentity.

call_chainOption<GovernedCallChainProvenance>

camelCase: evidenceClass, evidenceSources, optional upstreamProof, assertedContext, continuationTokenId, sessionAnchorId, receiptLineageStatementId, plus the flattened context chainId, parentRequestId, optional parentReceiptId, originSubject, delegatorSubject. The flattened fields are the effective projection; a preserved caller assertion sits under assertedContext and is unverified.

autonomyOption<GovernedAutonomyReceiptMetadata>

camelCase: tier, optional delegationBondId.

economic_authorizationOption<EconomicAuthorizationReceiptMetadata>

The versioned economic envelope below.

economic_authorization

EconomicAuthorizationReceiptMetadata keeps budget, meter, rail, and settlement facts in separate typed sub-blocks, serialized in snake_case. It is additive: the financial, commerce, metered_billing, approval, runtime_assurance, call_chain, and autonomy fields stay beside it.

The kernel attaches the envelope only when the request carried a governed intent and a verified payee binding. It refuses to sign when the binding disagrees with the intent digest, the seller, the settlement destination, or the approval digest.

versionEconomicAuthorizationReceiptMetadataVersion

Serialized v1.

economic_intent_digestOption<String>

Omitted when None. The kernel sets it from the verified payee binding.

payee_binding_digestOption<String>

Omitted when None. Set from the payee binding.

pre_action_authority_digestOption<String>

Omitted when None. Set from the payee binding.

credit_authority_digestOption<String>

Omitted when None. The kernel leaves it unset.

economic_modeEconomicAuthorizationMode

budget_only, prepaid_fixed, hold_capture, metered_hold_capture, or external_dispatch; chosen from the metered settlement mode, else from the presence of a payment reference.

payerEconomicPayerReceiptMetadata

party_id, funding_source_ref, optional custody_provider, optional obligor_ref.

merchantEconomicMerchantReceiptMetadata

merchant_id, optional merchant_of_record, optional order_ref.

payeeEconomicPayeeReceiptMetadata

beneficiary_id, settlement_destination_ref.

railEconomicRailReceiptMetadata

kind, asset, optional network, facilitator, contract_or_account_ref. The kernel writes kind shared_payment_token.

amount_boundsEconomicAmountBoundsReceiptMetadata

approved_max, optional hold_amount, settlement_cap, each a MonetaryAmount.

pricing_basisOption<EconomicPricingBasisReceiptMetadata>

Optional quote_hash, tariff_hash, quote_expiry. Omitted when None.

meteringOption<EconomicMeteringReceiptMetadata>

provider, meter_profile_hash, optional max_billable_units, optional billing_unit. Omitted when None.

liability_refsOption<EconomicLiabilityReceiptMetadata>

Optional bond_id, policy_id, indemnity_ref, dispute_policy_ref. Omitted when None; the kernel leaves it unset.

budgetEconomicBudgetReceiptMetadata

grant_index, cost_charged, currency, budget_remaining, budget_total, delegation_depth, root_budget_holder, optional attempted_cost, copied from the financial block.

settlementEconomicSettlementReceiptMetadata

settlement_status.

Receipt id and signing

The kernel checks the content preimage before it prepares or signs the receipt body. Preparation validates the semantics, binds the caller nonce, and derives the id; the final signature authenticates the rebuilt signing payload.

1. Check the content and signer binding. chio_kernel_core::receipts::sign_receipt recomputes content_hash from the supplied canonical content preimage. A mismatch returns ContentHashMismatch, and a body key that differs from the backend key returns KernelKeyMismatch. Both checks run before signing.
2. Validate the semantics. validate_signable_semantics rejects a body whose kind, boundary, observation outcome, decision, and trust level fall outside the accepted pairings.
3. Bind the signing nonce. bind_receipt_signing_nonce takes the caller-supplied body.id, trimmed, and writes it to metadata.chio_receipt_signing_nonce. A non-object metadata value moves under original_metadata first, and an empty id skips the binding. Because metadata is in the id preimage, the nonce falls under the id and the signature.
4. Compute the id. id = sha256_hex(canonical_json_bytes(ChioReceiptIdInput)) over the nonce-bound body. Canonical JSON is RFC 8785: keys sorted, no whitespace, deterministic number formatting. The preimage holds the 20 body fields, including kernel_key and the optional BBS projection version, and leaves out the id and all signature material.
5. Sign the signing body. ChioReceiptSigningBody is { id, body: ChioReceiptIdInput, bbs_signature? }, and its canonical JSON is signed with the kernel key. ChioReceipt::sign with an Ed25519 keypair leaves algorithm unset, and sign_with_backend records the backend algorithm. Both refuse a kernel_key that differs from the signer key.

The wire record then adds the optional algorithm hint and the outer signature, both outside the signed payload. sign_receipt_with_handle consumes a one-time ReceiptSigningHandle, so one handle backs at most one signature.

Transport adapters use a distinct path: sign_receipt_relaying_trusted_body accepts the content hash the upstream caller already computed. That FFI and WASM relay signs the hash as given, without reconstructing the content preimage.

Key and signature encodings

kernel_key and signature are hex strings whose prefix selects the algorithm. Bare hex is Ed25519 (32-byte key, 64-byte signature); p256: and p384: select ECDSA with an uncompressed SEC1 point as the key and DER as the signature; hybrid: carries a classical part, ML-DSA-65 bytes, and the algorithm set. PublicKey::from_hex, Signature::from_hex, and to_hex implement the encodings, and the record schema fixes the wire patterns:

kernel_key  ^([0-9a-f]{64}|p256:04[0-9a-f]{128}|p384:04[0-9a-f]{192}|hybrid:[0-9a-f]{64}:[0-9a-f]{3904}:ed25519\+mldsa65|hybrid:p256:04[0-9a-f]{128}:[0-9a-f]{3904}:p256\+mldsa65|hybrid:p384:04[0-9a-f]{192}:[0-9a-f]{3904}:p384\+mldsa65)$
signature   ^([0-9a-f]{128}|p256:([0-9a-f]{2})+|p384:([0-9a-f]{2})+|hybrid:[0-9a-f]{128}:[0-9a-f]{6618}:ed25519\+mldsa65|hybrid:p256:([0-9a-f]{2})+:[0-9a-f]{6618}:p256\+mldsa65|hybrid:p384:([0-9a-f]{2})+:[0-9a-f]{6618}:p384\+mldsa65)$

Verification dispatches off the signature material, and verify_signature_with_floor applies a ReceiptCryptoFloor before the cryptographic check: allow_classical (the default) rejects hybrid receipts, pq_required rejects classical ones, and allow_hybrid accepts both.

Verification

Verify the record's integrity against its embedded key, then decide whether your deployment trusts that key. ChioReceipt::verify_signature runs four checks in order, and a failed check verifies as false:

1. Semantics. validate_signable_semantics on the extracted body; a rejected pairing verifies as false.
2. BBS binding. validate_bbs_receipt_binding between bbs_projection_version and bbs_signature. It checks the binding and the material's shape; cryptographic verification of the BBS proof is a separate step.
3. Id. chio_receipt_id(body) must equal id, so a tampered identity-defining field verifies as false.
4. Signature. kernel_key.verify_canonical over the rebuilt ChioReceiptSigningBody.

ToolCallAction::verify_hash checks parameter_hash separately. Trusted kernel keys and accepted algorithms come from the verifier's own configuration: compare kernel_key with your trust store, because a receipt cannot establish its own signer's authority.

The signature authenticates the recorded content_hash. To check an output supplied separately, rebuild and hash that output's content preimage. A valid signature leaves the output's truth, the log's completeness, and effects outside the recorded mediation boundary to other evidence, as the assurance model sets out.

TypeScript verifier

verifyReceipt(receipt, trustedSigners) in @chio-protocol/sdk/invariants is synchronous and returns a ReceiptVerification with snake_case fields. signature_valid requires the id to verify and the semantics to be signable. signer_trusted is true only when kernel_key matches a supplied signer, so ok is false for an empty trusted set. authorized adds the mediated-decision, prevent, and allow test.

A signature in an algorithm the SDK does not implement verifies as false instead of throwing. verifyReceiptJson parses and verifies text with no trusted signers. parseReceiptJson parses JSON syntax and casts the result without validating the receipt schema, and structurally malformed input can throw before the cryptographic check, so validate the record shape at ingestion.

The helper's id and signing-body projections omit the BBS fields. Use it for receipts without BBS material, and verify BBS-bound records with the Rust verifier.

import {
  type ChioReceipt,
  verifyReceipt,
} from "@chio-protocol/sdk/invariants";

// Precondition: validate the wire schema at ingestion.
// This helper supports receipts without BBS material.
export function inspectReceipt(
  receipt: ChioReceipt,
  trustedKernelKeys: string[], // from deployment configuration
) {
  const result = verifyReceipt(receipt, trustedKernelKeys);

  if (!result.ok) throw new Error("Receipt integrity or signer trust failed");

  // A trusted denial passes integrity checks but is not authorization.
  return { authorized: result.authorized, outcome: result.result };
}

Evidence export

chio evidence export writes a verifiable package from the receipt store. The export takes the same tenant boundary as a listing, --tenant or --admin-all, and --require-proofs fails it when a selected receipt lacks checkpoint coverage.

$ chio --receipt-db .chio/receipts.db evidence export --admin-all --output ./evidence
$ ls evidence

README.txt
capability-lineage.ndjson
checkpoint-consistency-proofs.ndjson
checkpoint-equivocations.ndjson
checkpoint-publications.ndjson
checkpoint-witnesses.ndjson
checkpoints.ndjson
child-receipts.ndjson
inclusion-proofs.ndjson
manifest.json
query.json
receipts.ndjson
retention.json

Evidence verification

chio evidence verify checks one package offline. To pin the signer, pass a partner card with --partner or a kernel key with --trusted-kernel-pubkey; the output then states that signatures verified against pinned keys.

$ chio evidence verify --input ./evidence

evidence package verified
tool_receipts:          2
child_receipts:         0
checkpoints:            0
checkpoint_publications: 0
checkpoint_witnesses:   0
checkpoint_consistency_proofs: 0
checkpoint_equivocations: 0
capability_lineage:     2
inclusion_proofs:       0
uncheckpointed_receipts: 2
authorized_receipts:     1
trace_observations:      0
advisory_evaluations:    0
verified_files:         12
child_receipt_scope:    FullQueryWindow
transparency_preview_logs: 0
publication_state:      transparency_preview

Tampered package

One appended byte in receipts.ndjson moves the file hash the manifest committed to. The verify step exits 1 and names the file, so a script branches on the exit code.

$ cp -R evidence evidence-tampered
$ printf '\n' >> evidence-tampered/receipts.ndjson
$ chio evidence verify --input ./evidence-tampered

error[CHIO-ATTEST-PROVENANCE-MISSING]: evidence package file hash mismatch for receipts.ndjson
  help: receipts.ndjson changed after the package was exported; verify the package as exported, or export it again
  code: urn:chio:error:attest:provenance-missing
  docs: https://chio.computer/docs/reference/errors#error-attest-provenance-missing

Receipt querying

chio receipt list reads the local store and prints one JSON receipt per line. The HTTP routes with the same filters and cursor pagination are on Receipt Query API, and Query audit receipts builds an operational view from them.

The read fails closed when neither --tenant nor --admin-all is supplied, and clap refuses --min-cost or --max-cost without --cost-currency. The first-call example lists its store with a jq projection:

$ chio --receipt-db .chio/receipts.db receipt list --admin-all \
    | jq -r '[.decision.verdict, .tool_server, .tool_name, .id] | @tsv'

allow	hello	hello_world	448440b65fa15559a364d24512cbe4f08631befe2c3d2ab471dad7204b8b69c8
deny	hello	drop_tables	28b6e2576ca2ccbd031e769d8d2bd504317161115a600f27771a7f932307a284

$ chio --receipt-db .chio/receipts.db receipt list --admin-all \
    | jq 'select(.decision.verdict == "deny")'

{
  "id": "28b6e2576ca2ccbd031e769d8d2bd504317161115a600f27771a7f932307a284",
  "timestamp": 1788529912,
  "capability_id": "cap-01a06cb0-aae3-7ad3-8ba7-01350a3e01a0",
  "tool_server": "hello",
  "tool_name": "drop_tables",
  "action": {
    "parameters": {},
    "parameter_hash": "44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a"
  },
  "decision": {
    "verdict": "deny",
    "reason": "requested tool drop_tables on server hello is not in capability scope",
    "guard": "kernel"
  },
  "receipt_kind": "mediated_decision",
  "boundary_class": "prevent",
  "tool_origin": "caller_executed",
  "redaction_mode": "none",
  "content_hash": "74234e98afe7498fb5daf1f36ac2d78acc339464f950703b8c019892f982b90b",
  "policy_hash": "69e943b96e9ce64d0264bb56bf8930e77bd4e68adf68fcf1395790dae03e6b55",
  "metadata": {
    "attribution": {
      "delegation_depth": 0,
      "issuer_key": "3dbf7b1230475796d5c78cdcf441c84721d9e3c24362fbbfb4225e307d1b9fb4",
      "subject_key": "af2da8097f2c133affd89145302f029c7a5854e4e3a692a92b0cd20f84d07b37"
    },
    "chio_receipt_signing_nonce": "rcpt-01a06cb0-ab51-70d0-bcb3-72a8b78fe057",
    "receipt_context": {
      "request_id": "check-001"
    }
  },
  "trust_level": "mediated",
  "kernel_key": "3dbf7b1230475796d5c78cdcf441c84721d9e3c24362fbbfb4225e307d1b9fb4",
  "signature": "e89f7a9cbe6c6b207cf5ac0c3e197a3957d62d2994217a7dcaeeeb9869abef1233680328432ee7a502a76238eb6ee9e72b19715e2458a3ef85aebfbed0df9202"
}

chio receipt explain renders one receipt as a triage summary. It takes the receipt id, an optional --input-file holding one receipt or a bilateral co-sign document, --depth (default 8) and --fanout-limit (default 32) for the parent rendering, --inspect-bilateral for a structural trace of a bilateral envelope without signature verification, and the same tenant boundary.

$ DENY=$(chio --receipt-db .chio/receipts.db receipt list --admin-all \
    | jq -r 'select(.decision.verdict == "deny") | .id')
$ chio --receipt-db .chio/receipts.db receipt explain "$DENY" --admin-all

receipt: 28b6e2576ca2ccbd031e769d8d2bd504317161115a600f27771a7f932307a284
schema: chio.receipt.v1
identity: 28b6e2576ca2ccbd031e769d8d2bd504317161115a600f27771a7f932307a284
decision: deny
reason: requested tool drop_tables on server hello is not in capability scope
guard: kernel
policy_hash: 69e943b96e9ce64d0264bb56bf8930e77bd4e68adf68fcf1395790dae03e6b55
scope_diff: requested scope vs granted scope is not embedded in this receipt
parents: 0
repair_hint: inspect the guard and policy_hash, then mint or narrow a matching capability

Storage and checkpoints

The local receipt store keeps every signed receipt with a sequence number. chio receipt checkpoint create signs the next batch as a kernel checkpoint with the kernel signing key and a batch bound (--max-batch, default 1024). status and verify report and check the chain, and chio receipt audit runs the claim-log projection validation plus the full chain check.

KernelCheckpointBody, declared deny_unknown_fields, carries schema, checkpoint_seq, batch_start_seq, batch_end_seq, tree_size, merkle_root, issued_at, kernel_key, and the optional previous_checkpoint_sha256 and chain_root (an RFC 6962 root over the checkpoint-chain leaves that consistency proofs verify against). KernelCheckpoint is that body plus an Ed25519 signature over its canonical JSON.

ReceiptInclusionProof names the checkpoint_seq, receipt_seq, leaf_index, merkle_root, and a MerkleProof, and verifies the receipt's canonical bytes against an expected root. Its wire form is inclusion-proof.schema.json: tree_size (at least 1), leaf_index (below tree_size), and audit_path, the ordered sibling hashes from the leaf up to the root, each 32 bytes as lowercase hex with a 0x prefix, with right-edge siblings carried upward without pairing omitted. The evidence package from Evidence export carries the checkpoints and inclusion proofs as NDJSON files beside the receipts.

Receipt lineage

Lineage between receipts lives in a separate signed record, the ReceiptLineageStatement, with schema chio.receipt_lineage_statement.v1; ChioReceipt itself has no lineage field. One statement links one parent receipt to one child receipt, and multi-parent views are derived aggregates over these pairwise statements. The body serializes in camelCase, the signed record adds signature over the canonical JSON of the body, and verify_signature checks the pinned schema before the key.

finding_memory_write_to_delivery links a governed memory write to the verified finding delivery receipt it depends on. The crate also defines the ordering types a DAG verifier uses: ReceiptHybridLogicalClock (wallSeconds, logical, kernelId; camelCase, deny_unknown_fields), whose advance_from_parent takes the larger wall clock and increments the logical counter on a tie; ReceiptDagParent (receiptId, chainId, dagOrdinal); and parent_set_hash, the SHA-256 of the canonical JSON of the sorted, deduplicated parent receipt ids.

The record that carries chain_id, parent_set_hash, and dag_ordinal is the swarm join receipt, specified on Swarm Protocol.

Child request receipts

Nested flows such as sampling, elicitation, and resource reads under a parent call produce a ChildRequestReceipt. The signature covers the canonical JSON of ChildRequestReceiptBody, the record without algorithm and signature. The child links to its parent through parent_request_id; a lineage statement is a separate record.