Where the published record was wrong, and what changed so it would not happen the same way twice.
A body of work shows what someone can build. It does not show what they do when the work turns out to be wrong — which is the more useful thing to know, and the harder thing to fake.
So this is the other half of the record. Every entry below is a published claim that did not hold, what it cost, how it surfaced, and the mechanism that came out of it. The mechanism is the point. A correction that produces only a corrected file has taught nobody anything; a correction that produces a gate the pipeline now enforces cannot recur quietly.
Nothing here is reconstructed from memory. Each entry links to the commit, the rendered correction, or the artifact that carries it.
An adversarial audit started from a single flag — one case 7.4% off — and a purpose-built checker confirmed it was systemic. The renderer displayed whatever four numbers a brief supplied as a literal equation, with no validation. The scores had been authored editorially, chosen to read well, while the page presented them as computed.
Corrections were published as visible dated errata rather than silent edits, on the principle the surrounding methodology already stated: an artifact remembers its origin. Each affected case now carries a dated correction box naming what was originally published and what it became. Verdicts were re-checked against the threshold per case, never assumed.
The generate-and-deploy pipeline now hard-fails on any FETCH or DRIFT mismatch over 1%. A near-identical check already existed but only ran in a compile path this pipeline never used — and was a warning, not an error.
Evidence: 48 case briefs carry a CORRECTION-DATE field, rendered on the live pages — for example uc-302.stratiqx.com.
Each of sixteen cases carried a different, sequentially incrementing Zenodo identifier, rendered as a live clickable link in the page footer. Fourteen of the sixteen resolved to real deposits by other researchers — among them a Nigerian environmental-justice study, a study of 5G in Gabon, and a Slovak sheep-meat-market thesis. Two were dead links.
The cause is worth naming precisely, because it generalises: a DOI looks like a value you can pattern-match, when it is an identifier you must resolve. Once one case carried a plausible wrong number, each subsequent case inherited the habit. The run being contiguous is the tell.
A non-canonical DOI now blocks deploy at error level. Previously the audit flagged only an absent DOI, and only as information — which is exactly why all sixteen passed clean. A library-wide sweep followed: every case reconciled, none missing, none wrong.
Evidence: the library now resolves to a single canonical runtime DOI across every CAL case, alongside the handful of genuine external citations.
UC-062 forecast a severance cascade behind two triggers. On scheduled review, the second was retracted outright: the August jobs report revised July payrolls from −23,000 to +21,000 and printed +162,000 for August, leaving the “two or more negative payroll prints” condition unmet.
The detail that makes it worth publishing is that the case's overall health went up in the same review, from 38% to 55%. Withdrawing the trigger was not a downgrade. It was the record catching up with the data, in public, on a schedule set before the answer was known.
Evidence: uc-062.stratiqx.com/r/ — review R6.
IntentCut's release ceremony binds a human approval to an exact artifact. An independent review checked every documented guarantee against the code and tried to break each one. The mechanisms were real — but several trusted inputs they should not have, including an approval step that believed the pass recorded in its own candidate file.
The inputs were fixed. The more useful change was to the claim itself: the ceremony is now described as an integrity binding for an honest operator, which makes accidents fail closed — and explicitly not as access control, because a process holding the operator's shell could write the same records.
Every refusal gained a test. The narrower claim is stated in the project's own security documentation rather than left for a reader to discover.
Evidence: SECURITY.md and the project's progress record.
A design note argued that a speech synthesiser which samples would break the project's central claim, because rendering the same source twice must produce identical output. Stated that strongly, it was wrong.
Rendering never synthesises. Narration is produced by a separate command and consumed as a file, so reproducibility is a property of the compile, and a sampling voice only breaks it when the audio is regenerated. The real rule is narrower and more useful: decide whether the generated audio is disposable or kept, and make the repository agree with the answer.
The original entry was left standing and a follow-up published beneath it, rather than edited quietly. The history of getting it slightly wrong is worth more than a clean-looking file.
Evidence: the progress record in semanticintent/intentcut, entries dated the same day.
Three of the five were caught by something outside the author — an adversarial audit, an independent review, a scheduled check against evidence that had not arrived yet. Two were caught by noticing. None were caught by the tests that existed at the time, which is the argument for all three habits.
The threshold for appearing here is that something published was wrong. Not that a plan changed, or that a better idea turned up later — those are ordinary. This page is narrower on purpose, and it is expected to keep growing.