Truncated Structured Output Repair Prompt Template

This prompt is for integration engineers and backend developers who receive a truncated structured output (JSON, XML, YAML, or CSV) from a language model and need to repair it into a valid, complete structure without re-running the original, expensive generation. The job-to-be-done is automated recovery: detect the intended format from the partial content, infer the missing structural elements, and produce a parseable payload that passes schema validation. The ideal user is building a production AI pipeline where downstream parsers reject malformed outputs, and manual repair is not scalable.

Use this prompt when you have a partial, syntactically invalid payload and you know the expected output schema. It is designed for cases where the model's generation was cut off mid-structure—for example, a JSON object missing closing braces, an XML document without its end tags, or a CSV row with an incomplete final column. The prompt requires you to provide the truncated content, the target schema, and any format-specific constraints. It is not suitable for repairing outputs that are semantically wrong but syntactically valid, nor for recovering from truncation that lost critical data rather than just structural tokens. Do not use this prompt when the truncation point is ambiguous or when the partial content is too short to infer the format.

Before wiring this into an application, define clear failure modes: the repair may produce valid syntax that violates business logic, or it may hallucinate missing field values. Always validate the repaired output against your schema and, for high-risk domains, route ambiguous repairs for human review. The next section provides the copy-ready template you can adapt with your schema, format rules, and validation constraints.

This prompt template is designed to be injected into a retry or repair harness when a model's output has been cut off due to token limits or context window overflow. Its primary job is to accept the partial, malformed payload, automatically detect the intended format (JSON, XML, YAML, or CSV), and generate a syntactically valid, complete version that preserves the original semantic intent. The template uses square-bracket placeholders for all dynamic inputs, making it safe to copy directly into your application's prompt management system or configuration store.

textCopy
You are a structured output repair agent. Your task is to receive a truncated or incomplete output and reconstruct a valid, complete structure.

[INPUT]

[CONTEXT]

[OUTPUT_SCHEMA]

[CONSTRAINTS]

[EXAMPLES]

[TOOLS]

[RISK_LEVEL]

INSTRUCTIONS:
1. Detect the output format from the partial content provided in [INPUT]. Supported formats: JSON, XML, YAML, CSV.
2. If format detection is ambiguous, default to the format specified in [OUTPUT_SCHEMA]. If no schema is provided, default to JSON.
3. Analyze the partial content to understand the intended structure, field names, data types, and nesting.
4. Reconstruct a complete, syntactically valid output that:
   - Closes all open brackets, tags, or delimiters.
   - Preserves all intact data from the truncated input.
   - Uses null or sensible placeholder values for fields that were completely missing, unless [CONSTRAINTS] specifies otherwise.
   - Conforms to the [OUTPUT_SCHEMA] if provided.
5. If [CONTEXT] is provided, use it to infer missing values or structural intent.
6. If [EXAMPLES] are provided, match the style, key naming conventions, and structural patterns shown.
7. If [TOOLS] are specified, you may use them to validate the repaired output.
8. If [RISK_LEVEL] is set to HIGH, mark any inferred or reconstructed values with an "uncertainty" flag or comment as specified in [CONSTRAINTS].
9. Return ONLY the repaired output. Do not include explanations, apologies, or markdown fences unless the detected format is markdown.
10. If the input is too damaged to repair with confidence, return a JSON object with an "error" key describing the failure and a "partial_repair" key containing the best-effort reconstruction.

To adapt this template for your specific pipeline, replace each placeholder with concrete values. The [INPUT] placeholder should receive the raw truncated string. [OUTPUT_SCHEMA] should contain your expected JSON Schema, XML Schema Definition, or a plain-text description of the expected fields. Use [CONSTRAINTS] to enforce domain-specific rules, such as 'dates must be ISO 8601' or 'do not invent missing financial figures.' The [RISK_LEVEL] flag is critical for high-stakes workflows like healthcare or finance; when set to HIGH, your harness should route the repaired output for human review before it reaches downstream systems. Always validate the repaired output against your schema programmatically after the model responds, and implement a retry budget to prevent infinite repair loops.

The Truncated Structured Output Repair Prompt is designed to be called automatically by an application harness when a model response fails a completeness check or a structural validation. The harness must first detect that the output is truncated—typically by checking for balanced brackets, closing tags, or a valid end-of-file marker—and then invoke the repair prompt with the partial output and the expected schema. This is not a prompt for users to call manually; it is a recovery step in an automated pipeline where the cost of a malformed payload is high.

To wire this into an application, wrap the primary model call in a try/catch or validation gate. If the output fails a parse attempt (e.g., json.loads raises JSONDecodeError), pass the raw truncated string, the target format, and the expected schema into the repair prompt. The harness should include a retry budget—typically 1-2 repair attempts—before escalating. After each repair attempt, validate the output again using the same schema. If the repair succeeds, log the event as a recovery_success metric and proceed. If it fails, log the failure with the original and repaired payloads for debugging, then either return a controlled error to the user or route to a human review queue if the workflow is high-risk.

For model choice, use a model with strong instruction-following and code-generation capabilities, such as gpt-4o or claude-3.5-sonnet, since the repair task requires precise syntax reconstruction. Avoid smaller or older models that may hallucinate field values or invent missing data. The repair prompt should be configured with temperature=0 to maximize determinism. If your application uses structured outputs via the API (e.g., OpenAI's response_format or function calling), note that a truncated response may not be returned at all by the provider; in that case, your harness must catch the API error and retry the original request with a reduced context window before attempting repair.

Validation and evals are critical. After repair, run the output through a schema validator (e.g., jsonschema for JSON, lxml for XML) and a semantic completeness check: are all required fields present? Do enumerated values match the allowed set? Are numeric ranges respected? For high-stakes workflows, add a secondary LLM-as-judge eval that scores the repaired output against the original partial content to ensure no information was fabricated. If the repair prompt introduces data not present in the truncated original, flag it for human review. Never silently accept a repaired output that adds unsupported claims.