Truncated JSON Completion Repair Prompt Template

This prompt is for backend and platform engineers who need to recover API payloads, configuration blocks, or structured data records that were cut off by token limits, streaming interruptions, or model early-stopping. The job-to-be-done is straightforward: take a partial, unparseable JSON string and produce a structurally valid, parseable JSON output that preserves every piece of the original partial data without inventing new content. The ideal user is someone integrating LLM outputs into a production pipeline where downstream consumers—databases, API gateways, configuration parsers—will reject malformed JSON outright. You already have a partial payload in hand, you know the expected schema or at least the intended structure, and you need a repair that can be automated without manual intervention.

This prompt is designed for scenarios where the model output is almost complete but missing closing braces, brackets, or the final characters of a string value. It works best when you can provide the truncated output alongside the original task context or schema description so the model understands what it's repairing. You should not use this prompt when the truncation is so severe that the majority of the structure is missing—at that point, you're better off re-requesting the full generation with a higher token limit or using a continuation prompt instead. Similarly, avoid this prompt when the partial output contains hallucinated fields or values that need removal; this is a structural repair tool, not a factuality filter. For high-risk domains where the repaired JSON will trigger financial transactions, clinical actions, or legal commitments, always route the repaired output through a human review step and schema validation before it reaches any execution path.

Before wiring this into production, define clear failure boundaries. If the repair attempt produces JSON that still fails to parse after one retry, log the failure, capture the original truncated payload, and escalate rather than looping indefinitely. Pair this prompt with a JSON schema validator in your harness to catch field-level errors that structural repair alone won't fix. The next step after reading this section is to copy the prompt template, adapt the placeholders to your payload shape, and run it against a set of deliberately truncated test cases to establish your baseline repair success rate.

This prompt template is the core instruction you send to a language model when a JSON payload has been cut off by token limits, streaming interruptions, or early stopping. It is designed to be copied directly into your repair harness, with placeholders that your application code populates at runtime. The template instructs the model to act as a strict JSON repair engine: it must preserve all valid partial data, infer only the minimal structural closures needed, and never hallucinate new fields or values beyond what the partial input provides.

textCopy
You are a strict JSON repair engine. Your only job is to convert a truncated, incomplete JSON payload into valid, parseable JSON.

## Input
[TRUNCATED_JSON_PAYLOAD]

## Expected Output Schema (if known)
[OUTPUT_SCHEMA]

## Constraints
- Preserve every valid key, value, string, number, boolean, and null from the input exactly as it appears.
- Do not invent new fields, keys, or values. If a value is partially written (e.g., a truncated string or number), complete it to the most minimal valid form that allows parsing, or mark it with a placeholder like `"[INCOMPLETE]"` if the original intent is unrecoverable.
- Close all open objects, arrays, and strings. Infer missing closing brackets (`}`, `]`), quotes, and commas based on the structure of the partial input.
- If the input contains a truncated array, close the array after the last complete element. Do not add new elements.
- If the input contains a truncated object, close the object after the last complete key-value pair. Do not add new pairs.
- If a string value is truncated mid-content, close the string with a quote and append `[TRUNCATED]` inside the string value.
- If a number is truncated, complete it to the nearest valid number or replace it with `null` and add a `"_repair_note"` field at the same level.
- Output only the repaired JSON. No explanations, no markdown fences, no surrounding text.

## Examples
### Example 1: Truncated Object
Input: `{"name": "Alice", "age": 30, "city": "New Y`
Output: `{"name": "Alice", "age": 30, "city": "New Y[TRUNCATED]"}`

### Example 2: Truncated Array
Input: `[{"id": 1, "val": "a"}, {"id": 2, "val": "b`
Output: `[{"id": 1, "val": "a"}, {"id": 2, "val": "b[TRUNCATED]"}]`

### Example 3: Missing Closing Brace
Input: `{"results": [{"x": 1}, {"x": 2}]`
Output: `{"results": [{"x": 1}, {"x": 2}]}`

## Risk Level
[RISK_LEVEL]

To adapt this template, replace each square-bracket placeholder with runtime values from your application. [TRUNCATED_JSON_PAYLOAD] should contain the raw, incomplete JSON string exactly as received from the model or streaming buffer. [OUTPUT_SCHEMA] is optional but strongly recommended: provide the expected JSON Schema, TypeScript interface, or a plain-text description of the expected fields and types to help the model distinguish between structural truncation and intentionally missing optional fields. [RISK_LEVEL] should be set to high if the repaired JSON will be written to a database, sent to a user, or used in a downstream decision; in those cases, add an instruction like "If any field is unrecoverable, set its value to null and add a top-level _repair_errors array describing each repair action." For low-risk debugging or log contexts, you can omit the error-tracking instruction. After populating the template, wrap it in your standard chat message structure (system or user message) and send it to the model. Always validate the output with a JSON parser before accepting it, and log the repair attempt for observability.

The repair prompt is not a standalone utility; it is a recovery step inside a larger generation pipeline. The typical integration point is immediately after a model response fails JSON parsing or schema validation due to truncation. Your application should catch the parse error, extract the partial JSON string, and invoke this repair prompt before falling back to a full regeneration or escalating to a human. This keeps latency low and avoids discarding valid partial work that the model already produced.

Validation gates are mandatory before the repaired output enters any downstream system. After the repair prompt returns, run the result through a strict JSON parser. If parsing fails, apply a secondary structural repair (e.g., balancing braces with a deterministic algorithm) and retry the repair prompt once with the re-balanced partial input. If the second attempt fails, log the failure, capture the raw partial and repaired strings, and either request a full regeneration from the original task prompt or route to a dead-letter queue for manual review. For high-risk domains, always require human approval before repaired payloads are written to databases, sent to users, or used in automated decisions.

Model choice matters for repair reliability. Smaller or faster models often struggle with precise structural completion, especially for deeply nested JSON. Prefer a capable model with strong JSON-following behavior for the repair step, even if you use a cheaper model for the initial generation. Set temperature=0 and keep max_tokens high enough to complete the truncated structure. Log every repair attempt with the original partial output, the repaired output, parse success/failure, and the model version used. This trace data is essential for debugging systemic truncation issues and tuning your initial generation token limits.