AI Fact Checking: A Content Pipeline Stage That Cuts Claims

An AI fact-checking pipeline splits a draft into individual claims, types each one, fetches the source it points to, and compares the sentence to the page. A claim that matches stays. A claim that does not match is cut, and if the post cannot stand without it, the draft is blocked. No person approves the leftovers.

That is the stage most AI content pipelines skip, because it is the one a script cannot do by pattern. We wrote about the mechanical gate in AI content quality checks and ended on the hole it leaves: it cannot tell a true sentence from a false one. This post is about filling that hole.

One note on scope. Below is the fact-check stage as we design it for client installs. On our own blog today, the source check is a rule the drafting run follows, and no script proves it ran. We said so in the earlier post, and it stays true here.

What is an AI fact-checking pipeline?

An AI fact-checking pipeline is a fixed sequence of steps that turns a finished draft into a list of checkable claims, verifies each against a fetched primary source, and removes or blocks whatever fails. It runs before the pull request opens, produces a written record for every claim, and needs no reviewer to read the post.

The drafting is done by a tomte, our word for one production agent with one defined job. The fact-check is a second tomte with a different job: it never writes, it only tests. Keeping the writer and the checker apart matters, because a model asked to grade its own draft tends to defend it.

Why can’t a lint gate or a better prompt do this job?

A lint gate tests structure, and a prompt asks for honesty. Neither fetches a page and compares it to a sentence. Models still produce plausible false detail at measurable rates, and the failures cluster in exactly the places a reader trusts most: statistics, dates and citations.

Two data points, both from the last year. A peer-reviewed study in JMIR Mental Health (November 2025, Deakin University researchers) prompted GPT-4o in June 2025 to write six literature reviews and checked all 176 citations by hand. Of those, 35, or 19.9%, were fabricated, and 64 of the 141 real ones had errors, mostly bad DOIs.

The same study found that fabrication tracked topic familiarity: 6% for major depression, 28% for binge eating disorder and 29% for body dysmorphic disorder. Niche topics fail more. A B2B blog is made of niche topics.

NewsGuard’s August 2025 monitor (published 4 September 2025) tested 10 leading chatbots on news claims and found they repeated false claims 35% of the time, up from 18% a year earlier. Their non-response rate fell from 31% to 0%. A system that always answers will sometimes answer wrongly with confidence.

How do you extract and type claims?

Claim extraction means reading the draft sentence by sentence and listing every statement that could be true or false on its own, then labelling each by type. The type decides which check runs and what failure costs. A number is tested against a page. An opinion is not tested at all.

The extractor is a separate pass with one instruction: list every checkable statement, including the ones the writer thought were obvious. Typing then routes each claim.

Claim type	Example	Check	If it fails
Number	”35% repeated false claims”	Figure appears on the fetched page, same unit and base	Cut the claim
Date	”published 4 September 2025”	Date on the page matches, year anchor present	Fix if the page is clear, else cut
Quote	Any quoted words	Exact string found in the source	Remove the quotation marks or cut
Attribution	”NewsGuard found…”	Named publisher authored the page	Cut
Comparison	”up from 18%“	Both figures and both dates on the source	Cut
Our own number	A result from our work	Matches a figure already public on the site	Block the draft
Opinion or method	”short posts read better”	Not tested, kept out of fact claims	Kept

Notice the row for our own numbers. A figure about our own results is never verified against the open web, because the web has no copy of it. It is tested against what we have already published, and a new one blocks the draft until the figure itself has been published under a named sign-off. The number gets approved once, on the proof page. The post never does. For the record, the only site figures we reuse are public ones, such as the 363-product catalogue on our inbound machine proof page, dated July 2026.

What counts as a source, and how is it matched?

A source is a page the checker can fetch today, authored by the publisher the sentence names, from a tier a reader would accept. Tier 1 is primary: vendor documentation, government and standards bodies, peer-reviewed journals, the original announcement. Tier 2 is a named research firm publishing its own data. Everything else is a lead, never a citation.

Matching is the step that earns the pipeline its keep. The checker fetches the page, finds the number, and confirms four things: the figure is there, the unit and base match, the year matches, and the publisher in the sentence is the publisher of the page. A statistic repeated by an aggregator fails the fourth test even when the number is right.

Primary beats secondary even when the secondary is easier to read. When we checked the NewsGuard figure for this post, several news write-ups agreed with each other, and one of them misdated the comparison by a year. The monitor page itself had it right. Aggregators copy each other’s errors, and the copy is what a drafting model has usually seen.

The same applies to rules. Google’s spam policies page (last updated 28 August 2026) defines scaled content abuse as large amounts of unoriginal, low-value content “no matter how it’s created.” That sentence is why a claim about Google’s position is matched to that page, not to a blog summarising it.

What happens to a claim that cannot be verified?

An unverifiable claim is cut. If the sentence carries the section, the section is cut. If the section carries the post’s answer to its target query, the draft is blocked and goes back to be rewritten around claims that passed. No one is asked whether a shaky number is probably fine.

That rule removes the approval step on purpose. A person asked to approve a doubtful statistic at the end of a pipeline has the draft in front of them and a deadline behind them, and the cheapest answer is yes. Cutting is cheaper than arguing, and a post with four verified figures reads better than one with nine.

The pipeline we describe runs in order: draft, extract, type, fetch and match, cut or block, then the mechanical gate, pull request and automated merge on green. The fact-check sits before the gate so the gate sees only what survived.

One list keeps it honest. A stat blacklist holds figures that circulate widely and fail on the primary page: the number is missing, the base is different, or the study is a vendor survey presented as research. A claim that matches the blacklist is cut without a fetch. The list grows whenever a figure fails once, and it is written down in the rulebook, not remembered.

What does the audit trail hold?

The audit trail is one record per claim: the sentence, its type, the source URL, the fetch date, the matched text, and the outcome. It lets anyone reconstruct why a figure is in a post, and it makes the checker itself testable, because a wrong pass leaves evidence behind.

Model vendors now ship part of this plumbing. Anthropic’s citations documentation says that when citations are enabled, the API extracts the cited text itself and the citations are “guaranteed to contain valid pointers to the provided documents.” That is useful: the pointer cannot be invented.

Read it carefully, though. A valid pointer proves the passage exists in the document you supplied. It does not prove the document is a good source, that the sentence paraphrases the passage correctly, or that the year is right. Grounding tools give the checker a better starting record. They do not replace the match step, and we do not treat them as one.

What does this stage still not catch?

It does not catch a claim that is true but irrelevant, a source that is wrong at the publisher, or an inference the writer built on correct facts. It tests statements, not reasoning. It also depends on the extractor finding every claim, and an extractor can miss a quiet one.

So the stage narrows the gap and does not close it. We would rather say that than sell a pipeline as error-free, which no fact-checking process, human or automated, has ever been. What changes is where the failures show up: in a written trail with a source URL, not in a reader’s email.

Where this fits in the Content Engine

This is the stage we build into the Content Engine installs, around the same shape we run for our own publishing. You get fixed scope and a fixed price, the claim rules live in your repository, and you own the delivered code, data and documentation. The wider chain from queue row to live URL is in our AI content pipeline example.

If you want claim checks built around your own sources and your own banned figures, Start async. You get a written reply within one business day, and there is no call to book.