Every data contract pitch lands the same way: one YAML file, agreed between producer and consumer, versioned in Git, executable. The file genuinely is better than the wiki page it replaced. The trouble starts about two weeks after adoption, when someone asks what happened when the freshness SLA was missed on Sunday β and the answer turns out to be nothing, because nothing was watching.
In this edition of datapro.news, we cover the question the announcements skipped. ODCS v3.1.0 shipped in December 2025, the competing Data Contract Specification was deprecated by its own maintainers, and Bitol graduated at LF AI & Data in July 2026. Authoring in ODCS is now the boring, correct default, which is the highest compliment a standard can receive. But ODCS is a declarative specification, not an execution engine β it defines the what and deliberately leaves the how and the when to whatever system processes the data. Quality rules describe what should be true; something else has to go and check. The word doing the most work in "executable data contracts" is not contract. Here are the 3 layers the decision actually comes down to:
- π ODCS v3.1.0: Learn what actually shipped β relationships that hold even where the store enforces nothing, SLAs that carry a schedule, a registered media type β and the asterisk on the backward-compatibility claim, because "no migration required" and "run the linter before you upgrade CI" are different instructions and only one of them is accurate.
- ποΈ Bitol governance: Discover why graduation is the fact that should drive a procurement decision rather than any feature list, since it is a checklist and not a sentiment β plus the two things to verify yourself, including a foundation page that still says incubation and adoption figures published by the standard's own chair.
- βοΈ The enforcement layer: See why choosing ODCS is now low-risk and choosing what runs it is not. Soda Core changed licence in January 2026, GX Core stewardship passed to Fivetran in May, and the dbt Labs merger closed on 1 June. The open spec consolidated at exactly the moment the engines beneath it did.
We also take the objection your senior engineer will raise β why not just use dbt contracts? β and concede the strong version of it before drawing the line where a transformation project ends and a producer/consumer agreement begins. The issue closes with a scorecard: what each component actually does, and what to check before you commit.
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. Adopt the format without designating that point and you 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 arrives with the paperwork of assurance and none of the substance.
Check out the video edition below π