Token Limit Truncation Recovery Prompt for JSON Payloads

This prompt is for production engineers and API developers who need to recover a JSON payload that was cut off mid-stream by a model's token limit. The job-to-be-done is not to generate new content, but to salvage a partial, structurally invalid JSON response by identifying the exact truncation point, estimating the missing closing structure, and producing a valid, parseable JSON object that preserves as much of the original data as possible. The ideal user is an SRE or backend engineer who has already received a finish_reason: 'length' or similar signal from the model API and has a raw, truncated string that fails JSON.parse.

This prompt should be used when the truncated payload is a single, complete JSON object or array that was cut off before its closing brackets. It works best when you can provide the original prompt or task context so the recovery model can infer the intended schema. Do not use this prompt for streaming fragments that arrive in arbitrary chunks—use the Streaming Fragment Assembly Prompt instead. Do not use it when the payload is so severely truncated that no key structural elements remain; in that case, the correct action is to re-request with a higher max_tokens setting or to split the original task into smaller requests.

The prompt requires three inputs: the [TRUNCATED_PAYLOAD] string, the [ORIGINAL_TASK] that generated it, and an optional [EXPECTED_SCHEMA] to guide structural recovery. The output should be a valid JSON object with a recovery_metadata field that marks the truncation point and flags any estimated or reconstructed sections. Before shipping this into a production pipeline, you must validate the output with a strict JSON parser, diff the recovered payload against the original truncated string to ensure no data was hallucinated, and implement a circuit breaker that escalates to a human or re-requests the original task if the recovery confidence is below your threshold.

This prompt template is designed to be copied directly into your application's recovery layer. It takes a partial JSON payload that was cut off by a token limit, identifies the structural break point, and either closes the payload safely or prepares a continuation request. The template uses square-bracket placeholders that you must replace with runtime values before sending the prompt to the model.

textCopy
You are a JSON repair specialist. Your task is to recover a JSON payload that was truncated due to a token limit.

## INPUT
Partial JSON payload (truncated):
```json
[PARTIAL_JSON_PAYLOAD]

EXPECTED SCHEMA

[EXPECTED_SCHEMA]

RECOVERY STRATEGY

[RECOVERY_STRATEGY]

INSTRUCTIONS

1. Parse the partial JSON payload and identify the exact truncation point.
2. Determine the structural context at the truncation point:
   • Is it inside a string value?
   • Is it inside an array or object?
   • What keys, brackets, or braces are unclosed?
3. Based on [RECOVERY_STRATEGY]:
   • If strategy is "safe_close": Close all open structures (arrays, objects) and truncate the incomplete final value. Add a _truncated: true flag at the root level. Do not hallucinate missing data.
   • If strategy is "continuation_request": Output a continuation prompt that includes the last complete structural element and requests the model to continue generating from that point.
   • If strategy is "best_effort_fill": For the final incomplete value, provide a reasonable default based on [EXPECTED_SCHEMA] and mark it with _estimated: true.
4. Output the repaired JSON payload inside a ```json code block.
5. After the code block, provide a brief truncation report including:
   • Truncation point (character position or field path)
   • Structural context at break
   • Recovery action taken
   • Completeness estimate (percentage of expected fields present)

CONSTRAINTS

• Do not invent data for missing fields beyond what [RECOVERY_STRATEGY] allows.
• Preserve all valid data from the partial payload exactly as provided.
• If the payload is too damaged to recover, output: {"error": "unrecoverable_truncation", "details": "..."}
• If [RECOVERY_STRATEGY] is "continuation_request", output the continuation prompt, not a closed payload.

OUTPUT FORMAT

jsonCopy
{
  "repaired_payload": { ... },
  "truncation_report": {
    "truncation_point": "...",
    "structural_context": "...",
    "recovery_action": "...",
    "completeness_estimate": "..."
  }
}

To adapt this template, replace the three required placeholders: [PARTIAL_JSON_PAYLOAD] with the raw truncated output from your model, [EXPECTED_SCHEMA] with your target JSON Schema or a natural-language description of the expected structure, and [RECOVERY_STRATEGY] with one of the three supported strategies: safe_close, continuation_request, or best_effort_fill. The safe_close strategy is appropriate for user-facing responses where partial data is acceptable. Use continuation_request when you need the complete payload and can afford a second model call. Reserve best_effort_fill for internal pipelines where estimated values are better than missing records, but always flag estimated fields for downstream review.

Before deploying this prompt, validate that your application can parse the output JSON block and extract the repaired_payload field. Add a parse retry loop: if the model's response itself is malformed, retry once with a simplified instruction. Log every truncation recovery event with the completeness estimate so you can monitor whether your token limits need adjustment. For high-stakes payloads—financial records, clinical data, or legal documents—route best_effort_fill outputs to a human review queue and never auto-commit estimated values to a system of record.

The Token Limit Truncation Recovery Prompt is not a standalone fix; it is a component inside a larger recovery harness. The application layer must detect truncation before invoking the prompt, manage continuation state, and validate that the repaired output is structurally sound. The most reliable detection heuristic is to attempt JSON.parse() on the raw model response. If parsing fails with an unexpected end-of-input error near the final characters, the payload is likely truncated. A secondary signal is comparing the response's finish_reason to length or max_tokens in the API response object. Both checks should gate invocation of this prompt to avoid wasting tokens on non-truncated payloads.

Once truncation is detected, the harness should construct the prompt with three required inputs: the [TRUNCATED_PAYLOAD] (the raw string from the model), the [EXPECTED_SCHEMA] (a JSON Schema or TypeScript interface describing the target structure), and the [CONTEXT_HINT] (the last known complete field or array element before truncation, extracted from the partial parse). The prompt returns a repaired JSON object. The harness must then validate this output against the expected schema using a library like ajv or zod. If validation passes, the payload proceeds downstream. If it fails, the harness should not blindly retry the same prompt. Instead, it should attempt a continuation request: send the truncated payload back to the model with a continue instruction and a higher max_tokens setting, then feed the concatenated result through the repair prompt once more. Log every attempt with the original response ID, truncation point, repair latency, and validation result for observability.

For high-throughput systems, implement a circuit breaker. If the repair prompt fails three consecutive times for the same payload, stop retrying and escalate to a dead-letter queue for human review. Do not silently drop truncated payloads—they often contain partial user-facing content or database records. Model choice matters here: prefer models with strong code-completion capabilities (such as gpt-4o or claude-3.5-sonnet) for structural repair, as they are better at inferring bracket closure and field completion than smaller models. Avoid using this prompt on payloads under 100 tokens; the overhead of the repair call exceeds the cost of re-generating the entire response with a higher token limit. Finally, instrument the harness to track the rate of truncation events by model and prompt version—rising truncation rates signal that your primary generation prompts need higher max_tokens settings or output compression.