We are thrilled to announce the joint release of Open Data Contract Standard (ODCS) v3.2.0 and Open Data Product Standard (ODPS) v1.1.0. For the first time, both standards ship on the same day, sharing five approved RFCs and a single vocabulary for describing what data means to the systems that consume it. This release brings context for AI systems, portable contracts across environments, and richer types for modern workloads, while maintaining complete backward compatibility with ODCS v3.1.0 and ODPS v1.0.0.
Both releases carry the codename “Peter Flook,” the first time Bitol has named a release. They are dedicated to the memory of our dear friend and longtime contributor, whose work shaped many aspects of both standards: data quality testing, the negative test suite, schema validation, documentation, vendor onboarding, and more. We carry his contributions forward in this version and beyond. We miss you, Peter!
We extend our sincere gratitude to the Linux Foundation AI & Data for their unwavering support and governance. Having recently graduated from LF AI & Data, we continue to benefit from a neutral, collaborative environment that enables us to implement true open-source standards. Their commitment to building open standards for the AI and data community has been instrumental in making ODCS and ODPS the vendor-neutral, industry-wide standards they are today.
What Makes This Release Special
This is a release about meaning. Previous versions taught the standards for describing structure: which columns exist, what types they hold, and how they relate. v3.2.0 and v1.1.0 teach them to describe intent, so that the systems reading your contracts, increasingly agents rather than people, stop guessing.
The release brings several transformative capabilities:
- Context for AI systems: Tell agents how to use your data, what is verified, and what they must never do
- Synonyms: Record the other names your business actually uses, with, if needed, locale and provenance
- Variables: One contract that works in dev, test, and production, with no secrets in Git
- Vectors, maps, and enums: Describe embeddings, dictionaries, and controlled vocabularies properly
- Measures and dimensions: Declare semantic roles without leaving the property shape
- Deprecation: Retire fields and ports without breaking consumers
- Nine new server types: Iceberg, SAP HANA, Teradata, Exasol, and the Actian engines
- Five shared RFCs: The same features, defined once, landing in both standards together
ODCS v3.2.0 delivers seventeen approved RFCs. ODPS v1.1.0 delivers seven, five of which are shared with ODCS. Two are shared further still, with OORS v1.0.0, the work-in-progress Open Observability Results Standard.
Adoption
The last adoption survey, closing May 2026, counted 114 organizations using ODCS and ODPS, up from 9 fourteen months earlier. Those organizations employ roughly 4.5 million people across 21 countries and 15 sectors.
The latest adoption numbers were computed on August 31st, 2026. Numbers like that are only as good as the responses behind them, and the next round is open. If your organization is using either standard, in production or in a proof of concept, please take a minute:
It is the clearest signal we have about which parts of the standards are earning their keep, and it shapes what the TSC prioritizes next.
Key Enhancements in Detail
RFC-0038: Context for AI and Semantic Interoperability
An LLM pointed at your warehouse reads column names and infers the rest. It infers confidently; it infers wrong, and nobody finds out until the number slips.
RFC-0038 introduces an optional context block with three parts. instructions are natural-language guidance for agents and tools, effectively a system prompt scoped to this level. verifiedStatements is an array of canonical business questions, each with an optional curated answer. constraints is negative guidance: what an agent must not do. In ODCS, the block applies at the data contract and schema object levels. In ODPS, it applies at the data product and output port levels, while input ports defer to the context in the linked ODCS contract.
schema:
- name: turnover
context:
instructions: >
This table contains pre-aggregated turnover metrics at order granularity.
Always filter by turnover_ts when querying time ranges. For cross-country
comparisons, normalize using the currency_code dimension.
verifiedStatements:
- question: "What is the total revenue for Germany in Q1 2025?"
- question: "What is the average basket value?"
answer: "Use the average_basket_value measure directly; it is pre-computed."
constraints:
- constraint: "Do not query without a date range filter; the table is unbounded."
- id: no-individual-order-exposure
constraint: "Do not expose individual order details; always aggregate to country level."
tags: [gdpr, pii]
Note the shapes, because they are easy to get wrong. instructions is a single string, not a list. Each verifiedStatements entry requires a question; entries with an answer should be returned verbatim when a query is semantically close, while entries without one serve as sample questions for text-to-SQL priming. Each constraints entry requires a constraint string and may carry id, tags, and authoritativeDefinitions.
The constraints list is the part worth dwelling on. Guardrails written into a prompt live in one tool, get copied imperfectly, and drift. Guardrails written into the contract are versioned, reviewed, and travel with the data.
The release also adds glossary, ontology, and taxonomy to the recommended values for authoritativeDefinitions.type, so the pointer to your semantic source of truth is a first-class citizen.
RFC-0041: Synonyms
Your Paris team says “client.” Your New York team says “account.” Your natural language interface treats them as two different things and returns two different numbers.
RFC-0041 adds an optional synonyms array recording alternative names for catalogs, AI and LLM tools, and natural language interfaces. Each entry has a required synonym plus optional id, description, locale (BCP 47), source, status, and customProperties. In ODCS, it applies to schema objects and properties; in ODPS, to data products and output ports.
properties: - name: total_turnover_euros semanticType: measure logicalType: number transformLogic: SUM(turnover_euros) businessName: TurnOver (Euros) synonyms: - synonym: TO description: "Common abbreviation used by the finance team" source: finance-team - synonym: Sales locale: en-US - id: sales-fr synonym: "Chiffre d'affaires" locale: fr-FR description: "French equivalent used in European subsidiaries" - synonym: Total number of orders status: deprecated
Provenance matters here. A synonym with a source and a status is a governed fact. A synonym without them is just a rumor with better formatting and a more official look.
RFC-0050: Variables
Until now you had two options, and both were bad: maintain four near-identical contracts for dev, test, staging, and production, or hardcode a hostname and hope nobody noticed.
RFC-0050 standardizes variable interpolation across ODCS, ODPS, and OORS. Any string value may contain a ${VAR_NAME} reference, resolved at runtime by tooling, keeping secrets and environment-specific values out of the document. The POSIX ${VAR_NAME:-default} form provides an inline default when the variable is unset or empty.
servers:
- server: production
type: postgresql
host: ${DB_HOST}
port: ${DB_PORT:-5432}
database: ${DB_NAME:-analytics}
schema: public
The rules are deliberately strict. Tools MUST resolve references before using a value, SHOULD error on unresolvable references rather than silently substituting an empty string, and MUST preserve unresolved tokens verbatim when serializing back to YAML. That last rule is what keeps your contract intact after a round trip through a tool that does not understand your variables.
Server port fields now accept a string in addition to an integer, so they can hold a variable reference that the previous integer-only type rejected.
Best of all, the standards did not grow. No new section, no new field. Interpolation applies to string values, and that is the entire feature.
RFC-0042: Vector Type
If you are building retrieval-augmented generation (RAG) on top of governed data, your embedding column has until now been described in a README, if at all.
RFC-0042 adds a vector value for logicalType, describing a fixed-dimension dense numeric array for embeddings and similarity search, with dedicated logicalTypeOptions.
properties: - name: description_embedding logicalType: vector logicalTypeOptions: dimensions: 1536 elementType: float32 distanceMetric: cosine normalized: true embeddingModel: openai/text-embedding-3-small embeddingModelVersion: "2024-01"
Only dimensions is required, a positive integer. elementType is one of bfloat16, binary, float16, float32 (the default), float64, int8, or uint8, where binary means one bit per element for binary-quantized vectors. distanceMetric is one of cosine, dotProduct, euclidean, hamming, or manhattan, and is advisory: the physical index may differ.
Recording the model and version is what lets a consumer know whether your vectors and theirs live in the same space. Two 1536-dimension columns from different models are not interchangeable, however similar they look in a schema browser.
RFC-0030: Maps
RFC-0030 adds a map value for logicalType to represent the key/value structures common in Databricks, Snowflake, BigQuery, Spark, and Avro. A companion map object carries the required key and value sub-definitions, both of which follow the standard property shape.
properties: - name: user_preferences logicalType: map physicalType: "MAP<STRING, STRING>" description: "User preference key-value pairs" map: key: logicalType: string description: "Preference name" value: logicalType: string description: "Preference value"
map is required whenever logicalType: map is set. No more describing a dictionary as a string and apologizing in the description field.
RFC-0033: Enumerations
RFC-0033 adds an optional enum array on schema properties, constraining a property to a fixed set of allowed values. Each entry is an object with a required value plus optional label, id, description, tags, customProperties, and authoritativeDefinitions.
properties: - name: order_status logicalType: string enum: - value: PENDING label: "Pending" description: "Order received, payment not yet captured." - value: SETTLED label: "Settled" description: "Payment captured and reconciled." - value: REFUNDED label: "Refunded" description: "Full or partial refund issued." authoritativeDefinitions: - type: Glossary url: "https://glossary.acme.com/refund"
Entries must be unique, and the array must contain at least one value. value is the only required field. Validation and documentation from a single declaration, which beats a validation rule in one system and a wiki page in another that disagree by Thursday.
RFC-0034: Measures and Dimensions
RFC-0034 adds an optional semanticType field to schema properties, which indicates the semantic role a property plays: column (the default), measure, or dimension. A measure is an aggregated value whose aggregation expression lives in transformLogic. A dimension is a categorical attribute for grouping and filtering.
properties: - name: region semanticType: dimension logicalType: string businessName: "Sales Region" - name: total_revenue semanticType: measure logicalType: number businessName: "Total Revenue" transformLogic: "SUM(order_amount)"
Properties without semanticType remain implicit columns, so nothing changes for existing contracts. Measures and dimensions reuse the full property shape with no new top-level structures, which is why a semantic-layer feature arrives here without a semantic-layer-sized specification.
RFC-0051: Deprecated Flag
Shared with ODPS v1.1.0. RFC-0051 adds an optional, deprecated boolean to schema objects and properties in ODCS (including nested properties), and to data products, input ports, output ports, and management ports in ODPS.
properties: - name: legacy_customer_code logicalType: string deprecated: true description: "Superseded by customer_id. Removal targeted for 2027."
It defaults to false, and deprecated elements remain documented and validated. You can say “stop using this” without pulling the rug out from under anyone.
RFC-0035: Vendor Attribution for Custom Properties
Shared with ODPS v1.1.0 and OORS (coming soon). RFC-0035 adds an optional vendor string on customProperties items, associating a custom property with a specific vendor, provider, or external system.
customProperties: - property: catalogId value: "a1b2c3d4" vendor: zeenea description: "Internal identifier in the enterprise catalog."
It SHOULD be a stable, lowercase identifier matching ^[a-z0-9][a-z0-9-]*$, with confluent, zeenea, atlan, and soda given as examples. This is not enforced, and tools MUST preserve unknown vendor values. Custom properties have always been the extension point; now you can tell which extension you are looking at.
RFC-0047: Identifiers on Relationships
RFC-0047 adds an optional id string on RelationshipBase, surfaced on both schema-level and property-level relationships. This completes the stable-identifier work of RFC-0026a for the last referenceable array-item object that lacked one.
The id MUST be unique within its containing relationships array, SHOULD be stable across contract versions, and cannot contain . # / \ @ ! % & ^.
RFC-0046: SLA Custom Properties and Authoritative Definitions
RFC-0046 allows each slaProperties[] entry to carry optional customProperties and authoritativeDefinitions, consistent with other ODCS objects. v3.1.0 made SLAs executable; v3.2.0 makes them extensible and traceable to their source of authority.
RFC-0043: Physical Data Encoding
RFC-0043 adds an optional encoding string field on server definitions that expose serialized payloads (Azure, Glue, Custom, Kafka, Kinesis, Local, S3, SFTP), declaring the expected character encoding of the data.
servers: - server: legacy-drop type: sftp location: sftp://files.acme.com/exports/ format: csv encoding: ISO-8859-1
It is a free-form string with no enum, defaults to UTF-8, and documents the physical payload encoding separately from the ODCS document encoding. Anyone who has received a “UTF-8” file full of question marks will understand why this needed its own field.
New Server Types
ODCS v3.2.0 adds nine server types across four RFCs:
- iceberg (RFC-0049): Apache Iceberg catalogs through the standardized Iceberg REST API. Required catalog and catalogUrl, optional namespace and warehouse.
- hana (RFC-0045): SAP HANA. Required host, optional port, database (tenant), and schema.
- teradata (RFC-0057): Teradata Vantage. Required host, optional port (default 1025) and database. No schema field, since in Teradata the database is the namespace.
- exasol (RFC-0058): Exasol in-memory MPP analytics. Required host, optional port (default 8563), and schema. No database field, since an Exasol cluster runs a single database. host may be a cluster connection range such as n11..14.acme.com.
- ingres, vectorwise, versant, poet (RFC-0059): the Actian engines. ingres (OLTP RDBMS) and vectorwise (columnar analytical DBMS) require database and host, with optional port defaulting to 21064. versant (object DBMS) requires database, with host defaulting to localhost and port to 5019. poet (NoSQL FastObjects, object DBMS) requires database, with host defaulting to LOCAL for the in-process embedded engine and port to 6001. None carries a schema field: for ingres and vectorwise the namespace is the table owner resolved from the connecting user, and the two object databases have no SQL schema namespace.
- fastobjects and btrieve: two new synonyms, fastobjects for poet and btrieve for zen. Same fields, same definitions, and neither original value is deprecated, following the precedent where postgresql and postgres already share PostgresServer.
RFC-0059 also establishes a naming convention worth stating plainly: a server type value uses the name the product carried when it was created, in lowercase. Enum values are permanent. Marketing names are not.
Finally, servers gain an optional Athena workgroup field, and stagingDir is made optional in the schema.
What’s New in ODPS v1.1.0
Beyond the five shared RFCs above, ODPS v1.1.0 brings changes of its own.
RFC-0029: Product Type
A new optional top-level type field categorizes data products by architectural alignment.
apiVersion: v1.1.0 kind: DataProduct name: customer-360 type: consumerAligned
Suggested values are sourceAligned, aggregate, and consumerAligned. The data mesh vocabulary your architects have been using in slide decks for four years now has a home in the artifact itself.
Identifiers Everywhere
Every object inside an array now carries an optional id for stable, refactor-safe references, aligned with what ODCS did in v3.1.0. Renaming stops being a rename-and-pray exercise.
RFC-0061: Metadata on SBOM Entries
Every other nested object in ODPS carries tags, customProperties, and authoritativeDefinitions. The product root, all three port types, support, team, and team members all have them. outputPorts[].sbom[] was the exception, and because the object is closed there was no escape hatch: adding anything failed validation.
RFC-0061 adds the three fields.
outputPorts: - name: transactions sbom: - id: sbom-runtime type: external url: https://mysbomserver/transactions/runtime.cdx.json tags: ["runtime", "cyclonedx"] customProperties: - property: sbomFormat value: CycloneDX 1.6 - property: buildId value: build-8842 authoritativeDefinitions: - type: implementation url: https://ci.acme.com/builds/8842 - id: sbom-model type: external url: https://mysbomserver/transactions/model.spdx.json tags: ["model", "spdx"]
sbom is an array, so a product may publish several entries: one per runtime image, one per library set. Previously, none could be labeled, and hoisting the metadata up to the containing output port was ambiguous the moment there was more than one. The object stays closed; only its property list grows. Every valid v1.1.0 document stays valid.
Relaxed Port Requirements
inputPorts and outputPorts now require only name. version and contractId are optional, and sbom no longer requires url. You can describe a data product before every contract behind it is finalized, which is how data products actually get built.
Documentation
The full customer example has been modernized to v1.1.0, including type and context. The standard is now split into one page per section, outputPorts[].inputContracts is documented, and the shared sections (team, support, custom and other properties, authoritative definitions) cross-link to their ODCS definitions.
No Breaking Changes
We want to emphasize that ODCS v3.2.0 and ODPS v1.1.0 include zero breaking changes. Every addition is optional. No existing field changes meaning; no existing value is removed. Every contract that validates against v3.1.0 will continue to validate against v3.2.0, and every data product valid under ODPS v1.0.0 remains valid under v1.1.0.
Migration and Adoption
Upgrading
- Update the apiVersion in your contracts from v3.1.0 to v3.2.0, and in your data products from v1.0.0 to v1.1.0
- Validate against the new JSON Schemas
- Optionally adopt new features: start with context on your most-consumed contracts, since that is where agent confusion costs the most
- Consider synonyms next if you run a natural language interface over your catalog
There is no step involving rewriting anything. That is the point of a minor release.
Tooling Support
Implementations already supporting v3.2.0 and v1.1.0:
Entropy Data: full v3.2.0 and v1.1.0 support in the platform.
The Entropy Data team also maintains the open-source Data Contract Editor and the famous DataContract CLI.
Check the vendors page for the latest tool support information, and open a pull request to add yours.
Validation and Schema
The official media type for ODCS v3.2.0 is:
application/odcs+yaml;version=3.2.0
The official media type for ODPS v1.1.0 is:
application/odps+yaml;version=1.1.0
Many IDEs, including VS Code and IntelliJ, will automatically validate your contracts if you use the .odcs.yaml file extension, thanks to our integration with SchemaStore.
Examples and Documentation
Every v3.2.0 feature ships with a working example, and every YAML file in the examples folder validates against schema/odcs-json-schema-latest.json:
- Vector type, Maps, Enumerations
- Measures and dimensions, Deprecated
- Variables, Vendor attribution
- New servers: Iceberg, SAP HANA, Teradata, Exasol, Actian, S3 with encoding
- Full end-to-end example and the complete examples index
The standard now has dedicated documentation pages for Context and Variables, alongside the existing sections. ODPS documentation has likewise been split into one page per section, with the shared sections cross-linked to their ODCS definitions.
RFC Process and Community Development
This release demonstrates the power of our open RFC process. Approved RFCs are filed by standard, under odcs-v3.2.0 and odps-v1.1.0:
- RFC-0029: Data Product Type (ODPS)
- RFC-0030: Maps
- RFC-0033: Enumerations
- RFC-0034: Measures and Dimensions
- RFC-0035: Vendor Attribution (shared with ODPS)
- RFC-0038: Context (shared with ODPS)
- RFC-0041: Synonyms (shared with ODPS)
- RFC-0042: Vector Type
- RFC-0043: Physical Data Encoding
- RFC-0045: SAP HANA Server Type
- RFC-0046: SLA Custom Properties and Authoritative Definitions
- RFC-0047: Relationship Identifiers
- RFC-0049: Apache Iceberg Server Type
- RFC-0050: Variables (shared with ODPS)
- RFC-0051: Deprecated Flag (shared with ODPS)
- RFC-0057: Teradata Server Type
- RFC-0058: Exasol Server Type
- RFC-0059: Actian Server Types
- RFC-0061: SBOM Metadata (ODPS)
Each RFC went through community review, discussion, and iteration before being approved by the Technical Steering Committee. That five of them landed in two standards simultaneously is not a coincidence: it is what the process is for.
What’s Next
The community is already at work on the next set of enhancements. We encourage everyone to participate in RFC discussions, propose new features, and help shape what comes next.
Getting Started
- Read the documentation at the ODCS and ODPS sites
- Explore the examples in both repositories
- Validate your contracts using the JSON Schema and the .odcs.yaml extension
- Try interactive tools such as the Data Contract Editor or the Workbench (use code ODCS32) or command-line tools like the Data Contract CLI
- Review the changelogs for ODCS and ODPS
- Join the community on Slack via Data Mesh Learning, on GitHub, or on the twice-a-week working group meetings
- Tell us you are using it via the Bitol Adoption Survey
Contributing
Bitol thrives on community contributions. Share your contracts as examples, propose enhancements through the RFC process, improve documentation, build tools and add them to the vendors page, or report issues. If you are interested in deeper involvement in governance, reach out on Slack.
Acknowledgments
ODCS v3.2.0 and ODPS v1.1.0 represent the work of many individuals and organizations. We thank our Technical Steering Committee members for their leadership: Andrea Gioia, Andrew Jones, Andy Petrella, Atanas Iliev, Diego Carvallo, Dirk Van de Poel, Jean-Georges Perrin (Chair), Jochen Christ, Martin Meermeyer, Patrick Beitsma, Simon Harrer, and Tom De Wolf.
We also thank the dozens of community contributors who participated in RFC discussions, submitted issues, and helped test pre-release versions.
Our deepest appreciation goes to Linux Foundation AI & Data for the governance structure, neutral ground, and infrastructure that make this collaborative work possible.
And to Peter, whom we miss dearly.
