ODPS Is Becoming an Interoperability Layer
Independent teams are bringing the Open Data Product Specification into authoring, catalogues, delivery tooling, business context, and governed agent work.
An open specification earns trust when independent teams use it in working products. That shift is underway for the Open Data Product Specification, ODPS.
I founded ODPS 2021 to give data products a shared, machine-readable description. It is not a product or a platform. Its purpose is to retain a product’s meaning as it moves between tools, teams, and stages of delivery.
The implementation stories now span the data-product lifecycle. They also show why an open specification matters. Each platform solves a different problem. ODPS gives those platforms a common product definition.
Alation brings ODPS into authoring
Alation is an enterprise data intelligence platform for data cataloguing, governance, search, and data marketplaces. It helps teams find, understand, govern, and share data across the organisation.
Alation uses ODPS-based definitions in its Data Product Builder. This places the specification at the point where teams first define the product, its purpose, and its delivery expectations.
A shared definition at authoring time reduces rework later. The catalogue, governance process, engineering workflow, and consuming teams start from the same product description.
Dawiso shows implementation discipline
Dawiso is a data-product management platform focused on the lifecycle of governed data products. It supports organisations in designing, managing, and operating data products across business and technical teams.
Dawiso has adopted ODPS v4.1 as the base specification for its data-product layer, alongside ODCS and data-mesh practices. It also distinguishes LF/ODPI ODPS v4.1 from Bitol’s separate standard with the same acronym.
That clarity is essential. Interoperability fails when teams use the same acronym for different schemas. Dawiso gives users an unambiguous basis for product exchange.
OpenMetadata brings ODPS into platform exchange
OpenMetadata is an Apache-2.0 open-source metadata platform for cataloguing technical assets, ownership, lineage, data quality, and governance. Collate provides the managed enterprise offering built on OpenMetadata.
OpenMetadata merged ODPS v4.1 support in June 2026
Its implementation includes JSON and YAML import and export, validation, smart merge, full replace, converter tests, and interface flows for Data Products.
Smart merge preserves OpenMetadata-managed information outside the incoming ODPS document. This gives organisations a practical route for exchanging portable product definitions while retaining platform-specific governance records.
This is a significant ecosystem step. Every integration still needs transparent mapping guidance, version pinning, and conformance tests against the official ODPS schema. A converter helps. A demonstrably conformant converter earns trust.
FLUID Forge brings ODPS into delivery tooling
FLUID Forge is an open-source data-product compiler and CLI. A FLUID YAML contract defines the product, then Forge validates, plans, and deploys its technical infrastructure into local DuckDB, AWS, GCP, or Snowflake.
It is delivery tooling. Alation and OpenMetadata focus on data intelligence, catalogue, and governance. FLUID Forge focuses on building and verifying the technical product.
FLUID Forge separates the two ODPS standards clearly
Get Dr. Jarkko Moilanen’s stories in your inbox
Join Medium for free to get updates from this writer.
Bitol’s Open Data Product Standard is its default route. LF/ODPI Open Data Product Specification v4.1 requires an explicit — spec odps-4.1 choice.
Its current v4.1 route exports and validates documents, while the import route remains limited to Bitol. This clear behaviour avoids false interoperability claims where only one direction exists.
FLUID Forge also includes an OpenMetadata registrar for deployed output ports, schemas, domains, and tags. This creates a promising reference path between two independent implementations.
Maysano and Kentaro bring business and agent context
Maysano is a data-product portfolio and operating platform. It connects business objectives, decision context, use cases, data products, delivery state, and outcome evidence.
Maysano uses ODPS as its portable data-product definition. This links each product to the business purpose and lifecycle that justify its existence. A data product becomes part of a managed portfolio rather than an isolated technical asset.
Kentaro Business Harness is the related open-source local harness for governed agent work. Its first release reads bounded Maysano context, validates local governance and delivery objects, generates drafts and reports, and exports evidence. It does not create external records or act without defined authority.
Together, the operating model is:
Business objective → decision context graph → ODPS data product → governed agent work → delivery evidence → portfolio decision.
Maysano and Kentaro are emerging implementations. They do not claim the enterprise scale of Alation or OpenMetadata. Their role is different. They test how ODPS works with business decision context and governed AI-agent work.
Collibra community interest is emerging
Collibra is an enterprise data intelligence and governance platform used for data cataloguing, stewardship, policies, and business glossaries.
A recent Collibra Community discussion describes a governance-as-code approach based on ODPS v4.1 YAML. The proposed flow stores product definitions in version control, validates them in CI/CD, and maps them through Collibra’s Core REST API.
The work focuses on mappings for productStrategy, dataAccess, and metadata, together with stewardship, business glossaries, version updates, and idempotent REST operations.
This remains a community-led integration idea. It is not native Collibra support or a confirmed Collibra roadmap item. It still shows growing demand for ODPS as a source format for declarative data-product governance.
The next step is shared proof
The ecosystem now needs shared interoperability evidence.
A strong first reference flow starts with a FLUID Forge product, exports it as LF/ODPI ODPS v4.1, imports it into OpenMetadata, then exports it again and compares the result against the original document.
A second reference flow defines a versioned ODPS-to-Collibra mapping with explicit treatment of unsupported fields and Collibra-specific extensions.
Maysano and Kentaro add a third view. They show the role of ODPS in a business graph where agents work within defined authority, use current context, and return evidence into portfolio decisions.
These implementations serve different needs. They share one requirement: a portable product definition that retains its meaning across systems.
ODPS now needs more independent implementations, better conformance testing, public mapping guidance, real round trips between products, and business context that remains available when agents enter the workflow.
Teams building ODPS support are invited to share mapping questions, test cases, and edge cases. Study, do a PoC and apply
