Hallucination Severity Classification Handoff Prompt

This prompt is for output quality teams who need to classify potential hallucinations by severity and route high-risk fabrications to human review before user exposure. It sits downstream from content generation and upstream from user delivery, acting as a factuality gate. Use it when your system generates claims that must be verified against source material, and when different hallucination severities demand different actions: auto-correction, flagging, or hard escalation.

This is not a general-purpose fact-checking prompt. It assumes you already have a candidate output and its source context. The prompt performs structured severity classification, citation gap analysis, and a handoff decision with clear rationale. Do not use this prompt when you need real-time claim extraction from live conversations, when source documents are unavailable, or when your application can tolerate minor inaccuracies without user harm. For those cases, a lighter confidence score or a simpler binary check is more appropriate.

The ideal deployment pattern places this prompt inside a post-generation validation pipeline. After your primary model produces a response, this classifier inspects the output against the provided evidence before the user sees it. If the classifier returns a CRITICAL or HIGH severity rating, the system should block delivery and route to a human review queue. MEDIUM findings can trigger automatic regeneration with stricter grounding instructions, while LOW or NONE results allow the output through. This tiered approach keeps review queues manageable while catching the hallucinations that actually cause user harm or trust erosion.

Before adopting this prompt, confirm that your pipeline can supply the required inputs: the candidate output text, the source context used during generation, and any existing citations. If your generation step does not produce citation mappings, you will need to add a citation step or accept that the classifier will flag more outputs as unverifiable. Also ensure your human review queue can handle the expected escalation volume. Run a dry-run evaluation on historical outputs to estimate the escalation rate before turning on blocking behavior in production.

This template is designed to be pasted into your system prompt or a dedicated classification step in your AI pipeline. Its job is to analyze a model-generated statement against provided ground-truth context, classify the severity of any detected hallucination, and produce a structured handoff decision. The prompt uses square-bracket placeholders that you must replace with your application's specific context, policies, and output schema before deployment. Do not use this prompt as a standalone fact-checker; it requires verified source material to function correctly.

textCopy
You are an output quality auditor. Your task is to compare the [STATEMENT_TO_VERIFY] against the provided [GROUND_TRUTH_CONTEXT] and classify any factual discrepancies.

## Input
- Statement: [STATEMENT_TO_VERIFY]
- Ground Truth: [GROUND_TRUTH_CONTEXT]
- Risk Policy: [RISK_POLICY_DEFINITION]

## Classification Rules
Analyze the statement for factual accuracy. If a discrepancy exists, classify its severity:
- **CRITICAL**: The statement fabricates a dangerous instruction, a legal/medical claim, a financial figure, or a fact about a real person that could cause harm if acted upon.
- **HIGH**: The statement invents a non-existent product feature, API parameter, or a significant historical/technical fact that would mislead a professional user.
- **MEDIUM**: The statement contains a minor factual error, a wrong date, or a misattributed quote that does not change the core meaning but is objectively incorrect.
- **LOW**: The statement is vague, uses slightly imprecise language, or makes a subjective claim that cannot be strictly verified but is not contradictory to the ground truth.
- **NONE**: The statement is fully supported by the ground truth context.

## Handoff Decision
Based on the severity, determine the routing action:
- If CRITICAL or HIGH: Route to [HUMAN_REVIEW_QUEUE] immediately. Do not show the statement to the user.
- If MEDIUM: Log the incident in [OBSERVABILITY_PLATFORM] and flag for batch review, but allow the response if [MEDIUM_RISK_POLICY] permits.
- If LOW or NONE: Approve for release.

## Required Output
Return a single JSON object matching this [OUTPUT_SCHEMA]:
{
  "severity": "CRITICAL | HIGH | MEDIUM | LOW | NONE",
  "discrepancy_summary": "A concise, specific description of the factual error, or null if NONE.",
  "handoff_decision": "ESCALATE | LOG | APPROVE",
  "handoff_target": "[HUMAN_REVIEW_QUEUE] | [OBSERVABILITY_PLATFORM] | null"
}

## Constraints
- Do not infer intent. Judge only factual alignment with the ground truth.
- If the ground truth is insufficient to verify the statement, set severity to LOW and note the evidence gap.
- Never output the statement itself if the decision is ESCALATE.

To adapt this template, start by defining your [RISK_POLICY_DEFINITION] with concrete examples of what constitutes a CRITICAL fabrication in your domain. A medical app might define CRITICAL as any invented drug interaction, while a coding assistant might reserve it for hallucinated API methods that would crash a production system. Next, integrate the [OUTPUT_SCHEMA] with your downstream routing logic so that ESCALATE decisions automatically create tickets in your [HUMAN_REVIEW_QUEUE]. Finally, build an eval set of known hallucinations at each severity level to test that your classification thresholds remain stable across model updates. The most common failure mode is classifying all unsupported statements as HIGH, which floods your review queue—calibrate your MEDIUM and LOW tiers carefully using real production data.

This prompt is designed to run as a post-generation validation step before any model output reaches the user. It should not be used as a real-time guardrail on the primary generation call. Instead, integrate it into an asynchronous or synchronous validation harness that receives the candidate output, the source context (if any), and the user's original query. The harness calls this classification prompt, parses the structured severity rating and rationale, and then makes a routing decision: release the output, flag for review, or block and escalate.

For a synchronous implementation, place this prompt after your primary generation call but before streaming the response to the user. Use a fast, cost-efficient model (e.g., GPT-4o-mini, Claude 3.5 Haiku) for the classification step to keep latency under 500ms. The harness must enforce a strict timeout (e.g., 2 seconds) with a default action of HOLD_FOR_REVIEW if the classifier does not respond in time. Parse the model's JSON output with a schema validator. If the severity field is HIGH or CRITICAL, or if the requires_human_review boolean is true, route the output to a review queue and surface the rationale and flagged_claims fields to the reviewer. For MEDIUM severity, log the event and increment a per-session counter; if the counter exceeds a configurable threshold (e.g., 3 medium hallucinations in one session), escalate the session. LOW severity outputs can be released, but the harness should still attach the classification metadata to your observability traces for offline analysis.

When wiring this into an agentic or RAG pipeline, ensure the [SOURCE_CONTEXT] placeholder is populated with the exact retrieved passages or tool outputs the model used. An empty or incomplete context field will cause the classifier to over-flag hallucinations because it cannot distinguish between a missing citation and a fabrication. Implement a pre-check: if the primary generation model's own citation markers or grounding score fall below a threshold, skip the classifier and route directly to human review. Do not use this prompt to classify outputs from models that are not expected to be factual (e.g., creative writing, brainstorming). Finally, log every classification result—including the model, prompt version, severity, and routing decision—to your prompt observability platform. This data is essential for calibrating severity thresholds, measuring reviewer workload, and detecting model drift over time.