A data contract is a staffing decision, not a schema

Data contracts get introduced as a schema problem. A producing team publishes a definition, consuming teams validate against it, and the pipeline fails loudly instead of quietly. That part is straightforward and mostly solved by tooling.

The part that is not solved by tooling is what happens when the contract breaks. Someone has to be accountable for the producing system, available when it fails, and empowered to refuse a change that would break a downstream consumer. If that person does not exist, the contract is documentation.

This is why contract programmes tend to succeed in organisations that already have clear system ownership, and stall in organisations that do not. The contract exposes the ownership gap; it does not close it.

Our practical advice is to introduce contracts on the three or four datasets that already have a named owner, prove the discipline there, and use the results to argue for ownership on the rest. Rolling contracts out across an estate with no owners produces a great deal of validation and very little reliability.