Valid JSON is only the start of a reliable AI workflow.

Define the record before the prompt

Suppose your team needs to turn supplier emails into a table of requested items. Before choosing a model, write a small record definition: source reference, item description, quantity, unit, requested date, and review status. Decide what happens when the email does not contain a value. An explicit missing value is easier to audit than a plausible guess.

This is a workflow design guide, not a measured extraction benchmark. Use a small set of invented or properly authorized examples while you develop the process. Keep source documents separate from derived fields so corrections remain possible.

Separate structure from correctness

A JSON parser answers whether the response has valid syntax. A schema validator can check whether fields have the expected types and permitted values. Neither step proves that a quantity or delivery date matches the original message. Treat evidence checks as a separate stage.

Google documents structured output with a supported subset of JSON Schema and advises applications to validate values. Its feature support can change, so check the documentation for the exact model and schema you plan to use. Do not assume that every validation keyword is enforced by the generation service.

Make missing and uncertain cases visible

Our suggested record has a review flag and a reason, rather than an invented numerical confidence score. A message saying ‘the same amount as last time’ cannot establish a quantity without additional authorized context. The workflow should preserve that ambiguity instead of filling a required number arbitrarily.

Define the difference between a missing field, an explicitly empty field, and a failed extraction. A source may omit a requested date while clearly stating the quantity. A single generic error state can hide which parts of the record remain usable.

• Require a stable source identifier for every record.
• Keep extracted values and reviewer corrections in separate fields.
• Check dates and units against your business rules.
• Record why a result was rejected or routed for review.

Bound the retry and approval path

Decide how many attempts a record can consume before it needs review. Repeatedly asking for a new answer can increase cost while hiding a difficult example. Retain enough diagnostic information to distinguish transport failures, invalid structure, and missing evidence.

An extractor should produce a proposed record. Your application should decide whether it may be saved or used in a downstream action. Avoid giving untrusted source text a route to change access permissions or execute arbitrary commands. This is an architectural recommendation; a prompt by itself is not an access control.

Measure the pilot before scheduling it

Prepare expected answers for a manageable sample and compare the actual records field by field. Include emails with multiple items, missing dates, conflicting units, and irrelevant text. Count accepted records separately from records that needed editing.

Keep the provider, model version, schema version, and test date with the results. Calculate the cost per accepted record, including review time when that matters to the decision. A useful pilot ends with a list of known failures and an owner for the next review.

A related practical decision

• Decide between an AI agent and a fixed workflow ↗