Errata

Most projects publish what they got right. This is the other page.

Vera argues that a record beats a reputation. It is easy to say that and never be held to it, so here is the idea pointed at us: every claim we got wrong, what replaced it, which way the error ran, and who paid. 51 corrections in the build below, dated 2026-09-16, 46 of them errors that ran in our own favour and were fixed anyway. Errors that only embarrass your opponents are free to admit. These were not.

This page renders one sealed build. The record is published in full at github.com/jeb2-spec/errata, it is corrected more often than this page is rebuilt, and it may already be longer than what you see here. Where the two disagree, the published record is the one to read.

2026-08-29in the company's favour
A post analysing a corporate settlement
ClaimedDraft misstated the money, the term, the court status, and printed every remedy without its exclusion.
CorrectedRewritten against the filed agreement before publication. The published post discloses that its earlier draft was wrong.
Who paid: us. Caught by an adversarial review pass before it shipped.
2026-08-29against ourselves
A biographical detail on an unlisted page
ClaimedFlagged as unsourced and deleted.
CorrectedRestored. It was true, and the source was in previously published writing all along.
Who paid: the subject. Found by searching the corpus after the deletion, which is the wrong order.
2026-08-29against the company
The same settlement post, after publication
ClaimedClaimed an independent auditor's reports carried no requirement that any of it be published.
CorrectedThe filing requires a public executive summary of every final report, including whether the company adopted the auditor's recommendations. Corrected live with a dated note.
Who paid: the company we were writing about. A reader supplied a clause number; we read the clause.
2026-08-30in our favour
A statistic on a personal page: longest run of consecutive working days
Claimed38 days.
Corrected29 days. Sixteen days in the log had no human commit at all; a scheduled job was authoring them, and the job that wrote the statistic counted its own commits toward the total it reported.
Who paid: us. Found by asking who authored the commits, which nothing about the number itself would have prompted.
2026-08-30against a person, in our own favour
A claim about a third-party system's behaviour
ClaimedTold the person who raised it that he was wrong, after stating that the source was inaccessible.
CorrectedHe was right. Reasoning confidently from partial evidence after admitting the evidence was out of reach is worse than staying silent.
Who paid: him. He held the full record and showed it.
2026-08-31in our favour
The published README of this record's own repository
ClaimedCalled its verifier forty lines of Python. The commit message that published it said a hundred.
CorrectedIt was ninety lines on the day of this correction. Neither published number had ever been checked against the file, and the claim sat in the paragraph that invites readers to audit us instead of trusting us.
Who paid: the reader. Cloned the published repository as a stranger would and ran every command the README gives.
2026-08-31in our favour
A sentence about two people on an unlisted page
ClaimedImplied they had grown up together since childhood.
CorrectedThey met as adults. The person the sentence described read the draft and corrected it herself; her own phrase had meant the years they built together, not childhood.
Who paid: the subject. Caught by the person it described, reading the draft before it shipped.
2026-09-01in our favour
The landing page for a tool we published on a sister project's site
ClaimedWritten, we said, for one specific non-technical reader on a phone. It opened with the craft: the day as terrain, one calm page over coffee.
CorrectedThe reader it was written for said she was confused, and so did the first other person to read it. A third person then restated the page in one breath, plainly and benefit first. The page's first paragraph is now a line in that shape, and the craft line follows it.
Who paid: its first two readers. The readers said so, in a group thread, the same day it shipped.
2026-09-01in our favour
A published essay's sources, and the pull request that described them
ClaimedThe pull request said every citation had been checked against a search result. There were twelve; four had been written from memory.
CorrectedThree of the four were wrong in detail: a news article's address, a population figure with its age range, and a paper's identifier. All three were corrected before the essay was published. The claim that they had been checked was the error that mattered, because it is the claim a reviewer stops checking after.
Who paid: us. An audit of every citation against its source before merging, asked for by the founder: be certain.
2026-09-02in our favour
A forecast about federal legislation, given in conversation after a federal appellate ruling
ClaimedThat Congress was likely to act quickly to close the gap the ruling had opened.
CorrectedThe relevant bill had already passed the Senate unanimously on 16 December 2025 and had been held at the desk in the House ever since. It was not waiting on urgency, it was waiting on a floor vote. Two supporting details were also wrong: we called the Senate vote an overwhelming margin when it was unanimous, and implied the bill was in committee when it was further along than that.
Who paid: the founder. He disputed the forecast on the spot and said the laws were not actively happening. We checked. He was right.
2026-09-02in our favour
Constitutional analysis offered in conversation before the opinion itself had been read
ClaimedThat a 1990 Supreme Court case was the strongest argument available, because its rationale of destroying a market rather than policing thought transfers cleanly to synthetic material and needs no identifiable victim.
CorrectedThe panel had considered that argument and rejected it, a week before we made it. The opinion holds that because the images do not depict an actual child, the two victim-anchored precedents do not directly apply. We had recommended walking through a door the court had already closed, and the only thing standing between the reasoning and the record was that nobody had opened the PDF.
Who paid: the founder. He said be certain. We extracted the opinion from the court's own file and read it.
2026-09-02in our favour
The practical recommendation at the end of a piece of legal analysis
ClaimedThat the remedy for the gap was a phone call to the House about a named pending bill.
CorrectedWe read the bill as the Senate passed it rather than a summary of it. It removes a statute of limitations, adds sex offender registration, adds a presumption of pretrial detention, adds supervised release, and protects the material in discovery. It never amends the subsection the ruling struck down, and a statute could not have overruled that holding anyway. The bill is worth passing and it is not the answer to this. A practical thing at the end that does not reach the problem is decoration, and it is worse than no recommendation because it tells the reader the matter is handled.
Who paid: the reader. Fetched the engrossed text from the legislature's own server after two summary sources agreed with each other and neither quoted the operative sections.
2026-09-02in our favour
The correction row above, osborne-does-not-transfer, and the published article that cites it
ClaimedSaid the court had rejected the argument three weeks before we made it.
CorrectedSeven days. The opinion was decided on 25 August and the argument was made on 1 September, and both dates sit in the same paragraph as the number that contradicts them. It was already sealed into this record's digest and anchored to Bitcoin before anyone checked, so the anchor now proves exactly when we published a wrong number. That is the system working rather than failing, and it is the reason the row that admits not reading a source is the row that got its own arithmetic wrong.
Who paid: the reader. An adversarial review read the opinion's caption date and did the subtraction. Nobody on our side had.
2026-09-02in our favour
This database's README, describing the author_role column of the post_revisions table
ClaimedSaid the column tells you which changes came from a human, which from an assistant, and which from an unattended cron.
CorrectedIt never did. It reported git authorship, correctly, on every row: no published row was ever false. But squash-merging a pull request books the merger as the author, so jointly written work read as human and the column showed 8 assistant rows out of 117 when at least 77 carry a Co-Authored-By trailer naming the assistant. Every part true, the picture wrong by roughly nine times, in the column the README points at to argue the assistant is disclosed rather than hidden. Fixed by making the claim true rather than by weakening it, since withdrawing a disclosure is not a repair. The column now reads the trailer and reports a fourth role, co-authored, and the meta table states that the number is a floor because the trailer convention only began on 2026-06-15.
Who paid: the reader. An adversarial review checked the column against the commit messages behind it, which is the one check nothing about the column itself would ever prompt.
2026-09-03in our favour
The anchors table of this record
ClaimedSaid the digest moved after a merge because the post_revisions table is built from the commit graph, and called that the record working rather than drifting.
CorrectedThe post_revisions rows were identical. The digest moved because the meta table carried the hash of the commit that ran the build and the day it ran, and meta is inside the digest. So every commit to the source repository, and every rebuild on a new day, moved the seal with nothing in the record changed, and four anchors were struck for no other reason. The two provenance rows stay in meta for the reader and are now excluded from the digest, so the seal tracks the record's content and nothing else. The wrong sentence stands in the anchors table with the correction beside it.
Who paid: the reader. Rebuilt the record at a new commit with no content change and diffed the two SQL dumps. One row differed, and it was not in post_revisions.
2026-09-03in our favour
The adoption disclosure in this record's own meta table
ClaimedSaid the outside reader whose question prompted that disclosure had stated this repository's counts twice and differently.
CorrectedWithdrawn, and the clause is gone. Two different figures do appear across two screenshots of that reader's answers, but the earlier one is partly covered by the application's own input box, the order of the two was inferred from scroll position, and neither the conversation nor the prompts that shaped it were ours to read. That is a conclusion carried past the edge of the evidence, about a third party who is not here to answer it, written into a sealed record that is anchored where nobody can reach it. It was also not load-bearing: the disclosure's substance is the counts, which came from the hosting platform's API, and the limit they describe. What replaces it says only where the counts came from and why. This database already carries the same lesson from 2026-08-30, when confident reasoning from partial screenshots of a thread that could not be opened produced a verdict that was wrong; the lesson carved then was that stating a limitation does not discharge it, and this time no limitation was stated at all.
Who paid: the outside reader. The founder asked whether I was sure and named the reason to doubt it: the later screenshot may have come from an answer shaped by a different prompt.
2026-09-03in our favour
What this session could do about the published repository's settings
ClaimedTold the founder there was no tool in this session that could edit repository settings, so the About box was his to fill in.
CorrectedUntested. One fuzzy tool search had returned nothing and that was reported as a capability limit. The founder pushed back and the actual test took one command: the session holds authenticated write access to the GitHub API, and the proxy injects real credentials. The write is genuinely blocked, but for two specific reasons that had not been discovered, and reporting a limit is not the same as establishing one. Recorded because a claim of inability is a claim, and this record has no standing to demand evidence for assertions while exempting refusals. The correction is entered against a conversational claim rather than a published one, which is itself a widening of this table's scope: a false statement made to one person is still a false statement, and most of an assistant's claims are never published at all.
Who paid: the founder. The founder said: why no repo settings tool, you have full access. He was right to doubt it and the test took one command.
2026-09-04in our favour
The pre-write hook this project shipped to stop fabricated values, and the claim made for it
ClaimedReported to the founder and in a commit message that the hook was verified live rather than argued, on the evidence that it denied a fabricated hash when this session attempted one.
CorrectedIt denied the first attempt and would have allowed the second. The deny message named the offending value, that denial landed in the transcript as a non-assistant line, and the hook trusts non-assistant lines as things the session observed. So being blocked put the fabricated value into the observed set and the identical retry passed silently. Reproduced against the real transcript within the hour. A control that stops you once and waves the retry through is worse than no control, because it certifies. Fixed by fingerprinting the value into the log instead of printing it, quarantining anything once refused so quarantine beats the observed set, and naming only an eight character prefix in the message. Both attempts now deny and a genuinely observed digest still passes. The claim was not false about what was tested, it was false about what was concluded: only the happy path had been run.
Who paid: the founder. An adversarial review agent, reading the shipped code rather than the description of it, and it was right.
2026-09-04in our favour
The count of memory claims that record how a limitation was established
ClaimedReported that 49 sentences in memory assert a limit and 14 record the probe that established them.
CorrectedIt measured proximity, not probing. A command-shaped backtick or an HTTP status within two lines of a limit sentence scored it as probed, so the number rose passively as ordinary writing accumulated around a claim. Worse, it awarded full marks to vera-prod-db.md, the one file whose AWS free-plan blocker was false for nine weeks precisely because nobody re-ran it: that file is dense with aws commands, so every limit sentence in it read as probed. The metric gave its highest score to the exact failure it was built to detect. Replaced by claim age from git blame, which needs no seeding, cannot be satisfied by writing near a sentence, and distinguishes a stale line from a fresh edit in the same file, which is what the nine week failure actually required. It now reports 49 limit sentences, 19 untouched for sixty days or more, oldest seventy one.
Who paid: the founder. The same adversarial review agent. It overstated the mechanism, claiming any nearby backtick counted, which testing disproved. The substance held and the narrower reading was worse.
2026-09-04in our favour
The published repository itself, between 00:49 and 01:01 on the day of this row
ClaimedThat the published record carried nineteen corrections, including two entered that evening by a second session working on the same record.
CorrectedTwelve minutes later a publish from a different branch replaced the whole tree with a build carrying eighteen, and those two corrections were no longer in the published record. Nothing warned anybody. The publisher fetches the remote and commits its own tree on top rather than merging content, so a build produced from a branch that never merged the other session's work removes that work silently and without a conflict. It was two publishers writing one record with no check that the second contained the first. Restored by merging both branches and rebuilding from the union, and the publisher now refuses to ship a record with fewer rows in any table than the copy already on the remote. The dropped rows were corrections, so for twelve minutes this record published a smaller count of its own errors than it had already admitted to.
Who paid: the reader. The pull request reported a merge conflict, which was reason to compare the published repository's own commit history against the branch behind each build. The row counts differed and nobody had been looking at them.
2026-09-04in our favour
The canonical serialisation this record's digest is computed over, and the promise made for it
ClaimedThat the digest is a SHA-256 over a canonical serialisation of every row, and that any reader can recompute it from the published data. The serialisation took each table in a fixed order and sorted its rows by the first column.
CorrectedOrdering by the first column is unambiguous only where that column is unique, and in the detections table it is not: the primary key is two columns, and SQL leaves tied rows to the query plan. SQLite walked the primary key index and broke ties by the second column, a rule written down nowhere. An implementation reading only the published text dump therefore computed a different digest, differing in two rows. No published file ever failed its own verifier and nothing in the record was wrong; what was wrong was the claim that a stranger could arrive at the number independently, which is the whole promise. It was fragile as well as unstated, because a different query plan would have moved the seal with no content change, the same defect as a digest that tracked the build commit. The order is now fixed by sorting each fully serialised row as UTF-8 bytes, which needs no database and no query plan and can be reproduced from the text alone. The digest moved when the rule changed, and every earlier build stays checkable with the verifier published beside it.
Who paid: the reader. An outside reader who could read this repository through a code connector but could not execute anything said so plainly rather than implying a test had been run, and proposed the one that would settle it: alter a row, run the verifier, restore, then recompute the digest independently from the SQL dump. It was written as tools/tamper-test.py and run. The first two checks passed and the third failed.
2026-09-04in our favour
Lesson thirty three of this record, entered and published earlier the same day
ClaimedThat a kept record can put an assistant in the seat of the person it serves, and that only that person can say whether it did. The row was entered after the person it described read the assistant's reading of him and called it a match.
CorrectedThe second sentence is false, and false in the direction that flatters the instrument. Hours later a different vendor's assistant was given the same document and produced a structurally better reading: it named the mechanism the first reading had only gestured at, and drew a distinction the first reading missed entirely. So someone who is not the subject can say a great deal about whether a reading landed. What the subject is positioned to score is fit, and fit is the one property a matching reading will always appear to have; what he cannot see is the omission, because nothing about a reading that fits announces what it left out. Lesson thirty three stands as published with lesson thirty four beside it, because a lesson edited under its own citation is the change this record exists to refuse.
Who paid: the reader. A different vendor's assistant was given the same document and its reading was brought here. Nobody was looking for this defect.
2026-09-04in our favour
The errata mark, in this README's banner and in the repository's social preview
ClaimedStruck the word errata into the plate by asking for Palatino Linotype, Palatino or Georgia, at a size chosen as a fraction of the canvas.
CorrectedNone of those three faces is installed on the machine that strikes the plate, so every strike rendered in whatever serif the system fell back to, at a width nobody had measured, and the word ran under the rosette. The caption beneath it says the mark is struck from the record rather than drawn, and every element on the plate was geometry except the one that carried the name. A font request is not a measurement: no width exists until a renderer chooses a face, so no adjustment to the size could have fixed it and none of the arithmetic around it was ever checkable. Fixed by extracting the outlines of the two faces the site already uses and setting type as geometry, which two independent rasterisers now place at the same pixel. Two further defects surfaced while measuring rather than guessing. The ring the deletion ticks sit on was a fixed 1.235 radii while the weave reaches 1.247, so from the eighth correction onward the ring was inside the weave it was meant to bound. And the seal's footprint was a consequence of how many arms it drew, which made the room left beside it a function of the length of the record, so the wordmark changed size every time we corrected something. The plate now reserves a fixed field measured across every shape the digest can select. The first hypothesis, that a growing record had squeezed the void shut, was wrong and measurement killed it before it was told to anyone.
Who paid: the reader. The founder looked at the mark and said the text keeps changing and getting cut off.
2026-09-04in our favour
The what is inside table in this README, and the build gate that exists to keep it true
ClaimedListed twelve principles and one document, across six of this record's seven tables.
CorrectedThirteen and two, and the detections table was not in the table at all. The gate that fails a build when the README stops describing it checks the corrections, lessons and post_revisions rows and does not check principles or documents, and it cannot check a row nobody wrote. The two rows it skipped are exactly the two that went stale, which is not a coincidence: a gate written as a hand kept list of claims inherits every omission of the hand that kept it, and hand kept lists are the thing gates exist to replace. The gate now derives one expected row per table from the schema, so a table that exists and is not described, or is described with the wrong count, fails the build. Recorded because a section headed what is inside, in a repository whose argument is that claims should be checkable, is a bad place to keep a number nobody checks.
Who paid: the reader. Read the table while restriking the mark. Nothing had prompted a check of it.
2026-09-04in our favour
The measurement paper sealed in this record, and the README section that summarises it
ClaimedSaid the founder was the single largest independent detector of the assistant's errors.
CorrectedThe founder and the assistant auditing itself were tied at seven independent finds each, and the paper's own attribution table printed both sevens four lines above the sentence. A superlative is a claim about every other row in the table, and nobody had read the table against it. Both documents now state what the table shows, and the counts have moved again with the rows this correction arrived with.
Who paid: the reader. An adversarial review on a second model, reading the rewritten README against the detections table.
2026-09-04in our favour
The measurement paper, and lesson five of this record
ClaimedSaid every error the assistant caught on its own was mechanical: a wrong count, a stale digest, a rebuild that disagreed with itself.
CorrectedFive of seven were. Two independent self-catches were failures of judgement, found by going to a primary source: a remedy recommended from two agreeing summaries, and a true detail deleted as unsourced. Lesson five said the same over seventeen defects, when it was true, and was never reread at twenty four. A sentence sealed at one count is a claim about every later count. The lesson stands unedited with this row beside it.
Who paid: the reader. The same adversarial review, listing the independent self-audit rows and reading each one's note.
2026-09-04in our favour
The author-role disclosure in this record's meta table, and the README sentence that repeats it
ClaimedSaid seven revisions predate the Co-Authored-By convention of 2026-06-15 and cannot be classified either way.
CorrectedFourteen rows do, across five commits: seven dated 2026-06-14 and seven more from March. Only the June rows had been counted. The number understated how much of the column is unclassifiable, which is the wrong direction for a disclosure to be wrong in. The meta row and the README now say fourteen, derived from the table this time.
Who paid: the reader. The same adversarial review, running a count against post_revisions.
2026-09-04in our favour
The console block that opens this README, presented as the output of a query against the database
ClaimedShowed the twenty four rows in an order the command does not produce: within every day, the rows were shuffled.
CorrectedThe block had been typed and reordered by hand, and the build gate that checks it tested that each row was present somewhere, not that the block matched. The record's own correction an-order-the-text-could-not-reproduce is about published text failing to reproduce row order, and the first thing this README showed a reader was a transcript with that defect. The block is now emitted by the build and the gate compares it whole.
Who paid: the reader. The same adversarial review, running the command the block claims to show.
2026-09-04in our favour
The README's description of its verifier, in the paragraph that invites readers to audit rather than trust
ClaimedSaid tools/verify.py was ninety nine lines of standard-library Python.
CorrectedIt has been 107 lines since the 2026-09-04 build that replaced the row order rule with a byte sort, and the sentence went out unchanged in the publish that carried that file. The fifth hand-typed count about our own work to go stale, in the same sentence the first one, forty-lines, corrected. The number is gone rather than updated: a number that is not there cannot be wrong.
Who paid: the reader. Counted the file's lines before retyping the claim in a rewrite. Nothing had prompted it.
2026-09-04in our favour
The summary sentence beneath the anchor log in ANCHORS.md
ClaimedSaid fourteen of eighteen proofs were confirmed in Bitcoin and the four newest were pending.
CorrectedThe table it summarised had nineteen rows: fourteen confirmed and five pending. The sentence was written when the table was one row shorter and was not reread when the row was added. ANCHORS.md had no gate, and it is the one document whose job is to say the record cannot be quietly rewritten. The doctor now derives that sentence from the table and fails when the file disagrees.
Who paid: the reader. The same adversarial review, counting the rows.
2026-09-04in our favour
The correction every-was-five-of-seven in this table, lesson forty three, and the paragraph of the measurement paper both describe
ClaimedSaid lesson five was true at seventeen defects and went stale afterwards, because two self-catches that were failures of judgement arrived later.
CorrectedIt was false when it was sealed. Opening the seventeen defect build out of commit 119e44b, the detections table already held five independent self-audit rows and two of them were judgement failures: a true detail deleted as unsourced, and a remedy recommended from two agreeing summaries. Three of the five were mechanical, not five of five. The word every was not a sentence that aged, it was wrong on the day it was written, and a correction saying a claim went stale is a gentler account of us than one saying we never checked. This is a false sentence inside a correction row, running in our favour, which is the failure this table exists to make impossible. The rows stand unedited with this one beside them.
Who paid: the reader. An adversarial review flagged it. Confirmed by checking out the seventeen defect build and listing its independent self-audit rows one at a time.
2026-09-04in our favour
The correction a-tie-called-a-lead in this table, and lesson forty four
ClaimedSaid the attribution table printed both sevens four lines above the superlative that contradicted them.
CorrectedSeventeen lines above, with a ten line paragraph in between. In MEASUREMENT.md at commit b28c521 the founder's seven sits on line 92 and the false sentence begins on line 109. The detail existed to show how near the falsifying evidence sat, so shrinking the distance made the miss look more forgivable than it was. Both rows stand unedited with this one beside them.
Who paid: the reader. An adversarial review. Confirmed by numbering the lines of the file at the commit named.
2026-09-04in our favour
The anchor check published in the README, and the same block in ANCHORS.md
ClaimedHanded a reader two commands for checking this record's anchor without our help: ots verify against the current build's proof, and the same against an archived one.
CorrectedNeither runs. ots verify reads block headers from a local Bitcoin node and exits non-zero with a cookie file error when there is not one, which almost no reader has, and the requirement was never mentioned. The archived example additionally names its target by removing the .ots suffix, so the tool looks for a file that has never existed and stops before reading the proof. Both blocks now carry commands that were run on a machine set up from these instructions and nothing else, and both state the node requirement. The first repair fixed only the README and left the ANCHORS block byte identical while the correction row said both were done, which two independent reviewers caught before it was published. A reader without one can take the block heights and the file hash out of a proof with ots info and check the merkle root against any block explorer, which is the path that should have been published first.
Who paid: the reader. Installed the client on a machine that had never had it, following this README from its first line, and ran every command in it.
2026-09-04in our favour
Three published lines naming data/errata.db.ots, one in the README and two in ANCHORS.md
ClaimedSent a reader to the current build's proof at data/errata.db.ots.
CorrectedThere was no such file. The build published that day was made where the calendar servers cannot be reached, so its stamp was owed, and the archive move that recorded the debt left three sentences pointing at a path that no longer existed. The anchor log said the stamp was owed and the two documents around it did not. The remedy is not a better sentence. Any build whose stamp is owed now says so in the two documents that name the path, and the doctor fails a publish where data/errata.db.ots is named by the text but absent from the tree.
Who paid: the reader. An adversarial review, reading the published tree for the files its text names.
2026-09-04in our favour
The README's Limits section, and its abstract, on how this record is anchored
ClaimedSaid every published build is stamped with OpenTimestamps, and that every published build is submitted for anchoring to a public ledger.
CorrectedThe build those sentences shipped in was neither. A correctly hedged sentence existed one commit earlier and was replaced with the stronger one in the same commit that created the first unstamped build, so the claim was strengthened at the moment it became false. Both sentences now say what the anchor log says: a build made where the calendars cannot be reached ships with its stamp owed, and says so.
Who paid: the reader. An adversarial review, comparing the two sentences with the anchor log in the same tree.
2026-09-04in our favour
The README abstract, on what this record discloses about its own authorship
ClaimedSaid the file does not record who entered a row, and says so.
CorrectedIt says no such thing. Nothing in the sealed record states that entry authorship is unrecorded, and a search of the text returns nothing. The first half was true and the second half was a claim about the record's own contents made without opening it, written in the same pass that was correcting a different unverified claim.
Who paid: the reader. An adversarial review, searching the sealed text for the disclosure the sentence promised.
2026-09-04in our favour
The sentence beneath the console block that opens this README
ClaimedSaid the block is emitted by the build from the database.
CorrectedThe build derives the block and fails if the README does not already contain it. Nothing writes the README. The difference is the whole distance between a document that cannot go stale and one that cannot go stale silently, and the sentence claimed the stronger of the two. It was written while repairing a transcript that had been typed, which is the defect it describes.
Who paid: the reader. An adversarial review, reading the gate the sentence describes.
2026-09-04in our favour
The disclosures section of the README, on the assistant's share of the revisions
ClaimedSaid the query in section 5 shows how many of the revisions are co-authored or assistant.
CorrectedThe query is printed and never run, and no output appears anywhere near it. A reader is told a number is being shown to them and is then shown a SQL statement. The section that prints the verifier's output does the thing this sentence claimed to do, so the disclosure prints its result now as well.
Who paid: the reader. An adversarial review, looking for the output the sentence promises.
2026-09-04in our favour
The success line printed by scripts/errata-doctor.mjs, the tool that checks this record before every publish
ClaimedPrinted the number of anchor rows and then accounted for them as confirmed and pending only.
CorrectedTwenty rows, accounted for as fourteen and five. The owed category, which the same tool carries a whole branch to handle, was missing from its own summary, so the healthy output of the instrument was a count that did not add up. That is the defect fourteen-of-nineteen living inside the instrument written to prevent it.
Who paid: the reader. An adversarial review, adding up the numbers in the tool's own output.
2026-09-04in our favour
The paragraph on self review in the measurement paper, and the section of the README that summarises it
ClaimedSaid the failures that needed judgement about a person, about a public claim, or about the system's own limits were caught by somebody else every time.
CorrectedIt is false, and it was built so that nothing could show it. No column anywhere records whether a failure was one of judgement, so no reader could run the query that would test it; the sentence replaced two false superlatives with one nothing could come back at, which is a worse repair than a smaller claim would have been. Read against the table it summarises it fails anyway: two of the assistant's independent self-catches are judgement failures, one about a person and one about a public claim, and the same paragraph names both of them seven lines earlier. The replacement carries no count and points at the query instead.
Who paid: the reader. An adversarial review named the sentence unfalsifiable. Reading the paragraph against the detections table then showed it was also false, and contradicted by its own paragraph.
2026-09-04in our favour
The measurement paper, on what its central refusal means
ClaimedSaid the zero overlap between independent detectors is not a data problem but the result, and that the detectors each happened to be pointed at different work at a different moment.
CorrectedIt is substantially a property of how this project allocates its detectors. The record contains no instance of two detectors being given the same material with the same brief, and the two seats convened on 4 September were briefed differently on purpose, one for facts and one for whether the document lands. A design that never creates the opportunity for overlap cannot observe it, so a refusal to estimate that follows from the design was published as a finding about detection. The paper now says so and names the experiment that would settle it, which costs one review pass.
Who paid: the reader. Reading the day's two reviews as a study afterwards, and asking why every pair of detectors in the whole record is disjoint.
2026-09-04in our favour
The anchor check inside scripts/errata-doctor.mjs, the tool this project runs before every publish
ClaimedPrinted a note when the OpenTimestamps client was absent, and carried on to report errata-doctor OK.
CorrectedThe check that opens each proof and tests whether a row's confirmed or pending claim is true was skipped wherever that client was absent, and the tool then said OK. What actually hid behind the note is one thing, not three: five proofs submitted to the calendars and never upgraded, so five rows kept saying pending after they were confirmed. Two other defects found the same day, a published build with no anchor and a published anchor command needing a Bitcoin node, were NOT behind this note. The first is caught by a check that needs no client and was already running; the second is tested by nothing in this tool at all, and was found by a person setting a machine up and running the README. An earlier draft of this row claimed all three, which was a more flattering story about the fix than the evidence supports. A skip is now a failure unless the operator sets ERRATA_NO_OTS=1 to declare that this environment cannot check anchors, and a row that says pending over an upgraded proof now fails rather than notes. The new gate was broken deliberately and watched go red before this row was written.
Who paid: the reader. Setting up a machine that had neither the client nor Python. The note fired, and reproducing the other configuration, Python present and the client absent, produced errata-doctor OK with the anchor check disabled.
2026-09-04in our favour
The README's description of the passages this record preserves, standing since the first publication
ClaimedSaid forty nine revisions carry the exact prose that was removed, and that the surviving prior states prove nothing was quietly tidied.
CorrectedTwenty six of the forty nine are cut. The page-history builder caps a removed passage at seven hundred characters, the longest stored value is 711, and no flag recording that a value was truncated reaches the database, so a reader of the sealed record cannot tell a complete passage from a clipped one. The word exact was wrong for more than half of them from the first build onward. This is the oldest false claim found in this record and it sits in the layer the same build's new principle calls the foundation, which is the more useful half of the finding. Marking truncation in the record is the fix and it is not yet made; until it is, the README says the passages are capped and says where.
Who paid: the reader. An adversarial seat running on different model weights, given the identical brief as two others reviewing the same change. Neither of the others found it, and it is the only finding unique to that seat.
2026-09-05in our favour
MEASUREMENT.md, this record's own paper on how well the record works
ClaimedThat zero overlap means every defect in this record got exactly one look.
CorrectedAt the time of this correction, seven of the record's defects carried two rows in the detections table and were looked at twice. What is zero is not the number of second looks, it is the number of second INDEPENDENT looks, which is what the very next sentence of the paper says correctly. The bolded claim overstates by exactly the qualifier the sentence after it supplies, and the bolded one is the one that travels, gets quoted and gets remembered. It is also wrong in the direction that flatters the argument, because every defect got one look is starker and more alarming than no defect got a second independent look. Correcting it produced two findings the paper did not have and now carries. Every paired look is a finder plus a self-audit and every one of those self-audits is triggered, so zero overlap is a property of the design rather than a fact about coverage: the confirmer arrives after the find, by construction, and adding reviewers cannot change that. And the two most productive detectors, a review agent and the founder, find different classes of defect, arithmetic against the record on one side and judgement and observation on the other, so their zero overlap is not by itself evidence of thin coverage.
Who paid: the reader. Counted the detections table against the paper that is computed from it, while answering an open question about what the last two days had taught. Nothing had prompted a check of the paper.
2026-09-05in our favour
What this session told the founder about where this record's own handoff file lives
ClaimedThat the memory file headed READ FIRST for any errata work existed only on an unmerged branch and so could not stop this session building on a stale base.
CorrectedIt was on the trunk, byte identical, and had been since the day before. It is starred at the top of the memory index as READ THIS FIRST for any errata work, and it was in the working tree throughout. The claim was never tested and the test was one command printing the file's hash on three refs. That is an-inability-asserted-not-tested repeated a day and a half after it was published, in the opposite direction: that row asserted a limit that did not exist, this one asserted an absence that did not exist, and both were a single command away from the truth. The claim reached the founder in conversation, a commit message, a pull request body and a memory file before a council seat tested it. The finding underneath is why this row is not simply an apology. The file was present, indexed and flagged, and it still did not work, because its own header read Two states, do not confuse them and the two it named were the published mirror and the working branch. It never mentioned the trunk. A session standing on the trunk reads it, correctly concludes it is in neither described state, and learns nothing about its own base. The warning did not fail to travel. It failed to cover the case, and the case it forgot was the common one.
Who paid: the founder. A council seat convened on a decision tested the assertion instead of accepting it, and printed the file's hash on all three refs.
2026-09-05in our favour
The correction every-defect-got-one-look, entered and published earlier the same day
ClaimedThat the measurement paper said zero overlap meant every defect got exactly one look, found by counting the detections table against the paper computed from it.
CorrectedThe sentence was real and it was published, in the build the source trunk still tracked. It was not in the published record when this session read it. Another session had already rewritten that passage the day before, as part of an-overlap-nobody-tested-for, so by the time the count error was named the mirror a reader could clone no longer carried it. The row is not withdrawn and should not be: the count error was genuinely published, it was repaired as collateral of a different correction without ever being named, and a repair with no row is exactly the filtered record this project refuses. What is wrong is the framing. It reads as a defect found in the current paper and it was found in a stale local copy thirteen corrections behind, which is the same stale base that had already caused a publish to be refused an hour earlier. Both rows stand, this one beside it, because a correction edited under its own citation is the change this record exists to refuse.
Who paid: the reader. Cloning the published repository as a stranger immediately after publishing, and grepping for the sentence the new row said it had fixed. It was not there, and had not been for a day.
2026-09-05in our favour
The anchors table's row for the 2026-09-04 build, and this project's own check for a stamp nobody is going to make
ClaimedThat the row reading owed and not stamped yet. The current build. described the record's newest build, and that the tool reporting the record healthy had looked at it.
CorrectedIt had not been the current build for a day. Two later builds superseded it and neither supersession touched the row, so it went on introducing itself as the current build in the published table while the file it named sat unstamped. The tool said OK the whole time, and the reason is the more useful half of this row. The abandonment check exists exactly for a stamp that has stopped being a pending action, and it was written inside a branch that runs only when the owed row is also the current build. The current build is resolved by looking first for the row that points at the live proof file and only then for a row saying owed, so the moment a newer build was stamped it took the current slot and the older owed row lost its clock entirely. Nothing was counting its days. A gate that only inspects the case it was written for is not inspecting the case it exists for, and the case it exists for is the one that arrives when attention has moved on. Note which half held: the sentence under the table is derived and it counted the unstamped build correctly, saying one is not stamped yet. What was wrong was the hand written identification inside the row, which is the same split this record recorded a day earlier as a hand written statement of current state is a number typed in words. The debt is paid here rather than written off. The exact file was recovered from commit 89f26b95, which carries it byte for byte, and stamped against those bytes, and the row now says plainly that the proof attests the file existed by the day it was stamped and not by the day it was built, because for the earlier date the evidence is only the commit history and a reader should not be left to infer more than the proof carries.
Who paid: the reader. Noticed while flipping six confirmed proofs into the same table, which is adjacent work rather than a check aimed at this row. Nobody pointed at it and nothing failed. It was then confirmed by reading the resolution order in the tool's own source and by reverting the row to see whether the tool would say anything, which it did not.
2026-09-16in nobody's favour
A photograph's caption on an unlisted page, and the sentence beside it
ClaimedSonoma Raceway.
CorrectedThunderhill Raceway. The caption had stood for nineteen days on the subject's own earlier word, so the correction of 2026-08-28 that put it there was itself wrong about the track, and the sentence in the prose that repeated it moved the same day. The subject is the authority on his own record; he corrected it twice, and the second time is the one that held.
Who paid: the reader, and the subject. The person the page is about looked at his own page and named the track.
2026-09-16in our favour
The heading of this README's first section, above the block that lists every correction
ClaimedThe record, in forty six rows.
CorrectedForty seven rows sat beneath it, and had since the build of 2026-09-05 that added the forty seventh; the heading was written for the build before and never reread, through two published builds. The gate that checks this README against the database tested the comment inside the query block and the sentence beneath it, and not the heading two lines above them. The heading is in the gate now.
Who paid: the reader. Read while preparing a different correction. Adjacent work, not a pass aimed at the heading, and nothing had prompted it.
2026-09-16against ourselves
The errata page on the site, on whether the build of 2026-09-06 was stamped
ClaimedThis build, dated 2026-09-06, is not stamped yet.
CorrectedIt was stamped on 2026-09-06 with four calendars, and the anchor log said so from that day. The proof was never copied beside the site's copy of the database, and the page decides what to say by whether that file is present, so for ten days it reported the absence of a copy as the absence of a stamp, in the paragraph that explains why a missing stamp is disclosed rather than hidden. The doctor now fails when the anchor log calls the current build stamped and the site's copy of the proof is missing or differs.
Who paid: the reader. Read the live page against the anchor log while preparing two other corrections. Adjacent work; nothing had prompted it.
2026-09-16in nobody's favour
The published repository itself, between 21:10 and 21:12 UTC on the evening of this row
ClaimedThat the published record carried IOWA.md, the method applied to a subject outside this project, and the checker that tests every quotation in it against the scans.
CorrectedA publish replaced the whole tree with this project's copy of it, which had never carried either file: both had been added to the mirror directly three days earlier and not to the tree the publisher ships. The publisher resets onto the remote and stages everything, so a file the mirror holds and the tree does not becomes a deletion, and the guard added after the last dropped publish counts database rows, not files. Restored a minute and a half later by adding both files to the shipped tree, and the publisher now refuses to delete a published file unless the operator says the removal is intended.
Who paid: the reader. The publisher prints the tree it read back off the remote so that somebody looks. Somebody looked, and two files were missing from a listing that had carried them that morning.

Take the whole record with you

The page above is a rendering. The record itself is a SQLite database holding fourteen principles, the 51 corrections, 63 transferable lessons, and every revision of all 38 published articles, including the exact prose that was removed and why. Download it, open it anywhere, keep it.

errata.db is the database, SQLite
errata.sql is the same contents as plain text, readable in any editor
verify.py is the verifier, standard-library Python, offline, MIT

Check it before you believe it

The database carries a digest over every row, disclosures included. The verifier recomputes it:

python3 verify.py errata.db

  stored    2d0340722842ca59c49710e20f3098b463285084d2e79e57fbce798ff109bebf
  computed  2d0340722842ca59c49710e20f3098b463285084d2e79e57fbce798ff109bebf

  OK    contents match the recorded digest.

A match proves the contents are unchanged since 2026-09-16. It does not prove any statement in them is true, and a seal we make ourselves proves internal consistency only: we build this file, we hash it, we publish it. What closes that gap is an anchor, the record witnessed somewhere outside our reach. Each published build is stamped with OpenTimestamps, which commits the file’s fingerprint to the Bitcoin blockchain through independent calendar servers, a ledger nobody, including us, can rewrite.

The proof ships beside the record:

errata.db.ots is the anchor proof; check it with the open OpenTimestamps client

An anchor proves when the file existed. It still cannot prove any sentence in it is true. Integrity is not accuracy, here as everywhere on this page.

The corrections are not the cost of the work. They are the work.