Check the evidence yourself

The format

This is the part of the DeepSweep Agent Evidence Format the kit checks. It is enough to write a third checker from, which is the point: a format that only its author can check is a claim, not a format.

Primitives

• Canonical JSON: RFC 8785 (JCS): keys sorted, no whitespace, integers as plain numbers.
• Digest: lowercase hex SHA-256 of the UTF-8 bytes.
• Signature: Ed25519 (RFC 8032), base64. Public keys are SPKI, usually PEM.
• Key id: dsk_ followed by the first 16 hex characters of the SHA-256 of the base64 SPKI key.

Ledger entry (one JSON object per line of ledger.jsonl)

{ seq, prevHash, occurredAt, kind, payload, entryHash }

• An entry has exactly these six fields; a line with any other field is refused. entryHash is the SHA-256 of the canonical JSON of the other five.
• prevHash is the previous entry's entryHash; the first entry uses 64 zeros. seq starts at zero and goes up by one, with no gaps.
• payload holds digests, fixed codes, counts, the names of the rules you wrote, the identifiers of installed policy packs and the categories a call was classified into, and, on kill-switch entries, the label the operator gave when turning it on or off or running a drill. Review entries written by earlier versions also carry the workspace folder’s name. Beyond that, the format puts no file names, paths, arguments or tool content in a payload; an operator label is whatever the operator typed.

Entry signature (one line per entry of ledger-sig.jsonl)

{ schemaVersion: 1, seq, entryHash, keyId, signature }

The signature is Ed25519 over the canonical JSON of { schemaVersion: 1, seq, entryHash }. Signing the position with the hash is what lets a checker tell a reordering apart from an edit. keyId must be the pinned key's id. Any other field in a signature line is ignored and not signed.

Signed tree head

{ treeHead: { schemaVersion: 1, treeSize, rootHash, signedAt, logId }, signature, keyId }

rootHash is an RFC 6962 Merkle root. Leaves are SHA-256(0x00 || data), inner nodes SHA-256(0x01 || left || right). Over a ledger, each leaf's data is the 32 bytes of an entryHash; over a bundle, it is the canonical JSON of a record. logId must equal keyId, and the signature is Ed25519 over the canonical JSON of treeHead. signedAt is the signer's claim.

Reading JSON

The in-browser checker and verify_ledger.py read JSON the same strict way, so a file means the same thing to both. They refuse the non-standard values for not-a-number and infinity, numbers too large to be finite, integers beyond plus or minus 2⁵³ − 1, text that is not valid Unicode, an object that names the same field twice, a byte-order mark, and nesting deeper than 64 levels. A tree size, a proof index and a proof's sizes must be written as integers: 19.0 is refused there. Canonical JSON follows RFC 8785 including its number format, so inside a payload 3 and 3.0 are the same value and hash the same.

verify_bundle.py is published unmodified, and reads a bundle more leniently in a few places: it takes true or false where a number belongs, ignores stray characters in base64, accepts a digest followed by a line break, keeps the last of two fields with the same name, and counts inclusion proofs without matching each to its own record. None of these lets a changed record or signature pass: the signed root is still rebuilt from every record. But a field named twice can show a person reading the file one value while the hash covers the other, so treat a bundle this script passes and the in-browser check refuses as not verified. verify_ledger.py --bundle refuses all of them too.

The order of the ledger checks

A ledger can be wrong in several ways at once. The checks run in this order and the first one to fail names the result.

Evidence record and bundle

An evidence bundle turns each ledger entry into one record, builds a Merkle tree over the records, and carries an inclusion proof for every record, optional consistency proofs, and a signed tree head. Record fields:

Bundle fields the checker does not protect

The signature covers the tree head, and through its root every record. It does not cover the bundle's outer labels. Each item below was found by changing one field at a time and seeing the check still pass; treat these as unverified notes, not evidence.

• schemaVersion: The bundle's own version number is a label. Nothing checks it.
• workspace: The workspace name at the top of the bundle is a label. The copy inside each record is covered by the signature; this one is not.
• generatedAt: The export time at the top of the bundle is a label. The signed tree head carries its own time, which is covered by the signature but is still the signer's claim.
• treeSize: The record count at the top of the bundle is a label. The count that matters is inside the signed tree head, and the verifier checks that one.
• inclusion[].selfVerified: Each proof's selfVerified flag is the exporter grading its own work. The verifier ignores it and re-checks every proof itself.
• consistency[].selfVerified: Same as above, for consistency proofs.
• inclusion[].treeSize: The tree size written inside an inclusion proof is not compared with the signed tree size, so a changed value can still pass when the proof's shape happens to match. The proof still has to reproduce the signed root, so it cannot place a record that is not there.
• consistency[].secondSize: Same as above, for the larger tree size inside a consistency proof.
• delete schemaVersion: Removing the version label is not noticed.
• delete workspace: Removing the top-level workspace label is not noticed.
• delete generatedAt: Removing the export time label is not noticed.
• delete treeSize: Removing the top-level record count is not noticed.
• delete consistency: Consistency proofs are optional. Removing them removes that check; it does not make the bundle fail.

Two fields are required but not signed: status must be ok and chainIntact must be true. Anyone assembling a bundle can write both, so they show only that the exporter did not report a broken chain.