Most data quality programmes fail because they try to fix data after it has been produced. Contracts move the obligation upstream, to the only place where it can actually be met.

The familiar pattern: a dashboard breaks, an analyst investigates, and discovers that an upstream team renamed a column three weeks ago. Nobody told anyone because nobody knew who was downstream. A governance committee is convened. A data catalogue is purchased. Six months later the same thing happens with a different column.

The structural problem is that producers have no idea who depends on them and no obligation to anyone. Documentation does not fix that. Contracts do.

What a contract actually is

A data contract is a versioned, machine-readable agreement between a producing system and its consumers. It specifies the schema, the semantics, the freshness guarantee, the quality expectations, and the process for changing any of them.

  • Schema — fields, types, nullability, enumerated values.
  • Semantics — what "order_date" means, in which timezone, at which point in the process it is set.
  • Quality guarantees — uniqueness, referential integrity, accepted ranges, expected volume.
  • Freshness — how late the data may be before consumers should treat it as stale.
  • Change policy — notice period, deprecation window, who must be told.

Crucially, the contract is enforced in CI. A producer cannot merge a breaking change without either updating the contract — which notifies consumers — or failing the build.

Start with one painful interface

The failure mode of contract initiatives is attempting to cover everything. Pick the single interface that causes the most incidents and contract that one. Prove it works. The second is easier because the tooling exists and someone has felt the benefit.

We introduced contracts on one interface at a components manufacturer. Within a quarter, three other teams had asked for the same treatment. Nobody had to mandate anything.

Why this works when governance did not

Governance committees produce documents. Documents drift from reality the moment they are published, and nothing enforces the gap. A contract lives in the repository next to the code, is tested on every commit, and breaks the build when it is violated. It cannot drift, because drift is a failure.

It also changes the conversation about ownership. "Who owns this table" is a political question. "Which team's CI breaks if this contract is violated" is a factual one.

What we look for first

The interfaces where an incident has occurred more than twice, and the ones feeding a decision with real financial consequence. Those two lists usually overlap more than people expect.

The AI connection

Every machine learning system is a data consumer with unusually strict requirements and unusually quiet failure modes. When a schema changes, an application throws an error; a model silently degrades. Feature pipelines are the highest-value place to apply contracts and, in our experience, the last place anyone thinks to.

If you are planning an AI programme and your feature inputs are uncontracted, you are scheduling a production incident. You just do not know the date yet.