Data Contract

Data contracts exist because of a structural asymmetry in most data estates: the producer is an application team optimising an operational database for its own needs, and it has no idea that forty downstream tables depend on the shape of one column. A refactor ships, the pipeline breaks or worse silently changes meaning, and the data team finds out from a business user.

A contract turns that implicit dependency into an explicit one. It specifies the schema with types and nullability, the semantics — what the field actually means, its unit, its valid values, what a null signifies — the quality guarantees such as uniqueness and referential integrity, the delivery commitment for freshness and completeness, and the change policy covering compatibility and notice periods.

What makes it a contract rather than documentation is enforcement: it is a file in the producer's repository, validated in the producer's pipeline, and a breaking change fails their build. That placement is the whole point, and it is the part organisations skip when they implement contracts as a catalogue field.

The cultural precondition is harder than the technology: producers must accept accountability for data as a product with consumers, and that is an operating model change, not a tooling purchase.