KymiraCertified BI

Failure catalogue · The verification is theater · 38 of 51

OBSERVED FAILURE MODE

The stale fingerprint.

Index pages and summaries print a short hash prefix beside each artifact so a reader can spot-check what they are holding. A prefix copied from an earlier cut of the same file is a fingerprint that identifies a document nobody shipped. The page looks more auditable than one carrying no fingerprints at all.

What we saw

In our own audits an index page displayed truncated hashes beside the files listed under them. The digests were real, and they had been correct: they came from an earlier cut, and the surface printing them was regenerated on a different schedule than the artifacts themselves. A reader who checked one prefix against the file beside it found a mismatch and had every reason to distrust the whole pack. The manifest was current. The page a person actually reads was not.

Why it passes a glance

A hash prefix looks like machinery rather than prose, so it escapes the review that catches a hand-typed figure. It renders in a monospace column beside a filename and reads as generated. Nothing on the page states which build produced it, and a truncated digest is far too short for anyone to recognise as old at a glance.

What addresses it

The provenance-reproducibility skill keeps the input hash, the engine commit, the period and the verdicts in one record a stranger re-runs, so no surface invents a copy of its own. Doctrine principle 1, An AI never authors a number, extends to every shipped artifact: a figure on an index page, a README or a manifest is generated by the build or gated by a check that greps it against machine output, prefixes included.

Check your own file in two minutes

  1. Pick any hash prefix on an index or summary page and compare it to the manifest entry for the same file.
  2. Confirm the prefix is read from the manifest at render time rather than stored in the page's own source.
  3. Rebuild after changing one artifact and confirm every surface that names it moves with it.

What this does not catch

This addresses agreement between surfaces, not correctness of the underlying digest. If the hash was computed the wrong way, every surface agrees on a wrong fingerprint. Pair the surface check with a raw-byte re-derivation before the pack is certified.

Quick answers

Why print a hash prefix at all?
So a reader can spot-check the artifact in front of them without running a tool. That only helps when the prefix is read from the manifest at render time, so it can never describe an earlier cut of the file beside it.
Is a truncated prefix good enough?
For a spot check, yes. For an integrity claim, no. The full digest lives in the manifest and the verification instruction points there, because a prefix is a convenience and never the proof.
What if a surface cannot reach the manifest?
Then it prints no fingerprint. A missing prefix costs the reader a convenience. A stale one costs the pack its credibility, and it costs it at the exact moment someone decided to check.

Nearby failures

The hash that disproves itselfThe verification is theaterThe manifest that contradicts its pageThe wrapper betrays the numbersThe painted rowThe verification is theater

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.

Get the free skill → The doctrine All 51 failure modes