The required field the model skipped and the optional one it always filled

An engineering manager at an e-commerce company noticed an odd asymmetry in his logs. One field in the model’s output was always there, filled in cleanly every single time. Another field was there most of the time and missing every so often. The frustrating part was which was which. The always-present field was one his code barely used. The intermittent one was required.

His prompt asked for both, along with several others. From the model’s point of view they were all just fields to produce. From his system’s point of view they were not equal at all. One could be absent with no harm. The other, when absent, broke the record that depended on it.

Asking is not requiring

The team had assumed that listing a field in the prompt meant the model would always return it. That is the assumption the missing field quietly disproved. A model producing structured output decides, per call, what to include. It leans on the input in front of it. When the source document clearly contains a value, the model fills the field. When the document is thin on that value, the model sometimes leaves the field out rather than guess, and sometimes fills a different field that the document happened to make easy.

So you get this asymmetry. A field that is easy to extract from most inputs gets filled reliably, whether or not you care about it. A field that depends on information the input does not always carry gets filled intermittently, even when you care about it a great deal. The model is not ranking fields by your needs. It is responding to what each input makes available. Presence tracks the input, not your requirements.

Design for the fields that go missing

The fix is to stop treating field presence as guaranteed and start engineering for it, the same way you would with any data source that can return an incomplete record:

Mark required fields explicitly. Use the schema to declare which fields must be present. Where the model supports required-field constraints, turn them on so it is pushed to produce them.
Validate presence before use. After parsing, check that every required field is actually there and non-empty. Do not let a record with a missing required field flow downstream.
Design a default or a retry for omissions. Decide in advance what happens when a required field is absent. Retry the call, fall back to a safe default, or route the record for review. Have the answer ready before it happens.
Do not trust reliability you have only seen so far. A field that has always been present in testing can go missing on an input you have not tried. Handle the absence in code, not in hope.

The lesson is that structured output is a set of fields the model may or may not populate, driven by the input, and your required fields need enforcement and a plan for when they are missing. The field the model always fills is not a sign the system is healthy. It is a sign that field is easy. The field that matters is the one you have to defend.

How we approach it at Density Labs

In the AI Opportunity Assessment, our fixed two-week, $2,500 engagement that scopes real production work before you build, we separate the fields a feature merely lists from the fields it actually depends on, and we check whether the required ones are enforced and validated for presence. Usually they are not, because in testing they showed up. We mark them required, add a presence check, and design the default or retry for the day one goes missing. It is much cheaper to plan for an absent field than to explain a broken record after the fact.

The model fills what the input makes easy. Defend the fields you cannot do without.