Data Contract
A data contract is an explicit, testable agreement on the schema, semantics, and quality of data exchanged between a producer and its consumers.
Definition
A data contract is a versioned specification that a data producer commits to: field names and types, allowed values, nullability, freshness and volume ranges, and ownership. It is enforced in CI and at the boundary so that breaking changes cannot reach consumers silently. Where a schema describes structure, a contract also binds behaviour — how late data arrives, what happens to deleted records, and who is paged when a check fails.
Context and scope
Introduced in large data platforms where producers upstream of analytics, ML, and reverse-ETL pipelines can change data without coordination.
Common misconceptions
- A data contract is just a schema — schemas cover shape, while contracts also cover freshness, volume, semantics, and ownership
- Contracts freeze data forever — contracts make change deliberate and versioned, not forbidden
- Consumers own the contract — the producer, who controls the pipeline, must own and enforce it
Anti-patterns
- Publishing a contract that is never validated in the producer CI, so it drifts from reality
- Declaring a breaking change as a patch and rerouting every consumer without notice
- Enforcing only column existence while value distributions silently collapse
Related concepts
Related examples
Authoritative source
What it is
A data contract is the interface between a data producer and its consumers, written down and executable. It names the fields and types, but goes further to pin the behavioural promises: how fresh the data is, how late it may arrive, which values are impossible, how volume should track, and who owns the pipeline. Because it is machine-checkable, CI can reject a producer change that violates it before consumers ever see broken data.
Why it matters
In a modular data platform nobody knows every downstream use of a table. A silent rename, a new null, or a timezone shift can break a dashboard, a model, and a legal report at once. Contracts turn these from surprises into reviewed, announced, versioned changes, which is the difference between an incident and a routine release.
How to adopt it
Start with the most-consumed, highest-risk datasets and write the contract the consumers already assume. Validate it in the producer pipeline on every build, publish generated documentation, and route violations to the producer on call. Give breaking changes a new major version and a migration window. Over time this converts tribal knowledge about “how the data behaves” into checks that run without a human.