A record can be perfectly formatted and completely wrong. Imagine an AI assistant extracts a delivery date into a neat JSON object. The parser accepts it. Every required field is present. Unfortunately, the date belongs to the previous order mentioned in the same email.
Structured output is valuable because software needs predictable fields. The mistake is asking structure to do the job of evidence checking. A useful workflow treats those as separate gates.
Four questions that should not collapse into one
| Gate | Question | A failure it can catch |
|---|---|---|
| Syntax | Can this text be parsed as JSON? | A missing closing quote |
| Schema | Does the parsed record match the contract? | A string where a number is required |
| Evidence | Does the record agree with the source? | A well-formed but incorrect date |
| Permission | May the system act on this record? | An unauthorized change to an order |
Passing an earlier gate does not establish a later one. An application may also need business rules, duplicate detection and specialist review. These checks belong to the surrounding system, not to the appearance of the response.
Write down the contract before the prompt
Start with the fields the receiving application actually needs. For a hypothetical shipment note, that might be an order reference, a promised delivery date and a short evidence excerpt. Decide how to represent missing information. An explicit null can be better than a plausible guess, provided the schema and downstream application permit it.
The official JSON Schema object reference explains two easily missed details: listing a field under properties does not make it required, and extra properties are allowed by default unless the schema restricts them. Check both when defining an interface. A provider’s supported schema subset may differ, so confirm its current documentation before deployment.
A small example with a large consequence
Consider this invented source note: “Order A17 was delivered Tuesday. For order B42, we are still awaiting a confirmed date.” A tidy output such as the following is syntactically valid:
{
"order_reference": "B42",
"delivery_status": "delivered",
"delivery_date": "2026-11-03"
}Nothing in the note supports that record. The assistant has carried information between two orders and supplied a calendar date the source never gave. A strict schema can reject an invalid status label or date shape; it cannot establish which order the sentence described.
A better extraction preserves the missing date and marks the status as awaiting confirmation. Keep the source excerpt and location outside any field that will be automatically published to customers. Evidence can contain private information and should receive appropriate access controls.
Build tests around the mistakes you care about
- Missing facts: a document with no date should not produce a guessed date.
- Nearby distractors: two orders or people in one paragraph should remain separate.
- Conflicting revisions: an updated instruction should not silently merge with an older one.
- Unexpected fields: an unrecognized output field should be handled according to the contract.
- Boundary values: quantities, currencies and units should be checked together.
Use synthetic examples that resemble the workflow without exposing customer records. Keep the expected answer next to each example. When a test fails, record whether the problem was extraction, schema design or an application rule. That makes the repair more precise than adding another paragraph to the prompt.
Do not let a valid record authorize itself
An output field called approved is just data unless an authorized process assigned that approval. Before an agent sends an email, changes a file or updates an account, check the actual permission boundary. In a low-risk workflow you may allow automatic actions; in another, a person must confirm. Make that decision outside the model-generated record.
Track these gates in the task scorecard, and read the companion guide to instructions hidden in documents. Predictable formatting makes automation easier to inspect. It does not make the information true or the action authorized.
AI-generated conceptual illustration. The example records are invented for explanation.
