The first chain¶
A real evidence chain, produced on 2026-07-29 over real work, kept here so it can be read by someone who was not present when it was made.
It records four links from one day's change: a requirement, the structural test that holds it, and the two commits that landed it.
The code it attests was written by Claude Code, not by any tool in this repository. That is the property the whole product rests on — an evidence layer that can only vouch for what it generated itself is a feature of a code generator, not infrastructure.
Every link was sealed from the actual output of the command it names. None of it was transcribed by hand; a step that had failed would appear here as a failure.
Verify it yourself¶
You need the litatoli binary and nothing else. No key, no config file, no
network, no account — verification is offline by construction, which is what
makes the artefact usable in an air-gapped estate.
litatoli verify-chain --log-file chain.jsonl \
--expected-pubkey 4ad3b06403b057c1156ab5339a8fa7d188235fdb22aadde11096e76e88511ec4 \
--expected-head 6a639e00fcd44d3a894a36f4fd5767debcb3a7c0c14212bd9b1cbe1e80ff9653
Expect overall_ok: true, and a proves field reading chain integrity AND
signer identity, AND that no entry was removed from the end.
Pass both pins, and read proves rather than overall_ok. Drop
--expected-pubkey and the command refuses to run at all, because a log signed
end to end by one attacker's key is perfectly self-consistent. Drop
--expected-head and it runs, but says — in the report and on stderr — that it
cannot see entries cut from the end. overall_ok: true is the same true in
all three cases; proves is where the difference lives.
The signing keys are gone, deliberately¶
They were generated for this chain and never persisted anywhere. This is not a gap: verification never needs them. The public key is what you pin, and it travels inside every entry; the private half only ever mattered to whoever appended. A chain that needed its author's secret to be checked would be useless to an auditor.
The practical consequence is that this chain can be verified forever and extended never. For a specimen, that is the right trade.
The three broken copies are the point¶
A chain that verifies proves nothing until you have watched it refuse. Each of
these is chain.jsonl with one specific attack applied, and each must fail:
| File | What was done to it | What catches it |
|---|---|---|
tampered.jsonl |
Link 2's recorded result flipped from pass to fail | Ed25519 signature over the payload |
deleted.jsonl |
Link 2 removed from the middle | seq gap and prev_hash break — two independent checks |
truncated.jsonl |
The last link cut off the end | Only the pinned --expected-head |
Run the same command against each. The third is the interesting one: without
--expected-head it passes, and it should — cutting the end of a log leaves
nothing to find, since the remainder still numbers 1..n and still chains, and
the same cut removes any checkpoint that would have betrayed it. That is why
the head has to be recorded outside the log, and why this was fixed to be
stated rather than implied.
What this chain does not do¶
It proves provenance: who wrote what, which test ran, what its real result was.
It does not say "this satisfies clause 5.5 of IEC 62304". Clause attribution is a separate capability, and today it costs an adopter four more packages to assemble. Reducing that is tracked internally as an integration-budget item.