ODCS v3.1.0 Settles the Data Contract Format Without Settling Enforcement

Dear Reader…

For most of the last three years, a team that wanted to write a data contract first had to choose a format. That argument is now over, and it ended more decisively than most standards disputes do.

The Open Data Contract Standard shipped v3.1.0 on 8 December 2025 under Bitol, a Linux Foundation AI & Data project. In the same window, the competing Data Contract Specification was formally deprecated by its own maintainers in favour of the common standard — they had contributed concepts into ODCS and concluded that two specifications served nobody. If you are authoring a contract in 2026, you author it in ODCS. There is no serious second option.

The harder question, the one no announcement answers, is what happens next. A contract that nothing executes is documentation with a schema. The word doing the most work in "executable data contracts" is not contract.

What actually shipped

v3.1.0 is a maturation release rather than a rewrite, and the changes cluster around making the file machine-actionable rather than merely readable.

Relationships (RFC-0013). Contracts can now declare foreign-key and parent-child relationships between properties, at both schema and property level, including composite keys and nested references using dot-shorthand or fully qualified paths. Crucially this works even when the underlying store enforces nothing — a lakehouse table has no foreign keys, but the contract can still assert the relationship, which opens the door to generated DDL, ER diagrams and automated referential checks.

Strict JSON Schema validation. Earlier versions tolerated fields that weren't formally defined. That flexibility produced divergence between tools. v3.1.0 tightens the schema so that an ODCS file means the same thing to every implementation.

Executable SLAs. Service-level elements can now carry scheduling, so freshness and availability expectations can be checked automatically rather than asserted in prose.

Cleaner referencing, and a formal media type. Sections gained optional id fields for stable linking, and the standard registered application/odcs+yaml;version=3.1.0 — a small detail that matters if you intend to serve contracts over HTTP and have anything downstream negotiate on them.

Deprecations with a stated horizon. The v3.0.x team array structure and the old quality element-path notation are deprecated now and slated for removal in v4. Both still parse.

The backward-compatibility claim needs an asterisk

The release messaging is emphatic that every existing v3.0 contract remains valid, and that you can adopt on your own schedule with no emergency migration. For the overwhelming majority of files, that holds.

But it sits in tension with the flagship feature. The same announcement explains that previous versions tolerated additional fields that weren't formally defined in the schema, and that v3.1.0 now rejects them. Both statements cannot be true for the same file. If your team parked undeclared keys somewhere the schema didn't define — and teams did exactly that, because the standard permitted it — those contracts validated under v3.0 and will not validate under v3.1.

This is not a scandal. It is a well-signposted tightening, and customProperties is the sanctioned place to put the things you were smuggling. But "no migration required" and "run the linter before you upgrade CI" are different instructions, and the second one is the accurate one.

Governance: graduated, and the paperwork hasn't caught up

Bitol reached Graduated status at the LF AI & Data Foundation in July 2026, becoming the thirteenth project in the foundation to do so, confirmed in the Linux Foundation's August 2026 newsletter. The path was Sandbox in September 2023, Incubation in November 2024, Graduation in July 2026, cleared by unanimous Technical Advisory Council and Governing Board votes.

Graduation is the fact that should drive a procurement decision, because it is a checklist rather than a sentiment: contributions from at least five organizations (the project reports eleven or more, including Actian, Data Catering, Alliander, Agile Lab and Barcelona Supercomputing Center), sustained commit activity, and an OpenSSF Gold badge, upgraded from Silver at incubation.

One caution for anyone verifying this independently: the LF AI & Data project page for Bitol still describes it as an incubation-stage project. The landing page is stale, not the status. Cite the foundation newsletter or the graduation announcement instead.

On adoption, the numbers are striking and should be attributed rather than repeated flatly. The project chair reports growth from 9 to 114 adopting organizations in fourteen months, and cites a BARC 2026 study finding that 61% of organizations use data contracts in some form, with 41% of those practitioners on ODCS. Those are project-sourced figures published by the standard's own chair. They are plausible and consistent with the tooling activity, but they are advocacy numbers, and a skeptical CFO will treat them that way.

Where "executable" stops

Here is the part the announcements underplay, stated plainly by the vendors themselves: ODCS is a declarative specification, not an execution engine. It defines the interface and the expectations — the what. It deliberately leaves the how and the when to whatever system processes the data. Quality rules in a contract describe what should be true; something else has to go and check.

That something else is a fragmented and, in 2026, unusually unstable layer.

The Data Contract CLI natively supports ODCS: it lints against the JSON Schema, connects to Snowflake, BigQuery, Databricks, Postgres, Kafka and S3, tests real data against the contract, and exports to 25-plus formats including SQL DDL, dbt and Avro. It is MIT-licensed and it is the most direct on-ramp. It is best understood as a translation and test-execution layer — it turns one ODCS file into the artifact your existing engine already understands.

dbt model contracts (contract: enforced: true) remain the strongest build-time enforcement available: dbt verifies before building that the model returns the declared columns, and writes types and constraints into the DDL, so a violating build fails rather than shipping. The limit is scope, not quality — enforcement stops at the boundary of the dbt project, and says nothing about freshness, volume anomalies or drift after the data lands.

The quality engines moved under everyone's feet in the first half of 2026. Soda Core changed licence at v4 in January 2026, from Apache 2.0 to Elastic License 2.0 — still free for internal production use, but no longer open source and no longer offerable as a hosted service to third parties. v4 also replaced the SodaCL checks language with Soda's own contract format, a breaking change with a migration tool attached. Meanwhile Fivetran became steward of the Great Expectations open-source community and GX Core in May 2026, and completed its merger with dbt Labs on 1 June 2026, with dbt Core remaining Apache 2.0.

Read those three together and the strategic picture is uncomfortable. The open specification consolidated at exactly the moment the enforcement engines beneath it consolidated into fewer hands and, in one case, out of open source entirely. Choosing ODCS is now low-risk. Choosing what runs it is not, and that is the decision most teams are making casually.

The fair objection: why not just use dbt contracts?

Your senior engineer will ask it, and the honest answer starts by conceding the point. If everything your organization consumes is produced by your dbt project, dbt contracts give you real, build-time, fail-the-pipeline enforcement with no new standard to learn.

The case for ODCS is what sits outside that boundary. A dbt contract is a property of a transformation project; a data contract is an agreement between a producer and consumers who may be on different platforms, in different teams, using different engines. ODCS carries the parts dbt does not model: named ownership, support and escalation channels, service levels with schedules, server and access details, and the logical/physical type split that lets one contract describe data landing in BigQuery, Snowflake or Postgres with appropriate mapping.

The pragmatic architecture most practitioners converge on is not either/or: define the contract in ODCS, generate dbt schema from it to enforce structure at build time, and run contract tests in CI and on a schedule against deployed data. The contract is the source of truth; dbt is one of its enforcement points.

The scorecard

The specification question is answered, and answering it was worth the three years it took. Writing an ODCS file is now the boring, correct default, which is the highest compliment a standard can receive.

What has not been answered is the operational one. A contract creates an obligation only where something fails when it is broken — a build that stops, a pipeline that halts, a page that fires. Teams that adopt the format without designating that enforcement point will end up with a repository of well-validated YAML describing data whose behaviour nobody is checking. That is a more expensive failure than having no contracts at all, because it comes with the paperwork of assurance and none of the substance.

That’s a wrap for this week

Happy Engineering Data Pro’s