Streaming Structured Output Partial Repair Prompt Template

This prompt is designed for platform engineers and streaming infrastructure teams who receive partially streamed structured outputs—such as typed JSON or XML—from an LLM. Its job is to validate the partial structure against a known schema, identify which required fields are still missing, and determine whether the system should wait for more chunks or flag the record as incomplete. Use this prompt inside a streaming pipeline when you need a programmatic decision about partial payload integrity before the stream is finished. It is not a replacement for a full JSON Schema validator; it is a reasoning layer that decides what to do with an incomplete record.

Apply this prompt when your streaming consumer has accumulated a partial payload and must decide whether to continue buffering, request a continuation, or mark the record as permanently incomplete. The prompt expects a known output schema, the accumulated partial payload, and a streaming state indicator (e.g., stream_open or stream_closed). It returns a structured decision: wait, repair, or reject. This is most valuable when downstream systems cannot tolerate malformed records and when the cost of discarding a partial payload is high—such as in financial transaction logging, clinical note assembly, or multi-turn agent tool-call reconstruction.

Do not use this prompt for simple format validation that a deterministic JSON Schema validator can handle. Do not use it when the schema is unknown or when the partial payload is too small to reason about (e.g., fewer than three tokens). Avoid this prompt in latency-sensitive paths where a 200ms LLM call is unacceptable; a regex-based brace counter or a streaming parser may be more appropriate. For fully streamed payloads that have already reached a natural termination point, use a standard validation and repair prompt instead. If the workflow involves regulated data, always log the prompt's decision alongside the partial payload and schema for auditability, and require human review before any repair action is applied to production records.

This template is the core instruction set for a repair loop. It receives a partial, potentially malformed structured payload (like a truncated JSON object from a streaming API) and a target schema. Its job is to validate what exists, identify missing required fields, and either complete the payload to a valid state or flag it as irreparable. Use this prompt inside a retry or post-processing harness, not as a standalone one-shot instruction.

textCopy
You are a structured output repair agent. Your task is to validate a partially streamed [DATA_FORMAT] payload against a target schema and repair it to a valid, complete state if possible.

## INPUT
- Partial Payload: [PARTIAL_PAYLOAD]
- Target Schema: [TARGET_SCHEMA]
- Expected Output Format: [DATA_FORMAT]

## CONSTRAINTS
- Do not invent data for missing fields. If a required field is missing and cannot be inferred from the existing partial payload, mark it as [MISSING_VALUE_PLACEHOLDER].
- Preserve all existing valid fields and values exactly as they appear in the partial payload.
- Correct only structural errors: unclosed brackets, missing commas, invalid escape characters, and type mismatches where the intended value is unambiguous.
- If the payload is truncated mid-field (e.g., a string or number is incomplete), attempt to close the field to a valid terminal state. If impossible, mark the field as [TRUNCATED_VALUE_PLACEHOLDER].
- Do not reorder fields unless required by the schema.

## OUTPUT SCHEMA
Respond with a JSON object containing the following fields:
{
  "repair_status": "complete" | "partial" | "failed",
  "repaired_payload": <the repaired [DATA_FORMAT] payload>,
  "repair_log": [
    {
      "field_path": "$.field.name",
      "issue": "missing_required" | "type_mismatch" | "truncated_value" | "structural_error",
      "action": "filled_placeholder" | "coerced_type" | "closed_structure" | "unable_to_repair"
    }
  ],
  "missing_required_fields": ["$.field1", "$.field2"],
  "irreparable_issues": ["description of unfixable problems"]
}

## EXAMPLES
[EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

Adaptation notes: Replace [DATA_FORMAT] with JSON, XML, or the target format. The [PARTIAL_PAYLOAD] should be injected as a raw string to avoid pre-parsing errors. [TARGET_SCHEMA] can be a JSON Schema definition, a TypeScript interface, or a plain-text description of required fields. For high-risk domains, set [RISK_LEVEL] to high and ensure the harness routes repair_status: "partial" or "failed" to a human review queue. The [EXAMPLES] placeholder should contain 2-3 few-shot examples showing a truncated payload, the repair decision, and the resulting log. Start with a simple missing-brace example, then a truncated string, then an irreparable case.

The Streaming Structured Output Partial Repair Prompt Template is designed to sit inside a streaming middleware layer—not as a standalone endpoint. In a typical architecture, raw Server-Sent Events (SSE) or WebSocket frames arrive from the model provider and are buffered into an accumulating payload. A lightweight parser attempts to validate the partial structure against the expected schema on every flush interval (e.g., every 500ms or after each logical chunk boundary). When validation fails, the partial payload and the schema violation details are passed into this prompt to decide whether to wait for more data, request a continuation, or flag the record as permanently incomplete. This prompt is a decision engine, not a parser; it relies on the application layer to provide accurate schema violation context and the current buffer state.

Wiring the prompt into a streaming pipeline requires three integration points. First, a schema validator (such as jsonschema in Python or ajv in Node.js) must run against the accumulated buffer and produce structured error output—specifically the path to the violation, the expected type, and the actual fragment received. Second, a state manager tracks the stream's lifecycle: connection status, buffer age, retry count, and whether the model has signaled completion (e.g., via a [DONE] sentinel or a finished SSE stream). Third, the prompt itself is called with [PARTIAL_PAYLOAD], [EXPECTED_SCHEMA], [VIOLATION_DETAILS], and [STREAM_STATE] as inputs. The model returns one of three actions: WAIT (buffer more data), REPAIR (apply a suggested fix and proceed), or FLAG (mark as incomplete and escalate). The application must parse this structured decision and route accordingly—WAIT extends the buffer timeout, REPAIR applies the patch and re-validates, and FLAG writes to a dead-letter queue or triggers a human review workflow.

Retry and escalation logic is critical because streaming partial repair can loop indefinitely if the model hallucinates a fix that still fails validation. Implement a maximum repair depth (e.g., 3 attempts) and a maximum buffer age (e.g., 30 seconds after the stream closes). If the model returns REPAIR but the patched payload still fails schema validation, increment a repair counter and re-invoke the prompt with the updated violation details. After the retry budget is exhausted, force a FLAG decision. Log every repair attempt with the original payload, the suggested patch, the validation result, and the final disposition. For high-risk domains such as healthcare or finance, FLAG must route to a human review queue with full context; never silently drop incomplete structured records that could affect downstream decisions. Model choice matters here: use a fast, instruction-following model (e.g., gpt-4o-mini or claude-3-haiku) for the repair decision to keep latency low, reserving larger models only for complex nested schema violations that smaller models consistently misdiagnose.

Observability and production hardening require instrumenting every decision path. Emit metrics for: stream_repair_attempts, stream_repair_success_rate, stream_flag_rate, and buffer_age_at_decision. Attach trace IDs that link the original stream request to each repair invocation and final outcome. If the prompt returns an unparseable decision (e.g., free-text instead of WAIT/REPAIR/FLAG), treat it as a FLAG and log the raw response for prompt debugging. Finally, test this harness against real failure modes: truncated JSON mid-key, missing closing brackets, split escape sequences, and schema mismatches where the model generated a valid but wrong structure. A robust harness handles all of these without crashing the stream or silently corrupting downstream data stores.