loading…
How schemas turn model generations into typed contracts that software can validate, route, and safely act on.
Humans tolerate flexible phrasing; software needs predictable fields and types. Structured output bridges probabilistic generation and deterministic application logic.
Instead of parsing "I think this is a billing issue," request a typed object such as:
{
"category": "billing",
"confidence": 0.92,
"evidence": ["charged twice"],
"needs_human_review": false
}
A schema defines allowed fields, types, enums, required values, and nested structures. Some model APIs can constrain generation to a schema; otherwise, the application must parse and validate the response.
Schema validity is necessary but not sufficient. A perfectly valid JSON object can still contain a wrong decision or fabricated evidence.
Validate every model-produced object before it reaches business logic. Useful checks include:
When output is invalid, choose a bounded recovery policy. A cheap syntax repair may be safe for malformed JSON. A semantic contradiction should not be silently "fixed" by guessing. Limit retries and preserve the original failure for debugging.
| Failure | Typical response |
|---|---|
| Malformed serialization | Constrained retry or deterministic repair |
| Missing evidence | Retrieve again or escalate |
| Unauthorized action | Reject; do not retry around policy |
| Unknown enum / schema drift | Fail contract test and update version deliberately |
Structured contracts are valuable between models, tools, workflows, agents, and UIs. They make traces easier to inspect and allow deterministic testing. Version contracts explicitly; avoid changing a field's meaning without changing the schema version.