LLM Judge Failure Mode Classification Prompt Template

This prompt is designed for evaluation platform teams who need to move beyond binary pass/fail signals and into automated root-cause diagnosis. The primary job-to-be-done is routing a model output that has already failed a quality gate to the correct remediation path. Instead of a human manually inspecting every failure to decide whether it's a hallucination, a format error, a refusal, or a reasoning break, this prompt produces a structured classification label, a confidence score, and an evidence pointer that your downstream pipeline can act on. The ideal user is an AI engineer or evaluation lead building an automated debugging harness where speed and consistency matter more than perfect accuracy on edge cases.

You should use this prompt when you have a known-failing output, the original input that produced it, and any relevant context or source material that was available to the model at generation time. The prompt assumes the failure has already been detected by an upstream quality gate—such as a groundedness check, a schema validator, or a safety classifier. It does not replace that gate. Instead, it answers the question: 'Now that we know this output is bad, what kind of bad is it?' This classification then feeds into automated remediation: hallucination outputs go to fact-repair loops, format errors go to schema correction, refusals go to policy review, and reasoning breaks go to chain-of-thought debugging. The prompt is most effective when your failure taxonomy is stable and your remediation paths are well-defined.

Do not use this prompt as a substitute for human review in high-risk domains such as healthcare, legal, finance, or safety-critical systems. The classification it produces is a first-pass diagnosis intended to accelerate human triage or feed automated repair pipelines with low downstream risk. It is not a final judgment. Avoid using this prompt when the failure mode taxonomy is ambiguous or when multiple failure modes overlap in ways that require nuanced human judgment. Also avoid it when the cost of misclassification is high and the confidence score is likely to be low—for example, when the original input is adversarial, the context is contradictory, or the model output is so garbled that even a human would struggle to categorize the failure. In those cases, route directly to a human review queue with the raw evidence attached.

This prompt template is designed to be dropped directly into your evaluation harness. It instructs an LLM judge to analyze a failed model output against its original input and instructions, then classify the failure into a structured taxonomy. The template uses square-bracket placeholders that you must replace at runtime with actual values from your pipeline—the original user input, the system prompt or instructions, the model's failing output, and your specific failure taxonomy. The output is a strict JSON object containing the primary failure mode, a confidence score, a concise evidence quote, and a brief reasoning trace. This structure ensures that downstream debugging tools and dashboards receive consistent, machine-readable diagnostics.

textCopy
You are an expert AI output auditor. Your task is to analyze a model output that has been flagged as a failure and classify the failure mode.

## INPUT
[INPUT]

## SYSTEM INSTRUCTIONS
[SYSTEM_PROMPT]

## MODEL OUTPUT (FLAGGED AS FAILURE)
[FAILING_OUTPUT]

## FAILURE MODE TAXONOMY
[FAILURE_TAXONOMY]

## INSTRUCTIONS
1. Review the INPUT, SYSTEM INSTRUCTIONS, and FAILING_OUTPUT carefully.
2. Identify the single most specific failure mode from the FAILURE MODE TAXONOMY that best explains why the output failed.
3. Quote the shortest exact string from the FAILING_OUTPUT that serves as primary evidence for this failure.
4. Provide a concise, step-by-step reasoning trace that connects the evidence to the chosen failure mode.
5. Assign a confidence score between 0.0 and 1.0 reflecting how certain you are in this classification.

## OUTPUT SCHEMA
You must respond with a single JSON object conforming to this schema:
{
  "failure_mode": "string (exact value from taxonomy)",
  "confidence": number (0.0 to 1.0),
  "evidence_quote": "string (exact substring from FAILING_OUTPUT)",
  "reasoning_trace": "string (step-by-step explanation)"
}

## CONSTRAINTS
- Do not output any text outside the JSON object.
- The evidence_quote must be a verbatim substring of the FAILING_OUTPUT. If no single quote captures the evidence, use the most representative substring.
- If multiple failure modes apply, choose the most specific or root-cause mode.
- If the failure does not match any taxonomy entry, set failure_mode to "unclassified" and explain why in the reasoning_trace.

To adapt this template, replace the placeholders with data from your evaluation pipeline. [INPUT] should contain the original user query or task. [SYSTEM_PROMPT] should contain the full system instructions given to the model under test. [FAILING_OUTPUT] is the raw, unedited output that your primary evaluator or a human reviewer flagged as incorrect. [FAILURE_TAXONOMY] is a critical customization point: provide a newline-separated list or JSON array of your organization's specific failure categories, such as hallucination, refusal, format_error, reasoning_break, tool_call_error, or context_contamination. The quality of classification depends heavily on a well-defined, mutually exclusive taxonomy. Before deploying, run this prompt against a golden set of 50–100 known failures with human-verified labels to calibrate confidence thresholds and identify taxonomy gaps. In high-stakes domains, route classifications with confidence below 0.85 to a human review queue.

The LLM Judge Failure Mode Classification Prompt Template is designed to be called programmatically after a primary evaluation judge has flagged an output as a failure. It should not be used as a standalone classifier on raw outputs without a prior failure signal, because running detailed root-cause analysis on every response wastes tokens and latency. The typical integration pattern is: (1) a primary pass/fail or scoring judge evaluates the model output, (2) outputs scoring below a threshold or flagged as FAIL are routed to this classification prompt, and (3) the structured classification result is written to an observability store for aggregation and alerting.

Wire the prompt into your pipeline with a retry wrapper that handles malformed JSON, missing required fields, or confidence scores below a minimum threshold (e.g., confidence < 0.7). On parse failure, retry once with the raw model response and a repair instruction appended: The previous output was not valid JSON matching the required schema. Return ONLY the corrected JSON object. If the retry also fails, log the raw output and escalate for human review. For high-throughput pipelines, implement a circuit breaker that stops calling the classification judge if the error rate exceeds 10% over a rolling window, preventing cascading failures from a judge model degradation.

Model choice matters here. Use a model with strong instruction-following and structured output capabilities—GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro are appropriate defaults. Avoid smaller or older models (GPT-3.5, Claude Haiku) for this task because the classification taxonomy requires nuanced distinction between categories like reasoning_break and hallucination. If you must use a smaller model for cost reasons, reduce the taxonomy to 3-4 coarse categories and increase the confidence threshold for auto-acceptance. Always log the full prompt payload, model response, parse result, and any retry attempts to your observability platform. This trace data is essential for debugging classification drift and for building eval datasets that measure whether your judge is correctly attributing failures over time.

Before deploying to production, run this prompt against a seeded failure dataset where you've injected known failure modes (e.g., deliberately truncated context to trigger context_loss, inserted fabricated claims to trigger hallucination, removed required fields to trigger format_error). Measure precision and recall per failure category. If the judge consistently confuses refusal with safety_overblock, refine the category definitions in the prompt's taxonomy section. Wire these seeded tests into your CI/CD pipeline as a regression gate: any prompt change that degrades classification accuracy on known failures should block deployment until the taxonomy or instructions are corrected.