Evidence Sufficiency Assessment Prompt

This prompt is the automated triage gate for your verification pipeline. Its sole job is to decide whether a specific claim can be automatically verified given the evidence you have already retrieved. It does not perform the verification itself, nor does it retrieve evidence. Instead, it acts as a decision point that routes claims to one of three paths: auto-verification, human review, or a terminal 'unverifiable' state. The ideal user is a verification pipeline operator or an engineer building an automated fact-checking system who needs to control operational costs and latency by ensuring that only claims with sufficient, high-quality evidence proceed to automated judgment.

To use this prompt correctly, you must already have completed claim extraction and evidence retrieval. The prompt expects a structured input containing the original claim, its context, and a set of candidate evidence passages with source metadata. It produces a structured output with a sufficiency rating (e.g., SUFFICIENT, INSUFFICIENT, CONFLICTING), a confidence score, and a detailed list of evidence gaps. This output is machine-readable, enabling direct integration into workflow orchestration logic. For example, a SUFFICIENT rating can trigger an auto-verification prompt, while an INSUFFICIENT rating with specific gap descriptions can be fed back into a retrieval system for a second pass or used to generate a human review task with a clear explanation of what's missing.

Do not use this prompt as a substitute for evidence retrieval, contradiction detection, or final verification judgment. It is not designed to find evidence, only to assess the quality and completeness of evidence already provided. It will fail silently if you pass it empty or irrelevant evidence sets, producing a confident INSUFFICIENT rating without diagnosing the upstream retrieval failure. Similarly, avoid using it for real-time, user-facing chatbots where the triage decision itself must be explained conversationally; this prompt is designed for machine-to-machine workflow orchestration. The next step after implementing this prompt is to calibrate its sufficiency thresholds against a labeled dataset of claims and evidence sets from your specific domain, as a generic threshold will almost certainly be misaligned with your tolerance for risk.

This template is the core instruction set for an Evidence Sufficiency Assessment. It is designed to be dropped directly into your prompt management system, orchestration code, or AI gateway. The prompt forces the model to act as a verification analyst, evaluating a single claim against a provided evidence set and returning a structured sufficiency rating along with a documented gap analysis. It does not ask the model to determine truth; it asks the model to determine whether the provided context is enough to make a determination, which is a critical distinction for production verification pipelines.

textCopy
You are a verification analyst. Your task is to assess whether the provided evidence is sufficient to verify the claim. Do not determine if the claim is true or false. Determine only if the evidence set is adequate to make that determination.

## CLAIM
[CLAIM]

## EVIDENCE SET
[EVIDENCE]

## OUTPUT SCHEMA
Return a JSON object with the following fields:
- sufficiency_rating: string, one of "SUFFICIENT", "PARTIALLY_SUFFICIENT", "INSUFFICIENT"
- evidence_gaps: array of strings, each describing a specific piece of missing information needed to reach "SUFFICIENT"
- evidence_strengths: array of strings, each describing a specific piece of evidence that directly addresses the claim
- reasoning: string, a concise explanation of the rating, referencing specific evidence items

## CONSTRAINTS
- If the evidence directly supports or contradicts all factual components of the claim, the rating is "SUFFICIENT".
- If the evidence addresses some components but not others, the rating is "PARTIALLY_SUFFICIENT".
- If the evidence is entirely silent, off-topic, or only tangentially related, the rating is "INSUFFICIENT".
- Do not infer support or contradiction. Only use explicit information in the evidence set.
- If the claim contains multiple distinct assertions, evaluate each one.
- For numerical claims, note if the evidence provides a comparable figure within a reasonable tolerance.
- For claims about events, note if the evidence covers the relevant time, place, and actors.

## RISK_LEVEL
[RISK_LEVEL]

## EXAMPLES
[EXAMPLES]

To adapt this template, start by mapping your upstream claim extraction output into the [CLAIM] placeholder. The [EVIDENCE] block should contain the raw text of retrieved documents, pre-processed to include source identifiers (e.g., [DOC_ID_1]). The [RISK_LEVEL] field is a control parameter: for high-risk domains like healthcare or finance, you should append additional instructions here, such as 'If PARTIALLY_SUFFICIENT, treat as INSUFFICIENT and escalate for human review.' The [EXAMPLES] block is critical for calibration; provide at least two few-shot examples that demonstrate the boundary between PARTIALLY_SUFFICIENT and INSUFFICIENT using your domain's specific evidence standards. After integrating this prompt, you must validate the output JSON against the schema before allowing downstream consumption, and log any instances where the model fails to produce a valid sufficiency_rating for prompt debugging.

The Evidence Sufficiency Assessment prompt is not a standalone tool; it is a decision gate inside a larger verification pipeline. Its output—a sufficiency rating and documented evidence gaps—determines whether a claim proceeds to automated verification or is routed to a human review queue. To use this prompt safely in production, you must wrap it in a harness that validates the output schema, enforces domain-specific evidence thresholds, and logs every decision for auditability. The prompt itself handles the reasoning, but the harness owns the routing logic, retry policy, and escalation path.

Start by defining a strict output schema that the prompt must satisfy. The schema should include at minimum: a claim_id for traceability, a sufficiency_rating enum (e.g., sufficient, insufficient, borderline), a list of evidence_gaps with specific descriptions of what is missing, and a recommended_action field (auto_verify, human_review, discard). Validate this schema immediately after the model responds. If the output fails schema validation, retry once with the validation error injected into the prompt context. If the second attempt also fails, log the failure and route the claim to human review with a schema_failure flag. For model choice, use a capable reasoning model (e.g., GPT-4o, Claude 3.5 Sonnet) for the assessment itself, but consider a smaller, faster model for schema validation and retry formatting to control costs.

The most critical harness component is the threshold calibration layer. The prompt produces a qualitative sufficiency rating, but your pipeline needs a deterministic routing decision. Implement a post-processing step that maps the rating to a routing action based on domain-specific rules. For example, in a legal verification context, any claim rated borderline or insufficient might require human review regardless of the model's recommended_action. In a news fact-checking pipeline, borderline claims with corroborating evidence from at least two authoritative sources might proceed to auto-verification. Store these threshold rules in configuration, not in the prompt, so you can tune them without changing the model's reasoning surface. Log the raw prompt output alongside the final routing decision to enable threshold calibration audits over time.

Finally, instrument the harness with evaluation checkpoints. For each claim processed, record: whether the output passed schema validation on the first attempt, the sufficiency rating distribution over time, the rate of human_review escalations, and the average number of evidence_gaps per claim. Run periodic spot checks where a human reviewer compares the model's sufficiency rating against their own judgment on a sample of claims. If the model consistently over-rates sufficiency (a common failure mode when evidence is present but weak), adjust the threshold rules or add few-shot examples of borderline cases to the prompt. Never let the sufficiency assessment run unattended without these observability hooks—an over-confident sufficiency gate silently degrades the entire verification pipeline.