Structured Outputs Are Protocol Boundaries

Language models are valuable because they can turn ambiguity into useful language.

Software systems are dependable because they refuse ambiguity at important boundaries.

The tension appears whenever a model’s answer becomes input to code. A person can interpret “probably Tuesday afternoon.” A scheduling service needs a timestamp, timezone, confidence policy, and a decision about what to do when the source never specified the hour.

Structured output is how an AI system crosses from interpretation into execution. Treating it as convenient formatting understates its role. It is a protocol boundary between a probabilistic component and a deterministic one.

Valid JSON Is the Beginning

Producing syntactically valid JSON solves one narrow failure: the parser can read the result.

The object can still be meaningless. A date can have the right format and the wrong timezone. An order identifier can match the pattern but belong to another customer. A confidence field can contain a plausible decimal with no defined semantics. Two fields can be individually valid and mutually contradictory.

The contract must express more than types. It needs required fields, allowed states, invariants, provenance, and the meaning of absence.

If the source does not contain an answer, should the model omit the field, return null, choose unknown, or fail the operation? Each option drives different downstream behavior. Leaving it to prompt style creates a hidden protocol that changes with wording.

Design the Schema Around the Decision

Schemas often mirror the final database record. That can force a model to invent values it has not established.

Model the decision being made instead.

A policy extraction might return the claim, supporting passages, source identities, effective date, conflicts, and unresolved fields. A later deterministic or reviewed step decides whether those findings update the system of record.

This separation preserves uncertainty. It also avoids giving a probabilistic extraction task the appearance of an authoritative business object.

The smallest useful schema contains exactly what the next consumer needs to decide safely. Extra fields increase validation surface and give weakly grounded details somewhere to hide.

Distinguish Missing, Unknown, and Inapplicable

These states are not synonyms.

Missing means expected input was absent. Unknown means the system could not determine a value from available evidence. Inapplicable means the field does not belong to this case. A value may also be withheld because policy prohibits disclosure.

Collapsing all of them to null makes downstream code guess. The guess may become a default, and the default may become an action.

Use explicit states when the distinction affects behavior. Require a reason and source reference for uncertain findings. Do not ask the model for a numeric confidence score unless the system has defined how that score is calibrated and consumed.

Honest uncertainty is part of the payload.

Validate Syntax, Semantics, and Authority

Validation should occur in layers.

Syntactic validation checks whether the output conforms to the schema. Semantic validation checks cross-field rules and domain constraints. Authority validation checks whether the cited evidence is allowed to establish the claim.

An invoice date may be valid ISO 8601 but precede the purchase order. A requested refund may be within numeric limits but based on a customer comment rather than the payment ledger. A configuration change may be internally consistent but target a production environment the current operation cannot access.

These checks should live outside the model where possible. Models can help interpret ambiguous evidence, but they should not be the only component deciding whether their own output deserves acceptance.

Repair Is a Controlled Loop

When validation fails, many systems paste the error back into the prompt and ask the model to try again.

That is useful when bounded. It is risky when repair can change already valid meaning.

A repair request should include the rejected payload, exact validation failures, immutable fields, and the allowed scope of change. Preserve the original attempt in the trace. Limit retries and stop when the same semantic failure repeats.

Some failures should not be repaired by generation. If a required source is absent, the next step is retrieval or human input. If authority is insufficient, the next step is an approval boundary. Asking the model to rewrite the object cannot create missing evidence.

Repair should correct representation, not manufacture truth.

Version the Contract Deliberately

Structured outputs become APIs even when they begin as an internal prompt detail.

Downstream code, evaluation cases, traces, and human review interfaces come to depend on field names and meanings. Adding an enum value can change switch behavior. Tightening a validation rule can turn old successful runs into failures. Renaming a field can break replay.

Give the schema a version. Record it with every artifact. Make compatibility explicit and write migrations where durable outputs outlive a deployment. Evaluate new model and schema combinations together.

The prompt, model, parser, validator, and consumer form one protocol implementation. Changing any of them can change system behavior.

Keep Prose and Protocol Separate

One model response is often asked to satisfy two audiences: a machine that needs exact fields and a person who needs a clear explanation.

Mixing both in one free-form payload creates brittle parsing and awkward prose. Prefer a structured artifact for the workflow and a separate rendering step for the user.

The human explanation can cite the structured findings and evidence. It may use nuance and narrative without becoming the input to an effectful tool. The machine artifact can remain compact, validated, and versioned without pretending to be pleasant reading.

This also makes revisions safer. A copy edit to the explanation does not mutate the approved action artifact.

Do Not Hide Prompts Inside Data Fields

Structured output does not eliminate prompt injection.

A model may place hostile or irrelevant source text into a valid string field. If a downstream agent later treats that field as instruction, the attack has crossed the schema without violating it.

Fields need content types and provenance. A quoted source passage is untrusted evidence, not an instruction. A proposed command is inert data until a separate policy and execution step authorizes it. Render user-controlled content safely and keep it out of higher-authority prompt sections.

Schema validation proves shape. Trust boundaries still determine meaning.

Observe Rejections, Not Just Successes

Invalid outputs reveal where the contract and model disagree.

Track which fields fail, which enum values are confused, how often repair succeeds, and whether one source or model version produces semantic conflicts. A sudden increase in unknown may indicate retrieval failure rather than model degradation.

Do not count repaired output as indistinguishable success. The first-pass validity rate affects latency and cost, and repeated repair may conceal a poorly designed schema.

Feed representative failures into the evaluation pipeline. The contract should improve with evidence from real runs.

The Boundary Makes Agency Composable

Agents become useful systems when their outputs can move safely between steps.

That requires more than asking for JSON. Design around the next decision. Preserve uncertainty. Validate syntax, semantics, and authority. Constrain repair. Version the schema. Separate human prose from machine artifacts. Carry provenance across every field that matters.

A model will always produce language probabilistically.

The protocol boundary decides whether the rest of the system has to behave that way too.