Schema Mismatch Fallback Prompt for Structured Output

This prompt is for developers and AI reliability engineers who have already built a structured output pipeline—one that expects valid JSON conforming to a specific schema—and are now facing the production reality that models sometimes emit malformed, incomplete, or schema-violating payloads. The job-to-be-done is not initial schema design; it is a post-generation repair and disclosure step. You use this prompt when a primary generation attempt has failed schema validation and you need the system to either produce a corrected, schema-conformant output or return a clean, machine-readable failure object that the application can handle without crashing. The ideal user is someone integrating LLM outputs into a typed application boundary (e.g., a Pydantic model, a Zod schema, a protobuf deserializer) where a parse error is a hard stop.

This prompt is not a replacement for a robust initial schema prompt, few-shot examples, or constrained generation parameters. Do not use it as your primary output strategy. It is a fallback layer that activates only after validation fails. It is also inappropriate for low-risk, human-consumed text where a minor formatting glitch is acceptable. The prompt assumes you have access to the original [INPUT], the expected [OUTPUT_SCHEMA] (as a JSON Schema or TypeScript interface), and the raw [MALFORMED_OUTPUT] that failed validation. Without these three pieces of context, the model cannot reliably diagnose the mismatch or attempt a repair.

Before wiring this into your application, define clear eval gates: schema conformance (does the repaired output pass your validator?), transparency (does the response disclose when a repair was attempted?), and abstention correctness (does it return a failure object instead of guessing when repair is impossible?). In high-stakes domains such as finance or healthcare, the failure path should always escalate for human review rather than silently accepting a model's best-effort repair. The next step after reading this section is to copy the prompt template, adapt the placeholders to your schema and validation library, and run it against a golden set of known malformed outputs to measure repair rate and failure-mode clarity.

This prompt template is designed to be placed directly after a model's initial structured output attempt. It acts as a fallback instruction set, receiving the raw, malformed output and the expected schema. Its primary job is to attempt a repair of common structural errors—such as missing brackets, trailing commas, or incorrect key names—while being transparent with the user about any automatic fixes applied. If the output is too corrupted or semantically wrong to repair, the prompt instructs the model to generate a clean failure message instead of a hallucinated or partially valid object. This ensures that downstream application logic never receives a silently broken payload.

textCopy
SYSTEM: You are a strict JSON repair and validation engine. Your only job is to fix malformed JSON output so it strictly conforms to the provided [OUTPUT_SCHEMA]. You must never invent data, change semantic meaning, or guess missing values.

INPUT: The raw, potentially malformed JSON string that failed schema validation.
[RAW_OUTPUT]

EXPECTED SCHEMA: The JSON schema the output must conform to.
[OUTPUT_SCHEMA]

CONSTRAINTS:
[CONSTRAINTS]

INSTRUCTIONS:
1. Analyze the [RAW_OUTPUT] against the [OUTPUT_SCHEMA].
2. If the errors are structural (e.g., unclosed braces, trailing commas, incorrect quotes, wrong key names that map clearly to schema keys), repair them. Do not change any values.
3. If you make any repair, you MUST set a top-level boolean field `"_schema_auto_repaired"` to `true` and add a `"_repair_log"` array of strings describing each fix made.
4. If the errors are semantic (e.g., missing required fields with no data to fill them, wrong data types that cannot be coerced, or the output is completely unrecognizable), do NOT attempt a repair. Instead, output a clean failure object.

OUTPUT FORMAT (on success):
A valid JSON object conforming to [OUTPUT_SCHEMA] with the additional fields `"_schema_auto_repaired": true` and `"_repair_log": ["Fixed: ...", ...]`.

OUTPUT FORMAT (on failure):
{
  "_schema_repair_failed": true,
  "_failure_reason": "A clear, specific explanation of why the output could not be repaired to match the schema.",
  "_original_output_snippet": "A truncated, safe snippet of the original malformed output for debugging."
}

Do not include any text outside the JSON object.

To adapt this template, start by defining your [OUTPUT_SCHEMA] as a strict JSON Schema object, not just a description. The [CONSTRAINTS] placeholder is where you add domain-specific rules, such as value ranges, enum lists, or forbidden fields. The [RAW_OUTPUT] is the string you receive from the initial model call. In your application harness, you should parse the response from this fallback prompt and check for the _schema_auto_repaired or _schema_repair_failed flags. If a repair was made, log the _repair_log for monitoring and alerting; frequent repairs indicate a brittle initial prompt. If the repair failed, surface the _failure_reason to the user or an error queue, and never pass the malformed data to your database or API.

This prompt is designed as a post-generation repair step, not a standalone endpoint. It should be invoked only after your primary structured-output generation step fails schema validation. The typical integration pattern is: (1) call your primary model with a schema-constrained request, (2) validate the output against your expected JSON Schema, (3) if validation fails, invoke this fallback prompt with the original schema, the malformed output, and the validation error details. This separation ensures you pay the latency and cost of repair only when necessary, rather than slowing down every successful generation.

When wiring this into your application, pass the following inputs to the prompt: [ORIGINAL_SCHEMA] as a JSON Schema object (not a description), [MALFORMED_OUTPUT] as the raw string the model returned, [VALIDATION_ERRORS] as the structured error output from your JSON Schema validator (e.g., AJV, jsonschema, pydantic), and [ORIGINAL_INPUT] as the user request that generated the output. The prompt should return a JSON object with two possible shapes: a repair object containing repaired_output and changes_applied (an array of strings describing each fix), or a failure object containing reason and user_message. Your application code must parse this response and branch accordingly—if repair is present, re-validate the repaired_output against the original schema before using it; if failure is present, surface the user_message to the end user and log the reason for debugging.

Implement a retry loop with a hard cap of 2-3 attempts. On each retry, include the previous repair attempt's output and any new validation errors as additional context. If the fallback prompt itself returns malformed JSON or exceeds the retry limit, your application must surface a clean failure message to the user (never expose raw model output) and log the full failure chain for engineering review. For observability, instrument each step: log the primary generation latency, validation pass/fail, fallback invocation count, repair success rate, and the specific schema fields that most frequently cause mismatches. This data will help you improve your primary prompt or schema design over time. In high-stakes domains such as finance or healthcare, add a human review gate before any repaired output is committed to a system of record, and ensure your logging captures the full diff between the original malformed output and the repaired version for auditability.