The data contract grew up. It stopped being a schema and started being a governance control.

A contract is a promise about the shape of data. The interesting question is never the shape. It is who has to keep the promise when the column changes underneath it.

What happened: the data contract has migrated from a build-time nicety to a governance instrument. dbt's model contracts now refuse to build a model whose output does not match the declared columns, types, and constraints — the agreement is checked before data is written, not after it breaks a dashboard. The practitioners who developed the pattern, Andrew Jones (who published it in 2021) and Chad Sanderson (who reframed it as governance-as-code), describe the same move: pin the expectation, enforce it at the source.

Why it matters: enforcement relocates accountability. A test that fails after the fact files a complaint; a contract that fails the build assigns a debt to whoever owns the producing model. Buying a tool that breaks the build is one purchase order. Deciding who is blamed when it does is a commitment nobody volunteered for.

What it reveals about the field: we are good at the mechanical half of trust — schema, types, merge gate — and shy about the social half. A contract encodes what the data means and who answers for it. With no owner, it points at an empty chair. The drift moved from the data to the org chart.

What to watch: watch where the contract is owned versus written. Consumer-defined, producer-owned is Sanderson's design; the failure mode is a contract a downstream team authored that no upstream engineer agreed to honor. When the first breaks a build, the argument over who fixes it is the real governance program. The rest was tooling.