Structured Output Repair Harness Prompt

This prompt is for engineering leads and platform architects who need a single, configurable repair harness that can be wired into any model-serving pipeline. The job-to-be-done is recovering from structured output failures—malformed JSON, schema violations, type mismatches, missing fields, or truncation—without losing the original semantic content. The ideal user is someone integrating LLM outputs into downstream parsers, APIs, or databases where invalid payloads are not an option and manual repair does not scale. You should have access to the raw model output, the expected schema or format specification, and any validator error messages before invoking this prompt.

Use this prompt when you need a unified repair interface that handles format detection, validation, retry with error context, partial salvage, and escalation in one pass. It is designed for production inference pipelines where multiple failure modes can occur and you want a single harness rather than chaining separate repair prompts. The prompt expects a structured input block containing the failed output, the target schema, raw validation errors, and configuration parameters like retry budget and escalation thresholds. It returns a structured repair result with the corrected payload, a repair confidence score, a list of actions taken, and an escalation decision when repair is not possible.

Do not use this prompt for simple single-format repair tasks where a dedicated JSON repair or enum correction prompt would be more efficient and auditable. Avoid it when the original semantic intent has been lost—if the model output is nonsensical rather than merely malformed, no repair harness can recover meaning. This prompt also should not replace proper schema-first prompting at generation time; it is a recovery tool, not a substitute for well-designed output instructions. For high-risk domains such as healthcare, finance, or legal, always route repaired outputs through human review before ingestion, regardless of the repair confidence score.

This template is the core of the Structured Output Repair Harness. It accepts a malformed payload, the original generation context, and structured validation errors, then produces a corrected output or an escalation decision. The prompt is designed to be wrapped in application-level retry logic, not used as a one-shot fix. Every placeholder is a square-bracket token that your harness must populate before sending the request to the model.

textCopy
You are a structured output repair system. Your job is to fix a malformed payload so it passes validation against a target schema. Do not change semantic content unless a field is irreparable. Do not hallucinate missing data.

## TARGET FORMAT
[OUTPUT_FORMAT]

## TARGET SCHEMA
[OUTPUT_SCHEMA]

## ORIGINAL GENERATION CONTEXT
The original prompt that produced this output was:
[ORIGINAL_PROMPT]

## MALFORMED OUTPUT

[FAILED_OUTPUT]

codeCopy

## VALIDATION ERRORS
The following errors were detected by the validator:
[VALIDATION_ERRORS]

## REPAIR CONSTRAINTS
- Fix ONLY the fields mentioned in the validation errors.
- Preserve all other fields and values exactly as they appear in the malformed output.
- If a required field is missing and cannot be inferred from context, set it to null and add it to the `missing_fields` array in the repair metadata.
- If an enum value is invalid, map it to the closest valid enum member. If no safe mapping exists, set the field to null and flag it in `coerced_fields`.
- If a data type is wrong, coerce it only when the coercion is lossless. Otherwise, set the field to null and flag it in `coercion_failures`.
- If the output is truncated, close all open brackets, tags, or rows. Flag unrecoverable fields in `truncation_loss`.
- Do not add commentary, explanations, or apologies. Return only the JSON object below.

## RETRY BUDGET
This is repair attempt [ATTEMPT_NUMBER] of [MAX_ATTEMPTS].
- If this is the final attempt, prioritize producing a valid partial output over a complete but invalid one.
- If the output cannot be repaired within the constraints, set `escalate: true` and populate `escalation_reason`.

## REQUIRED OUTPUT SCHEMA
Return a JSON object with exactly this structure:
{
  "repaired_output": <the corrected payload in [OUTPUT_FORMAT]>,
  "repair_metadata": {
    "is_valid": <boolean, true if the repaired output passes validation>,
    "fields_fixed": [<list of field paths that were changed>],
    "missing_fields": [<list of required fields that could not be recovered>],
    "coerced_fields": [<list of fields where values were coerced to a different type>],
    "coercion_failures": [<list of fields where coercion was attempted but failed>],
    "truncation_loss": [<list of fields lost due to truncation>],
    "repair_confidence": <number between 0.0 and 1.0 indicating overall confidence in the repair>,
    "escalate": <boolean, true if the output should be escalated to a human or fallback>,
    "escalation_reason": <string, required if escalate is true, otherwise null>
  }
}

Adapting the template: Replace [OUTPUT_FORMAT] with the expected format name (e.g., JSON, XML, CSV, YAML). Provide the full schema in [OUTPUT_SCHEMA]—this should be a JSON Schema, XSD, or a plain-text description of field names, types, and constraints. [ORIGINAL_PROMPT] should contain the exact prompt that produced the failed output, so the model has the semantic context needed to infer missing values. [FAILED_OUTPUT] is the raw malformed payload. [VALIDATION_ERRORS] should be the structured error output from your validator (e.g., Ajv errors, Pydantic ValidationError, or a parsed error list). [ATTEMPT_NUMBER] and [MAX_ATTEMPTS] are integers your harness increments on each retry loop iteration.

When to use this template: Use it inside a retry loop that calls your validator after each repair attempt. If is_valid is true, break the loop and use repaired_output. If escalate is true, stop retrying and route to a human queue or fallback model. If neither is true and attempts remain, feed the new repaired_output and any fresh validation errors back into the next iteration. Never exceed [MAX_ATTEMPTS] without escalation—unbounded retry loops waste compute and delay the user. For high-risk domains (healthcare, finance, legal), always require human review when repair_confidence is below 0.85 or when escalate is true.

The Structured Output Repair Harness Prompt is designed to sit between your model's raw response and your downstream parser. In production, you should never trust a model's output to be valid JSON, XML, or any structured format on the first attempt. Instead, wrap every inference call in a harness that captures the raw output, runs it through a validator, and conditionally invokes this repair prompt when validation fails. The harness prompt accepts the original prompt, the failed output, the target schema, and the specific validation errors, then returns a corrected payload along with a repair confidence score and a flag indicating whether the output is now valid or requires escalation.

A typical implementation loop works as follows: (1) Call the primary model with your original prompt and structured output instructions. (2) Parse the response and validate it against your schema using a library like Ajv for JSON, Pydantic for Python objects, or Xerces for XML. (3) If validation passes, return the output immediately. (4) If validation fails, construct a repair request by populating the [ORIGINAL_PROMPT], [FAILED_OUTPUT], [TARGET_SCHEMA], and [VALIDATION_ERRORS] placeholders in the repair prompt. (5) Send the repair prompt to the same model or a cheaper, faster model. (6) Validate the repaired output. (7) If still invalid and your retry budget remains, repeat with escalating error detail. (8) If the retry budget is exhausted or the repair confidence score falls below your threshold, escalate to a human or a fallback path. Log every attempt, the repair actions taken, and the final disposition for observability.

When wiring this into your application, set explicit retry limits—typically 2 to 3 repair attempts—and a minimum repair confidence threshold, such as 0.7, below which you escalate rather than risk downstream corruption. For high-risk domains like finance or healthcare, require human review on any repaired output, not just on final escalation. Use a separate, lower-cost model for repair attempts when possible to control latency and cost. Always log the original failed output, each repair attempt, the validator error messages, and the final repaired payload. This trace data is essential for debugging prompt drift, identifying schema ambiguities, and tuning your retry budget over time. Avoid the temptation to silently accept repaired outputs without validation—every repair must pass the same schema check as the original response.