Retry with Error Context Prompt Template

This prompt template is for AI engineers and platform developers who need to recover from structured output failures in production pipelines. Use it when a model response has been rejected by a downstream validator, parser, or schema check, and you need to request a targeted correction without regenerating the entire response from scratch. The template wraps the original task instructions, the failed output, and the specific validation errors into a single retry request. It instructs the model to fix only the identified issues while preserving all other content unchanged. This approach is essential for self-correction loops, agent harnesses, and any inference pipeline where retries must be precise, cost-effective, and auditable.

The ideal user has already built a validation layer that produces structured error messages—such as JSON Schema violations, Pydantic ValidationError objects, or custom field-level checks—and needs a reliable way to feed those errors back to the model. The prompt works best when the failure is structural rather than semantic: a missing required field, a type mismatch, an enum violation, or malformed syntax. It is less effective when the model fundamentally misunderstood the task, when the output is factually wrong, or when the error context is so large that it consumes most of the remaining context window. In those cases, consider escalating to a human reviewer or regenerating from scratch with a clarified prompt.

Do not use this prompt when the original task was fundamentally misunderstood by the model, when the output is semantically wrong rather than structurally invalid, or when the error context is too large to fit within the remaining context window. Before wiring this into production, ensure your validation layer produces deterministic, parseable error messages that map to specific fields or positions. Pair this prompt with a retry budget and an escalation threshold—typically 2–3 repair attempts before falling back to a human review queue or a more expensive model. Log every retry attempt, the error context, and the final outcome for auditability and prompt debugging.

This template is designed to be appended as a follow-up message in a conversation thread that already contains the original task and failed response, or sent as a standalone retry request with all context included. It instructs the model to fix only the identified issues while preserving all other content unchanged. Before using, ensure you have captured the raw validation error messages from your schema validator, as these provide the precise fix instructions the model needs.

textCopy
You are a structured output repair assistant. Your task is to correct a failed model response so that it passes validation. You will receive the original task, the failed output, and a list of validation errors. Fix ONLY the errors described. Do not change any content that is not flagged by the errors. Preserve all valid fields, values, and structure exactly as they appear in the failed output.

## ORIGINAL TASK
[ORIGINAL_TASK]

## FAILED OUTPUT
[FAILED_OUTPUT]

## VALIDATION ERRORS
[VALIDATION_ERRORS]

## OUTPUT SCHEMA
[OUTPUT_SCHEMA]

## CONSTRAINTS
- Fix only the errors listed in VALIDATION ERRORS.
- Do not alter any field, value, or structure that is not explicitly flagged.
- If a required field is missing and no plausible value can be inferred from context, insert an explicit null and add a "repair_note" field explaining the missing data.
- If an enum value is invalid, map it to the closest valid enum member. If no safe mapping exists, use null and add a repair note.
- If a data type is wrong, coerce it to the correct type only when the conversion is lossless. Otherwise, use null and add a repair note.
- Return ONLY the corrected output in the exact format specified by OUTPUT SCHEMA. Do not include explanations, apologies, or markdown fences.
- If the output cannot be repaired with high confidence, return a JSON object with a single field "repair_failure": true and a "reason" string.

To adapt this template, replace each square-bracket placeholder with actual values from your pipeline. [ORIGINAL_TASK] should contain the full prompt or instruction that produced the failed output. [FAILED_OUTPUT] is the raw, unmodified model response that failed validation. [VALIDATION_ERRORS] should be the raw error messages from your validator, such as Ajv, Pydantic, or Xerces output. [OUTPUT_SCHEMA] should describe the expected format, ideally as a JSON Schema, TypeScript interface, or clear field specification. In high-risk domains such as healthcare, finance, or legal, always route repaired outputs through human review before they reach downstream systems, and log both the original failure and the repair actions for auditability.

The Retry with Error Context Prompt Template is not a standalone fix; it is a component inside a larger repair harness. The harness is responsible for catching validation failures, constructing the retry request, enforcing a retry budget, and deciding when to escalate. Without this surrounding logic, the prompt will retry indefinitely on unrepairable outputs, waste tokens on semantic drift, or silently accept a corrected output that introduced new errors. The harness must treat each retry as a stateful attempt: capture the original input, the failed output, the structured error list, and the model's corrected response for every cycle.

Start by wiring the prompt into a retry loop that parses raw validator output into a structured error list before injection. For JSON outputs, use a schema validator such as Ajv or Pydantic; capture each error's instance path, message, and expected vs. received value. Map these into a concise, line-by-line error block inside the [VALIDATION_ERRORS] placeholder. Set a maximum retry budget of 2 to 3 attempts. On each attempt, log the attempt number, the error context sent to the model, the full corrected response, and the result of re-validation. If the corrected output passes validation, break the loop and return it with a repair confidence flag. If the model introduces new errors or drifts semantically—detected by comparing field-level changes against the original failed output—increment a drift counter. If the drift counter exceeds 1, escalate immediately rather than consuming another retry attempt.

After the final failed attempt, route to a fallback path. Common fallbacks include: enqueueing the request for human review with the full attempt log attached; calling a simpler, faster model with a narrower repair task limited to a single error type; or returning a static default response with a degraded-service flag. For high-throughput pipelines, add a repair confidence check before accepting any corrected output. A lightweight evaluator prompt can score whether the repair preserved the original semantic intent without introducing hallucinated values. If the confidence score falls below a threshold—typically 0.85—escalate even if the output is technically valid. In agent frameworks, wrap this entire harness as a tool or sub-agent that receives the failed output and validator errors, executes the retry loop internally, and returns either a corrected payload or an escalation signal to the main execution loop. This keeps the agent's primary reasoning path clean while isolating repair complexity.