Claim-Supporting Quote Extraction Prompt Template

This prompt is designed for a specific, high-stakes job: extracting the most relevant verbatim quotes from source documents that directly support a given claim. It is built for citation-aware QA builders, fact-checking pipelines, and any system where grounding must be transparent and auditable. The core value is forcing the model to select exact text spans rather than paraphrasing, producing structured output that maps each quote to its source location and a relevance score. Use this when you need to show users exactly which passage supports an answer, when you must pass audit requirements for evidence provenance, or when downstream answer generation depends on precise evidence selection.

The ideal user is an engineering lead or AI builder integrating evidence extraction into a larger product workflow. Required inputs include a specific [CLAIM] to verify and one or more [SOURCE_DOCUMENTS] with clear identifiers. The prompt is most effective when the source documents are pre-segmented with stable IDs (e.g., doc_id, chunk_index) that can survive downstream processing. Do not use this prompt for open-ended summarization, creative generation, or tasks where verbatim extraction is unnecessary. It is also a poor fit when source documents are highly unstructured, contain heavy visual elements like charts, or when the claim is too vague to map to specific text spans. In those cases, a broader RAG synthesis or document intelligence prompt would be more appropriate.

Before deploying, ensure your evaluation harness measures both precision (are extracted quotes actually relevant?) and recall (are all supporting quotes found?) against human-annotated evidence spans. Common failure modes include the model extracting quotes that are topically related but do not actually support the claim, or missing key evidence buried in long documents. Plan for a human review step when the output will be surfaced in user-facing citations or audit trails. The next section provides the copy-ready prompt template you can adapt and wire into your application.

This prompt template is designed for citation-aware QA builders who need to extract the most relevant verbatim quotes from source documents that directly support a specific claim. It enforces strict output structure, requires source anchoring, and includes relevance scoring to make evidence selection transparent and auditable. The template uses square-bracket placeholders that you replace with your application's inputs before sending the request to the model.

textCopy
You are an evidence extraction specialist. Your task is to find verbatim quotes from the provided source documents that directly support the given claim.

## INPUT

**Claim:** [CLAIM]

**Source Documents:**
[DOCUMENTS]

## INSTRUCTIONS

1. Read the claim carefully and identify what specific factual assertions it makes.
2. Search the source documents for verbatim text that directly supports each assertion.
3. Extract only quotes that provide direct evidence for the claim. Do not extract quotes that are merely topically related but do not actually support the claim.
4. For each extracted quote, identify the exact source span (document ID, section, paragraph, or character offsets if available).
5. Assign a relevance score from 0.0 to 1.0 where:
   - 0.9-1.0: The quote directly proves or strongly supports the claim.
   - 0.7-0.89: The quote provides substantial but partial support.
   - 0.5-0.69: The quote is relevant but requires inference to connect to the claim.
   - 0.0-0.49: The quote is tangentially related and should not be included.
6. If no quote meets the 0.5 threshold, return an empty quotes array with a brief explanation of the evidence gap.
7. Do not paraphrase, summarize, or modify the quote text. Extract exact verbatim text only.

## CONSTRAINTS

- [CONSTRAINTS]

## OUTPUT SCHEMA

Return a JSON object with this exact structure:

{
  "claim": "[CLAIM]",
  "quotes": [
    {
      "quote_text": "Exact verbatim text from the source document",
      "source": {
        "document_id": "Identifier for the source document",
        "location": "Section, paragraph, or character offset reference",
        "document_title": "Title or name of the source document if available"
      },
      "relevance_score": 0.0,
      "relevance_rationale": "Brief explanation of why this quote supports the claim"
    }
  ],
  "sufficiency_assessment": {
    "is_sufficient": true,
    "explanation": "Whether the extracted quotes collectively provide sufficient evidence for the claim"
  }
}

## EXAMPLES

[EXAMPLES]

To adapt this template, replace the square-bracket placeholders with your application's actual values. The [CLAIM] placeholder should contain the specific claim you need evidence for. The [DOCUMENTS] placeholder should contain your retrieved source documents formatted with clear document IDs and section markers. The [CONSTRAINTS] placeholder lets you add domain-specific rules such as minimum quote length, maximum number of quotes, or required source metadata fields. The [EXAMPLES] placeholder should contain one or two few-shot examples showing the desired extraction behavior, especially for edge cases like partial support or conflicting evidence. Always test the adapted prompt against a golden dataset of human-annotated evidence spans to measure precision and recall before deploying to production.

The claim-supporting quote extraction prompt is designed to be called after retrieval and before answer generation in a RAG pipeline. The typical call pattern is: retrieve candidate documents, chunk them into manageable passages, and then invoke this prompt once per claim with the top-k passages as [SOURCE_DOCUMENTS]. Because the prompt returns structured JSON with quote text, source spans, and relevance scores, you can parse the output directly into your application's evidence store or citation renderer. Do not use this prompt on raw, unchunked documents—context windows will overflow and quote precision will degrade. Instead, pre-chunk documents into 500–1500 token passages with overlapping windows of 100–200 tokens to preserve quote boundaries, and pass only the top 5–15 passages per claim.

Validation is the first integration checkpoint. The output schema enforces quote_text, source_span (start and end character offsets), relevance_score (0.0–1.0), and reasoning. Before accepting any extracted quote, validate that: (1) the quote_text appears verbatim in the source document at the claimed offsets, (2) the relevance_score is a float in range, and (3) the reasoning field is non-empty. If validation fails, retry the prompt once with the validation error message appended to [CONSTRAINTS]. If the retry also fails, log the failure and escalate to a human review queue rather than silently accepting a malformed quote. For high-stakes domains like legal or compliance, always require human approval on quotes with relevance_score below 0.7 or where the source document contains contradictory language.

Model choice matters for this prompt. Use a model with strong instruction-following and structured output capabilities—GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro are good defaults. Avoid smaller models (under 7B parameters) for this task because they struggle with precise span boundary detection and tend to paraphrase rather than extract verbatim text. If you must use a smaller model, add a post-extraction verification step that checks exact string matching between the claimed quote and the source document. For latency-sensitive applications, consider batching multiple claims against the same document set in a single prompt call, but cap the batch at 5 claims to prevent attention dilution. Log every extraction with the prompt version, model, source document IDs, extracted quotes, validation results, and any human review decisions. This audit trail is essential for debugging hallucinated citations and for demonstrating grounding fidelity to compliance reviewers.

The most common production failure mode is the model extracting a quote that appears verbatim but is taken out of context—supporting the claim in isolation while the surrounding passage actually contradicts it. Mitigate this by including a [CONSTRAINTS] instruction that requires the model to read the full paragraph surrounding any candidate quote before extracting. A second failure mode is the model returning character offsets that are off by a few characters due to tokenization differences. Always implement fuzzy matching with a ±10 character tolerance when verifying span boundaries, and normalize whitespace before comparison. Finally, if your source documents contain tables, footnotes, or structured fields, preprocess them to flatten or annotate these elements before passing them to the prompt—the model will otherwise struggle to extract clean quotes from non-prose content.