Structured output validation
Structured output validation is checking that the model's output is really the shape you asked for: valid JSON, every required field present, each value the right type. The model can produce text that looks correct at a glance but breaks the moment your code tries to parse it. The trap is trusting the output because it reads fine, when a trailing comma or a string where you expected a number is enough to crash the next step.
Why it matters
Your code downstream expects real data it can act on. When the model returns malformed JSON, a missing order_id, or "twenty" instead of 20, whatever runs next throws or quietly does the wrong thing. Without validation you find these failures in production, one confused user at a time. With it, the bad output gets caught the instant it appears, so you can retry or fall back before anything ships.
How it works
You define a schema with something like JSON Schema, Pydantic, or Zod, then parse every model response against it. Valid responses pass through. Invalid ones get rejected, and you either reprompt the model with the error or fall back to a safe default. Many providers now support constrained decoding, which forces the tokens to fit your schema so the JSON is valid by construction. You still validate the parsed values, since well-formed JSON can carry a nonsense field.
A support bot is supposed to return {"intent": "refund", "amount": 49.99} so your billing code can act on it. One day it answers {"intent": "refund", "amount": "forty-nine ninety-nine"}. Schema validation rejects it on the spot, the bot reprompts, and the refund goes through correctly instead of your code choking on a string.