Structured Output Schema Violation Counterexample Prompt

This prompt is designed for integration engineers and developers who need to enforce strict output contracts—JSON, XML, CSV, or custom schemas—from an LLM in production. The core job-to-be-done is teaching the model to recognize and avoid specific, subtle schema violations that are difficult to describe with abstract rules alone. You should use this prompt when you have a well-defined output schema, a history of format drift or malformed outputs in production, and a set of known failure modes (e.g., missing required fields, incorrect enum values, wrapping objects in an extra array, or using the wrong data type). The ideal user is someone who has already tried schema descriptions and response_format parameters but still sees intermittent conformance failures under load or with edge-case inputs.

This approach is not a replacement for a validation layer; it is a complement to it. You should not use this prompt when you lack concrete examples of real failures, as fabricated or generic counterexamples can confuse the model and degrade performance on valid inputs. It is also the wrong tool if your primary problem is ambiguous user intent rather than output structure. In high-risk domains such as healthcare, finance, or legal applications, the counterexamples must be reviewed by a domain expert to ensure they do not inadvertently teach the model to omit critical information or alter factual content in the pursuit of schema compliance. Always pair this prompt with a post-generation validation harness that can reject non-conforming outputs and trigger a retry or repair workflow.

Before implementing, gather at least three to five real examples of schema violations from your logs or test suite. These should represent the most frequent and impactful failure modes, not edge cases that occur once in a million calls. The prompt works by pairing a valid output with a deliberately malformed version of the same output, clearly labeling the violation. This contrastive approach teaches the model the boundary between acceptable and unacceptable structure more effectively than a list of rules. After deploying, monitor your schema conformance rate and be prepared to rotate counterexamples as the model's failure modes shift over time.

This prompt template teaches a model to produce outputs that strictly conform to a target schema by showing it both correct examples and carefully constructed violations. The counterexamples are not random errors; they are specific, high-signal failures—missing required fields, wrong types, extra keys, malformed delimiters—that the model is likely to produce under ambiguity or context pressure. By labeling each counterexample as invalid and explaining why, the prompt establishes a clear boundary that reduces schema drift in production.

textCopy
You are a structured output generator. Your only job is to produce output that strictly conforms to the schema described below. Before every output, you must validate your own response against the schema. If you detect a violation, correct it before responding.

## TARGET OUTPUT SCHEMA
[OUTPUT_SCHEMA]

## FORMAT RULES
[CONSTRAINTS]

## CORRECT EXAMPLES
These examples show valid outputs that fully conform to the schema and rules above.

### Example 1
Input: [EXAMPLE_INPUT_1]
Valid Output:
[EXAMPLE_VALID_OUTPUT_1]

### Example 2
Input: [EXAMPLE_INPUT_2]
Valid Output:
[EXAMPLE_VALID_OUTPUT_2]

## COUNTEREXAMPLES: SCHEMA VIOLATIONS
These examples show deliberately malformed outputs. Each is labeled with the specific violation and the correction. Study these to understand what NOT to produce.

### Counterexample 1: [VIOLATION_TYPE_1]
Input: [COUNTEREXAMPLE_INPUT_1]
INVALID Output (do NOT produce this):
[COUNTEREXAMPLE_INVALID_OUTPUT_1]
Violation: [VIOLATION_EXPLANATION_1]
Corrected Output:
[COUNTEREXAMPLE_CORRECTED_OUTPUT_1]

### Counterexample 2: [VIOLATION_TYPE_2]
Input: [COUNTEREXAMPLE_INPUT_2]
INVALID Output (do NOT produce this):
[COUNTEREXAMPLE_INVALID_OUTPUT_2]
Violation: [VIOLATION_EXPLANATION_2]
Corrected Output:
[COUNTEREXAMPLE_CORRECTED_OUTPUT_2]

### Counterexample 3: [VIOLATION_TYPE_3]
Input: [COUNTEREXAMPLE_INPUT_3]
INVALID Output (do NOT produce this):
[COUNTEREXAMPLE_INVALID_OUTPUT_3]
Violation: [VIOLATION_EXPLANATION_3]
Corrected Output:
[COUNTEREXAMPLE_CORRECTED_OUTPUT_3]

## INSTRUCTIONS
1. Read the input carefully.
2. Generate an output that strictly conforms to the TARGET OUTPUT SCHEMA and FORMAT RULES.
3. Before responding, mentally check your output against every violation shown in the counterexamples.
4. If your output would match any counterexample pattern, revise it to match the corrected version instead.
5. Return ONLY the valid output. Do not include explanations, markdown fences, or extra text unless the schema explicitly requires it.

## INPUT
[INPUT]

To adapt this template, replace each square-bracket placeholder with concrete values specific to your schema and failure modes. The [OUTPUT_SCHEMA] should be a precise specification—JSON Schema, XML DTD, or a plain-text description of required fields, types, and constraints. The [CONSTRAINTS] block should enumerate format rules like "no trailing commas," "all fields required unless nullable," or "dates in ISO 8601." Choose counterexamples that represent the most frequent violations observed in your logs or eval runs. If you lack production data, start with structural violations—missing required fields, wrong types, unterminated strings—and expand as you observe new failure patterns. For high-risk domains where schema violations could cause downstream data corruption, always pair this prompt with a post-generation validation harness that rejects non-conforming outputs before they reach storage or APIs.

This prompt is designed to be used as a pre-deployment hardening step, not as a runtime repair prompt. You run it once to generate a set of valid and deliberately malformed examples, then inject those examples into your primary structured-output prompt as few-shot demonstrations. The harness therefore has two phases: a generation phase where you call this prompt, and an injection phase where you embed its output into your production prompt template. The generation phase should be treated as a build step—version the output, review it manually, and store it alongside your prompt templates.

Generation harness: Call the prompt with your target schema, constraints, and the number of counterexample pairs you need. The model will return a JSON object containing valid_examples and violation_examples. Validate the output immediately: confirm that every valid_example passes your schema validator and every violation_example fails in the specific way described by its violation_type field. If validation fails, retry once with the validation errors appended to the prompt as additional context. Log both the generated examples and the validation results. For high-stakes schemas—such as those used in finance, healthcare, or legal workflows—require a human reviewer to approve the counterexample set before it enters the production prompt.

Injection harness: Once approved, inject the examples into your production structured-output prompt as a few-shot block. Place valid examples first, followed by violation examples with explicit DO NOT DO THIS annotations. Monitor production for schema conformance drift using your existing output validation pipeline. If the violation rate on a specific violation_type increases, regenerate the counterexample set with a higher weight on that violation category. Model choice: This prompt works best with models that have strong instruction-following and JSON generation capabilities (e.g., GPT-4o, Claude 3.5 Sonnet). Avoid using smaller or older models for the generation phase, as they may produce counterexamples that are themselves malformed or ambiguous. What to avoid: Do not use this prompt at runtime for every user request—the token cost and latency are prohibitive. Do not skip the validation step; a counterexample that fails for the wrong reason will teach the model the wrong boundary.