In plain terms
A person can read “the invoice is from Acme, for 4,250 lira, due at the end of November”. A program cannot rely on it: next time the sentence may be worded differently. Structured output makes the model fill in a form: vendor, amount, currency, due date, each in its place and in the right type. The form is the same every time.
Why it matters
This is what allows a model to be a component in a system and not only a conversational partner. Every integration, whether it writes to a database, calls an API or feeds a dashboard, depends on output a machine can parse. Without it, teams write fragile code to scrape values out of prose and spend their time on the cases where the model phrased things differently.
Example
An accounts-payable team processes 3,000 supplier invoices a month. The model is given each PDF and a schema with nine fields. Its output goes straight into the ERP system's import queue. Invoices where a required field comes back empty are routed to a clerk; the rest need no retyping.
Most often confused with
Structured Output vs. JSON mode
JSON mode promises only that the output parses as JSON; the model may still omit a field or invent one. Structured outputs enforce the schema itself: required fields, types and allowed values. For anything feeding another system, schema enforcement is the feature to use.
Under the hood
Three levels of strictness: asking for a format in the prompt (usually works, no guarantee); JSON mode; and constrained decoding, where at each step the provider masks every token that would violate the supplied JSON Schema, so the result always conforms. Tool use relies on the same mechanism for function arguments. Practical points: a valid structure does not mean correct values, so validate the content; schemas have provider-specific limits; give fields descriptive names and descriptions, since the model reads them; allow a null or “unknown” option so the model is not forced to invent a value; ask for reasoning in a field placed before the answer if you want reasoning.