You asked the model to extract every dollar amount from a 40-page contract. It returned a clean table. Looked great. Three of the numbers were invented.

This is the default failure mode of every LLM in production. The output looks right. The format is correct. The confidence is high. And somewhere in the middle, the model filled a gap with something plausible instead of something true.

The fix isn't a better model. It's a second pass.

What the Verification Pattern Actually Is

Meta published the Chain-of-Verification (CoVe) paper in late 2023, and the core finding still holds: when you make a model check its own work in a structured way, hallucinated entities drop by 77%. No fine-tuning. No retraining. Just prompting.

The pattern is four steps:

Generate the initial output.
Plan verification questions based on that output.
Verify each question independently (this is the critical part).
Revise the original output based on what the verification found.

Step 3 is where most people get it wrong. If the model can see its original draft while verifying, it just confirms its own hallucinations. The research calls this "factored verification" -- you strip the original context and force the model to answer each verification question from scratch.

The difference between joint and factored verification is the difference between asking someone to proofread their own essay while reading it, versus quizzing them on the facts with the essay closed.

The Naive Version vs. the Pattern

Here's what most people do when they want to check LLM output:

The Prompt (naive):

Review your previous response and correct any errors.

Why This Fails: The model has no criteria, no structure, and full access to its original reasoning. It will almost always confirm what it already said. This is the LLM equivalent of asking "are you sure?" -- the answer is always yes.

Now here's the verification pattern applied to the same task:

Step 1 -- Generate:

Extract all monetary amounts from the following contract text.
Return a table with columns: Section, Amount, Context.

[contract text]

Step 2 -- Plan verification:

You produced the following extraction table:

[paste table from step 1]

List the 5 claims in this table most likely to be incorrect.
For each, write a specific verification question that could
confirm or deny it using only the source text.

Step 3 -- Verify (independently, without the original table):

Answer each question below using ONLY the contract text provided.
If the answer cannot be determined from the text, say "NOT FOUND."

Questions:
[paste questions from step 2]

Source text:
[contract text]

Step 4 -- Revise:

Original extraction:
[table from step 1]

Verification results:
[answers from step 3]

Produce a corrected table. Remove any row where verification
returned "NOT FOUND." Flag any row where the verified amount
differs from the original.

Why This Works: Step 3 forces the model to re-derive each answer from source material without seeing what it previously claimed. When the model hallucinated a dollar amount in step 1, step 3 catches it because it can't find supporting evidence. The separation between generation and verification is what makes this reliable.

Expected Output:

That fourth row? The model invented it on the first pass. Without verification, it ships to your client.

Where Chain-of-Thought Backfires

Here's a wrinkle most prompting guides won't tell you. An EMNLP 2025 paper found that chain-of-thought prompting -- the technique everyone defaults to -- actually makes hallucinations harder to detect. The model reasons its way into a wrong answer so convincingly that both humans and automated checks miss it.

CoT reduces hallucination frequency. But it increases hallucination confidence. The model becomes more articulately wrong.

This matters for verification because a confident, well-reasoned hallucination looks exactly like a correct answer. If your verification step is "does this reasoning make sense?" you'll approve fabricated outputs all day long. The verification has to check against source material, not against the model's own logic chain.

Similarly, research from ASE'25 on code verification found that asking the model to explain and correct errors in a single pass led to higher misjudgment rates. The model over-corrected, introducing new errors while fixing imaginary ones. The fix was separating analysis from correction into two distinct phases -- which is exactly what the CoVe pattern does.

A Verification Template for Code Review

Data extraction is one use case. Here's the pattern applied to code review, which has its own failure modes.

Step 1 -- Generate the review:

Review this Python function for bugs, security issues,
and performance problems. List each issue with severity
(critical/warning/info) and a fix.

[paste function]

Step 2 -- Plan verification:

You identified these issues:
[paste review from step 1]

For each critical and warning issue, write a question that
can be answered by reading the code alone:
- Does the issue actually exist in this code?
- Is the proposed fix correct and complete?
- Could the fix introduce a new bug?

Step 3 -- Verify independently:

Answer each question below by examining ONLY the code provided.
Do not assume any issue exists -- confirm or deny based on
what the code actually does.

[paste questions from step 2]

Code:
[paste original function]

Why This Works: LLMs love to find bugs that aren't there. They'll flag a SQL injection in code that uses parameterized queries, or warn about a null pointer in a language with option types. The independent verification step forces re-examination of the actual code rather than rubber-stamping the initial review.

When to Skip Verification

Not every LLM call needs a second pass. Here's the decision framework:

Skip it: Creative writing, brainstorming, marketing copy drafts, internal chat summaries. If a hallucination is just a creative suggestion you'll edit anyway, the verification cost isn't worth it.

Light check: Meeting notes, email drafts, content outlines. Verify only if specific numbers, dates, or names matter. One quick "confirm these three facts" pass is enough.

Full CoVe: Client deliverables, data extraction, anything published under your name, legal or financial content, code that will run in production. The 77% reduction in hallucinated entities isn't a nice-to-have here. It's the difference between professional output and liability.

The cost is real -- you're making 3-4 LLM calls instead of 1. But consider the alternative. GPTZero found that 16% of sampled ICLR 2026 papers contained hallucinated citations that passed multiple expert human reviewers. If domain experts miss fabricated references, your quick skim of an LLM's output won't catch them either.

Building It Into Your Workflow

Nobody types four prompts manually in 2026. The verification pattern belongs in your automation layer.

If you're building with Python, it's a function that wraps your LLM calls. If you're using n8n or Make, it's three additional nodes after your generation step. The pattern stays the same regardless of tooling: generate, plan checks, verify independently, revise.

The independence of step 3 is non-negotiable. If you're using an API, that means a fresh completion call without the original output in the context window. If you're using a chat interface manually, it means starting a new conversation for the verification questions.

One practical shortcut: you don't always need the model to plan its own verification questions. For repeatable tasks like data extraction or code review, you can write the verification questions yourself as a template. The model plans good questions, but your domain knowledge plans better ones.

The Real Lesson

Verification prompting isn't about trusting AI less. It's about building the same quality controls into AI workflows that already exist everywhere else in professional work. Accountants have audits. Engineers have code review. Writers have editors. Lawyers have cite-checking.

The LLM is the first draft. The verification pass is the editor. Skipping it doesn't make you faster -- it makes you the person who shipped a hallucinated number to a client and found out in the reply-all.

If your team wants to build verification patterns into production AI workflows, Kief Studio runs hands-on prompt engineering training. Connect on Discord or schedule a session.

hallucination detection

The Verification Prompt Pattern: Build Self-Checking Into Every LLM Call