Data Contracts Are Promises, Written Down

A data contract is a promise between the team that produces a piece of data and the teams that depend on it. That is the whole idea, and it is worth stating plainly, because most conversations about data contracts drift quickly into tooling and formats and lose the point. The point is the promise. Most data breaks not because the technology failed, but because the promise was never written down — and so was never really made.

In any organisation of scale, teams consume each other's data constantly, and they do it on a web of unspoken assumptions: that a field will keep its meaning, that a figure will arrive on time, that a column will not quietly disappear. These assumptions usually hold, right up until the day a producing team makes a sensible change to its own system with no idea who downstream was relying on the old behaviour. Nothing malicious happens. Something simply moves, and three weeks later a report is wrong and nobody can say why.

An interface, not a document

A data contract makes those assumptions explicit and mutual. It states what the data is, what each field means, what quality can be expected, how often it updates, and who is accountable for it. In that sense it is less a document than an interface — the same idea that lets one piece of software depend on another without knowing its internals. The producer commits to the interface; the consumer is free to build on it; and change happens through the contract rather than by surprise.

This is what turns a data product from a nice phrase into something dependable, and it is the missing half of most data mesh efforts. Distributing ownership to the teams closest to the data only works if each of those teams makes a promise the rest of the organisation can rely on. Without contracts, federation is just fragmentation; with them, a team can consume another team's data without having to know, or trust, the team behind it.

The hard part, as ever, is not the specification. It is the commitment to honour it. A contract means treating a breaking change as a breaking change — versioning it, giving notice, supporting the old shape until consumers have moved — rather than shipping it on a Tuesday and dealing with the fallout. That discipline is cultural before it is technical, and it is the part that tooling cannot supply.

The test is simple. Ask a team that depends on someone else's data what exactly they are owed — what they can rely on, and what would count as a breach. If they can point to it, a contract exists, whether or not anyone calls it that. If they answer with a shrug and a hopeful assumption, then they are not relying on a promise. They are relying on luck. Writing the promise down is how an organisation stops depending on luck and starts depending on data.