A Detect-LLM-Hallucinations Prompt That Checks Every Claim

A hallucination is a confident, fluent answer that the source material doesn't actually support. The danger isn't that it looks wrong. It's that it looks right: polished, structured, cited-sounding, and completely fabricated. To detect llm hallucinations at the speed you ship them, you need a check that's mechanical, not vibes-based.

The reliable move is a faithfulness check. The prompt takes the model's answer plus the source it was supposed to use, breaks the answer into atomic claims, and labels each one supported, unsupported, or contradicted, with the evidence quote written before the verdict. You get a per-claim table you can gate on, not a single number you have to trust.

That ordering, evidence first and verdict second, is what keeps the checker honest. Flip it and the model rationalizes whatever verdict it picked.

Why most hallucination-detection advice can't be run

The pages that rank read like product tours or research abstracts. Datadog's hallucination-detection writeup describes a solid claim-extraction-then-verdict approach but never publishes the prompt and tests only GPT-4o, never Claude. The semantic-entropy paper in Nature is rigorous and unusable as a copyable artifact. And general explainers like Appsmith's de-hallucination guide stay at the concept level.

So you're left understanding the theory with nothing to paste. That's the gap. A grounding check you can run on any answer, against any source, in any model, beats a platform feature you can't see inside.

Here's a take worth holding: stop chasing a single hallucination score. One number per answer hides the one fabricated claim inside five true ones. A per-claim verdict tells you exactly which sentence to cut, and that's the only output an editor or a CI gate can act on.

What you can do with this prompt

• Break any answer into atomic, separately-checkable claims.
• Label each claim supported, unsupported, or contradicted against a source.
• Force an evidence quote before every verdict so judgments stay grounded.
• Separate contradictions you should block from unsupported claims you should review.
• Flag claims that need an external source the provided context doesn't cover.
• Produce a gate-ready table for CI or a human-review queue.

Anatomy of the faithfulness-check prompt

The prompt takes a candidate answer and its source, then emits a per-claim grounding table.

Variables:
  {{candidate_answer}}  – the output to check
  {{source_text}}       – the context it should be grounded in
  {{strictness}}        – how to treat plausible-but-absent claims

Prompt:
  Role: faithfulness auditor. You verify grounding, not style.
  Steps:
    1. Decompose {{candidate_answer}} into atomic claims.
    2. For each claim, quote the supporting span from
       {{source_text}} FIRST, then assign the verdict.
    3. If no span supports it, mark unsupported or contradicted.

Output contract (restate on the final line):
  Per claim:
    - claim
    - evidence quote (verbatim from source, or "none")
    - verdict: supported | unsupported | contradicted
  Plus: overall PASS only if zero contradictions.

The evidence-before-verdict order in step 2 is the whole trick. Ask for the verdict first and the model picks one, then writes a quote to justify it. Ask for the quote first and it has to find real evidence before it can rule.

Step-by-step usage

1. Paste the answer and its source

{{candidate_answer}} is the output under test. {{source_text}} is whatever it was supposed to ground in: retrieved chunks, a doc, a transcript. No source means no faithfulness check, only open fact-checking, which is far less reliable.

2. Set the strictness for absent claims

{{strictness}} decides how to treat a claim that's plausible but not in the source. Strict marks it unsupported. Lenient lets through claims that are common knowledge. For regulated content, run strict.

3. Read the evidence quotes, not just the verdicts

The verdicts are only as good as the quotes. Scan the evidence column. If a "supported" verdict points to a quote that doesn't actually say the thing, the checker is rubber-stamping. That happens most on long sources where the model pattern-matches keywords.

4. Gate on contradictions, review the unsupported

Block anything with a contradicted claim outright. Route unsupported claims to a human, because some are fine (general knowledge) and some are quiet fabrications. Collapsing the two into one fail is how teams end up ignoring the gate.

5. Keep the failures as test cases

Every real hallucination you catch is a regression case. Save the answer, the source, and the verdict so the same fabrication can't slip back as prompts change.

Prompt-craft patterns for grounding checks

Atomic claims, not sentences. A single sentence often packs three claims, and one can be false while the others are true. Tell the prompt to decompose to the level where each unit is independently checkable, or the verdicts blur.

Decompose to atomic claims: each one true-or-false on its own.
"The API returns JSON and was added in v2" is TWO claims.
Check them separately or you'll pass a half-true sentence.

Quote verbatim, never paraphrase the evidence. A paraphrased "supporting" quote is where the checker smuggles in its own assumptions. Require the evidence span to be copied character-for-character from the source. If it can't copy, the claim isn't supported.

Mind which model over-trusts itself. Claude is comparatively willing to mark its own prior output unsupported when asked to audit against a source; GPT-4o more often defends a claim it would have generated, so it needs the evidence-first ordering enforced harder and the schema restated on the final line. When a checker passes everything, suspect the model is grading its own homework.

Variables you'll set

Getting started

1. Paste the answer into {{candidate_answer}}.
2. Paste its grounding context into {{source_text}}.
3. Set {{strictness}} to strict for anything regulated.
4. Run the prompt and read the evidence quotes before trusting verdicts.
5. Block contradictions; route unsupported claims to review.
6. Save every caught fabrication as a regression case.
7. Wire it into review. The free Hallucination Spot Checker runs this exact decompose-then-verdict pass on a single answer in seconds.

A spot check on one answer is the start. When the answers come out of a retrieval system, the failure usually starts upstream in what got retrieved, which is where a RAG Quality Audit playbook earns its place.

Grounding checks pair naturally with two other prompts: the LLM-as-a-judge grader template for scoring open-ended quality, and evaluating a RAG pipeline when the answer's faithfulness depends on what the retriever fetched.