Retry Budget for Structured Output Repair Prompt

This prompt is for backend developers and integration engineers who need to enforce a strict limit on the number of times an LLM can attempt to repair a malformed structured output (JSON, XML, YAML) before the system escalates to a fallback parser or a human review queue. The job-to-be-done is not just to fix the output, but to do so within a defined compute and latency budget, preventing infinite repair loops that degrade system reliability and waste resources. The ideal user is someone wiring LLM outputs into typed application code, where a downstream JSON.parse() or schema validator will reject invalid payloads, and where every repair attempt has a measurable cost.

You should use this prompt when you have a primary output generation step that has already failed validation and you are entering a repair loop. The prompt requires the original malformed output, the target schema, the specific validation errors, and a pre-configured retry budget as inputs. It is designed to be called programmatically within a retry harness that tracks the attempt count. The prompt instructs the model to act as a strict repair agent: it must correct only the schema violations without altering the semantic content, and it must refuse to generate a response if the budget is exhausted. This is not a general-purpose debugging prompt; it is a production circuit breaker.

Do not use this prompt for initial output generation, for repairing factual or semantic errors, or for tasks where the output format is loosely defined. It is also inappropriate when a single repair attempt is guaranteed to succeed or when the cost of escalation is higher than the cost of many retries. Before implementing, ensure your application harness can parse the model's refusal signal when the budget is exhausted and route the original input and error context to your designated fallback or human-in-the-loop system. The next step is to integrate this prompt into a validation-and-retry loop, covered in the Implementation Harness section.

The following prompt template is designed to be inserted into a repair loop within your application harness. It receives the original malformed output, the validation errors, and a running count of prior repair attempts. Its job is to produce a corrected output that conforms to the target schema or to signal that the retry budget has been exhausted and escalation is required. The prompt uses square-bracket placeholders for all dynamic inputs, making it straightforward to wire into any typed system that consumes structured model outputs.

textCopy
You are a structured output repair agent operating under a strict retry budget.

## Inputs
- Original malformed output: [MALFORMED_OUTPUT]
- Target schema (JSON Schema): [OUTPUT_SCHEMA]
- Validation errors from the last attempt: [VALIDATION_ERRORS]
- Repair attempt count so far: [ATTEMPT_COUNT]
- Maximum allowed repair attempts: [MAX_ATTEMPTS]
- Fallback action when budget is exhausted: [FALLBACK_ACTION]

## Task
1. If [ATTEMPT_COUNT] is greater than or equal to [MAX_ATTEMPTS], do NOT attempt another repair. Instead, output a structured escalation payload with the key "escalation" containing:
   - "reason": "Retry budget exhausted after [ATTEMPT_COUNT] attempts."
   - "original_output": [MALFORMED_OUTPUT]
   - "last_errors": [VALIDATION_ERRORS]
   - "fallback_action": [FALLBACK_ACTION]
   - "attempt_history": [ATTEMPT_HISTORY]
2. If [ATTEMPT_COUNT] is less than [MAX_ATTEMPTS], analyze [VALIDATION_ERRORS] and produce a corrected output that strictly conforms to [OUTPUT_SCHEMA]. Preserve all semantic content from [MALFORMED_OUTPUT] while fixing structural issues. Do not add new information.
3. If the validation errors indicate an unrecoverable structural problem (e.g., missing required fields with no inferable values, contradictory constraints), escalate immediately regardless of the attempt count. Set "reason" to "Unrecoverable validation error detected."

## Output Format
Return ONLY a valid JSON object. If repairing, use the key "repaired_output". If escalating, use the key "escalation". Do not include both keys.

To adapt this template for your system, replace each square-bracket placeholder with the corresponding runtime value. [MALFORMED_OUTPUT] should contain the raw model response that failed validation. [OUTPUT_SCHEMA] should be the JSON Schema definition the output must satisfy. [VALIDATION_ERRORS] should be a human-readable or structured list of the specific schema violations detected. [ATTEMPT_COUNT] and [MAX_ATTEMPTS] are integers tracked by your harness. [FALLBACK_ACTION] describes what happens after escalation—such as routing to a human reviewer, invoking a deterministic parser, or returning a safe default. [ATTEMPT_HISTORY] should be a serialized log of prior repair attempts and their outcomes, enabling downstream consumers to understand the full recovery path. For high-risk domains, ensure that the escalation payload includes enough context for a human reviewer to make an informed decision without re-executing the entire workflow.

The retry budget prompt is not a standalone artifact—it is a decision node inside a repair loop. Your application harness must call the model, parse its structured output, and enforce the budget constraints declared in the prompt. The harness owns the counter, the escalation path, and the final decision to stop retrying. The prompt's job is to produce a consistent, machine-readable verdict given the current attempt count, error context, and budget rules. Do not rely on the model to remember how many attempts have already occurred; pass the attempt number and remaining budget as explicit input variables every time.

Implement the harness as a loop with a hard ceiling. Before each call, inject [CURRENT_ATTEMPT], [MAX_ATTEMPTS], [ERROR_HISTORY], and [ORIGINAL_INPUT] into the prompt template. After each response, validate the output schema—expect a JSON object with at minimum a decision field (retry or escalate) and a rationale string. If the model returns retry, use the accompanying repair_instructions field to construct the next repair attempt. If it returns escalate, break the loop and route the escalation_payload to your fallback parser, dead-letter queue, or human review interface. Always increment a local counter and compare against [MAX_ATTEMPTS] before making the next call; never trust the model to enforce the ceiling on its own.

Validation is the primary safety net. After every model response, check that decision is exactly retry or escalate, that rationale is non-empty, and that escalation_payload is present when decision is escalate. If the output fails schema validation, treat it as a malformed response and count it against the retry budget—do not silently retry without decrementing the remaining attempts. Log every attempt with a trace ID, the model's raw output, the parsed decision, and the harness action taken. This trace becomes the audit evidence for why a request was escalated and is essential for tuning the budget thresholds later. For high-risk domains, insert a human approval step before executing any action derived from a repaired output, even if the budget was not exhausted.

Model choice matters. Use a model that reliably produces structured JSON and follows explicit constraints—GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro are strong defaults. Avoid models with weak instruction-following for this control-plane task; a model that ignores the budget and always says retry will create the infinite loop you are trying to prevent. Set temperature to 0 or near-zero to maximize deterministic budget enforcement. If you are routing across models, pin this prompt to a capable, low-temperature configuration and do not let a weaker model make escalation decisions. Wire the harness to emit a retry_budget_exhausted metric so your observability stack can alert on spikes in escalation rates, which often signal upstream schema changes or model regressions.