Failure catalogue · The verification is theater · 37 of 51
OBSERVED FAILURE MODE
The hash that disproves itself.
A manifest hash exists so a stranger can confirm the bytes they hold are the bytes you shipped. A sha256 computed over a text-mode read rather than raw bytes fails the recipient's first integrity check, on the one artifact whose whole job was to prove integrity. Nothing in the pack is corrupt. The proof is.
What we saw
In our own audits a manifest carried digests computed through a text-mode read, so line endings were translated before hashing. Every digest was internally consistent, the manifest listed every artifact, and the build reported a clean integrity pass. The first party to verify the pack the ordinary way, hashing the file as it sat on disk, got a mismatch on the very file offered as evidence. The pack was fine. The claim about it was not, and a failed integrity check reads as tampering to whoever runs it.
Why it passes a glance
The build hashes and verifies through the same call in both places, so producer and checker agree perfectly. A digest looks like a fact rather than a claim, and nobody re-derives one by hand. The defect surfaces only on a machine outside the build, which is exactly the audience the hash was written for and the audience the build never consults.
What addresses it
The provenance-reproducibility skill treats provenance as a promise about bytes: content-hash the input at ingest, keep the stored bytes write-once, and prove a record by re-deriving it from immutable bytes rather than from the code that wrote it. Doctrine principle 2, Two independent reads beat one careful one, supplies the guard: the digest is recomputed by a separate raw-byte read before the build may pass.
Check your own file in two minutes
- Hash one shipped file with your operating system's own tool and compare it to the manifest line.
- Confirm the hashing code opens files in binary mode, never text mode.
- Flip one byte in a copy and confirm the verifier reports a mismatch on that file.
What this does not catch
A matching digest proves the file is the file. It says nothing about whether the numbers inside are right, and it cannot detect a change made before the hash was taken. Identity first, meaning argued separately, is the order the record has to state.
Quick answers
- Does a hash prove the numbers are right?
- No. It proves the file you hold is the file that shipped. Reproducing a run over bad input reproduces the bad input faithfully, which is why identity is settled first and meaning is argued on its own terms.
- Why does a text-mode read break a digest?
- Because the read translates bytes before they reach the hash, so the digest describes a version of the file that never existed on disk. Anyone hashing the file the ordinary way gets a different answer, on the artifact you offered as proof.
- Is there a file the manifest should not list?
- The captured gate verdict, which is the one file no manifest lists or hashes. Everything else in the pack is listed with a digest computed from raw bytes and re-verified before the pack is certified.
Nearby failures
Last updated 2026-09-02 · Dylan, founder · one of 51 observed failure modes, every one seen in a real build or in our own audits, none invented.