An AI assistant can return a beautifully organized record with the wrong customer, the wrong date, and a quantity copied from the wrong line. Software may accept every field without complaint.
That is a practical risk when connecting AI to business software. Structured output makes a response easier for an application to read. It does not establish that the response accurately represents the source or belongs in the destination record.
We build AI integrations that connect models to existing software. For a workflow that turns documents or messages into records, we recommend treating the model’s output as a proposal with several checks still ahead of it.
Understand what the schema proves
JSON is a common format for exchanging named values between systems. A schema describes the expected structure: which fields exist, what types they contain, and which values are allowed.
Structured-output features can constrain a model to produce that shape. This avoids some ordinary integration problems, such as receiving a paragraph when the application expects a list of items.
The scope of that guarantee matters. A field called quantity can contain a valid integer while misreading twelve as twenty-one. A customer identifier can have the right format while pointing to the wrong customer.
Provider support also varies. Anthropic’s documentation describes a supported subset of JSON Schema and exceptions such as refusals or responses cut short by an output limit. Check the response status and the actual supported constraints rather than assuming every successful request contains a usable business record.
Write field meanings before writing prompts
Consider a hypothetical tool-hire business turning emailed reservation requests into draft bookings. A message says, “We need two floor sanders from Friday afternoon, back Monday morning.”
Before evaluating extraction, decide what the destination needs. Does quantity mean individual machines or packages? Which calendar dates do Friday and Monday refer to? Does the booking system require specific pickup times?
We recommend writing those definitions with the people who handle reservations. If the incoming message does not settle a detail, the output should preserve that uncertainty. It should not silently turn “afternoon” into an exact time merely because the booking form requires one.
Keep the original wording available beside any normalized value. A reviewer comparing “Friday afternoon” with a proposed timestamp should be able to see where interpretation entered the process.
Give missing information a real representation
A required field means the field must be present. It does not mean the source contains the answer.
JSON Schema distinguishes an omitted property from a property whose value is null. A schema must permit null if that is how an application represents an unknown value. Merely listing a property does not make it required, and unexpected properties need their own rule.
For our hypothetical booking workflow, we would separate the proposed pickup date from its resolution status. A date could be unresolved because the message is ambiguous, while a quantity could be directly stated. Those two fields should not receive the same treatment.
Avoid placeholder values that look real. Zero machines, today’s date, or an empty customer name can slip into reports if downstream software treats them as completed data. Define how unresolved values stop or redirect the workflow.
Check the record against the destination
Once a proposal has the expected shape, ordinary application checks should assess whether its values make sense together. OWASP distinguishes this semantic validation from checking syntax alone.
For the booking example, check that the return follows the pickup, the requested equipment exists in the catalogue, and the proposed customer matches the intended account. Availability needs a current lookup; the model should not infer it from the equipment description.
Keep authorization separate. A correctly identified account does not establish permission to create or change its bookings.
We recommend performing these checks before a draft becomes an active reservation. If availability changes while someone reviews the proposal, check it again at the point of commitment. A valid result from an earlier lookup is not a promise that the equipment remains available.
Test plausible wrong answers
A formatting test should include malformed records, missing fields, and unexpected fields. A useful workflow test also includes records that are perfectly formatted but wrong.
For the hypothetical hire business, we would test:
- A request that names two different pickup dates.
- A quantity mentioned in a quoted earlier email but changed in the latest reply.
- An equipment nickname that could match more than one catalogue item.
- A customer name shared by two accounts.
- A request with no return date.
- A complete request for equipment that is unavailable.
Write the expected handling for each case before inspecting the output. Some should produce a draft; others should request clarification or remain unresolved. Success should include correctly stopping, not just successfully filling a form.
Make rejection useful
When a check fails, retain a clear reason and enough source context for someone to resolve it. “Return date missing” tells staff what to ask. “Validation failed” sends them back through the entire request.
Do not repeatedly ask the model to produce a passing record without preserving the original uncertainty. That can turn an honest missing value into a plausible invention.
We recommend starting with a draft queue and measuring how much correction it needs. Our guide to evaluating document extraction covers the broader comparison with manual work. If the information already arrives in a reliable structured export, using that export may be simpler than asking a model to reconstruct it.
If you are considering this kind of integration, tell us what arrives and which system needs the result. The useful starting point is the meaning of a correct record, including when no record should be created.