Claim Extraction and Source Mapping Prompt

This prompt is a post-generation audit tool, not a first-pass answer generator. Use it after a model has already produced an answer from retrieved context, and you need to verify that every factual claim in that answer can be traced back to a specific source passage. The primary job-to-be-done is structured accountability: you want a machine-readable report that maps claims to evidence, flags unsupported statements, and identifies coverage gaps before the answer reaches a user or reviewer. The ideal user is an AI engineer or platform developer building a citation recovery harness, a compliance reviewer who needs audit artifacts, or a product manager who must prove grounding quality to stakeholders.

This prompt belongs in post-generation validation pipelines, not in the hot path of a real-time chat experience. It is designed for workflows where latency is acceptable in exchange for thoroughness—think batch processing, nightly compliance checks, or human-in-the-loop review queues. You should not use this prompt when the original answer is already fully cited with inline references, when the evidence set is empty or trivially small, or when the generated text contains no factual claims to audit (e.g., purely conversational or procedural outputs). It is also the wrong tool when you need to fix the answer itself; this prompt only diagnoses grounding, it does not regenerate corrected text.

Before wiring this into production, define what counts as a 'discrete factual claim' for your domain. A claim might be a single numeric value, a relationship between entities, a temporal assertion, or a causal statement. The prompt works best when you provide an explicit output schema that enforces claim boundaries—otherwise, the model may merge multiple facts into one claim or split a single fact into fragments. Pair this prompt with a downstream validation step that checks whether every source passage cited in the mapping actually exists in your evidence set, because the model can hallucinate source references even during an audit task. If your use case is regulated or high-stakes, route unmapped claims to a human reviewer and log the full mapping output as an audit record.

This prompt template is the core instruction set for a claim extraction and source mapping harness. It takes a block of generated text and a set of source documents, then decomposes the text into atomic factual claims. Each claim is mapped to the most specific supporting passage in the provided sources. Claims that cannot be matched to any source are flagged as unmapped, giving your pipeline a clear signal for coverage gaps, hallucination risk, or retrieval insufficiency. Use this template when you need to verify that every assertion in a generated answer is traceable to evidence before the answer reaches a user or auditor.

textCopy
You are a precise claim extraction and evidence mapping engine. Your job is to decompose a provided text into discrete, verifiable factual claims and map each claim to the best supporting passage from the provided source documents.

## INPUT

**TEXT TO ANALYZE:**
[GENERATED_TEXT]

**SOURCE DOCUMENTS:**
[SOURCE_DOCUMENTS]

## INSTRUCTIONS

1. **Extract Claims:** Break the TEXT TO ANALYZE into the smallest discrete factual claims that can be independently verified. Each claim must be a single, self-contained assertion. Do not combine multiple facts into one claim. Do not include opinions, interpretations, or rhetorical statements unless they assert a verifiable fact.

2. **Map to Sources:** For each extracted claim, search the SOURCE DOCUMENTS for the passage that most directly and specifically supports the claim. The supporting passage must contain the factual content of the claim, not merely related or adjacent information.

3. **Flag Unmapped Claims:** If no source passage adequately supports a claim, mark it as UNMAPPED. Do not stretch or infer support where it does not exist.

4. **Handle Conflicts:** If multiple sources provide conflicting evidence for the same claim, note the conflict and include both passages.

## OUTPUT FORMAT

Return a JSON object with the following structure:

```json
{
  "claims": [
    {
      "claim_id": "C1",
      "claim_text": "The exact factual claim extracted from the text.",
      "status": "MAPPED",
      "source_id": "SOURCE_DOC_ID",
      "supporting_passage": "The verbatim passage from the source that supports this claim.",
      "passage_location": "Section or paragraph identifier within the source.",
      "mapping_confidence": "HIGH",
      "mapping_rationale": "Brief explanation of why this passage supports the claim."
    },
    {
      "claim_id": "C2",
      "claim_text": "Another factual claim.",
      "status": "UNMAPPED",
      "source_id": null,
      "supporting_passage": null,
      "passage_location": null,
      "mapping_confidence": null,
      "mapping_rationale": "No source passage found that supports this claim."
    },
    {
      "claim_id": "C3",
      "claim_text": "A claim with conflicting source evidence.",
      "status": "CONFLICT",
      "source_id": "SOURCE_A, SOURCE_B",
      "supporting_passage": "Passage from Source A that supports the claim. ||| Passage from Source B that contradicts the claim.",
      "passage_location": "Source A Section 2, Source B Paragraph 4",
      "mapping_confidence": "CONFLICT",
      "mapping_rationale": "Source A supports the claim while Source B provides contradictory evidence."
    }
  ],
  "coverage_summary": {
    "total_claims": 0,
    "mapped_claims": 0,
    "unmapped_claims": 0,
    "conflict_claims": 0,
    "coverage_ratio": 0.0
  }
}

CONSTRAINTS

• Every claim must be a single, independently verifiable fact.
• Do not fabricate or infer source support. If the evidence is not present, mark the claim as UNMAPPED.
• Use verbatim source text for supporting passages. Do not paraphrase.
• If the TEXT TO ANALYZE contains no verifiable factual claims, return an empty claims array with an explanation.
• Mapping confidence must be one of: HIGH, MEDIUM, LOW. Use MEDIUM when the passage partially supports the claim but requires some inference. Use LOW when the connection is tenuous.
• [ADDITIONAL_CONSTRAINTS]

Adaptation notes: Replace [GENERATED_TEXT] with the model output you need to verify. Replace [SOURCE_DOCUMENTS] with your retrieved context, including document IDs and passage text. The [ADDITIONAL_CONSTRAINTS] placeholder lets you inject domain-specific rules, such as requiring exact quote boundaries, enforcing a minimum passage length, or adding a confidence threshold for automatic rejection. If your sources are long documents, consider chunking them before insertion and including chunk identifiers in the passage_location field. For high-stakes workflows, route UNMAPPED and CONFLICT claims to a human review queue before the output reaches end users. Run this prompt as a post-generation verification step in your RAG pipeline, not as a replacement for retrieval quality checks.

This prompt is a pre-verification step, not a final answer generator. It should be called after a model produces a draft response and before that response is shown to a user or logged in an audit trail. The harness sends the draft text and the retrieved source passages to the prompt, receives a structured claim-to-source mapping, and then uses that mapping to decide whether to approve, regenerate, or escalate the answer. The prompt itself does not modify the answer; it produces a diagnostic artifact that downstream logic acts on.

Wire the prompt into a validation gateway with three clear paths. If all claims are mapped to a source with a confidence score above your threshold (e.g., 0.8), pass the answer through. If unmapped claims exist but are low-risk boilerplate, route for lightweight human review. If high-severity claims are unmapped or mapped to low-confidence sources, trigger a regeneration loop with stricter evidence constraints, or escalate to a human reviewer with the mapping report attached. Log the full mapping artifact—including claim text, source passage ID, confidence score, and coverage gap flags—as structured metadata alongside the final answer for auditability.

Implement schema validation on the prompt's JSON output before acting on it. The expected schema includes a claims array where each object has claim_text, source_id, confidence, and mapping_status fields. If the model returns malformed JSON, missing required fields, or a claims array that doesn't cover the input text, retry the prompt once with a repair instruction. If the second attempt fails, log the raw output and escalate. Do not silently accept a broken mapping artifact—it defeats the purpose of the grounding check.

For model selection, prefer a model with strong instruction-following and structured output capabilities. This task requires precise extraction and disciplined mapping, not creative generation. If using a model that supports constrained decoding or structured output modes, enforce the claims array schema directly rather than relying on prompt instructions alone. For high-throughput pipelines, consider batching multiple draft answers into a single extraction call, but keep each answer's claims isolated with clear document IDs to prevent cross-contamination.

Build coverage gap detection into the harness, not just the prompt. After receiving the mapping, programmatically compare the set of extracted claims against the set of provided source passages. If the prompt flags gaps but your retrieval system has additional passages it didn't send, trigger a targeted re-retrieval for those specific gaps before regenerating. If gaps persist after re-retrieval, the harness should force an abstention or explicit uncertainty disclosure in the final answer. Never let an answer with known evidence gaps reach the user without a clear signal.

Finally, treat this prompt as a drift detector. Over time, track the rate of unmapped claims, low-confidence mappings, and coverage gaps. A rising trend often signals retrieval degradation, prompt drift in the answer generator, or source corpus staleness. Wire the mapping metrics into your observability stack alongside answer quality scores so that grounding failures surface before users report them.