A schema describes shape
JSON Schema can describe property types, required fields, and the handling of additional properties. Declaring a property does not automatically make it required. These distinctions are useful when an application expects a predictable object rather than free-form prose.
Structural validity is only the first layer. An object can satisfy its schema while naming the wrong customer, using an outdated price, or citing a nonexistent document. Treat model output as untrusted input to the application, even when a provider offers constrained generation.
Technical foundation: JSON Schema: Object validation
Design the smallest useful contract
Suppose an assistant extracts a support request. A reasonable candidate object might contain a category, a short summary, and source message identifiers. Avoid requesting an entire customer profile when the task only needs routing. Smaller contracts are easier to validate and explain when they fail.
Choose explicit representations for uncertainty. Missing, null, and an empty string should not all mean the same thing by accident. If a category cannot be determined, permit an unknown state and route it for review. Otherwise, the contract pressures the model to manufacture a valid-looking answer.
Validate in layers
First parse the payload and check the schema. Next verify references against records the current user may access. Then apply domain rules, such as whether an order is eligible for the requested operation. Authorization belongs to the authenticated server context, never to a user identifier proposed by the model.
For money, avoid accepting a model's arithmetic as the final amount. Resolve product identifiers and calculate totals in application code. For a date, verify the calendar value and relevant timezone. For a URL, restrict allowed destinations if the application will fetch it. Each check protects a different boundary.
Make repair bounded and observable
A malformed response can be retried with a concise validation error, but endless repair loops are not a recovery strategy. Set an attempt limit and expose a useful fallback. Keep enough diagnostic information to distinguish a schema mismatch from a provider timeout or a business-rule rejection.
Version the contract alongside its consumers. Adding a required field can break an older client or stored response. Test compatibility and plan migration rather than silently changing the object. Render any text fields safely; a valid JSON string is not automatically safe HTML.
Before connecting an output to production
- Specify required fields and unknown states intentionally.
- Reject unsupported extra fields where appropriate.
- Check referenced records and permissions server-side.
- Bound repair attempts and preserve useful error categories.
- Test schema changes against saved, non-sensitive fixtures.
