Context Engineering and Prompt Management
Structured Output Contracts — Stack
Structured output contracts › Stack
Technology landscape as of 2026-10-10. Knowledge cutoff May 2026.
Selection criteria
The question is how much of the declared schema is actually enforced, and what the mechanism does on the occasions it is not.
- Enforceable subset. Which schema keywords the mechanism genuinely constrains, and what it does with the rest — reject at registration, or accept and ignore. The second is the dangerous one.
- Guarantee strength. Whether conformance is assured by construction, made very likely by training, or merely checked afterwards.
- Streaming compatibility. Whether partial output can be validated and surfaced incrementally, or whether the object must be complete before anything is known about it.
- Failure surface. What a violation looks like to the caller: a typed error, a retry, a silently repaired object, or an exception from a parser deep in a library.
- Schema authorship. Whether the schema is written by hand or generated from the application's own types, and whether the generated form is reviewed before it is sent.
- Overhead. Per-request cost of grammar compilation or validation, and whether that cost is amortised across requests with the same schema.
- Evolution. Whether a schema change can be rolled out while older consumers are still running, and whether anything checks compatibility between versions.
- Portability. Whether the same contract works across the providers in use, since structured-output support and its restrictions differ significantly between them.
Options
| Option | Best for | Watch out for |
|---|---|---|
| Provider structured-output modes with a supplied schema | The default for hosted models; strong conformance with no infrastructure | The supported schema subset is narrower than the specification; unsupported constructs are rejected at registration or dropped quietly |
| Grammar-constrained decoding (Outlines, XGrammar, llguidance, LM Format Enforcer, GBNF grammars) | Self-hosted serving where conformance must be guaranteed rather than likely | Requires logit access; grammar compilation cost per distinct schema; expressiveness below full JSON Schema |
| Validate-and-retry wrappers (instructor and similar libraries) | Working with any model, including those with no structured-output support | Each retry is a full generation; failure rates become latency and cost rather than errors, which makes them easy not to notice |
| Typed model libraries emitting schemas (Pydantic, Zod, TypeBox) | Keeping one definition for the application types, the declaration, and the parse | Generated schemas contain constructs model runtimes handle poorly; review the emitted JSON rather than trusting the type |
| Schema-first prompt DSLs (BAML) | Products where the contract drives the prompt and both should be generated together | Introduces a build step and a new language; the generated prompt is a step removed from what anyone reviews |
| Generic JSON mode with no schema | Legacy models that can guarantee parseability and nothing else | Guarantees syntax only; every field check falls to your code, and absent fields are indistinguishable from unsupported ones |
| Incremental and partial JSON parsers | Streaming interfaces that must render progressively | A field can change after it has been displayed; the consumer needs a notion of provisional values |
| Repair libraries for malformed output | Salvaging the tail of a distribution you cannot otherwise control | Repairs the syntax and not the meaning, and masks a conformance problem unless every repair is counted |