Accuracy

AI factual errors: specific, confident, and mostly near the nouns.

Drafts rarely fail by being entirely wrong. They fail by being right about the shape of a thing and wrong about the detail, which is why a reader who skims will not catch it.

Run it here

Flag the sentences where a specific is doing the work.

Full verification report
Unsourced claim scanner

Words

0

Flags

0

Per 1,000

0.0

Reading

Nothing flagged

No term from this list appears in the text.

Paste a draft. The scanner counts vague attribution, unsupported certainty, undated claims and precision without a source, then shows where they sit. Counted in your browser. Nothing you paste leaves the page.

What counts as a factual error

A factual error is a statement that could be checked and would fail the check: a wrong number, a wrong name, a wrong date, a false relationship between two real things.

It is worth separating from three neighbouring problems. An unsupported claim is unverified rather than false. A misleading framing is true but selective. An opinion is not checkable at all. Editors conflate these and end up either over-correcting prose or under-checking numbers.

The distinction matters because the fixes differ. Unsupported claims need a source or deletion, misleading framing needs restructuring, and factual errors need a diff against reality.

Type one: the wrong number

The most common and the most expensive. A model asked for a market size, a conversion rate or a latency figure will produce a plausible magnitude, and plausible magnitudes are wrong in a way that is hard to see.

Numbers are particularly dangerous because they look researched. A sentence with a percentage in it reads as measured, so readers repeat it, and the error spreads with the authority of the page it started on.

Check every numeral against a primary source, including the ones that feel familiar. Familiarity is exactly the feeling a hallucinated statistic produces.

Type two: the wrong name

Product names, company names, job titles, statute numbers, journal names, API endpoints. These fail loudly once someone looks and silently when nobody does.

Two variations are worth knowing. The invented entity, which does not exist at all, and the real entity with the wrong attribute attached, which is harder to catch because a search returns plenty of true results about the thing itself.

The check is one search per name plus one click into the result. If the result is a directory page that mentions the name without describing the attribute you claimed, the claim is still unverified.

Type three: the wrong date or version

Dates drift because training data has a cutoff. A draft can describe a deprecated API as current, a superseded regulation as in force, or a company as independent after it was acquired.

Version errors are the most irritating because they are actionable. A command that no longer exists produces a support ticket that quotes your own documentation back at you.

Every time-sensitive statement needs the version or date it applies to written beside it, not implied. As of today is a fact with a shelf life, and the shelf life should be visible on the page.

Type four: the false relationship

This is the category that survives careful line editing. Two real entities, correctly described, joined by a relationship that does not exist: the author who did not write the paper, the company that did not acquire the other, the study that did not measure what the sentence says it measured.

It is hard to catch because each half of the sentence is true. You have to check the join, not the nouns, which means reading for the verb: funded, acquired, found, requires, causes, replaced.

The reliable method is to rewrite every relationship sentence as a question and answer it from a source: did X fund Y, does A require B, did the study find C.

Type five: the right fact in the wrong context

A true statement applied where it does not hold. A benchmark result from one workload presented as general performance. A jurisdictional rule stated as universal. A statistic about large enterprises used to describe small teams.

This type is the hardest to prove wrong, because the sentence can be defended in isolation. The error lives in the application, not the assertion.

The test is scope: who was measured, where, when, under what conditions, and does the paragraph's subject match that population. If the answer is unclear, the sentence needs its scope stated or it needs to go.

Why the errors survive an editing pass

Style editing makes prose smoother, and smooth prose hides specifics. An editor tightening sentences is looking at rhythm and clarity, not at whether 64 percent should be 46.

Editors also inherit trust in the draft. Once a paragraph has survived one read, later reads treat its facts as established, and the number becomes part of the page's furniture.

The fix is procedural: a separate factual pass whose only job is checking names, figures and dates, run by a person who has not read the draft for style.

Errors arrive in clusters, not alone

A single wrong fact is usually a slip. Three in one paragraph is a sign that the paragraph was generated without a source, which means the surrounding sentences need the same scrutiny even if they read well.

Clusters form for a reason. A model working without grounding fills a gap with a coherent-sounding set of details, and the details reinforce each other: a plausible company, a plausible product, a plausible statistic, a plausible quote. Each one makes the others feel verified, and none of them is.

So treat one caught error as a boundary marker rather than an isolated fix. Check the whole passage it sits in, then the section heading above it, then any list it belongs to. The correction you are looking for is usually not the only one.

The same applies in reverse to sources you did check. A paragraph whose facts all trace to one document is stable, and a paragraph whose facts trace to nothing is not, however confident its grammar.

The diff method

Put the draft and the source side by side and read only the specifics. Not the sentences, the specifics: the nouns and numerals extracted from the draft, ticked against the source.

Where there is no single source, do it in reverse. Extract the specifics first, then find one for each. Anything you cannot source in a few minutes is either deleted or marked as an open question.

Keep the extracted list with the draft. It is a reviewable artifact, it shortens the second review, and it shows a client or an auditor exactly what was checked.

What an error costs after publication

The cost is not the correction. It is the loss of the assumption that the page was checked. Readers forgive a typo and stop trusting a number.

In commercial writing the cost is often concrete: a wrong price honoured, a wrong compatibility claim returned, a wrong limit triggering a support queue. In regulated writing it is a compliance event with a paper trail.

The asymmetry should drive the process. Checking costs minutes, publication costs credibility, and the ratio is the argument for the factual pass being a fixed step rather than a good intention.

Make the check part of the template

Give every draft a claims block at the top: each specific, its source, and who verified it. It takes two minutes to fill and removes the ambiguity about whether a number was checked or merely copied.

Where a claim cannot be sourced, the block says so and the sentence goes. A visible gap is a decision; an invisible one is a future incident.

Then review the block, not just the prose. A page whose claims block is complete is a page someone can publish, and a page without one has not been checked, however clean the sentences read.

What this covers

  • Numerals extracted

    Every figure listed with its source, including the familiar ones.

  • Names clicked through

    Each company, product and person confirmed, with the attributed detail present in the source.

  • Versions stated

    Time-sensitive statements carry the date or release they describe.

  • Relationships questioned

    Every acquired, funded, requires or causes sentence answered from a source.

  • Scope declared

    Population, jurisdiction and conditions named wherever a statistic is generalised.

Questions this page usually raises

How common are AI factual errors?
It depends on the task. Summarising a supplied document produces few. Asking for specifics about a niche, a local market or anything recent produces many. Track your own rate rather than relying on a benchmark.
Will a second model catch the first model's errors?
Sometimes. Disagreement is a useful signal that a claim needs a source; agreement is weak evidence, because both systems were trained on similar material.
Is a citation enough to trust a claim?
No. Open the source and confirm the sentence. A real link attached to a misstated claim is one of the most common failures in generated research.
What is the fastest check for a long draft?
Extract every number, name and date, then work through the list against primary sources. Reading the prose for accuracy is slow and unreliable by comparison.
How do I handle an error I already published?
Correct it visibly, note the date of the correction, and check whether the claim was repeated elsewhere. Silent edits to a published number erode trust further when they are noticed.
Does the checker on this page find factual errors?
No. It counts sentence patterns where a specific is likely to be doing the work, which tells you where to check. Only a source confirms or refutes the fact itself.

AI factual errors

Run the checks, then decide who has to sign it.

The automated pass is free, needs no account and uploads nothing. Escalate to a named reviewer only where being wrong is expensive.