Hallucination Severity Classification Prompt Template

This prompt is a guardrail component designed to sit between hallucination detection and automated action. Its job is to classify a previously flagged hallucination by severity so your system can make a reliable decision: auto-repair a minor drift, queue a material error for human review, or block a safety-critical fabrication entirely. The ideal user is an AI safety engineer or platform developer building a production validation pipeline for a RAG application, customer-facing chatbot, or any system where unsupported output can cause user harm or erode trust. You should use this prompt only after a detection step—such as the Unsupported Statement Detection or Sentence-Level Grounding Verification prompt—has already identified a specific claim and its source evidence as problematic.

The prompt expects three concrete inputs: the original generated statement, the source evidence it was supposed to be grounded in, and the reason the detection step flagged it. From these, it produces a severity label (minor_paraphrase_drift, material_factual_error, complete_fabrication, or safety_critical_hallucination) along with a structured justification. This output is designed to be machine-readable so your application can route it without human parsing. For example, a material_factual_error on a product price might trigger a retry with stricter grounding instructions, while a safety_critical_hallucination in a medical context should immediately block the response and escalate to an on-call reviewer. Do not use this prompt on unverified outputs or as a standalone hallucination detector; it will not reliably identify unsupported claims on its own and will instead produce misleading severity assessments.

The primary failure mode to avoid is using this classifier without a high-quality detection step upstream. If the detection step produces false positives, the severity classifier will confidently label benign paraphrases as fabrications, leading to unnecessary escalations and broken user experiences. Before deploying this prompt, validate your detection pipeline's precision and recall against a labeled dataset. Once in production, log every severity classification alongside the original detection reason and the final action taken. This traceability is essential for auditing automated decisions and tuning your escalation thresholds over time.

This prompt template classifies detected hallucinations into severity tiers—minor paraphrase drift, material factual error, complete fabrication, or safety-critical hallucination—and produces a structured severity label with justification. Use it as the classification step in an output triage pipeline where downstream actions depend on severity: auto-repair for minor drift, human review for material errors, and blocking for safety-critical fabrications. The template expects you to have already identified a specific hallucinated span before classification; pair it with a hallucination detection prompt upstream.

textCopy
You are a hallucination severity classifier. Your job is to evaluate a detected hallucination and assign a severity level based on the definitions below.

## INPUT
- Generated Output: [GENERATED_OUTPUT]
- Hallucinated Span: [HALLUCINATED_SPAN]
- Source Evidence: [SOURCE_EVIDENCE]
- Domain Context: [DOMAIN_CONTEXT]

## SEVERITY LEVELS
1. MINOR_PARAPHRASE_DRIFT: The output paraphrases the source but introduces subtle meaning shifts, imprecise wording, or minor omissions that do not change the core factual claim. The information is substantially correct but not perfectly faithful.
2. MATERIAL_FACTUAL_ERROR: The output contains a factual claim that contradicts the source evidence, misstates a specific detail (name, number, date, relationship), or asserts something the source does not support. The error could mislead a reader or affect a downstream decision.
3. COMPLETE_FABRICATION: The hallucinated span has no basis whatsoever in the source evidence. The claim, entity, or detail is entirely invented and cannot be inferred from any provided context.
4. SAFETY_CRITICAL_HALLUCINATION: The hallucination could cause harm if acted upon—incorrect medical guidance, false legal claims, dangerous instructions, fabricated safety information, or misrepresented regulatory status. This overrides all other classifications when the content carries safety risk.

## CONSTRAINTS
[CONSTRAINTS]

## OUTPUT SCHEMA
Return valid JSON matching this schema:
{
  "severity": "MINOR_PARAPHRASE_DRIFT | MATERIAL_FACTUAL_ERROR | COMPLETE_FABRICATION | SAFETY_CRITICAL_HALLUCINATION",
  "confidence": 0.0-1.0,
  "justification": "Specific explanation referencing the hallucinated span and source evidence. Quote the conflicting or missing evidence.",
  "recommended_action": "auto_repair | human_review | block_output",
  "escalation_required": true/false
}

## EXAMPLES
[EXAMPLES]

Classify the hallucination now.

Adapting the template: Replace [GENERATED_OUTPUT] with the full model response, [HALLUCINATED_SPAN] with the specific text flagged by your detection step, and [SOURCE_EVIDENCE] with the retrieved passages or context the output should have been grounded in. Use [DOMAIN_CONTEXT] to specify the vertical (medical, legal, financial, general) so the classifier can calibrate safety-critical judgments appropriately. [CONSTRAINTS] should include any domain-specific severity rules—for example, in medical contexts, any fabricated medication name or dosage is automatically safety-critical. [EXAMPLES] should contain 2-4 few-shot demonstrations covering each severity level with clear justifications. For high-risk domains, always route SAFETY_CRITICAL_HALLUCINATION and MATERIAL_FACTUAL_ERROR classifications to human review before any automated action. Validate the output JSON against the schema programmatically and retry with a repair prompt if the model returns an invalid severity enum or missing required fields.

The Hallucination Severity Classification prompt is designed to sit after a hallucination detector and before an escalation or repair workflow. Its job is narrow: take a flagged hallucination (the claim, the source evidence, and the detector's output) and assign a severity label with justification. This prompt is not a detector itself—it assumes a prior step has already identified a candidate hallucination. In a production pipeline, you will typically call this prompt inside a post-generation validation layer, where each flagged span from a detector like Unsupported Statement Detection or Fabricated Detail Detection is routed here for severity triage.

Integration pattern. Wire the prompt as a single-turn classification call. Inputs must include: the original user query or task context, the full generated output, the specific hallucinated claim or span, the relevant source evidence passages, and the detector's confidence score or label. The prompt returns a JSON object with severity (one of minor_paraphrase_drift, material_factual_error, complete_fabrication, or safety_critical), a justification string, and a recommended_action (e.g., auto_repair, human_review, block). Validate the output against this schema immediately. If the model returns an unrecognized severity label or missing fields, retry once with a stricter schema reminder. After two failures, default to human_review and log the parse error for inspection.

Model choice and latency budget. Severity classification is a lower-latency, lower-cost step compared to detection or repair. A fast model (e.g., GPT-4o-mini, Claude Haiku, or a fine-tuned small classifier) is usually sufficient, provided you calibrate against a human-labeled severity dataset. If your use case is safety-critical—healthcare, legal, financial—run a periodic eval comparing the classifier's severity labels against expert human judgments. Track false negatives on safety_critical and complete_fabrication as your primary metric; a missed critical hallucination that gets auto-repaired instead of blocked is the worst failure mode.

Retry, logging, and escalation. Log every classification result with the input context hash, severity label, justification, and the detector's upstream confidence. This trace is essential for auditing triage decisions and tuning severity thresholds over time. If the prompt returns safety_critical, bypass any auto-repair step and route directly to a human review queue with the full context attached. For complete_fabrication, block the output from reaching the user and trigger a re-generation with stricter grounding instructions. For material_factual_error, you may attempt auto-repair using a separate repair prompt, but only if the domain risk tolerance allows it. For minor_paraphrase_drift, log and allow the output through with a quality flag for offline review.

What to avoid. Do not use this prompt as a standalone hallucination detector—it will miss hallucinations that were never flagged upstream. Do not skip schema validation on the output; an unparseable severity label in a production pipeline can silently drop a critical hallucination. Do not treat severity labels as static; periodically re-evaluate your severity taxonomy against real production incidents and adjust the prompt's definitions and examples accordingly. Finally, always include a human-review escape hatch: if the classifier's confidence is low or the input context is ambiguous, escalate rather than guess.