JSON Structure Repair Prompt Template

Use this prompt when a model returns a string that looks like JSON but fails to parse. This is a post-generation repair step, not a replacement for structured output prompting. It targets syntax-level defects: unclosed brackets, trailing commas, single-quoted strings, unquoted keys, and comment artifacts. It does not fix semantic schema violations such as missing required fields or incorrect types. Integration engineers and platform developers wire this into a retry loop after a JSON.parse failure, before the payload reaches a downstream API, database, or event bus.

The ideal user is an engineer who already has a target schema and a validator in place. The model output failed structural parsing, but the content is approximately correct. This prompt is the first repair attempt in a retry chain. If it succeeds, the repaired JSON proceeds to schema validation. If it fails, the system escalates to more expensive repair strategies—such as field-level correction prompts or human review. Do not use this prompt when the output is semantically wrong, when the model refuses to answer, or when the failure is a token limit truncation rather than a syntax error. Those failures require different repair playbooks.

Before invoking this prompt, log the raw model output and the parse error message. These artifacts are essential for debugging and for evaluating whether the repair prompt is improving over time. Wire the prompt into a controlled retry loop with a maximum of two repair attempts. If both attempts fail, route the payload to a dead-letter queue for offline analysis. Never silently discard malformed JSON—every repair attempt should produce an audit record that includes the original output, the repair prompt version, the repaired output, and the final parse result. This discipline prevents silent data corruption and makes repair quality measurable across model versions.

This template is the core repair instruction you paste into your application's retry or post-processing step after a JSON parse failure. It is designed to be self-contained: provide the broken JSON string and the expected structural constraints, and the prompt instructs the model to return only the repaired, valid JSON. The placeholders let you adapt it to different schemas, failure modes, and risk tolerances without rewriting the core logic.

textCopy
You are a JSON repair system. Your only job is to fix structural errors in malformed JSON and return valid, parseable JSON.

## Input
Below is a JSON string that failed to parse. It may contain unclosed brackets, trailing commas, unquoted keys, single-quoted strings, or other structural errors.

[INPUT]

## Expected Output Schema
Repair the JSON so it conforms to this schema:
[OUTPUT_SCHEMA]

## Constraints
- Return ONLY the repaired JSON. No markdown fences, no explanations, no commentary.
- Preserve all original field values unless they are structurally invalid and cannot be recovered.
- If a required field from the schema is missing and cannot be inferred, insert a null value for that field.
- Do not add fields that are not in the schema.
- Use double quotes for all keys and string values.
- Ensure all brackets and braces are balanced.
- Remove trailing commas.

## Examples
[EXAMPLES]

## Risk Level
[RISK_LEVEL]

To adapt this template, replace each square-bracket placeholder with concrete values for your use case. [INPUT] receives the raw, broken JSON string. [OUTPUT_SCHEMA] should contain a JSON Schema definition, a TypeScript interface, or a plain-text description of required fields and types. [EXAMPLES] is optional but recommended: provide 1-3 pairs of broken-input and repaired-output examples to ground the model's behavior. [RISK_LEVEL] controls the repair aggressiveness. For low-risk data pipelines, instruct the model to infer missing values. For high-risk financial or healthcare records, instruct it to preserve only verifiable fields and nullify anything uncertain. After pasting the completed prompt, always validate the model's output with a JSON parser and a schema validator before allowing the repaired payload to proceed downstream.

The JSON Structure Repair prompt is designed to sit inside a post-generation repair loop, not as a standalone utility. After your primary model generates a response that fails JSON.parse(), this prompt becomes the first recovery step before escalating to a human or discarding the output. The harness should catch the parse error, extract the raw malformed string, and pass it to the repair prompt with the original expected schema as context. This keeps the repair scope narrow—fixing syntax, not reinterpreting semantics.

Wire the prompt into a retry pipeline with a strict upper bound. A common pattern: attempt JSON.parse() on the raw output; on failure, call the repair prompt once. If the repaired output still fails validation, attempt a second repair pass with the specific parse error message injected into [CONSTRAINTS]. After two repair attempts, log the failure, capture the malformed string and error trace, and either return a structured error to the caller or escalate for human review. Never loop indefinitely—malformed JSON can indicate a deeper model failure that syntax repair cannot fix. For high-throughput systems, add a circuit breaker that stops repair attempts if the failure rate exceeds a threshold within a time window.

Validation must happen in application code, not in the prompt. After the repair prompt returns, run JSON.parse() and then validate against the expected schema using a library like Ajv (JSON Schema), Zod, or Pydantic. Check for: structural validity (parse success), required field presence, correct types, and no extra hallucinated fields. Log the repair_attempt_count, parse_success, schema_valid, and fields_preserved_rate as metrics. For observability, attach the original malformed string, the repaired output, and the validation errors to your trace. This data is essential for detecting whether the repair prompt itself is drifting or whether the upstream model's JSON generation quality is degrading. If your application handles PII or regulated data, ensure the repair prompt runs in the same data boundary as the primary model and that malformed outputs are never logged to unsecured storage.

Model choice matters for repair reliability. Smaller or faster models often struggle with structural repair tasks because they require precise bracket matching and escape character handling. Prefer a capable model with strong code-generation or structured-output performance for the repair step, even if your primary generation uses a smaller model for cost reasons. If latency is critical, consider running the repair prompt in parallel with a second generation attempt from the primary model and taking the first valid result. For streaming applications, buffer the complete response before attempting repair—partial JSON repair is significantly more error-prone and should be handled by a separate continuation or reassembly prompt instead.