Retry Budget for Validation Error Classification and Repair Prompt

This prompt is for integration engineers who need to stop validation pipelines from burning retries on errors that cannot be fixed by regeneration. The job-to-be-done is classification: given a validation error, the prompt decides whether the error is repairable, how many retries the repair budget allows, and when to escalate immediately. The ideal user is someone wiring an LLM output validator into a production harness where every retry costs tokens, latency, and compute. You should use this prompt when your pipeline already has a validator producing structured error messages and you need a policy layer that prevents infinite repair loops.

Do not use this prompt when you lack a structured validator output. The prompt expects a machine-readable error payload—if your validator only returns a pass/fail boolean or an unstructured string, you need to instrument the validator first. Do not use this prompt as a standalone repair engine; it classifies and budgets, but it does not perform the repair. The repair step is a separate prompt or code path that consumes this classification. Do not use this prompt for errors that require human judgment on first occurrence, such as safety policy violations, PII leaks, or legal compliance failures—those should escalate immediately without consuming retry budget.

Before wiring this into your harness, define your retry budget constants: maximum total retries, maximum retries per error category, and a hard escalation threshold. The prompt template includes placeholders for these values so the policy is explicit and auditable. After deployment, monitor the classification accuracy by sampling decisions and checking whether repairable errors actually improved after retries and whether unrecoverable errors were correctly escalated. A common failure mode is misclassifying a transient schema error as unrecoverable because the error message is ambiguous—plan to iterate on the classification examples as you observe production patterns.

This prompt template is the core instruction set you'll send to the model to classify a validation error and decide whether to retry or escalate. It is designed to be embedded in a retry harness that tracks attempt counts and enforces the budget. The template uses square-bracket placeholders for all variable inputs so you can wire it directly into your application code. Before using this prompt, ensure you have a defined validation error payload, a clear taxonomy of recoverable versus unrecoverable error types for your domain, and a retry budget limit configured in your harness.

textCopy
You are an error classification and repair decision agent inside a validation pipeline. Your job is to analyze a validation error, classify it, and decide whether to retry with a repair attempt or escalate immediately.

## INPUT
[VALIDATION_ERROR_PAYLOAD]

## CONTEXT
- Retry attempt: [CURRENT_ATTEMPT] of [MAX_RETRIES]
- Original model output that failed validation: [ORIGINAL_OUTPUT]
- Validation rules that were violated: [VIOLATED_RULES]
- Domain-specific error taxonomy: [ERROR_TAXONOMY]

## TASK
1. Classify the validation error into exactly one category:
   - **Recoverable**: The error can likely be fixed by regenerating with clearer instructions. Examples: malformed JSON, missing optional field, enum value mismatch, minor schema deviation.
   - **Unrecoverable**: The error cannot be fixed by retrying. Examples: fundamentally contradictory constraints, missing required source data, policy violation, input that requires human judgment.
   - **Uncertain**: The error type is ambiguous. Default to escalation after [UNCERTAINTY_THRESHOLD] uncertain classifications.

2. If Recoverable, produce a repair instruction that will be appended to the next generation request. The repair instruction must:
   - Identify the specific field or structure that failed.
   - State the expected format or constraint.
   - Preserve all valid portions of the original output.
   - Be concise enough to fit within [REPAIR_INSTRUCTION_TOKEN_BUDGET] tokens.

3. If Unrecoverable, produce an escalation payload with:
   - Error classification and justification.
   - The original output and validation error.
   - Recommended escalation path: [ESCALATION_TARGET].
   - Context for the human reviewer: what was attempted and why it cannot be repaired automatically.

## OUTPUT_SCHEMA
Return a JSON object with this exact structure:
{
  "classification": "recoverable" | "unrecoverable" | "uncertain",
  "confidence": 0.0-1.0,
  "justification": "string explaining the classification",
  "repair_instruction": "string | null — only if recoverable",
  "escalation_payload": {
    "reason": "string | null — only if unrecoverable",
    "escalation_target": "string | null",
    "reviewer_context": "string | null"
  }
}

## CONSTRAINTS
- Do not fabricate repair instructions for unrecoverable errors.
- Do not classify an error as recoverable if the same repair instruction has already failed [MAX_SAME_ERROR_RETRIES] times.
- If the error pattern matches any entry in [UNRECOVERABLE_PATTERNS], classify as unrecoverable immediately.
- Preserve the original output's semantic content; do not alter meaning during repair.

To adapt this template, replace each square-bracket placeholder with values from your application context. The [ERROR_TAXONOMY] should be a domain-specific mapping of error messages to recoverability categories—invest time here because it is the primary lever for classification accuracy. The [UNRECOVERABLE_PATTERNS] list acts as a hard override; populate it with error signatures you know cannot be fixed by regeneration, such as missing required upstream data or policy violations. Wire [CURRENT_ATTEMPT] and [MAX_RETRIES] from your harness's retry counter. The [REPAIR_INSTRUCTION_TOKEN_BUDGET] prevents repair instructions from consuming excessive context in subsequent retries. Test this prompt with a golden set of known recoverable and unrecoverable errors before deploying, and monitor the classification accuracy and escalation rate in production to tune the taxonomy and thresholds.

This prompt is designed to sit inside a validation harness, not as a standalone chat interaction. The harness calls the model after a primary output fails validation, passing the original input, the failed output, the validator error, and the current retry count. The model's job is to classify the error as repairable or unrecoverable and, if repairable, to produce a corrected output. The harness then checks the retry budget: if the error is unrecoverable or the budget is exhausted, it escalates immediately without another attempt.

To implement this, wrap the prompt in a retry loop with a hard stop. Before each call, increment a retry_count variable and inject it into the [RETRY_COUNT] placeholder. After the model responds, validate the error_classification field first. If it equals unrecoverable, break the loop and route to your escalation handler—typically a dead-letter queue, a human review interface, or a fallback model. If it equals repairable, extract the corrected_output and run it through your original validation function. On success, return the corrected output. On failure, loop again unless retry_count >= [MAX_RETRIES]. Log every attempt with the error type, classification, and retry count for observability.

The most common failure mode in production is a model that classifies every error as repairable and produces slightly different but still invalid outputs, burning the entire retry budget without progress. To guard against this, add a staleness check to your harness: compare the current corrected_output to the previous attempt. If they are identical or the validation error is unchanged after two consecutive attempts, force an unrecoverable classification and escalate. This prevents retry storms. For high-risk domains, always route unrecoverable classifications to a human review queue and never silently fall back to a degraded output.