A valid format does not prove a correct answer
Structured outputs let you describe the shape of a response: named fields, expected types and permitted values. That makes integration more predictable, but it cannot establish whether a supplier name belongs to the right account or whether a document author intended a particular date.
Google’s Gemini documentation explicitly recommends application-side value validation and handling responses that fit the schema but have incorrect meaning. It also documents limits to the schema features enforced during generation. These are provider-documented capabilities and limitations, checked on 31 October 2026, rather than independent accuracy results.
The practical consequence is simple: put a validation step between extraction and the destination system. Give the process owner a readable list of what passes automatically, what requires review and what must be rejected.
Illustrative example: preparing a supplier invoice draft
Imagine a UK maintenance company receiving supplier invoices as PDFs. An extraction workflow proposes a supplier reference, invoice number, invoice date, currency and total. This is an illustrative design, not a Fewzen client case study or a claim about achievable accuracy.
A PDF shows an invoice total of £1,240.00 and an outstanding account balance of £3,900.00. Both amounts are valid numbers. Selecting the balance as the invoice total could satisfy a simple schema while producing an incorrect draft. A date written as 03/04/2026 also needs the sender’s date convention; the company’s UK location alone is insufficient evidence.
The workflow should retain a link to the relevant page or source text, flag ambiguity and hold the draft for review. Creating a draft, posting an invoice and authorising payment are separate actions with separate controls.
Define the fields, units and missing-value rules
Write a small data contract with the team that owns the receiving system. For each field, specify its type, meaning, permitted values and what happens when the source does not contain it. Keep an extracted supplier reference separate from the internal account identifier resolved by your application.
JSON Schema distinguishes listed properties from required properties. Extra properties are permitted by default unless constrained; a null value is also different from an absent field. Check the subset supported by your chosen provider, then validate against your application’s complete contract.
For this example, represent a GBP amount as integer pence or an exact decimal with an explicit currency. Document the conversion rule. Preserve ambiguous dates for review instead of silently converting them. Allow an explicit unknown value where appropriate; requiring a field without a missing-data policy invites plausible guesses.
Check evidence and business rules outside the model
Use ordinary application code and trusted records for checks that have a definite answer. A model’s confidence statement is not proof that a value was copied correctly. A source reference helps a reviewer locate evidence, but the reference and the extracted value still need checking.
Choose rules with the process owner. For the invoice example, useful checks include:
- Evidence: the proposed amount and date correspond to the intended fields in the document, not a balance, payment date or unrelated note.
- Identity: the supplier resolves to an authorised account using trusted identifiers; ambiguous matches go to review.
- Consistency: line amounts, adjustments and totals reconcile under finance-approved rounding rules. Do not ask the model to invent accounting treatment.
- Authority: the proposed operation is allowed for the authenticated user and workflow. A valid supplier match does not authorise a payment.
- Destination: map only approved fields into the receiving API; do not copy every model-generated property into a live record.
Give incomplete and disputed results a clear route
Inspect the provider’s completion status before accepting a response. Anthropic documents that refusals and token-limit interruptions can produce responses that do not match the requested schema. An HTTP success response alone therefore does not establish a usable extraction.
Separate technical failure from a business exception. A truncated response may justify a bounded retry with an appropriate output allowance. A missing invoice number or conflicting account match needs new evidence or a person’s decision. Repeatedly asking the model until something passes can hide the original problem.
Give reviewers the proposed fields, the relevant source and a precise failure reason. Record corrections and the decision owner. Keep access and retention proportionate: the review queue should not become an unrestricted copy of every incoming document.
Keep extracted text separate from executable instructions
OWASP identifies improper handling of model output as a security risk when it reaches other systems. Treat extracted text as untrusted input even when it arrives inside valid JSON. Use parameterised database operations and appropriate output encoding when displaying it.
A supplier note belongs in an approved text field. It should not become a database query, shell command, arbitrary download URL or instruction to change permissions. Restrict destination actions in application code. Schema validation helps define the boundary but does not replace these controls.
Measure accepted work before expanding automation
Start with a redacted set of representative documents and independently checked expected results. Include missing fields, credit notes, unfamiliar layouts, ambiguous dates and conflicting identifiers. Compare important fields individually; one overall accuracy figure can conceal failures in amounts or account matching.
Track incorrect records accepted automatically, correct records unnecessarily held, reviewer time and unresolved exceptions. Stricter rules can increase review work. Loose rules can move mistakes downstream. Set the balance according to the consequences of the action, and keep a sample of accepted records under review.
Repeat these focused checks when prompts, schemas, models or document sources change. Your next step is to choose one document type and write its acceptance rules with the operational owner. If the rules cannot yet be stated clearly, keep the workflow at draft preparation while the team resolves them.