The data contract nobody wrote is the one that broke your AI feature

Two teams sit on either side of a table. One produces the data. The other feeds it to a model. They have never written down what passes between them.

That gap sounds harmless. It is where a surprising number of AI features go to die.

The handshake was always verbal

A product manager whose whole job is moving data out of fragmented SaaS apps into a warehouse described the pattern without meaning to. Her connectors pull from systems her team does not own. Someone upstream builds a field, names it, decides what goes in it, and ships. Her side reads that field and trusts it. There is no document that says the field will keep meaning what it meant last quarter. There is only a habit that held yesterday.

That is a contract. It is just an unwritten one. And an unwritten contract has no version, no owner, and no alarm when it is broken. The producing team can rename a column, change a type, or start allowing nulls, and nothing on their side tells them a model three teams away depended on the old behavior.

Silent degradation is the tell

Here is what makes this so hard to catch. When the contract breaks, the pipeline usually keeps running. No error, no failed job, no page. The data still arrives. It is just wrong, or partial, or shaped differently than the model was trained to expect. The model does what it always does with bad input. It produces a plausible answer that happens to be worse.

AI features generally need something on the order of 85% data accuracy before they hold up, and below that errors start to compound. A quiet contract break can drag you under that line without a single red light on any dashboard. So the model team does the natural thing. They assume the model regressed. They retune it, adjust prompts, swap a version. None of that touches the real problem, because the real problem is a field that changed meaning on a team they never talk to.

What a written contract actually pins down

A data contract is not a heavy document. It is a short agreement between the team that produces a dataset and the teams that consume it, and it pins down a few things that were always assumed:

The shape. Which fields exist, their types, and whether they can be null.
The meaning. What “status” actually encodes, what units a number is in, what a blank really represents.
The freshness. How current the data is promised to be, and what “stale” means for this feed.
The change process. How the producing team signals a breaking change, and who they tell before they ship it.

The value is not the paperwork. It is that a breaking change now has to be a decision someone makes on purpose, instead of a side effect nobody noticed. When the producing team goes to rename a field, the contract is the thing that says, quietly, other people are counting on this.

Contracts turn a mystery into a diff

Once the agreement is written, a broken feed stops being a mystery and becomes a diff. You can compare what arrived against what was promised and see, in one line, that a column that was never null is now 12% empty. That is a very different Monday than staring at a model whose output slid and having no idea why.

The teams that ship AI features reliably treat the boundary between producer and consumer as a real interface with a real spec. The teams that stall treat it as a hallway conversation that happened once and was assumed to hold forever. It rarely holds forever.

How we approach it at Density Labs

In the AI Opportunity Assessment, our fixed two week, $2,500 engagement, we map every data source a feature depends on and ask a blunt question about each one: is there a written agreement on its shape and freshness, or just a habit that has held so far. Where the answer is a habit, we flag it, because that is the exact seam where a silent upstream change will one day starve the model. We would rather draft that contract in week one than debug its absence in month four.

The feed that has no written contract is the feed that will change on you, and you will blame the model.