Data Contracts: The Idea. The Reality

Data contracts had a hype cycle. Around 2022 the term was everywhere – conference talks, vendor pitches, LinkedIn essays declaring that contracts would solve the upstream-data-changes-broke-the-pipeline problem once and for all. Three years later, the term is quieter and the problem isn’t solved, which is roughly what tends to happen when a sensible idea gets sold as a silver bullet. Worth unpicking what the idea actually is, what the hype overpromised, and what survives.

The idea

A data contract is an explicit, machine-readable agreement between the producer of a dataset and its consumers, covering schema, semantics, freshness, quality expectations, and ownership. The producer commits to what they will publish; the consumers commit to what they will rely on; changes go through a process that respects both sides.

The pitch is that this fixes the recurring failure mode of analytics engineering: someone on a product team renames a column or drops a field, and three downstream pipelines break two days later when the next dbt run discovers it. The contract would prevent the rename from shipping without coordination. Producers would know who depends on them; consumers would know what guarantees they had.

The shape of a real contract is usually a YAML or JSON file in version control. It defines the schema (column names, types, nullability), the semantics (what each column means, in prose), the quality rules (this column is never null, this one is unique), the SLA (refreshed daily by 8am, with 99% completeness), and the ownership (who’s on the hook when it breaks). Consumers reference it; CI breaks if the producer changes something incompatible.

What the hype overpromised

Three things, mostly.

First, that the contract would write itself. It won’t. Someone has to articulate what each column means, what the quality expectations are, what the SLA is. This is work the producer team usually hasn’t done and would rather not start. Tools that “auto-generate” contracts from the existing schema just give you a schema, not a contract; the meaning and the expectations aren’t in the data dictionary because nobody’s written them down anywhere yet.

Second, that the contract would solve organisational problems through technical means. The reason upstream teams break downstream consumers isn’t that they don’t know how to write a YAML file. It’s that they don’t know who depends on them, and even when they do, they’re not incentivised to care. Writing the contract makes the dependency explicit. It doesn’t make the producer take it seriously. That’s a culture and incentive problem, not a schema problem.

Third, that the contract would prevent change. It doesn’t and shouldn’t. Schemas evolve. Business logic evolves. The contract’s job is to make the change explicit, versioned, communicated – not to freeze the data in amber. The teams that took the contract as a barrier rather than a process found themselves either bypassing it or strangling product velocity.

What survived

The good ideas are still good, just deflated. What teams that took contracts seriously kept doing:

• Schemas in version control, alongside the producer code, with CI breaking on incompatible changes.
• Explicit consumer registration. A consumer signs up to depend on a producer’s dataset; the producer can see the list.
• Quality expectations expressed as code (Great Expectations, dbt tests, Soda). Failures break the pipeline rather than silently passing dirty data downstream.
• SLAs that get monitored. Refreshed by 8am is only an SLA if there’s an alert when it’s 9am and the table hasn’t arrived.
• A change process for breaking changes – deprecation period, notification, migration support. Not a freeze.

None of these need a tool called “data contracts” to work. Most teams that succeed are doing the same things under different names – schema-as-code, semantic models, data product specifications. The label is less important than the discipline.

Where it gets ideological

The strongest version of the data contracts argument is that the application engineers should write them, with the data team consuming the contracts and pushing back when they’re inadequate. This pairs with the “shift-left” framing of data quality – moving the quality concern upstream to the producers, where it’s cheaper to address than downstream where it’s discovered.

It’s a good argument in principle. In practice, it requires application teams to care about data analytics, which most of them don’t, and to take on work they don’t currently do. The mandate has to come from somewhere with the authority to enforce it – usually a CDO or CTO with a strong governance backbone. The companies where this works have leadership investment. The ones where it doesn’t are usually trying to drive the change from a data team that doesn’t have organisational standing to require anything of product engineering.

The honest position

Data contracts are a useful concept dressed in vocabulary that overpromises. Read them as “explicit, versioned, monitored agreements about data” and they’re obvious good practice. Read them as “a tool you adopt to fix upstream-downstream coupling” and you’ll be disappointed.

The work is the same as it ever was: documenting what you produce, monitoring what you consume, making changes deliberately, and giving the people on either side enough visibility to coordinate. The label doesn’t matter. The discipline does.

Next week – lineage. Specifically, why your lineage tool is probably lying to you, and what column-level lineage actually requires.