With OpenAI strict Structured Outputs, when can a response still fail to parse against your schema?

## The exact shape of the guarantee It is easy to hear "guaranteed schema adherence" as "you will always get your object." The precise claim is narrower and much more defensible: *a generation that runs to completion under a compiled grammar cannot contain a token sequence that violates the schema.* Everything that prevents the generation from running to completion sits outside the guarantee, and production code must handle each case. ## Failure 1 — refusal The model may decline a request on safety grounds. When it does, the assistant message carries a populated `refusal` field containing a natural-language explanation, and `content` is null. This is deliberate: rather than smuggling "I can't help with that" into a `summary` string field where it would sail through your schema and poison downstream data, the API puts it in a separate channel your code must look at. The practical rule: check `refusal` first, `content` second. In a batch extraction job, count refusals as their own outcome class — they usually cluster on a specific kind of input and tell you something about your prompt or your data. ## Failure 2 — truncation If generation stops because it exhausted the completion-token budget, `finish_reason` is `"length"` and the text is a *prefix*: correct as far as it goes, unterminated as JSON. Strict mode cannot help here — the grammar constrains which tokens may be emitted, not how many are available. This is the failure that surprises teams, because it is load-dependent. The schema that fits comfortably on typical inputs blows the budget on the one document with two hundred line items. Mitigations, in order of preference: raise the completion-token limit with headroom for the worst realistic case; shrink the schema so fewer tokens are spent on structure; paginate or chunk the work so a single call never has to emit an unbounded array; and bound array sizes in the prompt. What you must not do is close the braces yourself. A repaired fragment is silently missing data, which is worse than a loud failure — the whole point of adopting Structured Outputs was to delete that repair code. ## Failure 3 — filtering and transport `finish_reason` may come back as `"content_filter"`, and ordinary operational failures — a 429, a 500, a timeout, a dropped stream — mean there is no body to parse at all. These are retry-and-alert concerns rather than parsing concerns, but they belong in the same defensive branch as the other two so that one code path decides whether a usable object exists. ## Failure 4 — conformant but wrong The response satisfies the schema and your code parses it happily, and the values are invented. Constrained decoding removes a class of *format* errors; it has no opinion about truth. Two habits follow. First, keep semantic validation after parsing: totals that must reconcile, identifiers that must resolve, dates that must fall in range. Second, prefer enums over free-form strings for anything categorical — the grammar makes an out-of-vocabulary label impossible, which converts a silent data-quality problem into a constrained choice. A related trap: over-constraining can *cause* wrong values. If the schema offers no way to say "not present in the source," the model must still fill the field, and it will invent something plausible. Give extraction schemas a nullable value or an explicit `"unknown"` enum member so honesty is expressible. ## Streaming When you stream a structured response, intermediate chunks are partial JSON by construction. Accumulate the deltas and parse once at the end, or use a streaming-tolerant parser that understands it is looking at a prefix. Treating an arbitrary mid-stream buffer as a complete document reintroduces exactly the fragility the feature exists to remove — and a stream that ends early is the truncation case again, so check the terminal `finish_reason` before trusting the accumulated buffer. ## What good handling looks like One branch, evaluated in order: transport error → retry with backoff; `refusal` populated → record as a refusal, do not parse; `finish_reason` not `"stop"` → treat as incomplete, do not parse; otherwise parse, then run business validation. Instrument each branch separately, because their rates tell you different things — refusals point at prompt or input problems, truncations at budget or schema-size problems, and validation failures at model quality. ## Interview framing Say the guarantee is conditional on completion, then name refusal, truncation and filtering as the ways completion fails, and close with the observation that shape is not truth. That sequence shows you have run this in production rather than read the feature announcement.