Hallucination Severity Classification from Traces Prompt

This prompt is a triage and prioritization layer for production incident response and quality engineering workflows. It assumes you have already run a detection prompt or evaluation pipeline that identified unsupported claims in a model's output and matched them against the retrieved context captured in a trace. The job-to-be-done is not finding hallucinations—it is deciding which ones demand immediate action. Use this prompt when you have a list of extracted, evidence-matched claims and need to separate a critical safety misstatement that requires a model rollback from a minor stylistic imprecision that can wait for the next prompt update cycle. The ideal user is an incident responder, AI SRE, or quality engineer who needs to communicate severity to the broader team and prioritize remediation tasks.

The prompt requires three concrete inputs to function correctly. First, a list of claims that have already been flagged as unsupported, each with a claim ID and the generated text. Second, the associated trace context for each claim, including the retrieved passages that were available and the model's final output. Third, your organization's severity definitions, which must map to observable characteristics in the trace rather than abstract categories. A critical severity definition might be 'claim introduces a safety risk, legal liability, or contradicts a regulated fact' while a minor severity definition might be 'claim is imprecise but does not change the user's understanding or decision.' Without these concrete definitions, the model will apply its own inconsistent severity heuristics. The output is a severity-labeled list with per-claim justifications anchored to trace evidence, suitable for ingestion into an incident tracking system or remediation queue.

Do not use this prompt as the first step in hallucination detection. It is a classification layer that sits downstream of claim extraction and evidence matching. If you feed it raw model outputs without pre-extracted claims and trace context, it will attempt to do detection and classification simultaneously, producing unreliable results. Do not use this prompt when you need root-cause analysis—it tells you what is severe, not why the hallucination occurred. For root-cause diagnosis, use the Hallucination Root-Cause Trace Analysis Prompt instead. Do not use this prompt for real-time blocking decisions in a user-facing request path; its role is asynchronous triage and prioritization. If you need to block a response before it reaches the user, implement a streaming guardrail with a binary grounding check, not a multi-class severity classifier. The next step after classification is routing: critical findings go to the incident response channel, major findings go to the prompt engineering backlog, and minor findings feed into continuous improvement tracking.

The prompt template below is designed to classify hallucinated claims in a production trace by severity level. It expects a structured trace containing the generated output, retrieved context, and source documents. The model will extract claims, compare them against the evidence in the trace, and assign each unsupported claim a severity label: critical (safety or legal risk), major (factual error with user impact), minor (imprecise but not misleading), or stylistic (acceptable variation). Replace each square-bracket placeholder with your actual trace data and severity definitions before sending to the model. The template includes explicit output schema instructions to ensure structured, machine-readable results suitable for incident triage pipelines and monitoring dashboards.

textCopy
You are a hallucination severity classifier for production AI traces. Your task is to analyze a trace containing a generated output, retrieved context, and source documents, then classify any unsupported claims by severity.

## INPUT

[TRACE_DATA]

## SEVERITY DEFINITIONS

[SEVERITY_DEFINITIONS]

## INSTRUCTIONS

1. Extract all factual claims from the generated output in the trace.
2. For each claim, check whether it is supported by the retrieved context and source documents in the trace.
3. If a claim is unsupported, classify its severity using the definitions above.
4. For each unsupported claim, provide:
   - The claim text
   - The severity level
   - The closest retrieved passage (if any)
   - A brief justification for the severity classification
   - The trace event ID or span reference where the claim appears
5. If no unsupported claims are found, return an empty list with a confidence note.
6. Do not classify stylistic variations or acceptable paraphrasing as hallucinations unless they change the factual meaning.

## CONSTRAINTS

[CONSTRAINTS]

## OUTPUT SCHEMA

Return a JSON object with this structure:

{
  "trace_id": "string",
  "analysis_timestamp": "string",
  "total_claims_extracted": number,
  "unsupported_claims": [
    {
      "claim_text": "string",
      "severity": "critical | major | minor | stylistic",
      "closest_retrieved_passage": "string | null",
      "trace_event_reference": "string",
      "justification": "string",
      "recommended_action": "string"
    }
  ],
  "grounding_summary": "string",
  "confidence_note": "string"
}

## EXAMPLES

[EXAMPLES]

Adaptation guidance: Replace [TRACE_DATA] with the full trace object including the generated output, retrieved passages, source document references, and any tool-call logs. Replace [SEVERITY_DEFINITIONS] with your organization's specific severity taxonomy—the template assumes four levels but you can adjust the enum. Use [CONSTRAINTS] to add domain-specific rules such as regulatory requirements, prohibited severity downgrades, or mandatory human-review triggers for critical findings. The [EXAMPLES] placeholder should contain 2-3 few-shot examples showing correct severity classification for your domain's typical hallucination patterns. For high-risk domains like healthcare or legal, add a constraint requiring "recommended_action": "escalate_to_human_review" for all critical and major classifications. The output schema is designed to feed directly into incident management systems, monitoring dashboards, or automated alerting pipelines—ensure your downstream consumers can parse the severity enum and trace_event_reference fields.

This prompt is designed to operate as a classification microservice within a broader observability stack. It expects a structured trace input containing the generated output, the retrieved context, and any tool-call results. The primary integration point is a post-retrieval, pre-user-response hook in a RAG pipeline, or a batch processor that scans logged traces from a data warehouse. The output is a severity-labeled claim list, which downstream systems can use to trigger alerts, populate dashboards, or prioritize human review queues.

To wire this into an application, wrap the prompt in a function that validates the input trace schema before calling the model. The trace must include generated_output, retrieved_context (as a list of document objects with id and content), and optional tool_outputs. After receiving the model response, run a strict JSON schema validator against the expected output structure: a list of objects, each with claim, severity (one of critical, major, minor, stylistic), evidence_status (supported, unsupported, contradicted), and source_reference. If validation fails, implement a single retry with the validation error message injected into the prompt as additional [CONSTRAINTS]. Log both the raw and validated outputs to your observability platform, attaching the trace ID for correlation. For high-risk domains, route all critical and major findings to a human review queue before any automated action is taken.

Model choice matters here. Use a model with strong instruction-following and structured output capabilities, such as GPT-4o or Claude 3.5 Sonnet, and set a low temperature (0.0–0.2) to maximize consistency. Avoid using this prompt on streaming endpoints; the full trace context must be available before classification begins. For cost control in high-volume pipelines, consider sampling traces based on user-reported issues or low confidence scores from an upstream faithfulness evaluator, rather than classifying every single request. The next step after implementation is to build an eval set of 50–100 traces with known hallucination severities, run this prompt against them, and calibrate your alert thresholds based on the precision and recall of critical and major detections.