Evidence Grounding Pass/Fail Prompt

This prompt is a production-grade gate for verifying whether factual claims in AI-generated or human-authored text are supported by provided source evidence. It is designed for verification teams, RAG system builders, and compliance engineers who need a binary pass/fail signal per claim before content reaches an end user or auditor. The core job-to-be-done is automatable, evidence-backed decision-making: for every discrete claim you submit alongside a body of source documents, the prompt returns a grounded/ungrounded verdict, a direct quote mapping, and an inference flag. This replaces manual spot-checking with a repeatable, loggable, and evaluable process.

Use this prompt when you have already extracted discrete claims from a text and retrieved a set of candidate source documents. The prompt performs the alignment check—it does not extract claims or retrieve sources. Ideal users are engineers building RAG evaluation harnesses, compliance officers reviewing AI-generated reports, or QA teams verifying that summarization pipelines haven't introduced unsupported assertions. The required context is strict: you must provide the full text of each claim and the full text of each source document. The prompt cannot verify claims against knowledge the model may have been trained on; it only judges alignment with the evidence you provide. For high-risk domains such as healthcare, finance, or legal review, the prompt's output should be treated as a decision-support signal, not a final determination, and must be paired with human review.

Do not use this prompt for open-ended quality scoring, stylistic review, or tasks where source evidence is not provided. It is not a hallucination detector that works from model weights—it is a grounding checker that works from your supplied evidence. It is also not suitable for evaluating whether the provided sources themselves are authoritative, complete, or up-to-date; source quality assessment is a separate upstream concern. If you need to verify claims against a live knowledge base or the open web, you must retrieve that evidence first and pass it into this prompt as source material. The prompt's binary output is designed for pipeline gating: pass means the claim can proceed to publication or downstream consumption; fail means the claim must be blocked, rewritten, or escalated. Wire the output into your CI/CD or content approval workflow with clear actions for each verdict.

This prompt template performs a binary pass/fail evaluation on whether each factual claim in an AI-generated output is directly supported by provided source evidence. It is designed to be placed in your system or user message, with variables populated from your upstream extraction and retrieval pipeline. The prompt forces explicit quote mapping, flags inferred claims that lack direct textual support, and handles multi-source synthesis and negative-evidence scenarios. Use this when you need a reliable go/no-go signal for claim-to-source alignment before content reaches end users.

textCopy
You are an evidence verification specialist. Your task is to evaluate whether each factual claim in the [OUTPUT_TO_VERIFY] is directly grounded in the provided [SOURCE_EVIDENCE].

For each claim, you must produce a binary verdict: GROUNDED or UNGROUNDED.

## Verification Rules
1. A claim is GROUNDED only if the exact fact or a direct, unambiguous paraphrase exists in the source evidence. Quote the supporting text.
2. A claim is UNGROUNDED if:
   - The source evidence does not contain the fact.
   - The claim requires inference beyond what the source explicitly states.
   - The source evidence contradicts the claim (negative evidence).
   - The claim combines facts from multiple sources in a way that creates a new, unsupported assertion.
3. For multi-source synthesis claims, each component fact must be individually grounded in at least one source. Flag the claim as UNGROUNDED if the synthesis itself is not explicitly stated in any single source.
4. If the source evidence is insufficient to verify a claim (e.g., missing context, ambiguous language), mark it UNGROUNDED and explain why.

## Output Format
Return a JSON object with the following structure:
{
  "overall_verdict": "PASS" | "FAIL",
  "claims": [
    {
      "claim_text": "The exact claim from the output",
      "verdict": "GROUNDED" | "UNGROUNDED",
      "source_quote": "Direct quote from source evidence, or null if ungrounded",
      "source_location": "Document identifier and section where quote was found, or null",
      "inference_flag": true | false,
      "explanation": "Brief explanation of the verdict"
    }
  ],
  "failure_summary": "If FAIL, summarize which claims failed and why. If PASS, state 'All claims grounded.'"
}

## Input Data
### Output to Verify
[OUTPUT_TO_VERIFY]

### Source Evidence
[SOURCE_EVIDENCE]

## Constraints
- Do not consider information outside the provided source evidence.
- Do not mark a claim as GROUNDED based on general world knowledge.
- Flag any claim that requires logical leaps or assumptions as UNGROUNDED.
- If the output contains no factual claims, return PASS with an empty claims array.

To adapt this template, populate [OUTPUT_TO_VERIFY] with the AI-generated text you are evaluating and [SOURCE_EVIDENCE] with the retrieved documents, passages, or reference material that should support the output. For RAG systems, [SOURCE_EVIDENCE] typically comes from your retrieval pipeline. For document summarization, it is the original document. For multi-source synthesis, include all source documents with clear identifiers. The prompt is designed for a single model call, but for high-stakes verification, consider running it per claim in parallel to reduce context-window pressure and improve accuracy on long outputs. Always log the full JSON response for audit trails and eval analysis. If your use case involves regulated content, route FAIL verdicts to human review before any downstream action.

The Evidence Grounding Pass/Fail prompt is designed to operate as a deterministic gate inside a larger verification pipeline, not as a standalone chat interaction. In production, you will typically call this prompt once per factual claim extracted from a model output, passing the claim text, the source document context, and any relevant retrieval metadata. The prompt returns a structured JSON verdict with a binary grounded field, a direct quote mapping, and an inference flag. Wire this into your application by first extracting discrete claims from the target output using a separate extraction prompt or parser, then fanning out parallel calls to this grounding prompt for each claim. Aggregate results to produce an overall faithfulness score or to trigger downstream actions such as regeneration, human review, or output blocking.

Implement a validation layer immediately after the model response to enforce the expected output schema before the verdict enters your decision logic. The prompt template specifies a JSON output contract with required fields: claim_id, grounded (boolean), source_quote (string or null), inference_required (boolean), and explanation. Use a JSON Schema validator or a lightweight parser to confirm field presence, correct types, and non-null constraints where applicable. If validation fails, retry the prompt call once with the same inputs and an explicit error message appended to the context, such as 'Your previous response was missing the required field source_quote. Please provide a complete JSON response.' If the retry also fails, log the failure, flag the claim for human review, and do not silently accept a malformed verdict. For high-stakes domains like healthcare or legal review, route any claim where inference_required is true or where grounded is false to a human review queue with the full claim, source context, and model explanation attached.

Model choice matters for this prompt. Use a model with strong instruction-following and structured output capabilities, such as GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro. Avoid smaller or older models that may struggle with the dual task of quote extraction and binary classification simultaneously. Set temperature to 0 or a very low value (0.1 maximum) to reduce variance in verdicts. Enable structured output mode if your provider supports it, binding the response to a typed object schema rather than relying on prompt-alone format instructions. For latency-sensitive pipelines, consider batching multiple claims into a single prompt call with an array output structure, but keep batch sizes small (5-10 claims) to avoid attention dilution. Log every verdict with the prompt version, model identifier, claim text, source context, and raw model response for auditability and regression testing. When you update the prompt template, run your full golden dataset of known grounded and ungrounded claim pairs through the new version and compare pass/fail rates against the previous version before promoting to production.