Why this matters
A producer changes a column without knowing who relied on it. A data contract writes those assumptions down as terms that are versioned and tested, so the producer learns about the dependency before the change ships.
Before you start
A contract makes an implicit promise explicit
Every consumer of a table already relies on a set of assumptions: these columns exist, this one is never null, this arrives by 6am. Those assumptions are undocumented, so a producer cannot honor them on purpose. A data contract writes them down as terms both sides can see.
A contract is enforceable, which is what separates it from documentation
The terms of a contract map onto checks that run. Schema expectations, quality expectations and freshness expectations become tests, and a violation is a detectable event rather than a complaint that arrives three days later from a confused analyst.
A contract gives ownership obligations
Once a contract exists, "who owns this table" has a concrete answer with obligations attached. That is why contracts tend to be adopted at the boundaries between teams and domains, where the cost of an unstated assumption is highest.
The interactive demo
Work through the demo below. It runs in your browser with nothing to install. Watch for:
- Creating a data contract
- What each segment of the contract means
- Reviewing a completed contract and its run history
This demo is also available on its own at the Learning Center.
After this module you should be able to
- Create a data contract and explain what each segment commits you to
- Turn an unwritten assumption a consumer relies on into a stated term
- Interpret a contract run history to see whether terms are being met