Back to Intelligence Insider

Intelligence Insider

Data contracts are the missing layer in your AI stack

Your data team built schemas. Your AI team built prompts. Nobody built the contract between them - and that's why your AI gives different answers in dev and…

Bryan Guy, J.D.

Your data team built schemas. Your AI team built prompts. Nobody built the contract between them - and that's why your AI gives different answers in dev and prod.

I've watched this pattern play out in enough AI deployments to name it: the model is not the problem. The prompt is not the problem. The data reaching the model is different than the data your team tested against, and no one wrote down what "the same" was supposed to mean.

That written-down thing is a data contract. And in AI systems, it isn't a nice-to-have. It's the difference between a system you can trust and a system that fails silently in ways no dashboard will surface.

What a data contract actually is

A data contract is an explicit, versioned, enforceable agreement between the team that produces a piece of data and the team that consumes it. Five components:

  1. Schema. Field names, types, nullability. The boring part. Necessary but not sufficient.

  2. Semantic meaning. What each field actually represents in the world. revenue_usd means net revenue after refunds, not gross bookings. NULL in a consent field means suppression, not missingness.

  3. Freshness SLA. How stale is this data allowed to be before consumers should treat it as invalid? Ninety seconds? Twenty-four hours? Real-time?

  4. Error semantics. What happens on the producer side when something goes wrong? Does the row get dropped, get a sentinel value, get a partial payload? The consumer needs to know.

  5. Ownership. A named team, a named on-call, a named review process for changes.

If your data producers can't answer all five for a given feed, you don't have a contract. You have an implicit handshake, and implicit handshakes fail on the day of your biggest customer demo.

Traditional analytics teams have gotten away with fuzzy contracts for years because humans are excellent at catching things that look wrong. An analyst sees a spike, opens a notebook, and figures out that a field got renamed upstream. Total downside: a stale dashboard for a day.

That escape hatch does not exist in AI systems.

Why LLMs amplify contract violations

Here's what makes this different. A language model does not detect anomalies in its inputs. It doesn't flag "this field looks weird." It generates confident, fluent output using whatever it was given.

Feed an analyst a customer record with a missing subscription_tier and they'll pause. Feed the same record to a model and it will invent a plausible tier, or generalize from surrounding fields, or hallucinate a value that looks right and reads well. The output has the same shape as a correct answer. The failure is invisible until a customer complains, a compliance officer asks a question, or an autonomous agent takes an action you can't unwind.

Every missing field is not just a data issue. It's a prompt-injection surface, an audit-trail liability, and a customer-experience risk, all at once - compounded by the fact that LLMs are the most fragile consumers of inconsistent data anyone has ever built.

Analysts fail loudly. Models fail beautifully. That's the asymmetry contracts have to close.

Three places contracts are non-negotiable in AI

1. The feature store

Feature stores are marketed as sources of truth. In practice, they're sources of assumptions. A feature called customer_score in the offline store might use a 90-day window; the online store might use 30 days. Both are labeled the same. The training run learned one distribution. The inference path sees another.

Concrete example. A customer_score feature row has value FLOAT NULL semantics where NULL means "the customer opted out of profiling." That's a contract. If the consumer downstream - a routing agent, a recommendation model, a personalization prompt - interprets NULL as "missing data, impute a default," suddenly your profiling opt-outs are leaking into production decisions. That's not a bug. That's a regulator's dream discovery in an audit.

The contract has to lock down: definition, window, refresh cadence, error semantics, and what the value means when missing. All five.

2. The RAG corpus

Retrieval-augmented generation only works if the retrieved documents mean what you think they mean. Your RAG corpus has a contract whether you wrote one or not: what documents belong in it, when they get updated, how deletions propagate, what happens to embeddings when the underlying source changes.

Miss any of these and your model happily cites a policy that was rescinded three quarters ago, using a document ID that no longer resolves, with citation confidence at 92%. The user sees a fluent, authoritative answer. Your legal team sees a problem.

3. Tool-use return types

The moment you give an LLM tool-calling capability, every tool's return payload becomes a contract. If a get_customer_status tool sometimes returns {"status": "active"} and sometimes returns {"customerStatus": "active", "as_of": "..."}, the model will pattern-match its way through - sometimes correctly, sometimes not. The contract has to specify shape, nullability, error format, timeout behavior, and the exact schema the model was prompted to expect.

Tool contracts are the least discussed of the three, and in agentic systems the highest risk.

How to introduce contracts without stopping feature work

The mistake I see teams make: they decide contracts are important, launch a six-month platform initiative, and freeze all AI work behind it. That approach fails politically and dies technically.

The incremental path:

  • Start with one feed. The one your AI system is most dependent on. Usually a customer or account object.

  • Write a one-page contract. Not a schema registry, not a governance framework. A page. Schema, semantics, freshness, errors, owner.

  • Add contract tests to CI. If the producer breaks the contract, their build fails. Not the consumer's build. Theirs.

  • Version it. v1 today, v2 next quarter, and consumers pin to a version until they're ready to migrate.

  • Repeat quarterly. One new contract per quarter beats any big-bang program.

Momentum matters more than completeness. A contract on your most-used feed is worth more than an incomplete rollout across twenty.

Counterpoint: "Data contracts were 2024 hype that didn't deliver"

Fair. The 2024 wave over-promised. Tooling was immature, DX was miserable, and most teams that tried it bounced off after realizing the political cost of telling every upstream producer they now had to sign a paper for every field.

Two things changed by 2026.

First, the failure mode. In 2024, a broken contract meant a broken dashboard. Analysts routed around it. In 2026, a broken contract means a hallucinated customer response, an incorrect recommendation, or an autonomous agent acting on data that means something different than the agent thinks it means. The recovery cost is qualitatively higher.

Second, the enforcement surface. Contracts used to live in wiki pages. They now live in schema registries with runtime validation, in feature-store metadata layers, and in the OpenAPI specs of the tools LLMs call. Enforcement is finally cheap enough that "we should have a contract" and "we do have a contract" are close to the same sentence.

The urgency is not hype. The urgency is that AI systems have shifted the cost curve of getting data semantics wrong.

A 5-line contract template you can adopt tomorrow

Paste this into a markdown file, fill it in per data product, and check it into the producing team's repo.

Contract: customer_score.v1
Schema:    value FLOAT (nullable), computed_at TIMESTAMP
Semantics: NULL = profiling opt-out. Non-null = 0-100, higher is better.
Freshness: Updated within 15 minutes of source event.
Errors:    Producer failures emit NULL, not a default. Never impute.
Owner:     Customer Data team - #customer-data-oncall

Five lines. That's a data contract. Do it for the feed your AI depends on most. Do it this week.

Your model doesn't need a better prompt. It needs a signed contract on what it's being fed.


Bryan Guy is Founder & CEO of DataBillity, Inc., building Billity AI - a Network-Intelligent AI Sales Agent Platform.

#DataEngineering #AIagents #DataContracts #LLMOps #BuildInPublic

Bryan Guy, J.D.

Bryan Guy, J.D.