Structured outputs enforce JSON Schema, but production still needs semantic validation, retries, and observability. Build the pattern now. Read now.
Schemas Guarantee Shape, Not Correctness
Structured output modes constrain a model to emit JSON that conforms to a schema you supply. That solves a real and annoying class of problems: you no longer parse free text, strip stray prose, or repair trailing commas. The response is guaranteed to be valid JSON matching your declared types, so your deserialization layer stops being a source of runtime surprises.
What the schema cannot tell you is whether the values make sense. A field typed as a string will always be a string, but nothing stops it from being empty, contradictory, or plausibly wrong. A date can be well-formed and still fall outside the range your business allows. Schema enforcement buys you syntactic safety; it does not buy you semantic safety, and treating the two as the same is how bad data reaches downstream systems that assumed the model had already vetted it.
Add a Semantic Validation Layer
After the JSON parses, run it through checks that encode what your domain actually requires. These are ordinary assertions about meaning: cross-field consistency, allowed value ranges, referential checks against data you already hold, and rules the schema has no way to express. Keep this layer separate from parsing so a validation failure is distinct from a malformed response.
- Enum and range checks that go beyond the schema's loose types.
- Cross-field rules, such as one field being required only when another is present.
- Consistency against known records, so referenced IDs or names actually exist.
- Sanity bounds that catch confidently wrong but well-formed answers.
Return specific, machine-readable errors from this layer rather than a generic failure. The exact reason a result was rejected becomes the most useful thing you can feed back into a retry.
Retry With Context, Not Blind Repetition
When validation fails, resubmitting the identical request tends to reproduce the same mistake. A more effective retry appends the failed output and the specific validation error, asking the model to correct that field. This gives the model the information it was missing and turns a retry into a targeted repair instead of a coin flip.
Bound the effort. Set a maximum number of attempts, and after the last one, fail into a defined path rather than looping indefinitely: route to a human, fall back to a default, or surface an explicit error to the caller. Decide up front whether a partial-but-usable result is acceptable or whether the whole operation should be rejected, and make retries idempotent so a repaired call never double-applies a side effect.
Make the Loop Observable
You cannot improve a pipeline you cannot see. Instrument each stage so you know how often responses parse cleanly, how often semantic validation rejects them and for which rules, how many retries requests consume, and how often the whole loop exhausts its attempts. These signals tell you whether the model, the schema, or the validation rules are the weak point.
Log the failing outputs alongside the errors they triggered. That record is what lets you tighten a rule that fires too often, loosen one that is over-strict, or catch a drift in model behavior before it becomes an incident. Structured outputs, semantic validation, bounded retries, and observability are one pattern, not four features—build them together and the pipeline stays trustworthy under real traffic.