Validate the structured output before you trust the fields

A lead developer at a property-management company found a bad row in a table that feeds tenant billing. A field that should hold a positive number held a negative one. It had come from an AI feature that read a document, produced a structured object, and wrote that object to the database. No human had touched it on the way through.

The object had parsed fine. It was well-formed. Every field the schema named was present, and the JSON was valid. The problem lived one level deeper. A value that parsed correctly was still wrong for the business, and nothing had checked for that between the model and the system of record.

Parsing is not validation

The team had done part of the work. They asked for structured output, they parsed it, and when the parse succeeded they treated the data as good. That is the gap. A successful parse tells you the shape is right. It tells you nothing about whether the values make sense.

A number field can parse and be negative when your domain only allows positive. A date field can parse and sit in the year 1900 or 2999. A string field can parse and be empty when it is required to have content. A field can parse and hold a value that is fine on its own but contradicts another field in the same object. Parsing checks the grammar. It does not check the meaning, and the meaning is what your database and your billing run actually depend on.

The reason this slips through is that parsing feels like the finish line. You went from a messy free-text world to a clean typed object, the parse succeeded, and the relief of that makes it easy to stop. But the model’s structured output is a claim, not a fact. It is the model’s best guess at the right values, wrapped in the right shape. The shape is now trustworthy. The values still need to earn it.

Validate against types, ranges, and presence

The fix is a validation step that sits between the parsed object and anything real, and checks the values, not the shape:

Check types beyond the parse. Confirm a number is actually a number in the range you expect, not a string that happens to look numeric, and not a value the parser accepted loosely.
Check ranges and bounds. A quantity should be positive. A date should fall in a sane window. A percentage should sit between its limits. Reject values outside the bounds your domain allows.
Check required fields are present and non-empty. A field can appear in the object and still be blank. Confirm the ones you depend on actually carry content.
Check cross-field consistency. When two fields have to agree, verify they do. An end date before a start date parses cleanly and is still wrong.
Reject on failure, do not write. If validation fails, stop. Retry, flag for review, or route to a fallback. Nothing that fails validation should reach the system of record.

The rule is that a system of record deserves validated data, and the model’s output is not validated just because it parsed. You would not write an untrusted API response straight to your database without checking it. A model’s structured output is an untrusted response with a friendly shape. Treat it the same way.

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 trace the path from the model’s output to wherever it lands, and we look for the validation gate that should sit in between. Often it is missing, because the parse felt like enough. We add a step that checks types, ranges, required fields, and cross-field agreement, and we make it reject rather than write on failure. Catching a negative quantity at that gate costs nothing. Catching it in a tenant’s bill costs a lot more than money.

A parse tells you the shape is right. Validation tells you the value is. Do both before you write.