AI GUIDEA valid record can be wrong
Consider this fictional invoice note: “Studio Pine, work completed in October. Total €240 including tax. Payment date not stated.” You want a small record that another application can process.
A valid-looking object could still contain an invented payment date. A field named paid:true would be a serious change in meaning: completion of work does not establish payment. The first design task is to decide what each field means and what to do when the source does not answer it.
Structured output constrains the shape of an answer using a schema, a definition of permitted fields and types. It does not establish that the contents are true. Keep syntax validation, source verification and business decisions as separate checks. Prerequisites: context in A08 and the tool boundary in CA03.
Also handle refusals and output-limit interruptions before accepting a response as a complete schema-conforming result.
Make unknown explicit
Illustrative extraction: {"supplier":"Studio Pine","total":240,"currency":"EUR","payment_date":null,"payment_status":"unknown"}. Add a source reference such as “note-1” rather than presenting this as a verified bank transaction. Whether null is allowed must be part of your schema.
A useful instruction is: “Extract only facts stated in the supplied note. For each requested field, preserve missing information as unknown. Do not infer payment from completed work. Return a source reference and flag contradictions.”
Then validate the business meaning. Is €240 the tax-inclusive total or a subtotal? Does the supplied note actually identify an invoice number? Should a date without a year be preserved as text rather than guessed? These decisions belong in your extraction contract before you connect a payment system.
Give the right evidence
The context window is the material a model can process within a request, including relevant conversation and tool results. More material is not automatically better material. An obsolete price sheet next to a current invoice can create ambiguity.
If you retrieve documents, retain their identity, date and access scope. Retrieval-augmented generation, often called RAG, means supplying retrieved material to help generate an answer; it does not retrain the model or make every retrieved passage authoritative.
In our example, pass the invoice note and a short extraction policy. Do not attach every unrelated client document. If a second note says €260, return a conflict and both references rather than silently choosing one. This is an application design recommendation, not a claim that a particular retrieval system has been tested.
Build a small evaluation
Create four synthetic cases: an ordinary complete note, a missing payment date, conflicting totals and text that tells the assistant to ignore the extraction policy. Write the expected facts and allowed unknowns before looking at model outputs. Evaluate the last case as untrusted document content, not permission to change the task.
Check three layers: does the result satisfy the schema; can each populated field be traced to a source; does it avoid an unauthorised business action? A result can pass the first layer and fail the other two. If a model grades another model, retain a human-checkable rubric and review disagreements.
Exercise: add a case with two different currencies. A good design keeps the amounts distinct unless conversion was explicitly requested with a source and date. Record failures and rerun the same cases after changes. A few passing examples demonstrate those cases only; they do not establish general accuracy or exam readiness. Next: CA06 brings these decisions together.
Sources
Read the original sources to explore the topic and check specific claims.