Application patterns
Structured outputs
Structured output means the model's reply is data your program can parse, with keys, types, and allowed values you decided ahead of time.
Mental model
You are not hoping the paragraph contains a JSON object. You are requiring the object, and treating anything else as a failed call.
The rest of the system is code. Code can validate a shape. It cannot reliably scrape meaning out of prose.
When to use
- Another function, database, or UI will consume the result.
- The allowed values are an enum, a schema, or a tool's arguments.
When not to use
- The user is the only reader and a normal explanation is the product.
- You have not decided the shape yet. Decide it before you prompt.
- Messy text
- Schema
- Model
- JSON object
Example
Instead of "reply with the category and a reason," require:
{ "label": "billing", "evidence": "charged twice" }label is one of five strings. evidence is a short quote. A parser rejects extra keys, missing keys, and labels outside the list. The call is then either usable or visibly failed.
Implementation notes
Prefer the model's native structured-output or tool-argument mode when the provider has one. The prompt should still include the schema, because it tells the model what the fields mean, not only what they are called.
Validate again in your code. Provider-side structure checks types. It does not know that evidence must be a substring of the input, or that label: other should skip automation.
Keep the schema boring. Flat objects and short enums are easier to test than nested trees invented on the first afternoon.
Common mistakes
- Parsing the first
{to the last}and ignoring a preamble the model added. - Using a structure so loose that almost any reply validates.
- Changing the schema in the prompt and forgetting the validator, or the reverse.