How We Fact-Check AI-Written Content

Correction (September 2026): This post was rewritten against the pipeline’s own records. The earlier version put work in my voice that the records give to a model or leave without a record. Among it were a personal review of all 17 errors, a test of the 31 briefs that GPT-5.4 ran, a correction round’s approximate count stated as exact, and a plan for human annotation that no record holds. It also gave a reason for building the claim taxonomy and a verification pass I “would not otherwise perform”. It described five claim types that match neither the brief template nor a real brief, and it said the brief carries corrections across rounds and stops reviewers from flagging them again, which no record shows. It said a model will not flag a bad argument, although the adversarial reviewer in post 037 flagged exactly those. It dated the brief system after three reverts, two of which a methodology review had caught with briefs already in hand. It said the triage layer did not exist during the audit when post 037 describes one, and it called a follow-on fix a MUST FIX, a label the saved records do not show. It also called all 38 posts published when one never was, counted four stages without naming them, and gave the seven posts without briefs a reason no record states. It called one kind of false positive the most common with no count behind it, and it closed on a quotation of a sentence no longer in the post. Two quotations were reworded from their sources, the unverifiable claims were called mostly the blog’s own data when the record says only that they include it, and a leaderboard example had no dated source behind it. The March description of the badge’s tooltip is out of date, since the tooltip is gone.

Post 037 describes what three AI models found when they reviewed 33 of this blog’s posts for factual accuracy: 85 errors in the first pass and another 137 when the corrected posts were reviewed again, most of them pre-existing issues the first review had missed and some introduced by the fix agents themselves. Post 035 describes a related cost, that review by several models can cost more than the writing it reviews. This post describes the checking system built for the blog afterward, and what it found when it was run back over the corpus.

The account below covers four parts of that system: the registers a methodology brief sorts a post’s claims into, the brief itself, the triage rule that decides which findings become fixes, and the verification record that persists after a check. Each is described with what it catches and what it misses, because after an audit like 037’s the temptation is to build something comprehensive enough that it sounds like a solution, and the honest accounting is that it is a mitigation with known gaps.

The retroactive pass took all 38 posts then in the corpus, one of which has never been published, extracted 448 discrete claims, and had GPT-5.4 verify each one with web search. Of those claims, 68 percent verified cleanly, 13 percent were partially verified (directionally correct but overstated or imprecise), 8 percent could not be verified from external sources, and 5 percent needed corrections to phrasing or attribution. Nearly 4 percent, 17 claims, were substantively wrong in the ways post 037 catalogues (9 inaccurate, 7 misleading and 1 fabricated), and the one claim left over was pure opinion.

What Counts as a Claim

The first problem was deciding what the checker may flag, because the line between a factual claim and an interpretive judgment is not clean, and a common false positive in automated review is a model treating a thesis as an error. The brief template answers it with Reviewer Guardrails, which ask a reviewer to classify a passage before editing it, and the research record for this system names five registers for that sorting: empirical, epistemological, interpretive, perspective-framed and verbatim data.

Each brief turns those registers into review treatments for its own post. Post 009’s brief says its empirical claims “should be checked against source code and published literature” and its literature claims “should be verified against the cited sources”. Its philosophical claims “are the post’s thesis and should be evaluated for internal coherence, not corrected toward neutral technical language”. When post 009 argues that evaluation circularity is “not solvable in the epistemological sense,” a reviewer without context might flag that as overclaiming, so the brief lists “manageable but not solvable” as protected thesis language and warns reviewers against neutralizing it. In the template, verbatim material sits in a separate table where the only permitted edit is a transcription correction.

The Methodology Brief

A methodology brief is a companion document that travels with a post through every review stage. It describes what the post did, what its key design decisions were, which claims are thesis statements and which are empirical observations, and which phrases and framings are protected from editorial correction. Three corrections reverted during the audit in post 037 show what the brief is for. In post 010 a reviewer replaced “know”, a word chosen for its epistemological precision, with “attend to”. In post 032 model output was edited for style as if it were author prose, including “betwixt”, which was actual DeepSeek V3.2 output displayed as a data exhibit. The third revert restored a practitioner’s epistemic position in post 014 that a reviewer had rewritten into neutral technical language. The research record calls each of those changes locally reasonable but globally wrong, since the reviewer lacked the context to know what the author intended.

Four of the template’s sections address this. Reviewer Guardrails classify the text into registers, and a Claim Classification Map lists specific phrases with their type and what a reviewer may do with each. A Protected Language table holds coined terms, thesis statements and the framings an argument rests on, which are never changed, and a Protected Source Text table holds verbatim quotations and data, which are corrected for transcription only.

Of the 38 posts, 31 have briefs and the other seven have none. GPT-5.4 validated all 31 briefs against the three failure modes behind the system and reported 31 passes, a narrow validation (three known failure modes, not a comprehensive test). In the first review round recorded with briefs attached, the record reports fewer false positives than in the original audit, with none on the protected terms of posts 021 and 028.

The Triage Decision

Post 037 described the fix process, including the triage layer its second phase added, which read every reviewer finding and produced a fix manifest for each post. The correction rounds of the retroactive pass ran on a simpler rule, recorded for the second round: fix claims where the current text is materially stronger than the evidence supports, and leave everything else alone. A claim of “over 150,000” rows errs on the conservative side and stands, since the current count is 164,720, and a claim that costs are “widely estimated” already carries its hedge. The second correction round applied about 12 corrections and skipped 12 findings where the posts were already hedged appropriately. The skipped findings mattered as much as the applied ones, because correcting too aggressively produces prose that hedges everything into meaninglessness, and a post that says “approximately X, according to sources that suggest but do not confirm” about every claim has surrendered its authority without gaining its accuracy.

The hardest triage calls concern whether fixing a claim would break something else. A publication review fix in a post that remains unpublished changed “When machines rendered most physical work obsolete” to “When machines rendered much physical labor in wealthy economies less economically necessary”. The hedge was factually necessary, and it left the analogy that followed resting on the stronger framing, so the next review round had to align the analogy with the hedge. A triage system that evaluates findings in isolation misses correction cascades like this one, and the most dangerous corrections are right about the sentence they change and wrong about the paragraph it lives in.

Closing the Loop

The pipeline leaves three records behind, and their persistence is what makes it more than an editorial pass. The first is the .factcheck.json file beside each checked post, which holds the full verification record: each claim, its status, the source URL where one was found, and any correction notes. The glossary pipeline reads that file as its first source, so a glossary definition can take its source URL straight from the verification results instead of searching again. Before that integration, 77 of 372 glossary terms (21 percent) carried a source URL, and after it 411 of 530 did (77 percent), across a glossary that had grown in the meantime.

The second is the methodology brief, which persists as a review companion and is intended to reduce repeated flags by carrying context forward from one review round to the next. The records show the brief doing its first job, keeping reviewers off deliberate language, and do not yet show it carrying a ledger of corrections across rounds.

The third is the verification badge in the post header on the interactive tier (app.ashitaorbis.com). A green badge means all claims verified or plausible, a yellow badge means the post contains claims with caveats, and the badge carries the claim count, with the verification date in its accessible label. It is deployed only on the app tier, not the static blog, which limits its visibility, but the .factcheck.json file behind it is available to any tier that wants to surface it. The badge makes the verification process legible to a reader: how many claims were checked, when, and with what result.

What This Does Not Solve

The fact check stage catches factual errors and is not designed to judge arguments, which have no ground truth to check against. A post that builds a sophisticated case from accurate premises and reaches a wrong conclusion can pass that stage, because every individual claim verifies. The adversarial reviewer in the publication review does look for arguments that prove too much or too little, as post 037 records, but that review is optional and runs on some posts only.

The pipeline also cannot verify claims about the blog’s own systems, because those claims have no external source. When a post says “The optimizer improved 11 of 13 targets,” the only verification is the project’s own artifacts, which the checking model cannot access, and the 8 percent of claims that could not be verified externally include claims of this kind.

Post 009 describes the deepest limitation: an AI checking claims that an AI helped generate shares training distributions and architectural priors with the generating AI, and shared blind spots do not cancel. The publication review’s panel of models from different families and training lineages mitigates this without solving it, because the circularity is structural. Human ground truth annotations for a subset of posts would break the circle.

The pipeline works in the sense that the pragmatist case in post 009 would recognize. Applied to the existing corpus, it found 17 substantive errors among 448 claims, and applied to new posts, it adds a verification pass before publication, from inside the circle that post 009 describes.