Evidence-to-Claim Mapping Prompt for Fact Verification

This prompt is designed for fact-checking and verification pipelines that must decompose a piece of content into discrete claims and then map each claim to supporting or refuting evidence from a provided document set. Use it when you need a structured, auditable trace between an assertion and its source material, not just a binary true/false label. It is ideal for post-generation verification, content moderation, research synthesis, and compliance review where every factual statement must be accounted for. The prompt forces the model to handle three outcomes explicitly: supported, refuted, or insufficient evidence. It also requires the model to flag claims that could not be mapped to any evidence, closing a common gap in naive RAG evaluation loops.

The ideal user is an AI engineer or product team building a verification step into a larger pipeline—typically after content generation, document ingestion, or user submission. The required context includes the content to verify, a pre-retrieved evidence set, and a clear output schema for claim-evidence pairs. Do not use this prompt when you need real-time streaming verification, when the evidence set is too large to fit in a single context window without chunking, or when the content contains subjective opinions rather than factual claims. For subjective content, a stance-classification or policy-compliance prompt is more appropriate. This prompt also assumes the evidence retrieval step has already occurred; it does not perform search or retrieval itself.

Before deploying, define your evaluation criteria. A successful run produces a claim list with no orphaned claims (every claim has an evidence mapping attempt), explicit insufficient_evidence labels where appropriate, and rationales that quote or reference specific source passages. Common failure modes include the model inventing evidence not present in the provided set, skipping claims embedded in complex sentences, or labeling claims as supported based on partial matches. Plan to run this prompt with a validation layer that checks for hallucinated source references and a human review step for high-risk domains such as healthcare, finance, or legal compliance. Wire the output into a structured database or audit log so you can track verification decisions over time.

This template is the core instruction set for an evidence-to-claim mapping workflow. It takes a list of claims and a set of evidence passages, then produces a structured mapping that labels each claim as supported, refuted, or having insufficient evidence. The prompt is designed to be dropped into a fact-verification pipeline where claims have already been extracted from a source document and evidence has been retrieved from a knowledge base or search system. Replace every square-bracket placeholder with runtime data before sending the prompt to the model. The template enforces structured output, requires explicit rationale for every mapping decision, and includes handling for claims that cannot be verified with the provided evidence.

textCopy
You are a fact-verification analyst. Your task is to map each claim to the provided evidence and determine whether the evidence supports, refutes, or is insufficient to verify the claim.

## CLAIMS TO VERIFY
[CLAIMS]

## EVIDENCE PASSAGES
[EVIDENCE]

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "claim_mappings": [
    {
      "claim_id": "string",
      "claim_text": "string",
      "label": "supported | refuted | insufficient_evidence",
      "evidence_ids": ["string"],
      "rationale": "string explaining why the evidence supports, refutes, or is insufficient for this claim",
      "confidence": "high | medium | low",
      "unverifiable_reason": "string explaining why the claim cannot be verified, only present when label is insufficient_evidence"
    }
  ],
  "unmapped_claims": ["claim_id"],
  "mapping_completeness_notes": "string describing any claims that could not be mapped and why"
}

## CONSTRAINTS
[CONSTRAINTS]

## INSTRUCTIONS
1. For each claim, search the evidence passages for information that directly addresses the claim.
2. Assign a label:
   - "supported": The evidence provides positive confirmation of the claim.
   - "refuted": The evidence contradicts or disproves the claim.
   - "insufficient_evidence": The evidence does not contain enough information to verify or refute the claim.
3. For each mapping, cite specific evidence_ids that support your determination.
4. Write a clear rationale that explains the logical connection between the evidence and the claim.
5. If a claim cannot be verified with the available evidence, set label to "insufficient_evidence" and explain what information would be needed.
6. Include claims in "unmapped_claims" only if they could not be processed due to ambiguity or formatting issues.
7. Do not invent evidence. Only use the provided passages.
8. If evidence passages conflict, note the conflict in the rationale and assign confidence accordingly.

## EXAMPLES
[EXAMPLES]

Adapt this template by replacing the placeholders with your runtime data. [CLAIMS] should contain a structured list of claims, each with a unique claim_id and the claim_text. Format claims as a JSON array or numbered list so the model can reference them by ID. [EVIDENCE] should contain retrieved passages, each with a unique evidence_id and the passage text. Include source metadata such as document titles or URLs if attribution is required downstream. [CONSTRAINTS] can specify domain-specific rules, such as requiring direct quotes for supported claims or setting a minimum confidence threshold for accepting evidence. [EXAMPLES] should include one or two few-shot demonstrations showing correct mappings, especially for edge cases like conflicting evidence or claims that appear supported but rely on inference beyond the text. After the model returns the JSON output, validate that every claim_id in the input appears in either claim_mappings or unmapped_claims. Run a completeness check to ensure no claims were silently dropped. For high-stakes verification workflows, route outputs with low confidence or conflicting evidence to human review before accepting the mapping as final.

This prompt is designed to be called after evidence retrieval and before any final answer synthesis. In a typical pipeline, you retrieve a set of candidate documents or passages for a given input text, then pass both the input text and the retrieved evidence into this prompt. The output is a structured mapping of claims to evidence with support/refute/insufficient labels. This mapping becomes the audit trail for downstream answer generation or direct display to a reviewer. Do not use this prompt on its own to produce a final answer; it is a verification intermediate that should feed into a synthesis or review step.

Wire the prompt into your application with a strict JSON schema validator on the output. The expected schema is an array of claim-evidence pairs, each containing claim_id, claim_text, evidence_sources (array of source IDs with spans), label (enum: supports, refutes, insufficient), and rationale. If the model output fails schema validation, retry once with the validation error injected into the prompt as additional context. After a second failure, log the raw output and escalate to a human review queue. For high-stakes domains, always route insufficient labels and any claim with conflicting evidence sources to human review before the mapping is considered complete.

Model choice matters here. 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 collapse multiple claims into one or skip the rationale field. Set temperature to 0 or near-zero to maximize consistency across runs. If you are processing long documents with many claims, chunk the input text and run the prompt per chunk, then deduplicate overlapping claims in a post-processing step. Log every mapping output with the prompt version, model, input hash, and retrieval set ID so you can trace verification failures back to their source.

Build an eval harness that spot-checks claim-evidence pairs against human-labeled ground truth. For each pair, check that the claim is correctly extracted from the input, the evidence source genuinely contains the cited span, and the label is defensible. Track precision and recall on claim extraction separately from label accuracy. Common failure modes include: the model inventing claims not present in the input, citing evidence spans that don't exist in the source, and defaulting to insufficient when the evidence is actually supportive. If your eval shows more than 5% hallucinated claims or miscited spans, add a pre-check step that validates claim presence in the input and span presence in the evidence before accepting the mapping.