Structure / Decoding
verifiedSchema Conformance
The output has to be JSON matching a declared schema — the right keys, the right types, the enum values you listed. It is what makes a model callable from a program rather than readable by a person, and it is the boundary where a language model becomes a component instead of a conversation.
Conformance is a solved problem and correctness is not, which is the distinction most worth holding on to. A constrained decoder can guarantee the JSON parses and matches the schema, and it can do nothing at all about the value being the wrong value. A schema that says "severity": "low" | "high" gets one of those two strings every time, and whether it is the right one is exactly as uncertain as it ever was.
Worse, tightening the schema can move the answer. Every constraint removes options and renormalises over what is left, so a model that would have hedged in prose is forced to commit to one of the enum values — and the confidence that commitment implies is manufactured by the constraint rather than held by the model. So the conformant share rises to one while the correct share does not follow it, and the gap between them is invisible to every check the schema performs.
conformant-but-wrong holds 17% of the budget; rest holds the remaining 83%.
Outputs that match the schema perfectly and say the wrong thing, against the ones that are also right, in outputs. Drag the schema's tightness up to watch conformity rise without correctness following — the gap is invisible to every check the schema runs.
Reviewed by opendroid · 2026-08-18
- arXiv:2201.11227 — Synchromesh: Reliable code generation from pre-trained language models
- arXiv:2403.06988 — Guiding LLMs The Right Way: Fast, Non-Invasive Constrained Generation