How to use schemas as interface contracts while separately evaluating meaning, evidence, permissions, and consequences.
Separate syntax from meaning
A schema can require a date-shaped string, an enum value, or an array of actions. It cannot prove that the date came from the approved document or that the proposed action is appropriate. Validate types at the interface, then test semantics against the domain and source evidence.
Design the smallest useful contract
Include the fields the next system needs, explicit nullability, constrained values, stable identifiers, and a place for provenance when the decision depends on evidence. Avoid exposing an oversized internal object merely because it already exists.
Validate again at consequential boundaries
Authorization, current state, limits, and idempotency should be checked immediately before a tool changes data or communicates externally. Model output is a proposal entering an application boundary, even when it perfectly matches the requested schema.
Evaluate valid but wrong responses
Build cases where the format is correct but the source is missing, the classification is plausible but wrong, or the action conflicts with policy. These cases reveal risks that a parser success rate will never show.
References
This is an internal engineering interpretation of the OpenAI structured outputs and evaluation guidance. Schema conformance does not establish factual correctness.