Your extraction pipeline returns a beautifully formed object. Every required field is present, every type is correct, the schema validator is delighted. The customer ID it contains does not exist. The invoice date is the thirty-first of February. The line items sum to £340 and the total says £430.
Structured output constraints did exactly what they promise: they guaranteed the shape. Nothing about them guarantees the contents correspond to anything real, and treating schema validation as sufficient is how bad data enters systems that were supposed to be careful.
What changed in 2026
- Structured outputs became reliable enough to be trusted too much. Constrained decoding made malformed JSON rare, which shifted the failure mode from parse errors to plausible-looking wrong values.
- Validation moved into the pipeline as a distinct stage. Rather than a few
if statements after parsing, teams built explicit validation layers with their own error handling and metrics.
- Repair loops replaced blind retries. Feeding the specific validation error back to the model proved far more effective than regenerating from scratch.
- Cross-field checks got attention. The realisation that most real errors are relational — totals, date ordering, referential integrity — rather than per-field.
Four layers of checking
| Layer |
Checks |
Catches |
| Schema |
Types, required fields, enums |
Malformed structure |
| Semantic |
Ranges, formats, plausibility |
Impossible values |
| Referential |
Does this ID exist? |
Fabricated references |
| Cross-field |
Do the parts agree? |
Totals, date ordering, logic |
Schema validation is where most implementations stop, and it is the layer that constrained decoding already largely handles. The value is in the other three.
Semantic checks catch impossible values that are structurally fine. A date of 2026-02-31 parses as a string and fails a date parse. A quantity of -5 is a valid integer and an invalid quantity. A percentage of 340 is a number and not a percentage.
Referential checks are the highest-value and most-skipped layer. A model asked to extract a customer ID will produce something ID-shaped whether or not it saw one. Looking it up in your database is a cheap query that converts a plausible fabrication into a caught error. Anything the model returns that should correspond to a real record needs this.
Cross-field checks catch the errors that individually-valid fields hide. Line items summing to the stated total. An end date after a start date. A status consistent with the other fields. These are where extraction errors actually concentrate, because each field is individually reasonable and the combination is not.
Repair beats retry
When validation fails, the instinct is to call the model again. That regenerates blind — the model has no idea what was wrong and may well produce the same error.
Repair instead: send the failed output back along with the specific validation error, and ask for a correction. "The line items sum to 340 but total says 430. Re-extract, checking the arithmetic." The model now has the information it needs, and repair succeeds far more often than a blind retry at similar cost.
Two disciplines make this safe.
Cap the loop. Two repair attempts, then fail loudly. An uncapped loop against a genuinely ambiguous document is an unbounded bill and a hung request.
Fail visibly. When repair exhausts, the correct outcome is an error surfaced to a human, not a partial record written to your database. Silent partial success is worse than an obvious failure — it puts bad data somewhere durable.
Track your repair rate as a metric. A rising rate is an early signal of prompt drift or a model change, and it moves before downstream data quality visibly degrades — see eval drift.
Confidence, and what to do with it
Asking the model for a confidence score alongside its extraction is popular and worth treating carefully. Self-reported confidence correlates with correctness loosely and is not calibrated — a model can be confidently wrong and hesitantly right.
Where it helps is as a routing signal rather than a truth signal. Low self-reported confidence is a reasonable trigger for human review, even if high confidence is not proof of anything. Combined with your own validation results, it prioritises a review queue sensibly.
More reliable is checking whether the model can point at where in the source a value came from. An extraction that cites a span you can verify is checkable; one that cannot is not.
Common mistakes
- Treating schema validation as sufficient. It checks shape, and shape was already mostly solved.
- Skipping referential checks. The cheapest way to catch fabricated identifiers.
- Blind retries on validation failure. Wastes calls without giving the model the error.
- Uncapped repair loops. Unbounded cost on ambiguous inputs.
- Writing partial records on failure. Bad data that looks like good data.
- Trusting self-reported confidence as truth. Use it to route, not to decide.
- Validating fields nothing reads. Effort with no downstream consequence.
FAQ
Does strict structured output mode remove the need for this?
It removes the shape problem and leaves everything else. Strict mode guarantees the JSON matches your schema; it says nothing about whether the values are real — see structured outputs.
How much validation is too much?
Validate what you act on. A field written to a database, shown to a user, or used in a decision needs checking. A field nothing downstream reads does not.
Should a model validate another model's output?
For subjective qualities where code cannot express the rule, sometimes — with the usual caveats about judge reliability. For anything expressible as a rule, code is cheaper, faster, and deterministic. Reach for a model only when you genuinely cannot write the check.
How does this interact with guardrails?
Guardrails typically screen for safety and policy; this is correctness. Adjacent layers solving different problems — see AI guardrails.
Where to go next
For the constrained decoding that handles the shape layer, read structured outputs. For catching validation-rate changes before data quality suffers, eval drift, and for the policy layer alongside it, AI guardrails.