Data contract
Also known as: data contracts
A data contract is an agreement between the team that produces data and the teams that use it, defining what the data looks like, what quality to expect, who owns it, and how changes will be handled.
It's usually written as a machine-readable file that tools can check automatically. While contracts sound bureaucratic, they target a painfully common problem: an engineer renames a column and silently breaks finance's reports.
Data contract, explained at three levels
At home
Think of a data contract like a lease agreement. Both sides know what to expect: the landlord promises heat and water, and the tenant knows the rules. A data contract makes similar promises about a dataset.
At work
Data contracts reduce broken dashboards and reports. The team that creates data agrees to keep it in a certain shape and quality, and to give notice before making changes.
At home
A contract typically lists the dataset's columns and data types, rules like 'email can't be empty,' how fresh the data should be, who owns it, and how sensitive it is. Tools can check new data against these rules automatically.
At work
Contracts are enforced in CI pipelines (blocking schema-breaking changes), at ingestion (rejecting bad records), or through data quality monitoring. They work best for critical datasets that cross team boundaries, such as orders, customers, and billing events.
At home
The hard part isn't the file format, it's convincing software engineers to own the data their systems produce. In my opinion, contracts succeed only when producers see a benefit, such as fewer urgent requests from the data team.
At work
Version contracts with semantic versioning, define deprecation periods for breaking changes, and include service levels for freshness and completeness. Integrate them with catalogues and lineage so impact analysis is automatic. Start with a handful of high-value datasets rather than mandating contracts everywhere, which tends to produce stale paperwork.
Real-world examples
At home
Aisha ran analytics for a community sports league. After the registration app changed a date format and broke her standings report twice, she wrote a simple contract with the app's volunteer developer, and the problem stopped.
At work
Fatima leads data platform work at a Toronto subscription business. A product team renamed a field and finance's revenue report was wrong for a week. After introducing contracts on billing events, that change would have failed the product team's build first.
Common confusions
- A data contract is a legal document. — It's usually a technical agreement, often a YAML or JSON file, enforced by tools.
- Contracts mean data can never change. — Contracts define how change happens: versions, notice periods, and migration paths.
- Data quality tools make contracts unnecessary. — Quality tools detect problems after they happen. Contracts aim to prevent them upstream.
For analysts
Most data quality problems are really ownership problems. I'd start contracts with the three datasets whose breakage causes the most executive pain, and let that success sell the idea to other teams.
History & origin
Software teams have used API contracts for years to protect consumers from breaking changes. In data, producers often changed database tables without knowing who depended on them, leaving data teams to clean up. Andrew Jones wrote about data contracts at GoCardless in 2021, and Chad Sanderson helped popularize the idea, publishing widely on it. Open specifications followed, including the Open Data Contract Standard, now maintained by the Bitol project under the Linux Foundation. Tools such as dbt added 'model contracts' that enforce schemas at build time. In my view, data contracts are less about technology and more about making ownership explicit, which is why they're harder to adopt than to explain.