How do we stop it inventing values for missing fields?

Make the field optional, describe explicitly what to do when the source does not contain it, and check for the empty case downstream. A required field reads as an instruction to fill it. The most reliable extraction setups treat not found as a legitimate answer rather than as a failure.

Does asking for a shape make the answers worse?

Occasionally on tasks needing nuance, because a form has nowhere to put a qualification. Where that matters, a free-text field alongside the structured ones gives the model somewhere to note what the shape could not hold, and gives a reviewer something worth reading.

What should we check before trusting it in a pipeline?

Run your awkward documents through it, not the tidy ones: the unusual layout, the missing detail, the two dates where one was expected. What comes back on those decides whether the arrangement survives contact with real material, and it is a half-day that saves a great deal of quiet mess.

Glossary

Structured output

Structured output means making a model answer in a fixed shape with named fields, so the next piece of software can read the reply directly instead of a person interpreting a paragraph.

In plain terms

A form rather than a letter. Ask a model to summarise an invoice and you get prose that a person can read and nothing else can. Ask for a fixed shape with named fields and you get something a spreadsheet, a database or the next piece of software in the chain can consume without anybody in between. That difference is what turns an assistant into a component.

Why it matters

It is the step where a model stops being a tool somebody uses and starts being part of a system. Anything unattended needs a reply of a predictable shape, because software cannot read around an unexpected sentence the way a person does. Getting this right is usually the difference between an automation that runs for months and one that breaks the first week somebody's invoice arrives in an unusual format.

How it works

You describe the shape you want, field by field, and the model produces something matching it. Where a provider supports enforcing that description, the reply is checked against it before you receive it, which is a genuinely different guarantee from asking politely and hoping.

Being well-formed and being right are separate. A reply can match the shape perfectly and contain a date the document never mentioned or a total nobody can find. Shape enforcement removes an entire class of parsing problems and none of the accuracy ones, which is worth saying because the neatness is persuasive.

The awkward part is what happens when the answer genuinely is not there. A shape with a required field pressures the model to fill it, and filling it is exactly the behaviour you least want. Making fields optional, and providing an explicit way to say the document does not contain this, removes a great deal of quiet fabrication.

It works best when the fields are named the way a person would name them and described as though for a colleague. Cryptic names produce worse results, for the same reason a badly labelled form does: the model is reading those names for meaning rather than treating them as identifiers.

The same invoice, read into a shape

Six fields, and two of them are doing more work than they appear to. The total is well-formed, which is exactly the property that makes it persuasive and says nothing at all about whether it matches the page. That is the trade this technique makes: it removes every parsing problem and no accuracy problem, and the tidiness of the result quietly encourages people to stop checking. The due date is the more interesting line. Left required, a model with no date to find would supply one, because a required field reads as an instruction. Left optional, with somewhere to explain, the absence is recorded as an absence and a person can act on it. Designing for the missing case is most of what separates an extraction step that survives real documents from one that produces confident nonsense on the fifth of them.

Seen in the wild

Extract named fields from documents in an automation step and pass them straight to the next system, which is this working as intended.
n8n
Ask for the same summary twice, once as prose and once as a fixed set of fields, and notice how differently you can use the two replies.
ChatGPT
Push extracted fields into a record where a wrong shape would fail visibly, which is a cheap way of catching what a tolerant step would swallow.
Attio

Common misconceptions

People assume

If the shape is right the content is right.

In fact

The two are unrelated, and neat output is more persuasive than prose, which makes this the more dangerous direction of error. A perfectly formed record with an invented date passes every automatic check and fails the only one that mattered. Shape removes parsing problems and nothing else.

People assume

Every field should be required, to be safe.

In fact

Required fields are an instruction to produce something, and a model with nothing to produce will produce something anyway. Optional fields, and an explicit way of recording that the document did not say, convert quiet fabrication into a visible gap somebody can act on.

Telling them apart