How to Review AI Output Against a Source Document
An AI summary reads perfectly, but you can't tell if every sentence is in the source or whether a "may" hardened into a "will." Here's how to review AI output claim-by-claim against the document it came from, so unsupported and overstated claims surface before you rely on them.
Get the Hallucination Detection PromptWhen the summary reads perfectly — but is it in the source?
You hand the AI a cancellation policy and ask for a plain-English summary. Back comes one clean sentence: "Customers can cancel anytime with 30 days' notice and are eligible for refunds." It reads well, it sounds authoritative, and you're about to paste it into a customer reply. Then you look at the actual policy: cancellation is allowed with 30 days' notice *before the renewal date*, miss that deadline and it renews for a year, and refunds are *reviewed case by case*. The summary didn't just simplify — it said "anytime" where the source set a deadline, promised refunds the source only considers, and dropped the renewal trap entirely. Nothing in the output looked wrong. It was wrong against the source, and reading the output on its own could never have told you.
That's the problem this guide solves. A fluent AI output — a summary, a research brief, a compliance note, a support reply, a risk analysis — is not the same as a faithful one, and you can't judge faithfulness by rereading the output. You judge it by checking the output against the source, claim by claim. A source review can't prove the output is *true* — the source itself might be wrong — but it makes the unsupported, contradicted, and overstated claims visible, which is exactly what a confident-sounding summary hides. This is reviewing a finished output against its source, a different job from building source pointers into data as you extract it.
Why a fluent output isn't a faithful one
Models are trained to produce text that reads well and feels complete, and that pull is exactly what pushes an output away from its source. A summary that hedged every sentence the way a contract does would read badly, so the model smooths it — and the smoothing is where fidelity leaks out. Four failures hide inside prose that reads fine:
- Caveats get dropped. "Refunds are reviewed case by case" becomes "eligible for refunds" — the qualification that changes the meaning is the first thing to go when the model tightens the sentence.
- Modality hardens. A source's "may," "can," or "is typically" quietly becomes "will," "does," or "is" — the claim gets more certain than the document ever was.
- Sources blur with world-knowledge. The model fills a gap with what's usually true rather than what this source says, and the added fact reads identically to the ones actually in the text.
- Everything arrives in one confident voice. A claim lifted straight from the source and a claim the model invented are written in the same tone, so nothing on the surface flags which is which.
Step 1: Ground the source so each claim can point to a section
A claim-level review needs somewhere to point. Before you review anything, package the source so its parts are addressable and the model is told to stay inside them — wrap it in clear delimiters, label the sections, and set the rule that any judgment must cite the section it rests on and say plainly when the source is silent.
The Long Input Formatter does this in your browser: it wraps your pasted source verbatim between explicit markers, inserts [§N — title] section labels so a claim can name where it's supported (or isn't), and — in strict grounding mode — states the discipline the whole review rests on: only the delimited text exists, and a claim that can't be cited is a claim that can't be made. It packages the text you paste; it doesn't read a PDF, run a model, or check anything for you. With the source labelled this way, the review that follows can attach a section to every verdict instead of gesturing vaguely at "the document."
Step 2: Break the output into claims and rate each against the source
Now review the output the way you'd review a set of statements, not a paragraph. Split it into discrete, checkable claims — one assertion each — and rate every claim against the source, not against what you already believe: supported (the source says it), partially supported (true but missing a condition or scope), unsupported (not in the source, however plausible), contradicted (the source says otherwise), or inference (the model's conclusion, not a stated fact). For each, require the exact source span that backs it, or an explicit "not in the source." Then run the pass in reverse: scan the source for the material facts, caveats, and conditions the output never mentions at all — a claim-by-claim read of the output can only judge what's on the page, so a dropped requirement or an omitted consequence stays invisible unless you check the source for what's missing.
The Hallucination Detection Prompt is built for this pass: it extracts the checkable claims from an output you paste, classifies each as supported, contradicted, or unsupported *against the pasted source only* — treating "not in the source" as unsupported even when it's probably true — quotes the offending span, and ranks the unsupported claims you'd act on as highest risk. Its core is a three-way verdict; the partial and inference labels above are ones you add to the prompt when a plain supported/unsupported split is too blunt for your material. When the source is a set of retrieved passages rather than one document — a RAG answer — the Groundedness Check Prompt is the variant to reach for: it attributes each claim to a specific passage and returns a grounded / partially grounded / not grounded verdict. Both judge fidelity to the source, not truth: a claim can be marked supported and still be wrong if the source is wrong.
Step 3: Catch the claims that are stronger than the source
The dangerous claims aren't the invented ones — those often stand out. They're the ones that are *almost* right: a claim that's in the source but said with more certainty, wider scope, or fewer conditions than the source allows. These pass a casual read precisely because they're anchored to something real. So make "stronger than the source" its own thing the review looks for, separate from "in the source at all."
Ask the review to compare each claim's *strength and scope* to the source, not just its presence: did a caveat get dropped, did "may" become "will," did "reviewed case by case" become "granted," did a scoped rule ("cancel with notice *before renewal*") lose its condition, did an uncertainty get stated as a settled fact? A claim can quote a real sentence and still overstate it. Flagging that gap — between what the source supports and how far the output pushed it — is the part of the review a spell-check-style read will never do for you, and it's usually where the real risk in a summary lives.
Step 4: Sort what needs a human, then turn the review into a repair
The review is triage, not a verdict on the output. Sort the claims: supported ones pass, and the unsupported, contradicted, partial, and high-risk ones go to a person — you — who reads each flagged claim against its cited span and decides. The point of the classification is to shrink what you have to check by hand from the whole output to the handful of claims that actually moved off the source.
Then close the loop. Turn the flagged claims into a concrete repair: a prompt that rewrites the output to drop the unsupported claims, restore the dropped caveats, and pull the overstated ones back to what the source actually says — then review the rewrite the same way, because a repair is a new output with its own claims. And to need the repair less often, cut unsupported claims upstream: the Reduce AI Hallucinations with Grounding resource is a strict-grounding contract you wrap the source in *before* the model writes, so the output is told to answer from the source and cite it — or say it can't. Prevention thins the review queue; it doesn't replace the review.
Step 5: Know what the check proves — and what it doesn't
If you run this at any scale, you'll want the review as a structured report — one row per claim, with its verdict, its source quote, and its section — so the flags are sortable instead of buried in prose. If you produce that report, the AI Output Validator can confirm the *report* is well-formed in your browser: every claim has a verdict field, the structure parses, nothing required is missing. What it cannot do — despite the name — is tell you whether a verdict is right or a source is true. It checks the shape of your review, not its judgment.
That line is the honest boundary of the whole method. A clean source review is a strong grounding signal: it means the claims you checked trace to the document. It is not a proof of correctness — the source could be mistaken, a quote could be cited but not actually support the claim, and the review only covers the claims it managed to extract. For anything carrying legal, financial, medical, or compliance weight, a source review organizes the check and surfaces what to look at; the sign-off still belongs to you or a qualified reviewer, never to the prompt.
Common mistakes
A few habits let unfaithful claims through a review that was supposed to catch them:
- Reviewing the output on its own. Rereading a summary for whether it "sounds right" catches typos, not fidelity — the tells only appear next to the source.
- Only checking for invented claims. The overstated ones — a real claim pushed past what the source allows — are more common and more dangerous, and a presence check walks right past them.
- Accepting a citation as proof. A claim can quote a real sentence that doesn't actually support it; the quote makes the claim checkable, it doesn't make it correct.
- Treating "supported" as "true." The review measures fidelity to the source, not to reality — if the source is wrong, a faithful summary is wrong too.
- Letting the validator's name mislead you. Checking that a review report is well-formed says nothing about whether its verdicts are right — structure is not truth.
- Skipping the re-review after a fix. A repaired output is a new output; its rewrite can introduce a fresh unsupported claim, so it needs the same pass.
A worked example: a cancellation-policy summary
Say you're reviewing an AI summary of a cancellation policy before it goes into a customer reply. Here's the source, the summary to review, the claim-by-claim result, and a rewrite that stays inside what the policy actually says.
One overstated summary, reviewed claim-by-claim against the policy it came fromSOURCE (what the policy actually says):
"Customers may cancel with 30 days' written notice before the renewal
date. If notice is not received before that deadline, the subscription
renews for one additional year. Refund requests are reviewed case by case."
AI OUTPUT (the summary to review):
"Customers can cancel anytime with 30 days' notice and are eligible for
refunds."
CLAIM-BY-CLAIM REVIEW, against the source:
"cancel anytime" -> CONTRADICTED source ties cancellation to a
deadline: notice before renewal
"30 days' notice" -> PARTIAL true, but drops the scope — it must
be before the renewal date
"eligible for refunds" -> STRONGER source says refunds are "reviewed
case by case," not granted
(the renewal trap) -> OMITTED source: misses the deadline -> renews
for another year; summary is silent
SAFER REWRITE (kept inside the source):
"Customers may cancel with 30 days' written notice before the renewal date.
Miss that deadline and the subscription renews for another year. Refund
requests are reviewed case by case."Where this fits in NewPrompt
Reviewing one output against its source is a prompt you run and a judgment you make — NewPrompt has no button that audits an output for you, and that's the honest shape of it: you paste the source and the output into your own AI assistant, run the review, and read the flags. Where this becomes part of something larger is when grounded output is the whole point of what you're building. The Build an AI Research Assistant with AI project treats it as a named stage rather than an afterthought: its groundedness-and-hallucination evaluation stage is about checking that findings actually trace to their sources and catching the confident claim with no citation behind it — the same claim-versus-source discipline this guide applies to a single output, built into the path so an assistant ships on evidence it can stand behind. NewPrompt's part is upstream of the judgment: it packages the source so each claim has a section to point at, it supplies the audit prompt that sorts the claims, and it can check that a review report is well-formed. Reading each flagged claim against its cited span, and deciding whether a verdict actually holds, is the part no prompt performs for you.