Claim Verification Quote Selection Prompt

This prompt is designed for fact-checking and verification pipeline engineers who need to select the single strongest quote from a set of source documents that proves or disproves a specific factual claim. It operates in a binary verification workflow where the output must be a clear verdict, a verbatim quote, and a reasoning chain that connects the evidence to the claim. The ideal user is building an automated or semi-automated system where a pre-retrieved set of candidate passages needs to be reduced to one decisive piece of evidence before the result is passed to a downstream system or a human reviewer for final adjudication.

Use this prompt when you have a well-formed, unambiguous factual claim and a pre-filtered set of relevant candidate passages. The prompt assumes the heavy lifting of retrieval and initial relevance filtering has already been done by a search or vector database system. It is not designed for open-ended question answering, multi-source synthesis, or scenarios where the claim itself is ambiguous and requires clarification. Do not use this prompt if you need to generate an answer from scratch, combine information from multiple documents into a single narrative, or handle claims that are subjective opinions rather than verifiable facts. The prompt is also unsuitable for cases where the evidence set is noisy, completely unfiltered, or contains hundreds of documents, as it is optimized for selecting a single best quote from a focused candidate set.

Before integrating this prompt into your pipeline, ensure your upstream retrieval system is tuned for high recall on the claim's entities and key terms. The prompt's effectiveness depends entirely on the presence of at least one relevant passage in the input set. If your retrieval system consistently fails to surface relevant documents, this prompt will correctly return a 'not supported' verdict, but the root cause will be a retrieval gap, not a prompt failure. Plan to log both the selected quote and the verdict for downstream auditability, and consider implementing a confidence threshold that escalates low-confidence selections to human review. For regulated or high-stakes domains, always require a human-in-the-loop step after this prompt's output before taking any consequential action.

This template is the core instruction set for a claim verification workflow. It forces the model to select exactly one quote from the provided evidence that most strongly proves or disproves a factual claim. The prompt is designed for binary verification pipelines where every output must be traceable to a specific source span. Replace each square-bracket placeholder with your application data before sending the prompt to the model. The template assumes you have already retrieved candidate evidence passages and formatted them with source identifiers.

textCopy
You are a precise claim verification assistant. Your job is to determine whether a factual claim is supported or refuted by the provided evidence. You must select the single strongest quote from the evidence that proves or disproves the claim. Do not summarize. Do not use outside knowledge. If no quote adequately supports or refutes the claim, you must return a verdict of INSUFFICIENT_EVIDENCE.

## CLAIM
[CLAIM_TEXT]

## EVIDENCE PASSAGES
[EVIDENCE_PASSAGES]

## OUTPUT SCHEMA
Return a JSON object with exactly these fields:
- "verdict": one of SUPPORTED, REFUTED, or INSUFFICIENT_EVIDENCE
- "selected_quote": the exact verbatim text from the evidence that most strongly supports your verdict, or null if INSUFFICIENT_EVIDENCE
- "source_id": the identifier of the passage containing the selected quote, or null if INSUFFICIENT_EVIDENCE
- "reasoning": a concise explanation of why this quote proves or disproves the claim, or why no quote is sufficient. Reference specific words or phrases from both the claim and the quote.
- "confidence": a score from 0.0 to 1.0 indicating how certain you are in your verdict based solely on the provided evidence

## CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES
[EXAMPLES]

Adapt this template by populating the placeholders with your application's data. [CLAIM_TEXT] should contain the exact factual claim to verify, stripped of rhetorical framing. [EVIDENCE_PASSAGES] must include pre-retrieved passages formatted with unique source identifiers, such as [SOURCE_1] passage text here. [CONSTRAINTS] can specify domain-specific rules, such as requiring exact numerical match for financial claims or temporal alignment for news claims. [EXAMPLES] should include at least one SUPPORTED, one REFUTED, and one INSUFFICIENT_EVIDENCE example to calibrate the model's threshold for evidence sufficiency. If your application cannot tolerate any hallucinated quotes, add a constraint requiring the model to confirm the quote appears verbatim in the provided evidence before returning it. For high-stakes domains like legal or healthcare verification, always route INSUFFICIENT_EVIDENCE verdicts to human review before surfacing them to end users.

The Claim Verification Quote Selection Prompt is designed as a single-step binary classifier that returns a verdict, a verbatim quote, and reasoning. In production, this prompt should be deployed as part of a larger fact-checking or verification pipeline, not as a standalone endpoint exposed directly to end users. The typical integration pattern places this prompt after a retrieval step (where candidate passages are fetched from a knowledge base, search index, or document store) and before a final verdict aggregation step. The prompt expects a factual claim and a set of candidate passages as input, and it returns exactly one quote that best proves or disproves the claim. Because the output includes a binary verdict, the prompt can be used as a gating mechanism: if the verdict is DISPROVEN, the claim can be automatically flagged or routed for review without further processing.

Wire this prompt into your application with a thin orchestration layer that handles input assembly, output validation, and retry logic. Before calling the model, assemble the [CLAIM] and [PASSAGES] placeholders from your retrieval pipeline. Each passage should include a unique identifier and its full text. After receiving the model response, validate the output against a strict schema: the verdict field must be one of SUPPORTED, REFUTED, or INSUFFICIENT_EVIDENCE; the quote field must be a verbatim substring of one of the provided passages (validate this programmatically with exact string matching or fuzzy matching with a high threshold); and the reasoning field must be non-empty. If validation fails, retry with the same input up to two times. If validation still fails after retries, log the failure and route the claim to a human review queue. For high-stakes domains such as legal, medical, or financial verification, always require human approval before any verdict is surfaced to users or used in automated decisions.

Model choice matters for this prompt. Use a model with strong instruction-following and low hallucination rates, such as Claude 3.5 Sonnet, GPT-4o, or Gemini 1.5 Pro. Avoid smaller or older models that may paraphrase quotes instead of extracting them verbatim. If you are processing claims at high volume, consider batching multiple claims into a single request with clear delimiters, but keep each claim's passages separate to avoid cross-contamination. For observability, log every request and response pair, including the validated verdict, the matched passage ID, and any validation failures. This log becomes your audit trail and is essential for evaluating the prompt's performance over time. Use these logs to build a golden dataset of claim-passage-verdict triples for regression testing when you iterate on the prompt template.

The most common failure mode in production is the model returning a paraphrased or slightly altered quote instead of an exact verbatim match. Your post-processing validator must catch this. Implement a span-matching function that checks whether the returned quote appears as a contiguous substring in any of the provided passages. If exact matching is too strict for your use case (e.g., when passages contain OCR errors or inconsistent punctuation), use a token-level overlap threshold of at least 0.95. A second failure mode is the model returning INSUFFICIENT_EVIDENCE when a human reviewer would find a clear supporting or refuting quote. Monitor the rate of INSUFFICIENT_EVIDENCE verdicts and periodically sample them for human review to calibrate whether your retrieval step is surfacing the right passages or whether the prompt's evidence threshold is too conservative. A third failure mode is the model selecting a quote that is factually relevant but does not directly address the specific claim. Your eval harness should include claim-quote alignment checks, either through a secondary LLM judge prompt or through periodic human spot checks.

Do not use this prompt in isolation for claims that require multi-hop reasoning, temporal ordering, or quantitative comparison across multiple sources. The prompt is designed for binary verification against a single passage set. If your verification workflow requires synthesizing evidence from multiple documents, chain this prompt with a multi-document aggregation step first, or use the Multi-Passage Quote Ranking Prompt to pre-rank evidence before selection. For claims that involve numerical thresholds, statistical claims, or time-sensitive facts, add a pre-processing step that extracts structured data from passages before passing them to this prompt, as the model may struggle with quantitative reasoning inside a quote-selection task. Finally, never expose raw model outputs to end users without the validation and review gates described above. The prompt is a component in a verification system, not a replacement for editorial judgment or domain-expert review.