Validate the output, not just the input

A platform engineer at an e-commerce company told me they had been careful about inputs. They stripped suspicious characters, capped lengths, checked types, the discipline you build up over years of handling user data. Then whatever the model returned went straight to the customer. One day a response came back in the wrong format and a downstream page broke; another day one came back with a claim the company would never make. Both passed through untouched, because the team had guarded the door coming in and left the door going out wide open.

Clean input does not guarantee clean output

Input validation protects you from what the user sends. It does nothing about what the model produces, and those are separate risks. A model given perfectly clean input can still return malformed JSON, a number outside the allowed range, a tone that violates policy, or a confident statement that is simply wrong. The input was fine. The output is the problem, and the input gate never looked at it.

The engineer’s team had an old habit working against them. In a normal system, you validate at the boundary where untrusted data enters, and everything after that is your own code, which you trust. A model breaks that model. The output is not your own code. It is generated, variable, and capable of producing something you would never have written, yet it sits inside your trust boundary as if it were safe. So it flowed straight to the customer with no one checking, because the mental map said everything past the input gate was already clean.

That is the gap. The team had one gate, at the entrance, and treated the model as trusted infrastructure. The model is closer to an untrusted source that happens to live in the middle of your system.

Give the output its own gate

The fix is to add a second validation step, on the way out, that is independent of the input checks. Before any model output leaves the system or triggers an action, it passes through code that confirms it is well-formed, in range, on policy, and safe. If it fails, you regenerate, fall back, or block, but you do not ship it.

This gate treats the model’s output the way you already treat user input: as something that must earn its way through, not something you accept because of where it came from. The e-commerce team did not need a smarter model. They needed to stop trusting the model’s output just because their own code was sitting next to it.

Here is what the output gate should do.

Check structure before anything downstream reads it. Confirm the output parses and matches the schema the next step expects, so a malformed response fails here instead of breaking a page.
Enforce value ranges and allowed sets. Verify numbers, categories, and identifiers fall inside what is valid, and reject anything outside.
Screen against policy on the way out. Check for content the feature must never emit, independent of what the input looked like.
Regenerate or fall back on a failure. When output fails the gate, retry within a cap or return a safe default, so a bad response never reaches the user.
Log what the gate rejects. Record the failures, because they tell you your real output quality and where the generation needs work.

Two gates, not one. The input gate keeps bad data out. The output gate keeps bad output in, where it can be caught before it does anything.

How we approach it at Density Labs

In the AI Opportunity Assessment, our fixed two-week, $2,500 engagement, we look at both boundaries of every AI feature, and the output boundary is the one teams almost always skip. They have carried good input hygiene over from the rest of their system and assumed it covers them, when the risk has moved to the response the model generates. We put a validation gate on the output, wire up the retry and fallback behavior, and make sure nothing ships to a user or fires an action without passing it. It is far cheaper to add that gate before launch than to explain a bad response to a customer after.

You already validate what comes in. The model’s output is a new source of untrusted data, so validate what goes out too.