How this research is checked
This section appears at the end of every companion on this site. If you have read it before, you have reached the end of the article. If this is your first companion here, this is the part that explains why the numbers above deserve your attention — and how you can check them yourself.
Every paper in this series follows one written standard, and the standard has a single aim: by the time a claim reaches you, it should no longer depend on trusting the author.
It starts before any data is examined. The design of each study — what will be measured, what settings will be used, and what would count as success or failure — is written down and committed first, with timestamps. This is called pre-registration, and it exists to close the oldest loophole in research: trying many things and publishing only the one that happened to look good. A test whose rules were fixed in advance cannot be quietly steered toward a wanted answer, because by the time the answer exists, the rules are already on the record.
The data is sealed the same way. Every input file is downloaded once, at a stated date, and run through a standard mathematical fingerprinting method that turns the file’s exact contents into a unique code — change one digit anywhere and the code changes completely. The fingerprints are committed alongside the data, so anyone who downloads the paper’s materials can confirm, to the digit, that they hold exactly the files the paper used, unaffected by the quiet revisions government datasets accumulate over time.
The numbers in each paper are then generated, not typed. Every important figure is produced by a program committed to the paper’s public code repository, running on the sealed data, and recorded in a locked ledger that pairs each figure with the exact code and inputs that produce it. A verification program re-runs the full analysis and checks every figure in the paper against that ledger; if anything drifts — a number, a file, a line of code — the check fails and says so. The paper’s text receives its figures from this machinery directly, so a typo in a result is not just unlikely: there is no manual step where one could occur.
Before publication, each paper faces an adversarial review: a reviewer with no access to the project’s working history receives a sealed, fingerprinted package, independently re-runs the verification and the full test suite, and reports everything found. Every finding is either fixed or answered in writing, and the findings and responses are committed to the repository where anyone can read them. Separately, the entire pipeline is rebuilt from nothing — a fresh copy of the code, a new computing environment, every experiment re-run — to confirm that the results reproduce outside the author’s own machine.
Two more pieces complete the picture. Each paper carries a public corrections log, which starts empty and records any error found after publication: the date, the mistake, who caught it, and what changed. And where a paper’s claims reach into the future, the prediction is registered publicly and dated before the outcome is known — including the conditions under which it should be judged wrong. Those live on the forward predictions page, where anyone can keep score.
One disclosure belongs here in plain terms. This research was produced in a human-directed, AI-executed collaboration: the author set the questions, made the decisions on record, and ran the computations, while an AI system (Claude, by Anthropic) drafted the analysis code, the experiments, and the prose under that direction — and the adversarial review described above was itself performed by an AI in an isolated session. The safeguards on this page exist precisely so that none of the conclusions ask you to trust any author, human or machine. Each paper’s full disclosure appears in the paper itself.
None of this makes the work correct. It makes the work checkable — and the difference between those two words is what this series is about. Every paper links its repository, its data fingerprints, its review record, and its corrections log. The invitation is standing: download it, re-run it, and if something breaks, say so — the corrections log is waiting.
For replicators: walking a repository
Anyone who wants to go beyond reading can check the work directly. Each paper’s repository opens with a README and an index that name every part: the manuscript source, the analysis scripts, the sealed data recipes, the verification program, and the review record. The short version of a full check: clone the repository, restore the pinned data snapshot as the replication guide describes, and run the verification program — it re-derives every checked figure and prints a pass or fail for each of its checks, ending green only if the entire chain holds. The locked ledger (claims.lock) is the pairing of every printed number with the script and inputs that produce it; PREDICTIONS.md is the dated forward registration; CORRECTIONS.md is the public log of anything found wrong after publication; REPLICATION.md records the exact environment the results were reproduced in.
One convention deserves a decoder, because it looks unusual on first contact. Alongside standard scholarly labels — theorems, equations, tables — the papers and their repositories carry structured IDs: claims (C-), limits of claim (L-), findings (F-), and load-bearing values (LB-). These are the machine addresses the verification program checks: every consequential number and statement has a fixed name, so an automated gate can confirm each one is present, sourced, and unchanged — the same requirements-traceability discipline used in aerospace and other safety-critical engineering. In the paper’s source text, load-bearing numbers appear as placeholders that the build fills from the ledger; the published PDF shows only the finished values. A replicator who sees an LB- code in the repository is looking at the name of a number, and the ledger row under that name is its birth certificate.