Unsupported Statement Detection and Classification Prompt Template

This prompt is designed for verification pipeline operators who need to programmatically distinguish between a claim that has been proven false and one that simply lacks sufficient evidence. Its core job is to classify a single, atomic claim against a provided evidence set into one of four structured verdicts: SUPPORTED, UNSUPPORTED, CONTRADICTED, or UNVERIFIABLE. The ideal user is an engineer or AI system architect integrating this classification step into a larger automated fact-checking or content verification workflow, where a clean, auditable decision is required before routing the claim to downstream reporting, human review queues, or user-facing displays.

Use this prompt only when your system has already completed two critical upstream tasks: extracting a discrete, self-contained claim from source content and retrieving a candidate set of relevant evidence. It is not a substitute for open-ended question answering, multi-hop reasoning across disparate evidence sources, or generating natural-language explanations for end users without further processing. The prompt assumes the input claim is atomic and the evidence set is pre-retrieved and provided in full. It will not search for new evidence, weigh source authority beyond what is described in the provided text, or resolve complex temporal or logical contradictions that require chaining multiple inference steps.

Do not deploy this prompt in scenarios where the claim itself is ambiguous, compound, or spans multiple factual assertions. In those cases, use a claim decomposition prompt first to break the input into atomic units. Similarly, avoid using this prompt as a direct user-facing explanation generator; the raw verdict and rationale are designed for machine consumption and internal routing, not for public disclosure without additional framing and uncertainty disclosure. For high-stakes domains such as healthcare, legal compliance, or financial reporting, always route UNSUPPORTED and CONTRADICTED verdicts to a human review step before any downstream action is taken.

This prompt template is designed for verification pipeline operators who need to distinguish 'proven false' from 'not yet proven.' It forces the model to classify a statement against a provided evidence set into one of four categories: SUPPORTED, UNSUPPORTED, CONTRADICTED, or UNVERIFIABLE. The output is structured JSON suitable for downstream processing, audit logging, and human review routing. Use this template when you have a discrete claim and a bounded set of source evidence—not for open-ended research or retrieval-augmented generation where the evidence set is dynamically assembled.

textCopy
SYSTEM:
You are a verification classifier. Your task is to determine whether a statement is supported by the provided evidence. You must classify the statement into exactly one of four categories and provide a structured JSON output. Do not answer the statement. Do not provide your own knowledge. Only reason from the provided evidence.

CLASSIFICATION RULES:
- SUPPORTED: The evidence directly and unambiguously confirms the statement. All key factual assertions in the statement are backed by at least one source in the evidence.
- UNSUPPORTED: The evidence does not contain information that confirms or contradicts the statement. The statement may be true, but the provided evidence is insufficient to verify it.
- CONTRADICTED: The evidence directly and unambiguously refutes the statement. At least one source in the evidence explicitly contradicts a key factual assertion.
- UNVERIFIABLE: The statement contains claims that cannot be verified with the type of evidence provided (e.g., subjective opinions, future predictions, or claims requiring evidence outside the provided set's scope).

OUTPUT SCHEMA:
{
  "verdict": "SUPPORTED | UNSUPPORTED | CONTRADICTED | UNVERIFIABLE",
  "confidence": 0.0-1.0,
  "rationale": "Brief explanation of the classification decision, citing specific evidence items.",
  "evidence_gaps": ["List of specific factual assertions in the statement that lack supporting evidence."],
  "supporting_evidence": ["List of evidence items that support the verdict, with source references."],
  "contradicting_evidence": ["List of evidence items that contradict the statement, with source references."],
  "requires_human_review": true/false,
  "human_review_reason": "Explanation if human review is required, otherwise null."
}

CONSTRAINTS:
- If confidence is below [CONFIDENCE_THRESHOLD], set requires_human_review to true.
- If the evidence set is empty or contains no relevant information, classify as UNSUPPORTED with confidence 0.0.
- Never invent evidence. If you cannot find supporting or contradicting evidence, say so explicitly.
- For UNSUPPORTED verdicts, suppress confidence: maximum confidence is [UNSUPPORTED_MAX_CONFIDENCE].
- For UNVERIFIABLE verdicts, explain why the claim type exceeds the evidence scope.

USER:
Statement: [STATEMENT]

Evidence:
[EVIDENCE]

Classify the statement according to the rules above. Return only valid JSON.

Adaptation notes: Replace [STATEMENT] with the claim to verify and [EVIDENCE] with the source text block, including source identifiers for traceability. Set [CONFIDENCE_THRESHOLD] based on your risk tolerance—0.7 is a common starting point for auto-verification. Set [UNSUPPORTED_MAX_CONFIDENCE] to prevent over-confident unsupported verdicts; 0.4 is recommended. For batch processing, wrap this in a loop that feeds one statement-evidence pair per call. For production pipelines, always validate the output JSON against the schema before accepting the verdict. If the model returns a verdict outside the four allowed values or omits required fields, trigger a retry or fallback to human review. This template works best with models that have strong instruction-following and JSON output capabilities (GPT-4, Claude 3.5 Sonnet, or equivalent). Weaker models may require few-shot examples added to the system prompt.

This prompt is designed to be called as a single step within a broader verification pipeline, not as a standalone chat interaction. The model should be invoked with response_format set to json_object (OpenAI) or the equivalent structured output mode for your provider (e.g., Anthropic's tool use with a strict schema, Gemini's controlled generation). The output contract expects a JSON object with a verdict field constrained to the enum [SUPPORTED, UNSUPPORTED, CONTRADICTED, UNVERIFIABLE] and an evidence_gaps array documenting missing or conflicting sources. Do not allow the model to return free text or a verdict outside this enum.

After receiving the model response, validate the JSON structure immediately in your application layer. Check that verdict is present and matches the allowed enum values, that evidence_gaps is an array, and that each gap object contains the required claim_fragment, gap_type, and missing_evidence_description fields. If validation fails, construct a retry prompt that appends the raw model output and the specific validation error message to the original prompt context. Limit retries to one attempt to avoid infinite loops and escalating costs. If the retry also fails validation, route the entire claim record—including the raw model output, validation errors, claim ID, and evidence set hash—to a human review queue. Never silently accept a malformed verdict.

For high-stakes domains such as finance, healthcare, or legal, configure your pipeline to automatically escalate any verdict of UNSUPPORTED or CONTRADICTED to human review before publishing or acting on the result. These verdicts carry significant downstream risk and require human judgment to confirm the evidence gap is real and not a retrieval or parsing failure. Log every verdict with the claim ID, evidence set hash, model version, timestamp, and final routing decision (auto-accepted, retried, or escalated). This audit trail is essential for debugging pipeline regressions and demonstrating due diligence to compliance reviewers.