Asked about Asking for JSON versus guaranteeing it

Your extraction pipeline returns malformed JSON 5 percent of the time. What are the likely causes?

An answer that works

Two. Format drift from sampling, which shows as code fences or preamble, fixed by constrained decoding or a lower temperature. And truncation from hitting the token limit, which gives you half an object. The stop reason tells you which one you have.

Then they push further

You switch to a response schema and it still fails sometimes. Why?

Common reasons: the output hit max_tokens and was cut off, the schema uses features the provider does not enforce, or the JSON is valid but the values are wrong. Check the stop reason first.

Valid JSON, wrong values. How do you catch that?

Validate beyond the schema: ranges, consistency between fields, and that extracted values actually appear in the source where they should. Count failures by type so you know which to fix first.

What gets marked up

Marked up for checking the stop reason for truncation, and for separating well-formed output from correct output.

Reading an answer is not being able to give one. The section that teaches this is Asking for JSON versus guaranteeing it, 2 hours of Structured output.

Learn this properly

Also asked about Structured output

What does a response schema guarantee?How does constrained decoding actually work?Should every field be required?Why does field order in a schema matter?How would you reduce invented values in an extraction pipeline?Your classification enum has an 'other' option that is now used 30% of the time. What does that tell you?How would you measure the accuracy of an invoice extraction pipeline?When would you use a batch API?

All 10 questions on Structured output