Partial API Payload Repair Prompt Template

This prompt is for integration engineers and backend developers who receive a truncated REST or GraphQL response body from a model and need to repair it into a valid, schema-compliant payload. The job-to-be-done is recovering a partial JSON structure—where the model output was cut off by token limits, streaming interruptions, or early stopping—and producing a complete, parseable object that preserves all original field values while flagging unrecoverable segments. You should use this prompt when you have a partial payload that is structurally broken (missing closing braces, incomplete arrays, severed string values) but contains valuable data that would be expensive or impossible to regenerate from scratch. The ideal user has the original schema or an expected output contract available and can supply it as a constraint to guide the repair.

Do not use this prompt when the partial payload is so severely truncated that no meaningful structure remains—for example, only a single opening brace with no key-value pairs. In those cases, a full regeneration with a higher max_tokens setting or a streaming continuation prompt is more appropriate. This prompt is also not a substitute for schema-first generation. If you control the initial generation step, invest in strict output formatting instructions and structured output modes (like JSON mode or function calling) to prevent truncation at the source. Reserve this repair workflow for post-hoc recovery when the original generation context is lost, the cost of regeneration is prohibitive, or you are consuming outputs from a model you do not control directly.

Before using this prompt, gather the partial payload, the expected JSON schema or a representative example of a valid complete response, and any field-level constraints (required fields, enum values, data types). The prompt works best when you can clearly distinguish between fields that were fully captured, fields that were partially written, and fields that are entirely missing. Wire the output of this prompt into a JSON parser and schema validator as a hard gate—never trust a repaired payload without automated verification. For high-risk domains such as finance, healthcare, or compliance, add a human review step before the repaired payload enters any system of record. The next section provides the copy-ready template you can adapt with your own schema, partial payload, and constraints.

This template is designed to be copied directly into your application's prompt layer. It instructs the model to act as a strict JSON repair engine, taking a partial API payload and a target schema, then returning a valid, completed object. The prompt uses square-bracket placeholders like [PARTIAL_PAYLOAD] and [TARGET_SCHEMA] so you can inject the actual truncated text and your expected structure at runtime. The core instruction forces the model to preserve all existing data, infer only what is structurally necessary, and flag any field it cannot confidently repair.

textCopy
You are a precise API payload repair engine. Your only task is to repair a truncated JSON response body so that it becomes a valid, parseable object that conforms to the provided target schema.

## Input
- Partial Payload: [PARTIAL_PAYLOAD]
- Target Schema: [TARGET_SCHEMA]
- Truncation Point Context: [TRUNCATION_CONTEXT]

## Rules
1. Preserve every existing key-value pair, array element, and nested object from the partial payload exactly as it appears, unless it violates the target schema.
2. Complete any structurally broken JSON (missing braces, brackets, quotes, or commas) to make the output parseable.
3. For fields that are partially present but cut off (e.g., a string value missing its closing quote), infer the most likely completion based on the field name, schema type, and surrounding context. Do not hallucinate new factual content.
4. For required fields in the target schema that are entirely missing from the partial payload, insert a null value and add the field to a top-level `"repair_flags"` object with a reason like `"missing_required_field"`.
5. For optional fields that are missing, omit them entirely.
6. If the partial payload contains fields not in the target schema, remove them and list the removed fields in `"repair_flags.removed_fields"`.
7. If the truncation point context indicates the payload was cut off mid-array, close the array and mark it as `"possibly_incomplete"` in `"repair_flags"`.

## Output Format
Return ONLY a valid JSON object with this exact structure:
{
  "repaired_payload": { ... },
  "repair_flags": {
    "is_complete": boolean,
    "fields_repaired": ["field_name"],
    "missing_required_fields": ["field_name"],
    "removed_fields": ["field_name"],
    "possibly_incomplete_arrays": ["array_field_name"],
    "warnings": ["string"]
  }
}

Do not include any text outside the JSON object.

To adapt this template, replace the placeholders with your runtime data. [PARTIAL_PAYLOAD] should be the exact truncated string you received. [TARGET_SCHEMA] can be a JSON Schema definition, a TypeScript interface, or a plain-text description of expected fields and types. [TRUNCATION_CONTEXT] is optional but highly recommended—include any information you have about where the truncation occurred (e.g., "cut off mid-string in the 'description' field" or "token limit reached during array item 47"). After adapting, run the output through a JSON parser and validate the repaired_payload against your schema. If repair_flags.is_complete is false or missing_required_fields is non-empty, route the result for human review or a secondary repair attempt with more context.

Integrating the Partial API Payload Repair prompt into a production system requires treating it as a deterministic repair step within a broader API gateway or data pipeline. The prompt is not a conversational agent; it is a structured recovery function. The application should invoke it only after a primary model call has produced a payload that fails JSON parsing or schema validation. The harness must capture the exact raw output, the schema it was supposed to match, and any validation error messages to construct the prompt's [PARTIAL_PAYLOAD], [EXPECTED_SCHEMA], and [VALIDATION_ERRORS] inputs. This repair step should be synchronous and blocking—do not return the broken payload to the downstream client while the repair is in progress.

The core implementation loop is: parse failure → construct repair prompt → call repair model → validate repaired output → return or escalate. Use a model with strong JSON adherence for the repair call, such as gpt-4o or claude-3-5-sonnet, with response_format set to json_object and a low temperature (0.0–0.1). After receiving the repaired payload, run it through the same JSON parser and JSON Schema validator that rejected the original. If it passes, log the repair event with the original payload hash, the repair prompt version, and the number of fields preserved versus inferred. If it fails again, implement a single retry with the updated validation errors fed back into the [VALIDATION_ERRORS] placeholder. After two total repair attempts, escalate to a dead-letter queue for human review or log the unrecoverable payload for offline analysis. Never loop indefinitely.

For high-throughput systems, add a circuit breaker: if the repair success rate drops below a configurable threshold (e.g., 80% over a 5-minute window), stop invoking the repair model and fail open or closed depending on the endpoint's criticality. Instrument the harness with metrics for repair attempt count, success rate, field preservation rate (percentage of original keys retained), and hallucination flags (keys present in the repaired output but absent from the schema). These metrics feed directly into the eval criteria defined in the playbook. Finally, ensure all repair calls are logged with trace IDs that link the original generation request, the broken payload, the repair prompt, and the final output. This traceability is essential for debugging model drift and for auditing repair behavior in regulated environments.