What a data contract is
A data contract is a machine readable agreement between whoever produces a dataset and whoever consumes it. It specifies the schema, the freshness expectation, the ownership, and the quality rules a table or event stream has to meet, written down as a file rather than as a Slack thread or a wiki page someone forgot to update.
The idea did not come from a vendor. It came from engineering teams who kept getting burned the same way: an upstream service changes a field name or drops a column, and the change silently breaks every downstream dashboard, model, or pipeline that depended on it. GoCardless engineer Andrew Jones wrote publicly about the approach his team built starting in December 2021, and Chad Sanderson, then at Convoy, published a widely read piece the following year making the case more broadly. Jones later expanded the GoCardless approach into a full book, "Driving Data Quality with Data Contracts," published by Packt in 2023.
Why it exists
The mechanism is simple. Without a contract, a schema change is invisible until something downstream breaks in production. With a contract, the change has to pass a compatibility check before it ships, the same way an API contract stops a backend team from breaking every client that calls it. The contract turns an implicit assumption about a dataset into an explicit, testable one.
That is also why data contracts are not a replacement for data quality monitoring, they are the other half of it. A contract defines what a dataset is supposed to look like. Monitoring checks whether it actually does, in production, over time. One without the other is either a rulebook nobody enforces or an alert system with no rulebook to alert against.
How the early approaches differed, and why that mattered
For most of the last four years, "data contract" meant different things depending on who built the tooling. Jones's implementation at GoCardless defined contracts in Jsonnet, merged through Git by the data owner, with BigQuery and Pub/Sub resources provisioned automatically once a contract merged. Sanderson's approach at Convoy defined contracts in Protobuf and enforced them through Kafka's schema registry and Debezium, closer to the existing streaming infrastructure most platform teams already ran.
Both were credible, and both stayed provider specific. PayPal published its own approach in August 2022 and open sourced a Data Contract Template in May 2023. A separate, community maintained project called the Data Contract Specification emerged around the same period as a YAML based alternative, and adoption split across it, PayPal's template, and various in house formats. A contract written for one team's tooling did not travel to another's.
What just changed
In November 2023, the Linux Foundation's Bitol project released the first version of the Open Data Contract Standard, forked from PayPal's template, aiming to give the format a neutral home instead of a single vendor's roadmap. In December 2025, Bitol shipped ODCS v3.1.0, adding relationships between properties, stricter JSON Schema validation, and scheduling fields that make service level agreements for freshness and availability directly executable rather than descriptive text (Bitol, 2025).
In the same release window, the team behind the separate Data Contract Specification deprecated that project in favor of ODCS, with migration support running through the end of 2026 (datacontract.com project documentation, 2025). That closes off the format fragmentation that defined the space since 2022. A contract written to ODCS now has one specification to target instead of two or three.
What to look at when evaluating a data contract tool
The gap that matters most is between a tool that lets you define a contract and a tool that enforces it. A YAML file that describes a schema is worth little if nothing actually stops a bad change from shipping. According to an April 2026 review of the enforcement landscape, most tooling built around ODCS handles the definition well, exporting a single contract file into dbt model and source YAML, SodaCL checks, Great Expectations suites, Avro or Protobuf schemas, SQL DDL, and Terraform, but the enforcement step, the part that actually blocks a deploy, still depends on what runs in the CI pipeline, not the contract file itself (zircote, 2026). Confluent's Schema Registry is one of the few components that enforces contracts at the broker level in real time for streaming data, and that capability sits on its paid Stream Governance tiers rather than the free tier (Confluent, 2026; zircote, 2026).
The practical checklist: does the tool block a breaking change in a pull request, or only flag it after the fact. Does enforcement happen at write time, at deploy time, or only in a nightly batch check. And does the contract format you adopt now have a maintained specification behind it, or a project that might be deprecated in eighteen months the way the Data Contract Specification was.
What commonly goes wrong
Two failure modes show up repeatedly. The first is treating the contract as documentation rather than a gate: a team writes the YAML file, nobody wires it into CI, and it drifts out of date within a quarter. The second is the opposite problem, contracts so strict that every minor change requires a renegotiation, which pushes producing teams to route around the contract rather than update it.
The pressure behind all of this is not academic. Gartner's 2026 Magic Quadrant for Augmented Data Quality Solutions estimates that 70% of organizations will adopt modern data quality tooling by 2027, driven in large part by the accuracy requirements of production AI systems (Gartner, 2026, as cited across vendor analyst pages including Qlik and Informatica). A contract with no consumer enforcing it will not move that number. One wired into a deploy pipeline will.
Sources: Andrew Jones · Driving Data Quality with Data Contracts · Bitol ODCS v3 · Bitol ODCS v3.1.0 · Data Contract Specification · zircote · Confluent · Confluent Stream Governance