Receipt Aggregation

Receipts replicate between nodes, and each node commits its own copy

Node B reverifies node A's receipts, gives them positions in its own claim log, and commits a range under the key that signed them.

Tool and child receipts share one claim log, so a checkpoint range can hold both kinds. Every receipt in the range carries the same kernel key, and the checkpoint uses that key. Two stores holding the same receipts can still commit different roots, since each chooses its own order and batch boundaries.

Read more in Verifiable Evidence, which covers checkpoint chains and inclusion proofs.

Signed records cross between nodes, and commitments are made where they land

Each artifact has one path between peers and one treatment at the receiver.

chio_tool_receipts and chio_child_receipts project into claim_receipt_log_entries through AFTER INSERT triggers. Its entry_seq is local to the receiving store, and a checkpoint range is written in that combined sequence.

An imported receipt is verified again before the store accepts it

Service-authenticated receipt and lineage writes follow the locally selected leader, write locally, and re-read for leader visibility before answering. Follower replication and checkpoint coverage come afterward, on their own schedule.

The SQLite append path verifies each receipt against the public key it carries, at ReceiptCryptoFloor::AllowHybrid, and checks a tool receipt's action-parameter hash before the commit actor is queued. The path holds no policy handle or issuer allowlist, so a valid signature establishes integrity and trusting its signer stays your decision. Durable persistence is a later commit boundary, and a checkpoint is a later artifact still.

A peer page is checked for forward progress and ascending order, then passes through the ordinary append methods. Gaps are accepted, because receipt sequences carry gaps from conflict handling and retention. Newly inserted records take local positions, a replayed record needs no second claim-log entry, and the cursor advances once the complete page applies.

Read more in Receipts, which covers what one record establishes, and Node State, which covers the local writer.

A checkpoint commits a contiguous range under one signer key

With checkpointing enabled on a store that supports it, kernel attachment installs a background signer with a default batch of 100. A trust-control process that opens a receipt store only for replication installs no signer, so give that store a kernel attachment or an explicit checkpoint operation with a key that matches its receipts.

$ chio receipt checkpoint status --receipt-db ./receipts.db

status: healthy
committed_entry_seq: 3
checkpoint_seq: none
checkpointed_entry_seq: 0
next_range: 1..=3
retention_watermark_entry_seq: none

You should see committed_entry_seq beside checkpointed_entry_seq, then next_range. Here three records are committed and none is checkpointed. healthy means the local structure passed its checks, and a healthy store can still carry an uncheckpointed tail.

Setting checkpoint_batch_size to zero disables automatic checkpointing, and attachment refuses that setting when retention is configured, because retention needs checkpoint-covered boundaries. A store that claims checkpoint support and fails to install the requested signer is refused at attachment.

Read more in Retention & Archive, which covers how checkpoint boundaries constrain removal of the live prefix.

An export proves inclusion for the tool receipts it selects

Evidence export rebuilds the Merkle tree from the canonical bytes of a checkpoint's full claim-log batch, child leaves included, and emits an inclusion-proof row for each selected tool receipt. Selected tool receipts without a proof are listed in uncheckpointed_receipts.

That list covers tool receipts. Child inclusion has its own declared export scope, separate from committing child leaves into the tree; Evidence Export shows both the proof coverage and the child scope.

checkpoint_log_id derives local-log-… from the checkpoint's signing key, so it names a key: two stores sharing that key present the same log identity. Keep each checkpoint chain in its own context instead of merging node-local sequences into one fleet log.

Aggregation keeps every record’s evidence class

Collecting more records upgrades none of them. The bounded operational profile keeps asserted call-chain fields asserted unless observed lineage or verified provenance supports them, so a report can count a claim and keep its source. Each layer of evidence answers one question:

1. Record integrity. The signature and the applicable body bindings. Whether the signer is trusted for a conclusion is a separate decision.
2. Persistence. The durable receipt and claim-log state, which signing alone does not create.
3. Checkpoint. The local range, root, signature, and predecessor chain, on the node that produced them.
4. Export coverage. Selected records, proof rows, uncheckpointed tool receipts, child scope, and publication evidence.
5. Fleet visibility. The answering node's replication progress and the specific records required. A local proof and a healthy rollup each describe one node.

A relationship that passes the replay-corpus signed-statement predicate binds its named parent and child, and a caller-supplied trace node beside it inherits nothing. An imported bilateral share stays in its own tables, while a later federated-delegation operation can create a local federation-parent link.

Checkpoint, query, and provenance reference

$ chio receipt audit --receipt-db ./receipts.db

status: healthy
committed_entry_seq: 3
checkpoint_seq: none
checkpointed_entry_seq: 0
next_range: 1..=1
retention_watermark_entry_seq: none

Next: package the evidence for a verifier