It is three in the morning and a critical report came up empty. The investigation begins and, hours later, the cause is found: a team from another area renamed a column at the source, not knowing that half a dozen pipelines depended on it. This scenario repeats in companies of every size. Data contracts exist to end it.
The problem of pipelines that break without warning
Data flows between teams: those who produce it (an application, a system) and those who consume it (reports, models, other teams). The problem is that producers often do not know who depends on their data — they change a field, a format, a meaning, and downstream everything breaks silently. Trust erodes with each such surprise.
What a data contract is
A data contract is an explicit agreement between producer and consumer about the shape and meaning of the data: which fields exist, of what type, what they mean, with what quality and frequency they arrive. Like an API contract, it makes the promise formal — and verifiable — instead of an implicit assumption discovered broken when it is already too late.
What a good contract defines
- Schema: the fields, types and structure — and the guarantee they do not change without warning.
- Semantics: what each field actually means (what counts as "active customer").
- Quality: rules the data promises to meet (no nulls here, values in this range).
- Change commitment: how and with what notice you are warned before something changes.
The mindset shift: data as a product
Data contracts are part of a bigger idea — treating data as a product, with a responsible owner, and not as a byproduct that is dumped for someone downstream to sort out. Producers gain responsibility over consumers, and that responsibility changes everything: data stops breaking through carelessness.
How this avoids the 3am disaster
With a contract in place and automatically verified, the dangerous change is caught at the source: when the producing team tries to alter the schema, validation fails before it reaches production, and the change is coordinated with those who depend on it. The problem stops showing up at 3am in an empty report — it is blocked at the entrance, when it is still cheap to fix.
It is not just technology — it is agreement
The technical part (validating schemas, testing quality) is the easy one. The hard and valuable part is the human agreement: teams talking to each other, taking on responsibilities, treating the data they produce with the care of a product. Technology materializes the contract, but culture is what enforces it.
In practice
If you live catching broken pipelines from changes nobody warned about, data contracts are the structural answer — not another patch. Start with the most critical flow: write what it promises, validate it, and agree how changes are communicated. How many of your data failures came, in fact, from a source change nobody agreed on?
