Self-Correction Ineffectiveness Root Cause Prompt Template

This prompt is a diagnostic tool for AI platform and evaluation teams who have implemented retry-with-feedback loops and need to understand why self-correction failed to resolve an error. It analyzes three artifacts from a failed correction cycle: the initial incorrect output, the correction instruction sent back to the model, and the still-incorrect corrected output. The prompt attributes the ineffectiveness to one or more root causes—an insufficient error signal that didn't give the model enough information to localize the mistake, a repeated mistake pattern the model cannot break despite clear feedback, or a correction instruction that was too weak, ambiguous, or misdirected. Use this prompt when your retry loop is burning tokens without improving quality and you need to decide whether to rewrite the correction prompt, adjust the retry strategy, or escalate to a human.

This is not a prompt for generating corrected outputs. It is a diagnostic instrument for debugging the correction mechanism itself. The ideal user is an engineer or evaluation lead who already has logs of failed correction attempts and needs a structured root cause analysis before making changes. Required context includes the full initial output, the exact correction instruction sent, and the full corrected output. The prompt works best when the failure is reproducible or well-documented—single anomalous failures may not provide enough signal for reliable attribution. Do not use this prompt when you need a corrected output, when the error is trivial and the fix is obvious, or when you haven't yet implemented a retry loop to diagnose.

After running this prompt, you'll receive a structured root cause classification with evidence pointers and a recommended action. Wire the output into your observability stack so that correction loop failures are automatically categorized and routed: insufficient error signals should trigger correction prompt rewrites, repeated mistake patterns may indicate a need for few-shot examples or fine-tuning, and weak correction instructions should be strengthened with specific constraints. For high-stakes domains where correction failures could cause harm, always include a human review step before acting on the diagnosis. The next section provides the copy-ready prompt template you can adapt for your own retry loop debugging.

This template is designed to be copied directly into your evaluation harness, debugging notebook, or prompt management platform. It accepts a failed correction attempt—including the original error, the correction instruction, and the model's failed response—and produces a structured root cause analysis. The square-bracket placeholders represent the variables you must supply before execution. Do not ship this prompt with unresolved placeholders in production; wire it into a harness that populates [ORIGINAL_ERROR], [CORRECTION_INSTRUCTION], [FAILED_CORRECTION_OUTPUT], and [CONTEXT] from your application state or log stream.

textCopy
You are an AI debugging specialist analyzing why a self-correction loop failed to fix an error. Your job is to produce a structured root cause analysis that attributes the failure to specific, actionable causes.

## INPUT

**Original Error:** [ORIGINAL_ERROR]

**Correction Instruction Given to Model:** [CORRECTION_INSTRUCTION]

**Model's Failed Correction Output:** [FAILED_CORRECTION_OUTPUT]

**Additional Context (optional):** [CONTEXT]

## TASK

Analyze the failed correction attempt and classify the root cause into one or more of the following categories. For each category that applies, provide specific evidence from the input and explain why it contributed to the failure.

### Root Cause Categories

1. **Insufficient Error Signal:** The correction instruction did not clearly identify what was wrong with the original output. The model lacked enough information to understand the failure mode.
2. **Repeated Mistake Pattern:** The model produced a correction that repeats the same error class as the original output, indicating a capability gap or persistent misunderstanding rather than a one-off slip.
3. **Correction Instruction Weakness:** The correction instruction was ambiguous, contradictory, or asked for something the model cannot reliably do given the context.
4. **Context Interference:** Existing context, system instructions, or prior turns contained information that conflicted with or undermined the correction instruction.
5. **Overcorrection:** The model changed behavior beyond what was requested, introducing new errors while attempting to fix the original one.
6. **Format or Constraint Collapse:** The correction attempt broke output format, schema, or explicit constraints that were previously satisfied.

## OUTPUT SCHEMA

Return a JSON object with the following structure:

```json
{
  "failure_summary": "One-sentence summary of why self-correction failed.",
  "primary_root_cause": "The single most impactful category from the list above.",
  "contributing_causes": [
    {
      "category": "Category name from list above",
      "evidence": "Specific quote or observation from the input that supports this category.",
      "explanation": "Why this evidence indicates the category applies."
    }
  ],
  "correction_loop_audit": {
    "error_signal_quality": "clear|partial|absent",
    "instruction_clarity": "specific|ambiguous|contradictory",
    "model_capability_gap_suspected": true_or_false,
    "recommended_remediation": "Concrete change to the correction instruction, context, or retry strategy."
  },
  "should_retry": true_or_false,
  "retry_strategy": "If should_retry is true, describe the specific change to make before retrying. If false, explain why further retries are unlikely to succeed."
}

CONSTRAINTS

• Base your analysis only on the provided input. Do not speculate about model internals or training data.
• If multiple root causes apply, list all contributing causes but identify the single most impactful primary cause.
• When evidence is insufficient to determine a cause, mark it as absent rather than guessing.
• The recommended remediation must be actionable: someone reading it should know exactly what to change.

Adaptation guidance: Replace each bracketed placeholder with real values from your correction loop logs. [ORIGINAL_ERROR] should contain the error message, validator output, or failure description that triggered the correction attempt. [CORRECTION_INSTRUCTION] is the exact prompt or instruction you gave the model to fix the error. [FAILED_CORRECTION_OUTPUT] is the model's response that still failed validation or review. [CONTEXT] is optional but useful for including system prompts, prior conversation turns, or retrieved documents that may have influenced the failure. If your correction loop uses structured error objects rather than natural language descriptions, serialize them into the [ORIGINAL_ERROR] field before calling this prompt.

Validation and risk notes: The output of this prompt is a diagnosis, not a fix. In high-stakes pipelines, route the should_retry and retry_strategy fields through a human reviewer or a secondary validation step before automatically re-injecting the corrected instruction into your retry loop. If the prompt returns model_capability_gap_suspected: true, stop retrying and escalate—further correction attempts will likely waste tokens and latency without improving the output. Test this prompt against a seeded dataset of known fixable and unfixable errors to calibrate its should_retry accuracy before relying on it in production.

Next steps: After copying this template, build a small eval harness that feeds it 10–20 known correction failures with ground-truth root cause labels. Measure whether the primary_root_cause field matches your labels at least 80% of the time. If accuracy is low, add few-shot examples to the prompt showing correct root cause attribution for your specific error types. Once calibrated, wire this prompt into your retry loop's observability path so every failed correction produces a structured audit record you can aggregate to identify systemic correction weaknesses.

This prompt is designed to be invoked after a self-correction cycle has failed to resolve an error. It should not be used as a standalone diagnostic for general model failures; its value is in analyzing the specific gap between a correction attempt and a successful fix. The primary integration point is inside a retry-with-feedback loop where a validator has already rejected the corrected output. The harness must capture the original error, the correction instruction sent to the model, and the model's corrected output before calling this prompt.

The implementation requires a structured input object with three mandatory fields: original_error (the validator's rejection message or error code), correction_instruction (the exact prompt sent to the model to fix the error), and corrected_output (the model's response to that instruction). Before calling the LLM, validate that all three fields are non-empty and that the corrected_output still fails the original validator. Log the validator's second failure alongside these inputs. For model choice, use a model with strong reasoning capabilities (e.g., GPT-4, Claude 3.5 Sonnet) because the task requires counterfactual analysis. Set temperature to 0 to ensure deterministic root cause attribution. The output must be parsed as JSON and validated against the expected schema: root_cause_category (enum), evidence (string), and fixability_assessment (string). If parsing fails, retry once with a stricter schema reminder; if it fails again, escalate for human review.

For production pipelines, wrap this prompt in a logging decorator that records the full input, output, and any parse failures to your observability platform. Use the root_cause_category field to increment a metric (e.g., correction_failure.insufficient_signal, correction_failure.repeated_mistake, correction_failure.weak_instruction) so you can track which failure modes dominate over time. If the fixability_assessment indicates the error is likely unfixable via prompt-based correction alone, route the case to a human review queue or trigger a fallback workflow. Do not loop this prompt back into another automatic retry; its purpose is diagnosis, not repair. The next step after receiving this analysis is to decide whether to rewrite the correction instruction, adjust the validator, or accept the failure and escalate.