What Is Structured Output?
Structured output is a generated reply constrained to a declared shape — a JSON object with named fields, a fixed set of keys, an enumerated value — so that the program which asked for it can parse it directly instead of reading it. The declaration is what makes it structured. A reply that happens to be well-formed JSON is not structured output; a reply that could not have been anything else is.
Three ways to obtain a parsable reply, and only one of them is a constraint
The weakest arrangement is instruction alone: the prompt asks for JSON and the caller parses whatever arrives. Nothing enforces it. What comes back may carry an introductory sentence, a code fence, a closing remark, a trailing comma or a key nobody asked for, and each of those is a parse failure in a caller that assumed otherwise. Supplying a worked example of the shape narrows the range of what arrives without forbidding anything, because an example is also an instruction.
The middle arrangement keeps the instruction and adds a check behind it: parse the reply, validate it against a declared schema, and on failure send it back with the validation error attached, up to a retry limit. This catches a bad reply rather than preventing one, and it is honest about the cost — an extra round trip on the failing share of requests, a latency tail set by the retry limit, and a caller that still has to decide what happens when the limit is reached.
The strongest arrangement changes the decoder instead of the prompt. A grammar is compiled from the declared shape, and at each decoding step the candidate tokens that would take the partial output off a path the grammar still permits have their probability set to zero; the remaining mass is renormalised and the draw is made from what is left. Syntactic conformance stops being something requested and becomes something the decoding loop has no way to produce a counterexample to. This is called constrained decoding, and the name is exact: nothing about the generation is improved, the set of sequences that can be emitted is made smaller.
| Arrangement | What it guarantees |
|---|---|
| Instruction in the prompt | Nothing structural. Conformance is requested, and the caller finds out by parsing. |
| A worked example of the shape | Nothing structural either. An example narrows what arrives; it forbids nothing. |
| Parse, validate, retry | That a non-conforming reply is caught rather than used. It is prevented on no attempt, and every retry is another request. |
| Constrained decoding from a grammar | That the emitted sequence is in the declared syntax, because no token leaving that syntax was available to emit. |
| Validation after decoding | That the document satisfied the keywords the schema declared — a narrower set than the constraints the caller has in mind. |
The rows are layers rather than alternatives, and a careful implementation keeps the last one even when it has the fourth: a grammar covers only what the compiler could express, and whatever part of a schema it could not is left to the validator standing behind it. Where an implementation publishes the subset of the schema language it supports, that subset is the actual guarantee, and it is smaller than the language.
What a conforming document does not establish
Shape is not content. A constrained decoder guarantees that a field is present, that it is a string, and that it matches whatever pattern the grammar was able to encode. It does not guarantee that the string is true, that the enumerated value selected is the right member of the enum, or that a required field holds anything more considered than the most probable filler for the position. The failure moves rather than disappearing: an unparsable reply is loud and stops the caller, while a well-formed reply carrying a wrong value is silent and is passed on.
Requiring a field also removes the option of declining to fill it. Where the honest answer is that the input did not contain the value, a schema demanding a non-empty string obtains a non-empty string. That is a decision taken in the schema, and it is usually taken by accident. The alternative is to make absence representable — a nullable field, an explicit not-found member of the enum, a separate boolean recording whether the extraction found anything — so that the caller can still distinguish a value that was read from a value supplied to satisfy the shape.
Two mechanical consequences follow from the constraint being applied one token at a time, and neither is visible in the document that comes back. The order of fields in the declaration is the order they are produced in, so a field placed early is produced with nothing later in view: a conclusion declared above the evidence that supports it is a different computation from the same two fields declared the other way round. And the masking is local and forward-only — a prefix that was permitted at every individual step can arrive somewhere the only remaining legal continuations are awkward, and a decoder with no backtracking has to finish from there. Both documents parse perfectly.
How the Registry classifies a schema-constrained output task
Constraining a reply to a declared schema so that every field parses without a repair step is filed as a code modification task in this registry's classification. The classification reads the deliverable rather than the reply: what such a task leaves behind is a schema, a decoding setting and a caller with one branch fewer in it, all of them source, and all of them reviewed in a diff like any other change.
The Registry's canonical brief for this entry is filed as:
Constrain a reply to a declared schema so every field parses without a repair step.
Submitted for assessment it is
classified as Code modification, and its wording is hashed once — to
7ff4d27bad3c73bb…, the first sixteen of sixty-four hexadecimal
characters — with the wording itself never stored. The hash is what the derivation
reads.
That class's own page is /tasks/code.
Classification is one of three inputs. The other two are the configuration submitted with the task, and the permanent chart derived from that configuration — fixed by the model name, the training cutoff and the temperature alone, and never reading the task at all. The same ascendant, ruling planet and harmony therefore appear on every assessment a given configuration receives, whatever it was asked to do. The derivation is published in full at /method.
What this page does not claim about structured output
Which keywords a given implementation can compile into a grammar, and what it does with the ones it cannot, are facts that implementation publishes about itself, and the canonical brief above names no implementation. This registry constrains no decoder, validates no reply on an operator's behalf, and has never compared a constrained arrangement against a retry loop on any workload. It reads the wording of a submitted task, and the wording is all it reads.
The Registry does not run this task, does not inspect any system's output for it, and validates no assessment it issues against what afterwards happens. What it does is compute — from a published method, for one submitted task and one submitted configuration — a verdict and a recommended execution window. It computes neither on this page.
Questions about structured output
- What is structured output?
- Structured output is a generated reply constrained to a declared shape — a JSON object with named fields, a fixed set of keys, an enumerated value — so that a program can parse it directly. The declaration is what separates it from a reply that merely happens to be well formed.
- How is structured output enforced?
- Three arrangements are in use: an instruction in the prompt, which enforces nothing; a parse-validate-retry loop, which catches a bad reply after it has been produced; and constrained decoding, which compiles the declared shape into a grammar and removes non-conforming tokens from consideration at each step, so that a non-conforming sequence is never emitted at all.
- Does structured output guarantee correct values?
- No. It constrains the shape of a reply and says nothing about the content of its fields. A document can satisfy every declared type, pattern and required key while holding a value that is wrong, or one filled in only because the schema left no way to record that the input did not contain it.
- What is constrained decoding?
- Constrained decoding compiles a declared schema or grammar into a machine that tracks which continuations remain legal for the partial output. At each decoding step, tokens that would leave that set are masked to zero probability and the remaining distribution is renormalised before a token is drawn.
- Does the order of fields in the schema matter?
- It can. Fields are produced in the order the declaration fixes, so an earlier field is generated without any later field in view. Placing a conclusion before the evidence for it is a different computation from placing it after, even though the two documents parse identically.
Related entries
Order an assessment for code modification tasks
The Registry issues a permanent, numbered task risk assessment for one submitted task and one submitted configuration. EUR 1.90 Standard, EUR 4.90 Extended, EUR 14.90 Full Chart, which adds the permanent chart. Assessments from EUR 1.90; machine-readable at /pricing.json.