Structured output is one of the points where the gap between impressive demos and dependable workflows becomes especially clear. A model that can generate clean JSON in a short, friendly example may still drift, omit fields, or invent values when the source material is long, the schema is nested, or the same request is repeated under slight variation. I have spent a significant portion of testing time watching structured outputs succeed and fail under controlled conditions. The observations below are organized around what tends to work, what tends to break, and the design choices that improve the odds of staying on the useful side of that line.
What Tends to Work Under Realistic Conditions
Flat or Shallow Schemas With Explicit Required Fields
When the schema is relatively flat and every required field is named in the instruction, compliance rates are noticeably higher. Deeply nested objects and optional fields that the model must decide whether to include create more opportunities for drift.
Schemas That Mirror the Source Structure
If the desired JSON fields correspond closely to sections or entities already present in the source material, the model has less need to invent intermediate structure. Alignment between source shape and output shape reduces one major source of error.
Explicit “Absent” or Null Handling Instructions
Telling the model what to do when a value is not present in the source—emit a null, emit a specific sentinel string, or omit the field—produces more consistent behavior than leaving the decision implicit. Silence on absence invites invention or quiet omission.
What Tends to Break and Why
Nested Objects Under Length or Complexity Pressure
As nesting depth increases or the source grows longer, secondary fields begin to disappear, rename themselves, or change type between runs. The model appears to allocate attention preferentially to top-level keys.
Optional Fields Treated as Required or Vice Versa
When the schema mixes required and optional fields without strong instructional reinforcement, the model sometimes elevates optional fields into required ones (inventing values) or drops required fields that were harder to populate from the source.
Type Drift Across Repeated Runs
A field defined as a string occasionally appears as a number, a list, or a nested object in later runs with identical instructions. Type stability is not guaranteed even when the schema is stated clearly.
Invented Keys That Look Plausible
Under incomplete source material the model may add keys that fit the apparent domain but were never requested. These extra keys are especially dangerous when downstream code assumes a closed schema.
The following table summarizes high-frequency failure modes and the conditions that make them more likely:
Failure Mode | Conditions That Increase Likelihood | Typical Downstream Impact |
|---|---|---|
Missing required fields | Long source, deep nesting, weak reinforcement | Pipeline breakage or silent data loss |
Type drift | Repeated runs, mixed-type examples in prompt | Parsing errors or incorrect processing |
Invented keys | Incomplete source, open-ended domain language | Schema validation failure or data pollution |
Optional/required confusion | Mixed cardinality without explicit rules | Inconsistent records across a batch |
Value invention | Missing source data + pressure to complete | Corrupted analytics or false decisions |
Design Rules That Improve Reliability
State the Schema Twice and Keep It Closed
List the exact keys and types at the beginning of the instruction and restate the closed list at the end. Explicitly forbid additional keys. Redundancy here is cheap insurance.
Prefer Separate Calls for Complex Extraction
Rather than demanding a large nested object in one response, extract high-level entities first and then issue follow-up calls for the details of each entity. The extra calls often cost less than the debugging time created by a single complex failure.
Validate Structure Before Content
Always run structural validation—required keys present, types correct, no extra keys—before any human or automated content review. Content review on malformed structure wastes effort and hides the real problem.
Log Schema Compliance Across Runs
Track the percentage of outputs that pass structural validation under identical instructions. A declining or highly variable compliance rate is an early warning that the current schema or instruction pattern is unstable for the task.
Practical Workflow Adjustments for Teams
Treat JSON Generation as a Distinct Skill From Prose Generation
Success at fluent summarization does not automatically transfer to reliable structured output. Teams should test JSON tasks separately and apply stricter success criteria.
Budget for Schema Iteration Early
The first schema that looks clean on paper often needs adjustment once real outputs arrive. Plan for two or three short iteration cycles before declaring the structure production-ready.
Keep Human Review Focused on Semantic Correctness
Once structure is validated programmatically, human effort should concentrate on whether the values are faithful to the source. Mixing structural and semantic review in the same pass slows both.
What This Analysis Deliberately Leaves Open
Exact Model Version or Interface Behavior
No claims are made about specific API parameters, response formats, or version-specific guarantees. Those details change and must be verified under the actual interface in use.
Performance on Extremely Large or Highly Nested Schemas
The observations above are drawn from schemas of moderate complexity. Extremely large or deeply recursive structures introduce additional failure modes that require their own testing.
Cost and Latency Trade-offs of Multi-Call Designs
Separate extraction calls improve reliability in many cases but increase total token volume and latency. Teams must measure those costs against the cost of downstream failures.
Closing the Structured Output Discussion
Structured JSON is powerful precisely because it is machine-readable. That power disappears the moment required fields go missing, types drift, or invented keys appear. Opus 5.2 can produce clean structured outputs under favorable conditions. Under realistic pressure—long sources, nested schemas, incomplete data, repeated runs—the same system exhibits predictable failure modes that design choices can reduce but not entirely eliminate.
Useful remains a higher bar than impressive. A structured-output workflow earns its place when structural validation passes consistently and the remaining human effort can focus on semantic fidelity rather than repairing the shape of the data. Designing for that outcome is the practical work.
