Self-Correction Loop Prompt for Structured Output

This prompt is for platform architects and AI reliability engineers who need to build an automated, multi-pass repair loop for structured outputs. The core job-to-be-done is turning a malformed model response (JSON, XML, YAML, or typed objects) into a valid, schema-conformant payload without losing semantic content. The ideal user is someone integrating LLM outputs into a production API pipeline where downstream parsers are strict and manual repair is not an option. You should use this prompt when a single retry is insufficient, and you need a controlled loop that feeds escalating validation errors back to the model until the output is clean or a retry budget is exhausted.

Before using this prompt, you must have three concrete inputs: the original model response that failed validation, the exact validation error messages from your parser (e.g., Ajv, Pydantic, Xerces), and the target schema or interface definition. The prompt is designed to be called iteratively within an application harness, not as a one-shot fix. Each iteration appends the previous failure context, instructing the model to fix only the identified issues while preserving all valid fields. This constraint is critical—without it, the model may rewrite the entire payload and introduce new errors. You should not use this prompt when the output is semantically nonsensical or when the failure is due to a fundamental misunderstanding of the task rather than a formatting error; in those cases, escalate to a human reviewer or restart with a clarified original prompt.

The prompt is most effective when paired with a strict retry budget (typically 3-5 attempts) and an escalation threshold. After each failed repair, the harness should check if the error count is decreasing. If errors are not converging, or if the repair introduces semantic drift (e.g., changing a date or a name to 'fix' a format), the loop should break and escalate. This prompt is not a substitute for robust initial schema prompting; it is a safety net for production systems where even well-prompted models occasionally produce malformed output under load, with long contexts, or when using smaller models. Wire this into your inference pipeline after your primary validation step, and always log each repair attempt for observability and debugging.

This template implements a controlled self-correction loop for structured output. It is designed to be called repeatedly by an application harness, not by an end user. On each pass, the prompt receives the original task, the previously failed output, and the specific validation errors that caused rejection. The model is instructed to fix only the identified issues while preserving all other content, and to stop and escalate if the output becomes unrepairable. The application layer controls the loop count; the prompt itself defines the repair discipline and the escalation condition.

textCopy
You are a structured output repair agent operating inside an automated correction loop.

Your task is to produce a valid output that satisfies the original request and the output schema. You have previously produced an output that failed validation. You will now receive the original request, the failed output, and a list of specific validation errors. Your job is to correct ONLY the identified errors and return a complete, valid output.

## ORIGINAL REQUEST
[ORIGINAL_PROMPT]

## OUTPUT SCHEMA
[OUTPUT_SCHEMA]

## PREVIOUS FAILED OUTPUT
[FAILED_OUTPUT]

## VALIDATION ERRORS
[VALIDATION_ERRORS]

## REPAIR ATTEMPT
This is repair attempt [ATTEMPT_NUMBER] of [MAX_ATTEMPTS].

## CONSTRAINTS
- Fix ONLY the fields and structures identified in the validation errors.
- Do not alter any other content, values, or structure.
- If a required field is missing and no context exists to infer a safe value, 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 based on semantic similarity. If no safe mapping exists, use null and add a repair note.
- If a data type is wrong, coerce it to the correct type where the conversion is lossless. If coercion would lose information, use null and add a repair note.
- If the output is truncated, close all open brackets, tags, or structures. Flag any unrecoverable fields with a repair note.
- If the errors cannot be repaired without guessing or fabricating data, set a top-level "repairable" field to false and explain why in "escalation_reason".

## REQUIRED OUTPUT FORMAT
Return a JSON object with exactly these top-level keys:
{
  "repairable": true or false,
  "repair_notes": ["string"],
  "output": { ... }
}

If repairable is false, "output" must be null.
If repairable is true, "output" must contain the fully corrected payload conforming to the OUTPUT SCHEMA.

To adapt this template, replace the square-bracket placeholders with values from your application context. [ORIGINAL_PROMPT] should contain the full user request and any initial instructions. [OUTPUT_SCHEMA] should be the complete JSON Schema, TypeScript interface, or a plain-text description of required fields, types, and constraints. [FAILED_OUTPUT] is the raw string the model produced on the previous attempt. [VALIDATION_ERRORS] should be the structured or raw error messages from your validator, formatted so the model can map each error to a specific field and failure reason. [ATTEMPT_NUMBER] and [MAX_ATTEMPTS] let the model adjust its repair strategy as the budget shrinks. The application harness must parse the repairable flag and either use the corrected output or route to the escalation path defined in your Escalation Threshold Prompt.

The self-correction loop prompt is not a standalone artifact; it is the core instruction set inside a retry harness that your application code orchestrates. The harness is responsible for calling the model, validating the structured output against a schema, collecting error details, and deciding whether to retry, salvage partial results, or escalate to a human. The prompt itself should be treated as a parameterized template that receives the original task, the failed output, and a structured error report on each iteration. Do not rely on the model to track its own retry count or decide when to stop—that logic belongs in the application layer to prevent infinite loops and unbounded costs.

A robust implementation follows a tight loop: (1) Send the initial prompt with the task, output schema, and constraints. (2) Parse the response and validate it against the expected schema using a library like Ajv (JSON), Pydantic (Python), or Xerces (XML). (3) If validation passes, return the output. If it fails, increment a retry counter and check against the retry budget. (4) Construct a retry payload containing the original task, the failed output, and a machine-readable error report mapping each failure to a specific field and violation type. (5) Feed this payload into the self-correction prompt template and go back to step 2. The retry budget should be small—typically 2 to 4 attempts—because beyond that, the model is unlikely to converge, and the risk of semantic drift or hallucinated fixes increases sharply.

Logging and observability are critical at every stage. Record each attempt's raw output, validation errors, repair actions taken, and the final outcome (success, partial salvage, or escalation). This trace data enables debugging of brittle prompts, identification of recurring schema violations that may indicate a poorly specified output contract, and cost attribution for retry overhead. For high-risk domains such as healthcare, finance, or legal workflows, insert a human review gate after any repair that modifies a field value rather than just reformatting it. A repair that changes a patient's medication name or a contract's liability clause must never be accepted silently. The harness should flag such modifications and route them to a review queue with the original and repaired values side by side.

Model choice matters for this pattern. Models with strong instruction-following and structured output capabilities (such as GPT-4o, Claude 3.5 Sonnet, or fine-tuned variants) will converge faster and require fewer retries. Weaker or smaller models may struggle to isolate the specific field that failed and instead regenerate the entire output, risking new errors. If you must use a smaller model, consider narrowing the repair scope by sending only the failed field's context rather than the full output. Finally, never wire this loop into a synchronous user-facing request path without a timeout. A stalled retry loop will block the user. Instead, return a partial result or an escalation message after the budget is exhausted, and process further repair attempts asynchronously if needed.