Data contracts work exactly where people said they would

Data contracts had their hype cycle around 2023, complete with the claim that they would reorganize companies. They did not reorganize companies. What survived the discourse is smaller and better: a machine-checked agreement about schema and semantics at the boundaries where teams hand data to other teams.

The mechanics are now commodity. dbt's model contracts enforce column names, types and constraints at build time, so a breaking change fails in CI on the producer's desk instead of at midnight on the consumer's dashboard. Equivalent enforcement exists at the ingestion and schema-registry layers. The tool was never the hard part.

what practice taught

Contracts pay at boundaries, not everywhere. Contracting every internal staging model buries teams in ceremony; contracting the twelve models other teams actually consume converts surprise breakage into a reviewable pull request. The teams that report contracts "didn't work" almost always applied them uniformly, which is to say, indiscriminately.

The second lesson is that a contract without an owner is a comment. Enforcement requires someone empowered to reject a change, and a paging path when the check fails. Schema files do not attend incident reviews.

what a working contract actually contains

The word contract suggests law, and the analogy holds better than its authors intended. A useful one has five clauses. The schema: column names, types, nullability. The semantics: what a row means, what the grain is, which time zone the timestamps pretend to be in. The freshness promise: when the data lands and how late counts as late (enforcement is a scheduled query, the first of the four-check quality floor). The change process: how a producer proposes a breaking change and how long consumers get to object. And the escalation path: who gets paged when the check fails, which is the clause that separates a contract from a wish.

Most published examples stop at the first clause. Schema is the easy part, which is why the tooling commoditized it first. The teams getting real value wrote the other four clauses in prose, in the same file, where the CI check can at least keep them visible even when it cannot enforce them.

the failure modes we keep seeing

Two patterns account for most contract programs that quietly stall. The first is contracting downward. Platform teams impose contracts on producers who never agreed to be producers, usually application teams whose database exhaust was annexed into analytics years ago. The contract then formalizes a relationship the producer never wanted, and the first breaking change becomes a negotiation between a team with a pager and a team with different priorities. Contracts formalize agreements; they do not create them.

The second is versioning theater. A producer who can ship v2 alongside v1 indefinitely has not signed a contract, they have opened a museum. Old versions accumulate, consumers never migrate, and the platform pays storage and confusion for both. A working change process has a deprecation clock that actually expires, and an owner willing to let it.

the economics, briefly

The cost of a contract is a slower producer. Every enforced boundary adds a review step to changes that used to be free, and producers notice immediately. The benefit lands on a different team's budget: fewer midnight breakages for consumers, fewer archaeology sessions for whoever owns the dashboard. That asymmetry is why grassroots adoption stalls, and why the programs that survived were sponsored a level up, where both budgets roll into one number. The pattern is old: quality gates get funded by whoever pays for both sides of the incident.

What we could not find, three years in, is a credible negative result at genuine boundaries. Teams abandon contracts everywhere else; at real team boundaries with named owners, they keep them, renew them, and stop writing about them.

One measurement note for anyone trying to build the internal case: do not count contracts written, count breakages that arrived as pull requests instead of incidents. The first number rewards ceremony and grows fastest in the programs doing the least. The second number is the product. A team that can show six months of would-have-been incidents caught at review time has an argument no slide about coverage percentages can match, and the query to produce it takes an afternoon.

where the discourse went instead

The people who predicted reorganization moved on to data products, then to data as a product, then to whatever the current noun is. The arc deserves its own review someday: an idea arrives attached to an org-chart revolution, fails to revolutionize, and the useful mechanical core gets adopted by the unfashionable teams who never blogged about it. Contracts joined dbt tests and schema registries in the toolbox of things that simply run. There are worse fates for a technology than becoming boring, and most of them involve staying interesting.

verdict

Worth adopting, at boundaries, with owners: the evidence from teams running them this way is consistent and undramatic, which is the best kind of evidence. The maximalist version (contract everything, reorganize the company) remains marketing. As usual, the technology was ready before the org chart, and the org chart is where the actual contract gets signed.