Data mesh promised that domain teams would publish data as products, with clear owners, interfaces and quality guarantees. For several years the hard part was not the idea but the vocabulary. Every organization invented its own YAML template for “data contracts,” every catalog had its own notion of a “data product,” and none of them could talk to each other. As a result, contracts lived in wikis, drifted from reality, and were rarely enforced.
That is changing quickly. Two open specifications from the Linux Foundation’s Bitol project, the Open Data Contract Standard (ODCS) and the Open Data Product Standard (ODPS), have become the common language for describing what a data product promises and how it is delivered. In its November 2026 Technology Radar, Thoughtworks placed ODCS in its “Adopt” ring, calling it a sensible default for teams building data products. This article explains what the standards contain, why they matter now, and how to adopt them pragmatically.
Why Contracts Became the Center of Data Mesh
The four data mesh principles (domain ownership, data as a product, a self-serve platform and federated computational governance) all depend on one thing: a reliable agreement between the team that produces data and the people or systems that consume it. Without that agreement, “data as a product” is just a renamed table, and “computational governance” has nothing to compute against.
A data contract is that agreement made explicit and machine-readable. It states what the data looks like, what it means, how good it must be, how fresh it will be, who supports it and under what terms it may be used. Three pressures pushed contracts from a niche practice to a mainstream one in 2025 and 2026:
- AI consumers. Language models and agents cannot ask a colleague what a column means. They need semantics, quality expectations and usage terms in a form they can read. Thoughtworks specifically notes that the declarative format of ODCS helps both humans and AI agents interpret and validate contracts.
- Breaking changes at scale. As change data capture and streaming spread, a renamed upstream column can break dozens of consumers within minutes. Contracts enable automated compatibility checks before a change ships.
- Regulation and audit. Rules such as the EU AI Act’s data governance requirements for high-risk systems and long-standing financial data rules reward organizations that can show documented provenance, quality criteria and permitted uses for their data.
What ODCS Defines
ODCS describes a single data contract in YAML. The current release on the project’s GitHub repository is version 3.1.0, published under the Apache 2.0 license. A contract is organized into sections that together answer the questions consumers actually ask:
- Fundamentals: identity, version, status, domain and a human description of purpose and limitations.
- Schema: objects and properties, logical and physical types, keys, classification of sensitive fields, and business definitions.
- Data quality: rules at dataset and column level, expressed in a way that tools can turn into executable checks.
- Service-level agreement: properties such as latency, frequency of updates, retention and availability.
- Servers and infrastructure: where the data physically lives, such as a Snowflake schema, a Databricks catalog, a BigQuery dataset or an object store path.
- Team, roles and support: owners, stewards, access roles and the channels consumers use to get help.
- Pricing and custom properties: optional commercial terms for internal chargeback or external data sharing, plus extension points.
Two design choices make ODCS practical. It separates the logical contract from the physical server, so the same promise can be fulfilled on different platforms. And it treats quality rules as first-class content rather than prose, so contracts can be tested in CI and monitored in production.
What a minimal contract looks like
Teams new to ODCS often over-engineer their first contract. A useful minimum for an internal analytical table fits on one screen: an identifier, version and status; a one-paragraph purpose statement including what the data should not be used for; the table’s grain and primary key; each column with type, a business definition and a classification flag for personal or confidential data; three to five quality rules that reflect real past failures; a freshness commitment; the owning team and a support channel. Everything else, from pricing to detailed infrastructure properties, can be added when a consumer actually needs it.
The single most valuable line in many first contracts turns out to be the grain statement. Ambiguity about whether a table has one row per customer, per account or per subscription causes more silent reporting errors than malformed data ever does.
What ODPS Adds
If a contract is a promise about one dataset or interface, a data product is the unit that owns and delivers one or more of those promises. ODPS describes that product. Bitol announced ODPS v0.9.0 in July 2025 and released v1.0.0 in autumn 2025, aligning its team and governance structures with ODCS v3.1.0.
An ODPS document typically captures the product’s identity and lifecycle state (draft, active, deprecated, retired), its owning team, the input ports it consumes from other products, the output ports it exposes, and references to the ODCS contracts that govern each port. Products can reference other products, which makes dependencies, derivations and bundles visible. The Bitol announcement summarizes the relationship neatly: contracts define the promise, and the product standard defines the product.
Why two standards instead of one
Keeping them separate reflects how organizations actually work. Contracts change with schemas and quality rules, often weekly. Product definitions change with ownership, scope and lifecycle, usually far less often. Separating them lets a product expose several contracts (for example, a stable analytical table and a near-real-time event stream) and lets contract tooling evolve independently from catalogs and marketplaces.
The split also clarifies responsibilities. Data engineers in the producing team usually maintain contracts, because contracts are tightly bound to pipeline code and schemas. Product owners or domain leads maintain the product description, because it encodes decisions about scope, audience, lifecycle and investment. When a product is deprecated, ODPS records the decision and its timeline; the contracts for each port then carry the technical deprecation details that consumers need to migrate. That division mirrors how software teams separate API specifications from service catalogs, and it tends to feel natural to organizations that already run microservices.
The Tooling Ecosystem Is Converging
Standards matter only if tools speak them. According to Thoughtworks, the maintainers of the Data Contract CLI are deprecating their own Data Contract Specification in favor of ODCS, and teams building data meshes are moving to ODCS, often alongside ODPS. Data product marketplaces such as Data Mesh Manager were among the early adopters of ODPS, and Thoughtworks reports that Bitol graduated within the Linux Foundation in July 2026, a sign of maturing governance.
For practitioners, this convergence has three concrete benefits:
- Portability. A contract written once can be validated by an open source CLI, rendered in a catalog and enforced in a pipeline without rewriting it in three formats.
- Automation. Generators can produce dbt tests, SQL quality checks, JSON Schema or documentation from the same source of truth.
- Interoperability with AI. Agents and copilots can read standard contracts to discover data, understand semantics and respect usage terms, which we return to in our companion piece on agent-ready data meshes.
A data contract that is not machine-readable and not enforced is documentation. A contract in a shared standard, tested in CI and monitored in production, is infrastructure.
An Adoption Playbook That Avoids Bureaucracy
The fastest way to kill data contracts is to mandate them everywhere on day one. The organizations that succeed treat contracts as a product feature that removes pain, starting where the pain is greatest.
- Pick three to five high-value interfaces. Choose datasets with many consumers, frequent breakages or regulatory exposure, such as customer, order or financial ledger data.
- Write contracts with consumers in the room. The producer knows what is feasible; consumers know what they rely on. A one-hour workshop per contract usually surfaces hidden assumptions about grain, nulls and timeliness.
- Store contracts in Git next to the code that produces the data. Contracts are versioned with semantic versioning; a breaking schema change requires a major version and a deprecation window.
- Enforce in CI first. Validate that the producing pipeline’s output schema matches the contract on every pull request. Blocking a breaking change before deployment delivers immediate, visible value.
- Monitor in production. Run the contract’s quality rules and SLA checks on schedule, publish results to the catalog, and alert the owning team, not a central group.
- Wrap contracts in products. Once several contracts exist for a domain, describe the domain’s data product in ODPS, list its ports and owners, and publish it to the catalog or marketplace.
- Scale through templates and platform support. The self-serve platform should generate contract skeletons, run validations and provision access automatically, so the cost per new contract keeps falling.
Measuring whether contracts are working
Contracts justify themselves through fewer incidents and faster onboarding, so measure those directly rather than counting contracts. Useful indicators include:
- The number of breaking changes caught in CI versus discovered by consumers in production.
- Mean time to detect and resolve data incidents on contracted interfaces compared with uncontracted ones.
- Time for a new consumer to start using a data product, from discovery to first trusted query.
- The share of contracted interfaces meeting their SLA and quality rules over a rolling 30 days.
Worked Example: A Customer Data Product
Consider a subscription business whose customer domain feeds billing analytics, a churn model and a customer-service assistant. Breakages are frequent: last quarter a change to how cancelled accounts were flagged silently inflated the active-customer count in finance reports.
The domain team defines a Customer 360 data product in ODPS with two output ports. The first is a daily analytical table in the lakehouse, governed by an ODCS contract that defines grain (one row per customer account), a precise definition of “active,” classification of personal fields, quality rules (no duplicate account IDs, cancellation date never before signup date, null rates below agreed thresholds) and an SLA of availability by 06:00 UTC. The second is a near-real-time stream of status changes, governed by its own contract with a freshness target of under five minutes and a narrower schema without direct identifiers.
In CI, a change that would rename the status field fails validation against the published contract, so the team ships it as version 2.0 with a 60-day overlap. In production, quality checks run after each load and publish pass or fail status to the catalog. The churn model’s feature pipeline subscribes to contract notifications, and the assistant’s retrieval tool reads only the governed port. The finance team, which previously reverse-engineered the definition of “active” from SQL, now reads it in the contract. No new committee was created; the governance lives in the files and the checks.
Pitfalls to Avoid
- Contracts as paperwork. If nothing fails when a contract is violated, people stop maintaining it within months.
- Central authorship. A central team writing contracts for domains recreates the bottleneck data mesh set out to remove. The platform team provides tools; domains own content.
- Over-specification. Dozens of quality rules on day one create alert fatigue. Start with the rules that capture known failures and grow from incidents.
- Ignoring semantics. A perfect schema with an ambiguous definition of “revenue” still produces wrong answers. Business definitions belong in the contract.
- Forgetting usage terms. Purpose limitations and classification matter more as AI agents become consumers; capture them explicitly.
Outlook: From Standards to Computational Governance
The next phase is less about writing contracts and more about using them. Expect access requests to be evaluated against contract terms automatically, catalogs to derive lineage and ownership from ODPS documents, quality monitors to configure themselves from ODCS rules, and AI agents to discover and query products through standard interfaces. Early research, such as the 2026 Data Product MCP paper from academic and industry authors, already demonstrates agents checking queries against contracts and declared purposes before execution. The organizations that have their important data described in open standards will be able to adopt these capabilities as they mature, rather than retrofitting metadata later.
Conclusion
Data mesh’s central idea, data managed as a product with a clear owner and promise, finally has the shared vocabulary it needed. ODCS gives teams a standard, testable way to express what a dataset guarantees; ODPS describes the products that deliver those guarantees. Adopted incrementally, starting with the interfaces that break most often and enforcing contracts in CI and production, these standards turn federated governance from a slide into a working system, and they prepare your data estate for a world where many of its consumers will be machines.
How Hanoi Technology Can Help
Hanoi Technology helps domain teams define, automate and enforce ODCS data contracts and ODPS data products as part of a practical data mesh rollout.
Further Reading
- Open Data Contract Standard (ODCS) – Thoughtworks Technology Radar
- Open Data Contract Standard repository – Bitol / GitHub
- Announcing ODPS: a major step toward standardizing data products – Bitol
- Announcing ODPS v1.0.0: Building the Language of Data Products – Bitol
- Data Product MCP: Chat with your Enterprise Data – arXiv