In words
What it is, why it matters, and what it is like.
Why am I learning this?
Structured output constraints are what let you build software that talks to an AI and trusts what comes back. Without them, a model can reply with prose when you asked for a number, add text around a JSON array, or misname a field—and your code crashes. With them, you can safely feed model output straight into a database, an API, or another system. This concept unlocks three things you will meet soon: Context Packs (where you bundle the schema you want with the prompt), Prompt Iteration (where you measure whether your constraint is holding), and AI Agents (where a model calls tools, and only a validated call can be allowed to run). If you skip this, every later lesson that depends on reliable model output will feel impossible.
The idea, in plain terms
When you ask a language model a question, it does not return a structured record. It returns a string of text—it is a text generator. So when you want 'a list of three restaurants with names and ratings', the model does not naturally give you a tidy list; it gives you sentences, maybe with bullet points, maybe with extra commentary. Structured output constraints are the set of techniques that force the model to produce text that exactly matches a pre-agreed shape, like a table with specific columns. Think of it as a form with fixed fields versus a blank sheet of paper. Without constraints, you get the blank sheet; with constraints, you get a form and the model must fill it in. The point is not to ask nicely—it is to make it structurally impossible for the model to deviate.
An analogy
Imagine you hire an assistant to record orders at a restaurant. If you just say 'please record the orders', you might get 'table 3 wants the dosa but no onions, and they asked about the chutney'. That is useful to a human, but useless to a computer that needs a table of order, table number, and items. Now imagine you hand the assistant a pre-printed form with three boxes: TABLE NUMBER, DISH, MODIFICATIONS. The assistant is taught that the form is the only output allowed—no extra notes, no commentary, no crossing out. The form is the schema. The assistant is trained (or constrained) to only ever fill in boxes. This is exactly what grammar-constrained decoding does: it does not hope the model will follow instructions; it restricts the very act of writing so that only valid forms can be produced. Where the analogy stops working: a human can still fill a box with nonsense (write 'red' in the dish box). A grammar constraint only fixes the shape, not the content—you still need validation to check that the dish actually exists on the menu. So the constraint is about form, and validation is about content.
Definition
Structured output constraints are techniques that force a language model to generate text that exactly matches a predefined schema, typically by restricting the allowed tokens at each step (grammar-constrained decoding) or by validating and retrying function calls, so that downstream code can parse the output without error.
Where this sits
This concept is part of Prompt Engineering — the idea that you must design not just what you ask, but how the answer is allowed to look. The library notes say it best: 'structured output should be enforced by schema, not requested politely.' You already know from your notes that few-shot examples (giving examples in the prompt) are often stronger than long instructions; that is true here too, except that a schema constraint is the strongest possible hint. This connects to Context Packs because a schema is part of the context you bundle; to Prompt Iteration because you will measure whether the constraint is holding; and to Prompt Optimization because a schema is something you can define and evaluate objectively. The book 'Large Language Models: The Hard Parts' emphasises that this is a constraint problem, not a politeness problem.
