Claim-to-Paragraph Citation Linking Prompt

This prompt is for verification engineers and RAG pipeline builders who need to map discrete factual claims to their exact source locations within a document. Unlike broader evidence matching prompts that return relevant passages, this playbook produces fine-grained location mappings including paragraph numbers, line ranges, and section identifiers. Use it when downstream systems require clickable citations, audit trails, or when a claim is supported by multiple non-contiguous passages that must be linked together. The core job-to-be-done is provenance resolution, not retrieval, claim extraction, or veracity judgment.

The ideal user has already completed claim extraction and has the full source document available as input. The prompt expects two concrete inputs: a list of pre-extracted claims and the complete text of a single source document. It does not perform retrieval across a corpus, nor does it judge whether a claim is true or false. It only answers the question: 'Where in this document does this claim appear, if at all?' The output is a structured mapping that can be consumed by a citation formatter, a UI component for highlighting text, or an audit logging system. Do not use this prompt when you need to search across multiple documents, when claims have not yet been extracted, or when you need a truthfulness assessment. For those tasks, pair this with a retrieval step, a claim extraction prompt, or an evidence sufficiency scorer from the broader Evidence Matching and Source Attribution group.

A critical constraint is handling claims supported by multiple non-contiguous passages. A single claim like 'The company increased revenue by 20% and expanded into three new markets' might have its revenue evidence in paragraph 2 and its market expansion evidence in paragraph 7. This prompt must link both locations to the single claim without forcing a false choice. Similarly, it must explicitly flag when a claim has no supporting location in the document, rather than hallucinating a paragraph reference. Before deploying this prompt, define your evaluation criteria: exact paragraph number accuracy, recall of all supporting locations for multi-part claims, and the false-positive rate for claims incorrectly linked to a location. Wire these into your test harness before shipping.

Next, proceed to the Prompt Template section to copy the ready-to-use template with placeholders for your claims, document, and output schema. Then review the Implementation Harness section to understand how to validate outputs, handle retries, and integrate this into a production RAG pipeline with proper logging and human review gates for high-stakes use cases.

This template is designed for document intelligence and verification pipelines that require fine-grained provenance. It takes a list of pre-extracted claims and a source document with numbered paragraphs, then produces a structured mapping showing exactly which paragraph(s) support, contradict, or fail to address each claim. The prompt handles claims supported across multiple non-contiguous passages and explicitly flags claims with insufficient evidence rather than silently treating them as unverified.

textCopy
You are a precise claim-to-evidence citation linker. Your task is to map each provided claim to the specific paragraph(s) in the source document that support, contradict, or fail to address it.

## INPUT

### Claims to Verify
[CLAIMS_LIST]

### Source Document with Numbered Paragraphs
[SOURCE_DOCUMENT]

## OUTPUT SCHEMA

Return a JSON object with a "mappings" array. Each element must have:
- "claim_id": string matching the input claim identifier
- "claim_text": the original claim text
- "verdict": one of "supported", "contradicted", "partially_supported", "insufficient_evidence"
- "paragraph_ids": array of paragraph numbers that provide evidence (empty array if insufficient_evidence)
- "relevant_spans": array of objects with "paragraph_id", "quoted_text" (exact short quote from source), and "relationship" ("supports" or "contradicts")
- "explanation": one-sentence explanation of the mapping logic
- "confidence": "high", "medium", or "low" based on evidence clarity

## CONSTRAINTS

1. Only cite paragraph numbers that exist in the source document. Never invent paragraph numbers.
2. If a claim is supported by multiple non-contiguous paragraphs, list all of them.
3. If evidence partially supports a claim but leaves some aspects unaddressed, use "partially_supported" and explain which parts are unverified.
4. If no paragraph provides sufficient evidence, use "insufficient_evidence" with an empty paragraph_ids array.
5. Quote exact text from the source for each relevant_span. Do not paraphrase.
6. If two paragraphs contradict each other on the same claim, flag both and note the contradiction.
7. Do not infer support from absence of contradiction. Absence of evidence is not evidence of absence.

## EXAMPLES

### Example 1: Clear Support
Input Claim: "The company reported $4.2B in Q3 revenue."
Source Paragraph 12: "Third-quarter revenue reached $4.2 billion, up 8% year-over-year."
Output:
{
  "claim_id": "C1",
  "claim_text": "The company reported $4.2B in Q3 revenue.",
  "verdict": "supported",
  "paragraph_ids": [12],
  "relevant_spans": [{"paragraph_id": 12, "quoted_text": "Third-quarter revenue reached $4.2 billion", "relationship": "supports"}],
  "explanation": "Paragraph 12 directly states Q3 revenue of $4.2 billion, matching the claim exactly.",
  "confidence": "high"
}

### Example 2: Multi-Paragraph Support
Input Claim: "The acquisition was announced in March and closed in June."
Source Paragraph 5: "On March 15, the company announced its intent to acquire StartupCo for $800M."
Source Paragraph 18: "The acquisition closed on June 3, following regulatory approval."
Output:
{
  "claim_id": "C2",
  "claim_text": "The acquisition was announced in March and closed in June.",
  "verdict": "supported",
  "paragraph_ids": [5, 18],
  "relevant_spans": [
    {"paragraph_id": 5, "quoted_text": "On March 15, the company announced its intent to acquire StartupCo", "relationship": "supports"},
    {"paragraph_id": 18, "quoted_text": "The acquisition closed on June 3", "relationship": "supports"}
  ],
  "explanation": "Paragraph 5 supports the March announcement; paragraph 18 supports the June closing. Both components are verified.",
  "confidence": "high"
}

### Example 3: Insufficient Evidence
Input Claim: "The CEO plans to step down next year."
Source: No paragraph mentions CEO departure plans.
Output:
{
  "claim_id": "C3",
  "claim_text": "The CEO plans to step down next year.",
  "verdict": "insufficient_evidence",
  "paragraph_ids": [],
  "relevant_spans": [],
  "explanation": "No paragraph in the source document mentions CEO departure plans or succession.",
  "confidence": "high"
}

## RISK LEVEL
[RISK_LEVEL]

## INSTRUCTIONS
Process all claims in [CLAIMS_LIST] against [SOURCE_DOCUMENT]. Return only valid JSON matching the output schema. Do not include commentary outside the JSON.

To adapt this template, replace [CLAIMS_LIST] with your extracted claims in a structured format that includes unique claim IDs. Replace [SOURCE_DOCUMENT] with your document text where each paragraph is prefixed with a stable numeric identifier. The [RISK_LEVEL] placeholder should be set to high for regulated domains (legal, medical, financial) to trigger stricter confidence thresholds and more conservative verdicts, or standard for general document intelligence workflows. For production use, add a post-processing validator that checks every paragraph_id against the actual document paragraph range and rejects any output referencing non-existent paragraphs before it reaches downstream systems.

This prompt is designed to be a single step in a larger document intelligence pipeline. The application layer is responsible for providing the pre-extracted claims and the full source document text with paragraph-level identifiers. Do not send raw PDFs or scanned images directly to this prompt; pre-process documents into a structured format where each paragraph has a stable, unique ID (e.g., doc-01-para-03). The prompt expects [CLAIMS] as a JSON array of objects, each with an id and text field, and [DOCUMENT] as a JSON array of objects with paragraph_id, text, and optional section fields. The application should construct these inputs programmatically to avoid token waste and formatting errors.

After receiving the model's response, the first and most critical validation step is to verify that every paragraph_id in the output exists in the input document's index. A hallucinated paragraph ID is a hard failure that should trigger a retry or escalation. Next, validate that the citation_text substring actually appears in the referenced paragraph; a simple string containment check catches many fabrications. For high-stakes workflows, implement a secondary LLM call or a deterministic check that compares the claim against the cited paragraph to confirm the support_type classification (SUPPORTS, CONTRADICTS, PARTIAL). Log every mismatch for eval dataset construction. The output schema should be strictly enforced: if the model returns malformed JSON, use a repair prompt or a schema-constrained generation mode (e.g., Structured Outputs, JSON mode with a provided schema) rather than attempting regex-based fixes.

Model choice matters here. This task requires strong instruction-following and long-context handling, as documents can easily exceed 10k tokens. Claude 3.5 Sonnet, GPT-4o, and Gemini 1.5 Pro are suitable starting points. For production, implement a retry strategy with exponential backoff on validation failures, but cap retries at 2-3 attempts. If the model consistently fails to link a claim, route that claim to a human review queue with the claim text, the full document, and the model's best-effort output attached. Never silently drop unlinked claims—they represent a hallucination risk downstream. Finally, store the complete prompt, response, and validation results in an audit log. This traceability is essential for debugging citation drift and for demonstrating provenance to users or auditors.