Claim-to-Evidence Pairing Prompt Template

This prompt is designed for verification engineers and RAG pipeline builders who need to create a structured, auditable link between a set of discrete, pre-extracted claims and a body of pre-retrieved evidence passages. Its core job is to pair each claim with the most relevant evidence, providing a direct quote, a source identifier, and a clear match type (support, contradict, or insufficient). It is a critical middleware step that sits strictly after a claim extraction phase and an evidence retrieval phase, and before any final verification scoring, confidence calibration, or human review routing. It does not perform retrieval, answer a user's question, or generate new content; it only maps existing claims to existing evidence.

Use this prompt when you have a clean list of atomic claims and a set of candidate evidence documents or chunks, and you need to produce a structured JSON output that explicitly ties them together for downstream processing. This is essential for building transparent, debuggable verification systems where every factual assertion must be accounted for. The prompt is particularly valuable when you need to detect contradictions between sources, identify claims that lack sufficient evidence, or generate precise citations for an audit trail. It assumes the input claims are already decomposed into single, verifiable statements and that the evidence set has been retrieved and is ready for analysis.

Do not use this prompt as a general-purpose question-answering system or to perform the initial retrieval of evidence. It is not designed to handle raw user questions or to search a knowledge base. It also should not be used if the input is a single, long-form document that hasn't been decomposed into claims, or if the evidence set hasn't been pre-filtered for relevance. Applying this prompt to unprocessed text will lead to poor pairings and missed connections. The next step after using this prompt is typically to feed the structured output into a verification scoring model or a human review queue, where the pairings can be validated and final judgments can be made.

This prompt template is designed to be pasted directly into your system instructions for a verification or RAG pipeline. It takes a list of pre-extracted claims and a set of evidence documents, then produces a structured mapping of each claim to supporting, contradicting, or insufficient evidence. The output includes direct quotes, source identifiers, and a match type classification, making it suitable for downstream audit logging, human review routing, or automated confidence scoring.

textCopy
You are a claim-to-evidence verification engine. Your task is to pair each provided claim with evidence from the provided source documents.

# INPUTS
- Claims: [CLAIMS_LIST]
- Evidence Documents: [EVIDENCE_DOCUMENTS]

# OUTPUT_SCHEMA
Return a JSON object with a single key "claim_evidence_pairs" containing an array of objects. Each object must have the following fields:
- "claim_id": string (the identifier from the input claims list)
- "claim_text": string (the original claim text)
- "match_type": string (one of "SUPPORT", "CONTRADICT", "INSUFFICIENT")
- "evidence": array of objects, each containing:
  - "source_id": string (the identifier from the input evidence documents)
  - "quote": string (the exact text from the source that supports or contradicts the claim)
  - "relevance_explanation": string (a brief explanation of how the quote relates to the claim)
- "confidence": number (a score from 0.0 to 1.0 indicating how strongly the evidence supports the match_type determination)
- "missing_evidence_note": string or null (if match_type is "INSUFFICIENT", describe what specific evidence would be needed to verify the claim)

# CONSTRAINTS
- Do not fabricate quotes. Every quote must be a verbatim substring from the provided evidence documents.
- If a claim is partially supported, prefer "INSUFFICIENT" over "SUPPORT" and explain what is missing.
- If multiple sources contradict each other on the same claim, include all contradictory evidence and set match_type to "CONTRADICT".
- Do not infer evidence beyond what is explicitly stated in the documents.
- If no evidence documents are provided, set match_type to "INSUFFICIENT" for all claims.

# EXAMPLES
[EXAMPLES]

# RISK_LEVEL
[HIGH] This task involves factual verification. Hallucinated citations or misattributed evidence can cause real-world harm. If you are uncertain about a match, default to "INSUFFICIENT".

To adapt this template for your pipeline, replace the square-bracket placeholders with your specific data. [CLAIMS_LIST] should be a JSON array of objects with claim_id and claim_text fields. [EVIDENCE_DOCUMENTS] should be a JSON array of objects with source_id and content fields. The [EXAMPLES] placeholder should be replaced with 2-4 few-shot examples demonstrating correct SUPPORT, CONTRADICT, and INSUFFICIENT pairings, including edge cases like partial matches and multi-source conflicts. For high-stakes domains such as healthcare or legal review, add a [CONSTRAINTS] entry requiring a human-readable disclaimer when confidence is below a calibrated threshold, and route those outputs for human review before any downstream action is taken.

The Claim-to-Evidence Pairing prompt is designed to be a single step within a larger verification pipeline, not a standalone application. It expects pre-extracted claims and pre-retrieved evidence chunks as input. The implementation harness must therefore handle claim decomposition upstream, evidence retrieval upstream, and output validation downstream. The prompt itself should be treated as a stateless function: claims and evidence go in, structured pairings come out. Do not use this prompt to generate claims or retrieve evidence—it will hallucinate both if asked.

Input assembly: Before calling the model, construct the [CLAIMS] array from your claim extraction step and the [EVIDENCE_CHUNKS] array from your retrieval step. Each claim must include a unique claim_id and the original claim text. Each evidence chunk must include a chunk_id, source identifier, and full text. The prompt's [MATCH_TYPES] placeholder should be set to a controlled vocabulary such as ['SUPPORT', 'CONTRADICT', 'INSUFFICIENT']. The [OUTPUT_SCHEMA] placeholder should specify a JSON array of objects with fields: claim_id, chunk_id, match_type, direct_quote, and explanation. Model choice: Use a model with strong instruction-following and structured output capabilities (e.g., GPT-4o, Claude 3.5 Sonnet). Avoid smaller models for this task—they frequently confuse INSUFFICIENT with CONTRADICT and fabricate quotes when evidence is thin.

Validation and retry logic: After receiving the model response, validate the output against the schema before accepting it. Check that every claim_id and chunk_id in the output exists in the input arrays—hallucinated IDs are a common failure mode. Verify that every direct_quote is a substring of the referenced evidence chunk using an exact or fuzzy string match. If validation fails, construct a retry prompt that includes the original input, the invalid output, and a specific error message describing which field failed validation. Limit retries to 2 attempts; if validation still fails, route the affected claims to a human review queue with the partial output and error context attached.

Logging and observability: Log every prompt invocation with: input claim count, input chunk count, model used, latency, token usage, validation pass/fail, and retry count. Attach the validated output to your verification audit trail. For high-risk domains (legal, medical, financial), do not auto-accept SUPPORT or CONTRADICT pairings without human sampling. Implement a review sampling rate—start with 10% of pairings—and increase it if your eval metrics show precision below your threshold. What to avoid: Do not send claims without evidence chunks to this prompt expecting it to search; it cannot. Do not use this prompt's output as ground truth for training without human verification. Do not skip the quote substring check—it is your primary defense against hallucinated evidence.