Structured output beats parsing prose
When a model's output feeds code rather than a person, constrain it to a schema. Native structured-output modes make the shape guaranteed rather than likely, and validating before use turns an unpredictable text problem into an ordinary data problem.
There is a clean line between two kinds of model output. One is read by a person, where prose is the right answer. The other is consumed by your code, where prose is a liability.
The second kind should be structured, validated, and treated like any other untrusted input.
Why parsing prose breaks
The regex that extracts a sentiment from "This review is positive." meets "The reviewer seems broadly positive, though with reservations." and quietly returns nothing. Or worse, returns the wrong thing.
The failure mode is the problem: it is not an error, it is a plausible sentence your parser did not anticipate. And there is an unbounded supply of those.
Constrain the generation, not just the request
Asking for JSON helps. Using a provider's structured-output or tool-schema mode helps far more, because it restricts which tokens may be produced at each step. The difference is between hoping for valid output and making invalid output unreachable.
Where that mode exists, use it. Where it does not, ask for JSON, then strip the markdown fence the model adds anyway, then validate.
Schemas the model actually follows
Keep the structure flat. Name fields the way you would name them for a colleague. Use enums for anything with a fixed set of values, so "Positive", "positive" and "POSITIVE" cannot all appear. Deeply nested objects get filled in inconsistently, particularly near the bottom.
Validate on the way in
Parse into a real type with a real schema — Zod, Pydantic, a form request, whatever your stack uses. A field the model omitted should fail loudly at the boundary rather than surface as a null three layers down.
This is the step that converts an unpredictable text problem into an ordinary data problem, which is a problem your codebase already knows how to handle.
Decide what failure does
Validation failing is a normal event at scale, not an exceptional one. Give it a designed path: retry once with the validation error appended, since that resolves most cases. If it fails again, surface something honest to the user.
The one thing not to do is substitute a default and continue. A confidently wrong value flowing into your database is worse than an error the user can see.
Frequently asked questions
Does asking for JSON in the prompt guarantee valid JSON?
No. It makes it likely, which is not the same thing. Markdown fences, a trailing comment or a truncated response all still happen. Native schema modes are considerably stronger because they restrict what can be generated at all.
What should happen when validation fails?
Decide deliberately rather than letting an exception decide for you. One retry with the validation error fed back fixes most cases. After that, fail in a way the user can act on — never silently substitute a default.
