Data Contract

Origin & evolution

The pattern grew out of a practical pain. At GoCardless, Andrew Jones found that upstream schema changes kept breaking downstream pipelines without warning, and around 2022 he began describing the fix as a "data contract": treat the dataset like an API, codify the schema and ownership and service-level objectives🏁ObjectiveStrategyA strategic goal (OKR)View reference → up front, and deliver pre-modelled data into the warehouse. He set the approach out in full in *Driving Data Quality with Data Contracts* (Packt, 2023). The idea spread quickly and became one of the most discussed topics in data engineering.

How it works in practice

A payments team owns a transactions event stream. The analytics team depends on three fields from it: amount_cents, currency, and settled_at. A data contract records those fields, their types, a freshness target (events land within five minutes), and the owning team. When a backend engineer later proposes renaming settled_at to completed_at, the contract test fails in CI before the change merges, naming the analytics models that would break. The rename still happens, on a schedule both teams agree, with a deprecation window. The breakage moves from a 2am dashboard🎛️DashboardData & AnalyticsAn analytics dashboardView reference → outage to a code review comment.

Data contract vs. its neighbours

• API contract🤝API ContractEngineeringAn API contract or specificationView reference → governs a request-and-response interface between services at call time. A data contract governs a dataset at rest or in motion, where the consumer reads on its own schedule and there is no synchronous handshake to fail loudly.
• Data quality rule🧹Data Quality RuleData & AnalyticsA data quality validation ruleView reference → is one testable assertion (currency is not null). A data contract is the broader agreement that may contain many such rules alongside schema, ownership, and SLAs.
• Data source🛢️Data SourceData & AnalyticsA data source or integrationView reference → is the system the data comes from. The contract sits on top of a source, defining what consumers are promised from it.

In the graph

In the Unified Product Graph, a data contract lives in the compliance region, which is the right home because it is fundamentally about an enforceable promise. A product is bound to it (product_bound_by_data_contractProductbound byData Contracthierarchy), a compliance framework🏟️Compliance FrameworkComplianceA compliance framework (SOC 2, GDPR, etc.)View reference → can govern it (compliance_framework_governs_data_contractCompliance FrameworkgovernsData Contracthierarchy), and the contract in turn governs the underlying source (data_contract_governs_data_sourceData ContractgovernsData Sourcecross-domain). That last edge is what makes the structure useful: trace from a contract to its data_source🛢️Data SourceData & AnalyticsA data source or integrationView reference → and you see exactly which system is obliged to honour the promise.