The ML pipeline broke because someone upstream changed a column name.

No warning. No communication. Just a silent failure that corrupted a week of predictions.

This is why data contracts exist. And why every ML team should demand them.

A data contract is a formal agreement between data producers and consumers about: what fields will be present, what types they'll be, what values are valid, how frequently the data updates, and who to contact when something changes.

Think of it as an API contract, but for data.

Tools: Great Expectations for validation rules, Soda for data quality checks, custom JSON schema validators, or even a well-maintained document that everyone agrees to follow.

The minimum viable data contract for ML: a schema definition (field names, types, allowed values), freshness requirements (data must arrive by X time), quality thresholds (null rate below 1%, no duplicate keys), and a notification process for breaking changes.

When a producer wants to change something, they notify consumers first. The consumers test the impact. Changes are coordinated, not surprising.

It sounds bureaucratic. It saves enormous pain. The cost of one data pipeline failure — debugging time, corrupted predictions, lost trust — far exceeds the cost of maintaining data contracts.

If your ML system depends on data from other teams, get a contract in place. Your future self will thank you.