Hallucination Detection Prompt for Generated Answers

This prompt is a post-generation guardrail for Retrieval-Augmented Generation (RAG) systems. Its job is to take a generated answer and the source evidence used to produce it, decompose the answer into discrete factual claims, and verify each claim against the evidence. The output is a structured audit trail that flags unsupported statements, identifies faithful synthesis, and separates interpretation from fabrication. The ideal user is a QA engineer, an AI pipeline builder, or a product team lead who needs automated hallucination detection before an answer reaches a user. You should use this prompt when you are building CI/CD quality gates for answer accuracy, calibrating hallucination rates against human audits, or implementing a runtime safety net that catches fabrications missed during generation.

To use this prompt effectively, you must provide two critical inputs: the full generated answer text and the complete set of source evidence chunks that were used during generation. The prompt does not perform retrieval itself; it assumes the evidence is already selected. The output is a structured JSON object containing a list of claims, each with a verification status (SUPPORTED, UNSUPPORTED, or PARTIALLY_SUPPORTED), the specific source passage that supports or contradicts the claim, and a brief explanation of the mismatch if the claim is unsupported. This structure is designed for direct integration into an automated evaluation pipeline. You can wire the output to a validation function that blocks answers exceeding a configurable unsupported-claim threshold, logs the audit trail for human review, or feeds the flagged claims back into a self-correction loop.

Do not use this prompt as a substitute for retrieval quality improvements. If your retrieval system consistently returns irrelevant or insufficient context, this prompt will correctly flag most answers as unsupported, but it will not fix the root cause. It is a detection tool, not a repair tool. In high-stakes domains such as healthcare, legal, or finance, this prompt must not be the sole safety mechanism. Always route answers with a high proportion of unsupported claims or any UNSUPPORTED claim in a critical category to a human review queue. The prompt itself can hallucinate—it may incorrectly classify a supported claim as unsupported or vice versa. Calibrate its performance against a golden dataset of human-annotated answers before relying on it in production, and monitor its false positive and false negative rates over time.

The following prompt template is designed to be dropped directly into your post-generation validation pipeline. It instructs the model to act as a factual verification auditor, extracting every discrete factual claim from a generated answer and checking each one against a provided source evidence block. The output is a structured JSON object that flags unsupported and contradicted claims, providing a clear, auditable grounding score. This is not a prompt for generating answers; it is a guardrail for verifying them.

textCopy
You are a factual verification auditor. Your task is to decompose a generated answer into discrete factual claims and verify each claim against the provided source evidence. You must flag any claim that cannot be fully supported by the evidence as unsupported. Do not introduce external knowledge. Do not fill gaps with assumptions.

## Source Evidence
[SOURCE_EVIDENCE]

## Generated Answer
[GENERATED_ANSWER]

## Verification Instructions
1. Extract every discrete factual claim from the Generated Answer. A factual claim is a statement that can be verified as true or false against the Source Evidence.
2. For each claim, search the Source Evidence for direct support. A claim is supported only if the evidence explicitly states the fact or the fact can be directly inferred from a single passage without additional assumptions.
3. Assign a verification status to each claim:
   - SUPPORTED: The claim is explicitly stated in or directly inferable from the Source Evidence.
   - UNSUPPORTED: The claim cannot be verified from the Source Evidence.
   - CONTRADICTED: The Source Evidence directly contradicts the claim.
4. For SUPPORTED claims, provide the exact source passage ID and the supporting text.
5. For UNSUPPORTED claims, explain what is missing from the evidence.
6. For CONTRADICTED claims, provide the conflicting evidence passage ID and text.
7. Produce a final grounding score: the percentage of claims that are SUPPORTED.

## Output Format
Return a JSON object with the following structure:
{
  "claims": [
    {
      "claim_id": "string",
      "claim_text": "string",
      "verification_status": "SUPPORTED | UNSUPPORTED | CONTRADICTED",
      "source_passage_id": "string | null",
      "source_text": "string | null",
      "explanation": "string"
    }
  ],
  "grounding_score": number,
  "total_claims": number,
  "supported_claims": number,
  "unsupported_claims": number,
  "contradicted_claims": number
}

To adapt this template, replace the [SOURCE_EVIDENCE] placeholder with the raw text of your retrieved documents, ideally with each passage prefixed by a unique ID (e.g., [P1], [P2]) to make citation mapping deterministic. Replace [GENERATED_ANSWER] with the full text output from your RAG synthesis step. For high-stakes domains like healthcare or legal, consider adding a [CONSTRAINTS] section that explicitly forbids the model from making any inferential leaps, requiring verbatim support for every claim. The JSON output schema is strict; validate it in your application layer before processing the results to guard against malformed model responses.

After running this prompt, your application should parse the grounding_score and iterate through the claims array. Any claim with a status of UNSUPPORTED or CONTRADICTED represents a potential hallucination. Your next step should be to route answers with a grounding score below your defined threshold (e.g., 0.95) to a human review queue or a self-correction loop. Do not treat this prompt as a final arbiter of truth; it is a signal that requires calibration against human-annotated ground truth to measure its own hallucination recall and false positive rate.

This verification prompt is designed to operate as a post-generation guardrail, not a pre-generation filter. After your primary answer generation model produces a response, pass both the generated answer and the retrieved source passages to this prompt. The model will decompose the answer into individual claims, match each claim against the provided evidence, and return a structured JSON payload with per-claim grounding assessments and an overall grounding_score. This architecture keeps the verification logic decoupled from the synthesis logic, allowing you to tune, version, and evaluate each component independently.

Parse the JSON output and check the grounding_score field against your defined threshold. If the score falls below your threshold, route the answer for human review, trigger a regeneration with stricter grounding instructions, or surface the unsupported claims to the user with appropriate caveats. For CI/CD integration, run this prompt against a golden dataset of question-answer-evidence triples and track grounding scores over time. Log every verification result—including the original answer, evidence, and claim breakdown—for audit trails. Implement retry logic with temperature variation if the model fails to produce valid JSON. Set a timeout appropriate for your latency budget; verification adds one additional model call per answer.

Choose a model for verification that balances accuracy and cost. A smaller, faster model may suffice for straightforward factual checks, while complex multi-hop answers may require the same tier model used for generation. Always validate the JSON schema before trusting the output—malformed JSON is a common failure mode. If the verification model consistently misses a specific class of hallucination, add few-shot examples of that failure pattern to the prompt. For high-stakes domains, maintain a human audit sample of verification decisions to calibrate your threshold and detect drift in the verifier's behavior over time.