Structured output is the beginning of validation
JSON schemas help software read model responses. Business rules, evidence checks, and authorization still decide whether those responses are usable.
A model response can be valid JSON and still contain the wrong information. It can have the correct fields, use the correct types, and describe an event that never happened. Structured output solves an integration problem: it gives the application a predictable shape to inspect.
Google's structured-output documentation distinguishes syntactic conformance from the semantic correctness of values. That distinction should shape your application boundary. Treat a returned object as a candidate result that must pass the checks relevant to the action you plan to take.
Design a small, explicit contract
Imagine an assistant that turns a workshop request into a proposed booking. A useful response might contain a service category, a requested date, and missing details. Keep fields narrow enough that the application can validate them. If a value is unknown, represent that explicitly rather than encouraging a guess.
Avoid a single unrestricted “instructions” field that downstream code interprets as an action plan. Separate descriptive text from operational fields. This makes it easier to display a draft while keeping booking creation behind application checks.
Validate meaning after parsing
Check that dates are real, categories belong to the supported set, and identifiers refer to records the user can access. Then enforce cross-field rules. A service duration may be individually valid but incompatible with the selected appointment slot.
For an illustrative booking on a closed day, the JSON parser should succeed and the business validator should reject the proposal. Return a useful correction path, such as a list of available dates. Do not silently rewrite a user's request into a confirmed booking that they never reviewed.
Preserve evidence for extracted facts
If the model extracts a serial number from a document, keep enough provenance to compare the value with the input. For higher-consequence fields, show the supporting text or page location during review. A required schema field should not pressure the system into inventing missing data.
Test blurred images, contradictory documents, and absent fields. Decide whether the response should contain an unknown value, request clarification, or stop the workflow. This policy belongs in product requirements before you optimize the prompt.
Put retries inside a budget
When validation fails, a targeted retry can explain the failed rule. Bound the number of attempts and the total input and output allowance. Repeatedly asking for a different answer can increase cost without providing new evidence.
Handle timeouts, refusals, and interrupted responses as explicit outcomes. A partial object should not be committed as a completed operation. Preserve the user's input and provide an understandable status rather than letting the interface appear successful while the server discarded the result.
Keep actions separate from proposals
The server should derive permissions from the authenticated user, not from a model-supplied role or account identifier. When a validated proposal becomes a write operation, apply normal authorization and concurrency controls. Use an idempotency strategy where retries could create duplicate bookings.
Build a test matrix around the boundary: valid shape with wrong meaning, valid meaning with missing permission, and a repeated request after a network failure. Passing these cases gives you evidence about the application as a whole. A neatly formatted response alone cannot provide that evidence.