LLM output validation checks whether a generated response is complete, structurally valid and acceptable for the task. JSON Schema can describe types, required properties and allowed values. Application checks must establish whether those values are supported and safe to use.
A valid object is only the starting point. An order identifier can match its pattern while referring to the wrong order, and a refund amount can be a valid integer without being authorised.
Design fields around the decision
Keep the schema focused on information the application needs. Give fields precise names and descriptions, including units and missing value rules.
The following is a standard JSON Schema example. A model provider may support only a subset, so check compatibility before using it as a generation constraint.
{
"type": "object",
"properties": {
"order_id": {
"type": ["string", "null"],
"description": "Order reference stated in the message, or null."
},
"requested_amount_minor": {
"type": ["integer", "null"],
"minimum": 0,
"description": "Amount requested in currency minor units, or null."
},
"currency": {
"enum": ["GBP", "EUR", "USD", null]
}
},
"required": ["order_id", "requested_amount_minor", "currency"],
"additionalProperties": false
}
In JSON Schema object validation, required controls presence. It does not by itself prohibit null; the property's schema determines which values are allowed.
For money, establish the currency and its unit convention before converting an amount. Avoid assuming that every currency has two decimal places.
Validate completion, syntax and structure
Start with the provider response status. A refusal, cancellation or incomplete response needs its own handling before the application attempts to parse an object.
Next, parse the JSON. Then run the application schema validator, even when generation was constrained. This checks the actual received value against the contract the application uses.
Schema validation should catch missing required fields, unexpected properties and invalid enumerated values. Configure format validation deliberately. A validator may treat a format keyword as an annotation unless assertion support is enabled.
Check source evidence and business meaning
Semantic checks establish relationships a basic schema cannot.
If an extraction claims to quote the customer's message verbatim, check that the quoted text appears in the source. This verifies quotation fidelity, though it does not prove that the quote supports the interpretation.
If the model extracts an order ID, confirm that the authenticated user may access that order. If the model proposes an amount, check the applicable policy and authoritative account data. Keep approval separate from extraction.
Arithmetic, identifier membership and permitted transitions can be checked deterministically. Others need a reviewed rubric or a calibrated model grader. Prefer the simplest check that measures the actual requirement.
A response passes through several checks before the application can use it. The workflow below shows why valid JSON alone is insufficient.
Bound repair attempts
A formatting error may be repairable by giving the model a concise validation error and the necessary source input. A missing fact cannot be repaired by repeatedly demanding a value.
Set a retry limit, deadline and cost allowance. Preserve the original response and the repair history for diagnosis. Do not let the repair process loosen the schema or invent evidence merely to make validation pass.
For example, allow one repair for an unsupported enum spelling if the intended value can be re extracted. Route an unknown order identifier to clarification or review. Retrying it until a real identifier appears could attach the request to the wrong record.
Validate contracts between workflow steps
Intermediate outputs need the same discipline as final responses. An extraction error can become a false premise for every later step.
Record the schema version with stored results. When a schema changes, review downstream consumers and historical data. Adding a field may be harmless to one client while a renamed enum breaks another.
Use a small contract suite containing valid data, missing values, unsupported extra fields, invalid types and source mismatches. The suite should demonstrate that each failure reaches the intended error or clarification path.