FDE Times: Strict structured outputs still need refusal and truncation checks before you parse JSON
A 5 November FDE Times guide shows why turning on strict schema mode is not enough for customer extraction pipelines: Claude refusals still return HTTP 200 and burn tokens, truncated JSON has its own stop signal, and schema-valid values can still fail business rules—so FDEs should branch on stop_reason/status, retry truncation with a budget, and validate in application code.
FDE Times published a 5 November guide on structured outputs for customer data-extraction work. Strict schema mode only guarantees structure when the model answers in full. With Claude, a refusal still returns status 200, is still billed, and may not match the schema; truncated output carries a distinct stop_reason of max_tokens (OpenAI signals incompleteness via status / max_output_tokens).
The piece walks through an invoice-extraction example: keep schemas compatible with Anthropic and OpenAI (every key in required, additionalProperties: false, no unsupported min/max constraints), read the stop signal before json.loads, retry truncation by raising max_tokens with a hard attempt limit, and validate values in application code because schema match does not mean correct totals or currency codes.
For FDEs, the career takeaway is production hygiene: count refusals, truncations and validation failures separately in the first week on real data, rather than reporting a single “pipeline works” percentage from demo runs.
Source: fdetimes.net