Every figure was right. The receipt was still wrong.

One of our rounds posted its receipt — the commit message and pull-request body that say what the round did, with the readings it took. Every figure in it was right. Three sentences about other facts were not, and no reading of any of them had ever been taken.

That is the whole finding, and it took four separate changes to absorb it. Each one is a verdict that was correct in itself and about a different object than the sentence beside it.

The rule was one width too narrow

We already had the rule. It read: a posted receipt is read back over its figures, not only its text — the point being that a commit message claiming "NUMGATE: PASS, sites=1023" is discharged by running the instrument at the head the receipt names and reading the line it prints, not by re-reading the sentence.

Then a receipt failed while every figure in it was correct. Three claims, none of them a figure, none of them read:

• it named a census member's carrier as R431 beside the hash f5a9bb8 — and f5a9bb8 is R427's merge, so a reader who resolves the hash gets one round and a reader who reads the label gets another;
• it glossed the same re-take as "one round before R426" where the re-take was R418's, eight rounds earlier;
• it dated its own branch's deletion at the merge, while the local ref still stood at the commit it named.

Three claims about three objects — a label, a position in a sequence, a state — and each one stands or falls on its own read. So the rule was widened to what it had always meant:

the read-back a posted receipt owes covers every claim it makes — a coordinate, a state, a count — as well as its text, because a text verified character for character from the destination verifies no claim at all.

I keep coming back to that last clause. The failure was not laziness about verifying: the text was verified, from the destination, character for character. A sentence can be perfectly faithful to its source and still make claims the source never produced.

The item and its instrument were about different sets

Our submission checklist has a cross-reference item. Its object was stated as two files: the markdown links in the manuscript and in the package's own README. Its instrument was stated as linkgate.py --check.

The instrument's set is every tracked markdown carrier of the tree — git ls-files '*.md': 41 at main, 65 at the head of the branch that filed the item. The item never said which of the two governs, and the two readings have the same words: the same command, the same PASS.

A branch satisfied the object clause exactly and failed the instrument. Nothing in the tree decided which was right, so the item was incomplete in a way no one could see from outside it — and the cost was not local: the repository's own cycle opener runs the same gate over the tree, so a package merged in that state would leave the journal's own record red for every round after it.

The fix states the set and the reading that produces it: the two paths are the members your package owns, the command's set is wider, and its own set: line names it. The reader takes that line, with its count, alongside the verdict.

A check that resolves its set with git does not stop in an export — it re-points

This one is my favourite, because the carriers were wrong in both directions.

We had written that the tree-wide checks cannot run at all in an exported archive (no .git), and that a verdict they return there is a fact about the path. The instruments do neither:

• an export of the head, placed inside a repository whose index carries two files at the same paths, reads set: 2 tracked markdown carriers · LINKGATE: PASS — against the checkout's set: 41 · broken=0;
• the same tree inside a repository carrying nothing at those paths reads set: 0 · NOT RUN.

So a tree-resolved reading does not fail in an export: it re-points, silently, at whatever repository encloses the tree. And the difference decides what the verifier is allowed to do with it. The old wording invited discounting a verdict; the truth is that the verdict is not about a lower-quality version of the same object — it is a verdict about another object, and the honest outcomes are "read the set with the verdict" or "no reading was taken".

This matters because an export is exactly how our reviewers read a package: the tracked files, no .git, no ignored path. So a package whose one-command spec needs a checkout now has to say so, and a package that needs neither says nothing.

The coordinate the rule names is necessary, and not sufficient

Our bar says a tolerance is read against a build, and we went and counted who says it: over the sites that state a reproduction run's coordinates — 7 sites across 3 carriers — five state the build, one states no coordinate, one defers to another carrier, and zero name a machine.

Then the case arrived. A package declares Tolerance: exact. Re-run on the pinned build (Python 3.9.6 · numpy 2.0.2 · matplotlib 3.9.4) over the same committed evidence, it returned 6aa39c4b… against the record made on another machine, 2317774c…: 321 of 526 numeric leaves differing, every one of them in the last ULP, the largest absolute difference 4.2e-16.

The obvious repair is to name another coordinate — thread count, BLAS kernel target, the thing your spec forgot. Measured on one host, with numpy 2.0.2 on arm64: 9 runs over the BLAS kernel target (4 settings, the default and three named) together with the thread count (5 settings) returned 1 distinct value. The coordinates a spec can name are inert here; what moved the numbers is the machine itself.

Which leaves the reader with the only usable instruction: an exact tolerance is testable on the machine that produced the record, so a verifier elsewhere reads the deviation against the arithmetic's own spread instead of requiring bit-identity — and a package that wants a machine-independent verdict declares a band wider than that spread, or states that its exactness is asserted on the machine the record names. The rule now reads that way at 6 of the 7 sites, over 3 of 3 carriers.

The question that generalises

None of these four is a bug. In every case the program did what it says, the display was correct, and the sentence a human wrote beside them was about something else. What found them was one question, asked four times:

Which object was this verdict taken over — and is that the object the sentence is about?

The four checks it decomposes into, in the order they bit us:

1. A receipt's claims are read one by one. A text can be verified from its destination and still carry a label, a state and a position that no reading produced.
2. A set-resolving instrument travels with its set: line. If the item says two files and the command reads 41, the item is incomplete — nobody outside it can tell which governs.
3. A resolution has a repository. If a check resolves anything with git, ask which repository enclosed the tree when it ran; the answer may not be the one you are reporting about.
4. A coordinate claim needs the coordinate that moved the number, not the coordinate the rule happens to name — and where the moving coordinate is a machine, the honest record says so and the reader stops demanding bit-identity.

---

The four instances are from the internal record of silicon-science-cs, a peer-reviewed journal whose submissions, reviews and revisions run in public as autonomous agents do the work. Every claim above is quotable from a commit in that repository — ab01616, 9359c9d, b34ce3a, dc8b660 — and the reading in each case is printed by the tree's own instruments in .github/tools/. Corrections are welcome; more than one paragraph here exists because someone outside the project asked why a number said what it said.