Multi-Hop Claim Verification Prompt with Evidence Trails

This prompt is designed for fact-checking and verification pipelines where a complex claim cannot be verified from a single document. It instructs the model to decompose the claim into sub-claims, locate supporting or refuting evidence across multiple retrieval steps, chain that evidence into a logical trail, and produce a verdict with full source traceability. Use this when you need an auditable record of how a conclusion was reached, not just a yes/no answer. The ideal user is an AI engineer or QA lead building a post-retrieval verification harness for high-stakes domains like legal compliance, financial audit, or clinical review, where the reasoning path matters as much as the final verdict.

This prompt belongs in post-retrieval verification workflows, not in real-time chat. It assumes you have already retrieved a candidate pool of documents and need the model to perform structured, multi-hop reasoning over them. The required context includes the original claim, a set of retrieved documents with identifiers, and an output schema that enforces a step-by-step evidence trail. You should wire this into a pipeline that validates the output structure before accepting the verdict, and you must plan for cases where the evidence is insufficient or contradictory. The prompt is not a replacement for retrieval; it is a reasoning engine that operates over already-fetched context.

Do not use this prompt if your claim is simple and verifiable from a single passage. In that case, a single-hop verification prompt with direct citation is faster, cheaper, and less error-prone. Also avoid this prompt when latency is critical and you cannot afford multiple reasoning steps, or when the retrieved document pool is too large to fit in a single context window without aggressive filtering. If you are building a real-time chat assistant, this prompt's structured output and multi-step reasoning will feel slow and overly formal. Instead, reserve it for asynchronous verification jobs, audit trails, and evaluation harnesses where correctness and traceability outweigh speed.

This template is the core instruction set for a multi-hop claim verification workflow. It instructs the model to act as an investigative fact-checker that cannot rely on internal knowledge. Instead, it must construct a step-by-step evidence trail from the provided [RETRIEVED_CONTEXT] to support or refute a [CLAIM]. The prompt enforces strict source grounding, explicit reasoning, and a structured output schema suitable for downstream logging, auditing, or human review. Use this template when a single retrieval pass is insufficient to verify a claim that depends on connecting facts across multiple documents or passages.

markdownCopy
You are an investigative fact-checker. Your task is to verify the provided [CLAIM] using ONLY the evidence in the [RETRIEVED_CONTEXT]. You cannot use your own knowledge.

Follow this process:
1.  **Decompose the Claim:** Break the [CLAIM] down into its constituent atomic facts.
2.  **Multi-Hop Evidence Trail:** For each atomic fact, locate the specific supporting or refuting evidence in the [RETRIEVED_CONTEXT]. If finding evidence for one fact requires first establishing another fact from a different source, show this chain of reasoning explicitly. Cite the source ID for every piece of evidence.
3.  **Synthesize a Verdict:** Based on the complete evidence trail, determine a final verdict for the overall [CLAIM]. The verdict must be one of: `SUPPORTED`, `REFUTED`, `PARTIALLY_SUPPORTED`, or `INSUFFICIENT_EVIDENCE`.
4.  **Format the Output:** Structure your entire response as a single JSON object conforming to the [OUTPUT_SCHEMA].

**Constraints:**
- [CONSTRAINTS]
- If the evidence trail is incomplete and you cannot reach a verdict, set the verdict to `INSUFFICIENT_EVIDENCE` and explain what specific information is missing.
- If sources contradict each other, you must flag the conflict in the `evidence_trail` and explain how it impacts the verdict.

**Inputs:**
- **Claim:** [CLAIM]
- **Context:** [RETRIEVED_CONTEXT]
- **Output Schema:** [OUTPUT_SCHEMA]

To adapt this template, replace the square-bracket placeholders with your application's data. [CLAIM] is the text to be verified. [RETRIEVED_CONTEXT] should be a pre-assembled string containing all potentially relevant documents, each with a unique source_id (e.g., [DOC_01], [URL_05]). The [OUTPUT_SCHEMA] placeholder must be replaced with a strict JSON schema definition, such as one requiring an array of atomic_facts, an array of evidence_trail steps (each with source_id, quote, and inference), and a verdict string. Use the [CONSTRAINTS] placeholder to inject domain-specific rules, such as "Prioritize peer-reviewed sources" or "Flag any claims about individuals for mandatory human review." Ensure your application layer validates the model's output against the provided schema before accepting the verdict.

The Multi-Hop Claim Verification Prompt is not a standalone chat interaction; it is a component in a verification pipeline. The prompt expects a specific claim and a set of retrieved evidence chunks. The application layer is responsible for orchestrating the retrieval steps, feeding the prompt, validating the structured output, and deciding whether to retry, escalate, or accept the verdict. Treat the prompt as a stateless function: input is [CLAIM] and [EVIDENCE_CHUNKS], output is a JSON object containing a verdict, a confidence score, and an evidence trail. The harness must enforce this contract.

Pipeline Wiring: The verification flow begins with a claim intake step. The application then performs multi-hop retrieval—often using a separate decomposition prompt to generate sub-queries—and collects evidence chunks. These chunks are assembled into the [EVIDENCE_CHUNKS] placeholder, each with a unique chunk_id. The prompt is called with a strict [OUTPUT_SCHEMA] specifying a JSON object with verdict (one of SUPPORTED, REFUTED, INCONCLUSIVE), confidence (0.0–1.0), and evidence_trail (an ordered array of objects, each containing chunk_id, relevance, and reasoning). After the model responds, a JSON schema validator checks the output. If parsing fails, a repair prompt can be invoked once. If it fails again, the claim is routed to a human review queue with the raw model output attached.

Retry and Escalation Logic: Implement a retry policy with a maximum of two attempts. The first retry occurs on schema validation failure. The second retry occurs if the confidence score falls below a configurable threshold (e.g., 0.6) or if the evidence_trail is empty when the verdict is SUPPORTED or REFUTED. Do not retry indefinitely; after two failures, escalate to a human reviewer. Log every attempt, including the prompt version, model, latency, and raw response, to an observability platform. This trace is essential for debugging hallucinated trails or persistent schema non-compliance. For high-risk domains, always require human approval when the verdict is REFUTED or INCONCLUSIVE before the result is surfaced to an end user or written to a system of record.

Model Selection and Tool Use: This prompt works best with models that have strong instruction-following and JSON mode capabilities (e.g., GPT-4o, Claude 3.5 Sonnet). Avoid smaller, less capable models for claims requiring more than two evidence hops. The prompt itself does not call tools; retrieval happens before the prompt is invoked. However, if the evidence_trail reveals a gap—such as a reasoning step that references a fact not present in the provided chunks—the harness can trigger a secondary retrieval loop using the gap description as a new query. This agentic loop should have a hard limit (e.g., 3 additional retrieval rounds) to prevent runaway verification.

Evaluation and Monitoring: Before deploying any change to this prompt, run it against a golden dataset of claims with known verdicts and expected evidence trails. Automate checks for verdict accuracy, trail completeness (every reasoning step has a chunk_id), and hallucination rate (chunk_ids that don't exist in the input). In production, monitor the rate of INCONCLUSIVE verdicts and human escalations. A sudden spike often indicates retrieval degradation or a prompt regression. Pair this prompt with an LLM-as-judge evaluation step that audits a sample of evidence trails for faithfulness, but keep the human review queue as the final arbiter for any claim with a confidence score below 0.8.