Output Repair Prompt for Malformed JSON

This prompt is a production recovery tool for AI engineers whose structured output pipelines have already failed. It is designed for a single, narrow job: taking a malformed, truncated, or structurally invalid JSON string and repairing it into a valid, schema-compliant payload without data loss. The ideal user is a backend engineer or platform developer who has already implemented a primary generation step with schema instructions, received a 4xx or 5xx error from a downstream parser, and needs a targeted repair step before falling back to a human operator or discarding the response. You should use this prompt when the cost of failure is high—such as in payment processing, user-facing API responses, or data ingestion pipelines—and when the original model output contains recoverable data that is too valuable to discard.

This prompt is not a substitute for proper schema-first prompting, structured output modes, or function-calling APIs. Do not use it as your primary generation strategy. It is a safety net, not a foundation. The prompt assumes you have already captured the raw, broken output and the exact validation error or structural defect. It works best when the damage is syntactic (unescaped quotes, trailing commas, missing brackets) or structural (truncation, incorrect nesting) rather than semantic (the model generated the wrong keys or invented fields). If the model hallucinated entirely incorrect data, no repair prompt will recover it—escalate to a full retry or human review instead. For high-risk domains such as finance, healthcare, or legal, always log the original broken output and the repaired version, and require human review before the repaired payload is acted upon.

Before wiring this into your application, define clear circuit-breaker conditions. If the repair prompt itself fails validation after a single attempt, stop retrying and escalate. Do not loop repair attempts indefinitely—each cycle risks compounding errors. Pair this prompt with a strict JSON schema validator in your application layer, and only pass the repaired output downstream if it passes validation. For additional safety, compare the key set of the repaired output against the expected schema to detect dropped or invented fields. The next section provides the copy-ready prompt template you can adapt to your specific schema and error-handling workflow.

This prompt template is designed to be used inside a repair loop: when your application's JSON parser rejects a model output, you feed the invalid string and the parser's error message back to the model with a strict instruction to return only a corrected, valid JSON object. The template uses square-bracket placeholders so you can wire it directly into your production retry or post-processing pipeline without modification.

textCopy
You are a JSON repair agent. Your only job is to fix malformed JSON.

You will receive:
- A malformed JSON string inside <MALFORMED_JSON> tags.
- A parser error message inside <ERROR_MESSAGE> tags.
- An expected JSON schema inside <EXPECTED_SCHEMA> tags.

Rules:
1. Return ONLY the corrected JSON object. No markdown fences, no commentary, no explanation.
2. Preserve all data values from the original malformed JSON. Do not invent, drop, or summarize fields.
3. If a value is truncated, mark it with a [TRUNCATED] placeholder and set a "_repair_note" field to "truncated_value".
4. If a string is unescaped, escape it properly using valid JSON escape sequences.
5. If the structure is missing closing brackets or braces, infer the correct nesting from the schema and remaining content.
6. If the malformed JSON is unrecoverable, return a valid JSON object with a single field "_repair_error" set to "unrecoverable" and include the original error in "_original_error".
7. Do not add fields that are not in the expected schema unless they are repair metadata fields prefixed with "_repair_".

<MALFORMED_JSON>
[MALFORMED_JSON_STRING]
</MALFORMED_JSON>

<ERROR_MESSAGE>
[PARSER_ERROR_MESSAGE]
</ERROR_MESSAGE>

<EXPECTED_SCHEMA>
[EXPECTED_JSON_SCHEMA]
</EXPECTED_SCHEMA>

To adapt this template, replace the three placeholders with live data from your application: [MALFORMED_JSON_STRING] should contain the raw model output that failed parsing, [PARSER_ERROR_MESSAGE] should contain the exact exception or error text from your JSON parser (e.g., json.JSONDecodeError: Expecting ',' delimiter: line 14 column 23), and [EXPECTED_JSON_SCHEMA] should contain a JSON Schema definition or a representative example of the target structure. For high-risk workflows where data fidelity is critical—such as financial transaction repair or clinical data extraction—always log both the original malformed output and the repaired version, and route outputs containing _repair_note or _repair_error fields to a human review queue before ingestion.

The Output Repair Prompt for Malformed JSON is designed to sit inside a post-generation repair loop, not as a standalone prompt. After your primary generation model produces a response, your application should attempt to parse it. If parsing fails with a specific error (truncation, unescaped characters, trailing commas, or structural breaks), capture the raw output and the exact parse error, then invoke this repair prompt. The repair prompt should be treated as a stateless utility function: it receives the broken payload and the error, and it returns either a valid JSON object or a structured failure signal. Do not use this prompt for initial generation; it is a recovery mechanism, not a primary output strategy.

Implement the harness with three layers of defense. First, validate the primary output against your expected schema using a strict JSON parser (such as json.loads in Python or JSON.parse in Node.js). If validation fails, extract the error type and line number. Second, construct the repair call by injecting the raw broken string into the [MALFORMED_JSON] placeholder and the specific error message into [PARSE_ERROR]. Use a faster, cheaper model for the repair step (such as GPT-4o-mini or Claude Haiku) since repair is a constrained task that rarely requires full reasoning capacity. Third, validate the repaired output against the same schema. If it still fails, log the original payload, the repair attempt, and the failure reason, then escalate to a structured error response that your application can handle gracefully—never return raw broken JSON to downstream consumers.

Add observability and circuit breakers around the repair loop. Log every repair invocation with the original error type, the model used, latency, and whether repair succeeded. Track the repair success rate by error category (truncation vs. unescaped characters vs. structural breaks) to identify whether the primary generation prompt needs improvement. Implement a maximum retry limit (typically 1-2 repair attempts) to prevent infinite loops. If the repair model itself returns malformed output, do not recurse—fail immediately and return a predefined error payload. For high-throughput systems, consider caching repair results for identical broken patterns, but be cautious: structurally similar breaks may contain different data. Finally, if the repaired JSON passes schema validation but contains semantic errors (wrong field types, missing required fields, hallucinated values), route it to a separate validation layer that checks business rules before the payload enters your data pipeline.