Claim Extraction and Evidence Matching Prompt

This prompt is designed for verification pipeline builders who need to decompose unstructured text into discrete, verifiable factual claims and pair each claim with the most relevant evidence passage from a provided corpus. It is the first stage in a multi-step groundedness evaluation workflow, producing structured claim-evidence pairs that feed downstream scoring, fact-checking, or human review queues. Use this when you have a generated output or document and a set of source documents, and you need a machine-readable artifact that maps every assertion back to its supposed origin.

The ideal user is an AI engineer or evaluation lead building an automated groundedness pipeline for a RAG system, content generation product, or document verification workflow. You must provide both the text to be analyzed and the evidence corpus as inputs. The prompt expects the evidence to be pre-retrieved and supplied inline; it does not perform retrieval itself. The output is a structured list of claim-evidence pairs, each containing the extracted claim, the matched evidence passage, and a relevance indicator. This output is designed to be consumed programmatically by a downstream scoring prompt or a human review interface.

Do not use this prompt for open-domain question answering, real-time chat, or when no evidence corpus is provided. It is not a retrieval step and will hallucinate evidence if asked to operate without source material. Avoid using it for subjective or opinion-based content where factual verification is not the goal. For high-stakes domains such as healthcare, legal, or finance, the structured output should feed a human review queue rather than an automated pass/fail gate. If your evidence corpus is large, pre-filter it with a retrieval step before passing the top-k passages to this prompt to stay within context window limits.

This prompt is the core instruction set for a claim extraction and evidence matching pipeline. It is designed to be dropped into an application that already has access to a source text and a corpus of evidence passages. The model's job is not to answer questions or summarize, but to atomize the input text into individual, verifiable factual claims and then find the single best supporting evidence passage for each claim. The output is a structured JSON array ready for downstream scoring, human review, or database ingestion.

textCopy
You are a precise claim extraction and evidence matching engine. Your task is to read the provided text, decompose it into discrete, self-contained factual claims, and match each claim to the most relevant evidence passage from the provided corpus.

# INPUT
## Text to Analyze
[TEXT]

## Evidence Corpus
[EVIDENCE_CORPUS]

# INSTRUCTIONS
1. Extract every discrete factual claim from the text. A claim is a single, verifiable statement of fact. Break compound sentences into separate claims.
2. Ignore opinions, rhetorical questions, greetings, and purely stylistic language.
3. For each extracted claim, search the evidence corpus and identify the single passage that best supports or refutes it.
4. If no evidence passage is relevant to a claim, set the evidence field to null and set the match status to "UNSUPPORTED".
5. If evidence partially supports a claim, set the match status to "PARTIAL" and include a brief explanation in the match_reasoning field.
6. Do not modify or paraphrase the claim text. Quote it exactly as it appears in the input.
7. Do not introduce claims that are not present in the input text.

# OUTPUT SCHEMA
Return a valid JSON object with a single key "claims" containing an array of objects. Each object must have the following fields:
- "claim_id": string, a unique identifier for the claim (e.g., "C1", "C2")
- "claim_text": string, the exact text of the extracted claim
- "evidence_passage": string or null, the most relevant passage from the evidence corpus, quoted exactly
- "evidence_id": string or null, the identifier of the evidence passage if provided in the corpus
- "match_status": string, one of "SUPPORTED", "PARTIAL", "UNSUPPORTED", or "CONTRADICTED"
- "match_reasoning": string, a brief explanation of why the evidence was selected and how it relates to the claim

# CONSTRAINTS
- Return ONLY the JSON object. No markdown fences, no introductory text, no summaries.
- Ensure all strings are properly escaped for JSON.
- If the input text contains no factual claims, return {"claims": []}.

To adapt this prompt, replace the [TEXT] and [EVIDENCE_CORPUS] placeholders with your actual content at runtime. The evidence corpus should be pre-formatted as a string that includes passage identifiers if you want them reflected in the evidence_id field. For high-stakes domains like healthcare or legal review, add a [RISK_LEVEL] parameter that adjusts the match_reasoning verbosity and requires explicit uncertainty language. Always validate the output JSON against the schema before passing it downstream—malformed JSON is the most common failure mode. For production deployments, pair this prompt with a retry-and-repair harness that catches schema violations and re-prompts the model with the validation error.

This prompt is designed to be a single step inside a larger verification pipeline, not a standalone chat interface. The typical harness wraps the prompt in a function that accepts unstructured text and a pre-retrieved evidence corpus, then returns structured claim-evidence pairs for downstream scoring. Because the output is a JSON array of objects, the harness must validate the schema before passing results to the next stage—malformed JSON or missing fields will break any automated groundedness scorer that follows.

Start by defining a strict output schema in your application code, not just in the prompt. Each claim-evidence pair should have at minimum: claim_id (string), claim_text (string), evidence_passage (string or null), evidence_index (integer or null), and match_confidence (float between 0 and 1). Validate these types after every model call. If the model returns evidence_passage as a string when no match exists, normalize it to null in post-processing. Use a JSON schema validator like jsonschema (Python) or zod (TypeScript) to reject malformed responses before they enter your scoring pipeline. For high-stakes verification workloads, add a requires_human_review boolean field set to true when match_confidence falls below a configurable threshold—typically 0.7 for factual claims in regulated domains.

Model choice matters here. This prompt requires strong instruction-following and structured output discipline. Prefer models with native JSON mode or constrained decoding (GPT-4o with response_format, Claude 3.5 Sonnet with tool-use-shaped output, or fine-tuned open-weight models with grammar-constrained generation). Avoid models that frequently drop fields or hallucinate evidence indices. Implement a retry loop with exponential backoff: if validation fails, re-prompt with the validation error message appended to [CONSTRAINTS]. Log every failure, the retry count, and the final output shape. For production observability, emit metrics on claim extraction rate (claims per input word), null evidence rate (claims with no match), and schema compliance rate. These metrics will surface drift when the model or input distribution changes.

The evidence corpus must be pre-segmented into indexable passages before this prompt runs. Each passage should have a stable integer index that the model can reference in evidence_index. If your retrieval system returns passages with unstable ordering, sort them by a deterministic key (e.g., document ID + chunk offset) before assigning indices. Never rely on the model to match evidence by content alone—the index is your audit trail. When the model returns evidence_index: null, log the unmatched claim for retrieval gap analysis. Over time, these null-evidence claims become a prioritized list for improving your retrieval pipeline or expanding your knowledge base.

Wire the output of this prompt directly into a downstream groundedness scorer or factuality classifier. The structured claim-evidence pairs are the input contract for those prompts. If you skip validation here, you will spend more time debugging hallucination false positives downstream. For CI/CD integration, run this prompt against a golden dataset of 50-100 annotated documents where claim extraction and evidence matching have been human-verified. Measure precision and recall of claim extraction, and accuracy of evidence-to-claim pairing. Set a minimum threshold (e.g., 90% pairing accuracy) before promoting a new prompt version. If pairing accuracy drops, inspect the null-evidence rate and the model's tendency to over-claim or under-claim before adjusting the prompt.