ODCS 3.2: Is This the New Standard for Context?

The Bitol project released version 3.2.0 of the Open Data Contract Standard (ODCS) on September 8, 2026, along with version 1.1.0 of the Open Data Product Standard (ODPS). Why does this matter?

ODCS 3.2: Data Contracts That AI Can Read

Data contracts are intended to give data producers and consumers a reliable picture of what data is provided, how it’s structured, and which quality and service requirements apply. That principle doesn’t change with ODCS 3.2. What does change is the scope, and that’s an important step. The standard now describes more than what data exists. It’s starting to capture what the data means, how it should be used, and where its limits are.

The focus moves from a pure data contract toward machine-readable context for AI, semantic systems, and automation.

That shift matters because the audience for data contracts is changing. Until now, the main readers were data engineers, data stewards, platform teams, and validation tools. Going forward, AI agents, copilots, text-to-SQL systems, semantic layers, and automated governance services will read them, too. These systems need more than column names and data types. They need to know how the business defines each term, which calculations are valid, how data may be joined, and when an answer would be risky or just plain wrong.

Take a field called “Revenue” with the data type “decimal.” Technically, it’s unambiguous, but from a business perspective, it falls short. Is it gross or net revenue? Has it been adjusted for currency effects? Can you break it down by individual customer, or is that off-limits? Can it be used for the annual financial statements, or only for operational trend analysis? People answer these questions through documentation, experience, and in meetings. An AI agent doesn’t have that implicit context. ODCS 3.2 adds structures that let more of it travel with the data contract itself.

What’s New in ODCS 3.2

1. The new context block: a user manual for data

The new optional context block adds usage instructions, verified statements, and constraints. For AI, this is a major change. Business context becomes machine-readable, so there’s less room for misinterpretation.

2. Semantic modeling: from columns to business terms

You can now classify properties as a measure, a dimension, or a regular column, and add synonyms. That matters a lot for business intelligence (BI) and AI, since meaning and permitted use become more portable.

3. Vectors as a dedicated data type: embeddings become explainable

ODCS 3.2 introduces a logical vector type that can describe an embedding’s dimensionality, model, and distance metric, among other things. This is important for retrieval-augmented generation (RAG) and semantic search. For classic analytics, it’s more of a niche feature.

4. Enumerations and maps: more precise descriptions of complex structures

Enumerations define allowed values. Maps describe flexible key-value structures. It’s a sensible but incremental addition for validation and modern data formats.

5. Operational features: contracts that are more portable and easier to maintain

Variables, deprecation flags, and stable relationship IDs make contracts easier to manage and evolve. None of this is technically exciting, but it matters for production use.

6. Broader infrastructure support: closer to real-world platform environments

New server types for Apache Iceberg, SAP HANA, Exasol, Teradata, and Actian, plus details on character encoding, extend the standard’s technical reach. That’s relevant if you run these platforms. Overall, though, it’s a compatibility feature more than a strategic one.

ODCS 3.2: From Data Contract to Context Contract?

The term context contract is a useful way to describe what these extensions mean strategically, even though ODCS is still a data contract standard.

A classic data contract mainly defines:

• Data offering: Tables, fields, data types, formats, and delivery.
• Quality and service: Validation rules, error thresholds, refresh frequency, and service level agreements (SLAs).
• Purpose: The business goals and use cases the data product is intended for.
• Governance: Owners, terms of use, policies, and requirements for access and protection.

A context contract adds four things in particular:

• Meaning: Business definitions and calculation logic for terms such as “net revenue.”
• Interpretation: Synonyms, relationships, and allowed aggregations, such as “Sales” = sum of net revenue.
• Usage guidance: Concrete instructions on how people and AI should use the data correctly.
• Verified context: Validated statements and examples that automated systems can use as a reference point.

Context is then more than supporting documentation. It becomes part of a standardized, machine-readable interface that can be versioned. AI agents depend on that, because they don’t automatically know what an organization has learned through experience. If context only lives in slide decks, wiki pages, or the heads of individual experts, automated systems will struggle to access it.

So ODCS 3.2 isn’t a standalone “context contract” yet. It’s a data contract that deliberately makes room for machine-readable context. The standard provides the structure. That structure only pays off once companies fill it with reliable content and their systems actually process it.

Business Impact of ODCS 3.2

More reliable AI results

AI agents and text-to-SQL systems can generate better queries when they know the metrics, synonyms, relationships, and usage limits. Higher technical accuracy is only part of the benefit. The bigger benefit is fewer answers that sound plausible from a business perspective but are actually wrong.

Faster use and reuse of data

New hires, analysts, and development teams spend less time piecing together context through person-to-person handoffs. Data products can be understood more quickly and reused across tools. That reduces dependence on a few key people.

More portable semantics

Today, business definitions are often tied to a specific BI tool, catalog, or proprietary semantic layer. An open contract can bring some of that semantic information closer to the data and make it portable across platforms. Switching costs go down, and companies keep more control over their own knowledge.

Governance you can automate

Machine-readable constraints, deprecation information, quality rules, and ownership details make automated checks possible. Governance can kick in earlier in development and deployment instead of waiting for a manual review or an incident.

Better oversight of data products

By connecting technical, semantic, and operational metadata, companies can judge more accurately which data products are actually ready for analytics and AI. A data product’s formal existence doesn’t automatically make it trustworthy or AI-ready.

What It Takes to Use Data Contracts with Context

The benefits don’t come from a schema update alone. ODCS is a declarative specification and doesn’t execute anything itself. A constraint in the contract won’t stop an unauthorized query unless the systems involved interpret and enforce it.

1. Start with a clear use case

Pick an important data product that a BI or AI system already uses. Define a concrete question, such as “What was net revenue last quarter?” Then measure errors and the manual effort needed to correct them.

2. Decide who provides and maintains the context

Assign a business owner to each data product. Working with data stewards and data engineers, this person defines the terms, calculations, permitted uses, and constraints. They also review the context whenever business or technical changes occur, so it stays current.

3. Make the context usable in your tools

Catalogs, semantic layers, and AI platforms need to be able to import and process the information in the data contract. Start by testing one end-to-end path from the contract through the catalog to the AI agent.

4. Tie every rule to a technical control

Don’t just document rules in the data contract. Specify which system checks or enforces each one. For example, automated tests verify quality requirements, the authorization system handles access rules, and a policy engine or AI gateway enforces usage restrictions. Start with a few rules that can be checked unambiguously and that trigger a block or an alert when violated.

Our Take on ODCS 3.2

ODCS 3.2 has the potential to turn the data contract into a context interface for people and machines. Business definitions, calculation rules, and usage limits can help AI systems interpret data more reliably.

It’s an important step, but not a quick fix. For now, the contract only describes definitions and rules. It only has an effect once platforms process it, enforce it technically, and keep it up to date over time.

Technically, that’s realistic, but it is organizationally demanding. Companies need to name data owners and keep the context reliable. That’s why a focused start makes sense: a few important data products and concrete AI use cases.

The context extensions in data contracts don’t replace semantic modeling, governance, or data quality. But they can connect all threeto BI tools, platforms, and AI agents through an open, machine-readable layer. If companies get this right, more complex agent architectures move a good step closer.