Verifiable Evidence

Merkle Receipt Log

The kernel periodically batches pending receipts and commits the batch into a Merkle tree, the same construction Certificate Transparency logs use under RFC 6962. Each commit produces a KernelCheckpoint: a signed signed record of the tree's size and root hash, plus previous_checkpoint_sha256, the preceding checkpoint hash. A changed historical receipt requires recomputing subsequent checkpoints.

The kernel can also produce a per-receipt inclusion proof: sibling hashes that show one receipt was in the tree at a given checkpoint, without including the full log.

{
  "checkpoint": {
    "tree_size": 48213,
    "root_sha256": "9f2a1c7e...e04b",
    "previous_checkpoint_sha256": "3b7e40aa...d281",
    "signature": "ed25519:..."
  }
}

For the fields inside one receipt itself (the signature, the trust and boundary tags, the call it attests to) see Receipts. This page covers how batches of receipts are chained and verified.

External Anchoring

A checkpoint hash chain makes edits to an old receipt visible during verification. It does not prevent an operator from replacing an entire chain stored on its own infrastructure. chio-anchorcan record a checkpoint root on an independent public ledger (Bitcoin, Solana, an EVM chain) or a transparency service such as Rekor or OpenTimestamps.

An anchored root records its existence at a particular time through infrastructure outside the operator's control. It adds no fields to an individual receipt, but a different history will conflict with prior anchors.

Offline Verification

The verifier for all of this is chio replay, and it carries a receipt log or live NDJSON tee stream, it verifies each Ed25519 signature and recomputes the Merkle root incrementally. If a signature fails or the recomputed root differs from the claimed root, it reports the first divergence by byte offset and JSON pointer.

chio replay receipts.log

# or from a live NDJSON tee stream
chio replay < receipts.ndjson

chio-siem applies the same checks to a live export. It verifies each row's ID, signature, and signer trust as the row leaves the kernel.

Evidence Classes

chio-lineage builds a provenance graph over how information and effects flow through a system, and it tags every node and every edge in that graph with a class: Asserted, Observed, or Verified. The class distinguishes caller-supplied claims, facts observed by the kernel, and facts checked against a cryptographic or authoritative source.

Receipts record related limits in two fields. TrustLevel (Mediated / Verified / Advisory) records how the kernel mediated the call and its effect. BoundaryClass (Prevent / DetectOnly / AdvisoryOnly / CannotSee) records what the runtime could see, independent of whether it acted. Definitions for both are in Trust Boundaries & Limits; the fields state the runtime's authority and visibility for the recorded call.

Using Receipt Bundles

A receipt bundle can be recomputed offline. Before paying, a buyer can replay the included signatures, inclusion proofs, and checkpoint chain.

Receipt-log replay supports the proposed Cognition Market depends on: buyers must be able to check the records sellers provide. See Formal Assurance for the formal claims related to policy enforcement.

Next Steps

• Receipts · the object this log is made of: fields, signature, and the trust and boundary tags a single receipt carries
• Formal Assurance · how recompute-based verification extends to the guarantees behind policy enforcement
• Trust Boundaries & Limits · full definitions for every TrustLevel and BoundaryClass value
• On-Chain Settlement · where anchored checkpoints meet on-chain payment
• Receipt Query API · pulling receipts and inclusion proofs programmatically
• SIEM Export · streaming independently re-verified rows into a live security pipeline