Earlier this summer, two open specifications shipped. Both are aiming at the same broad problem: AI systems need context that the model does not have.

ODCS and ODPS are the source of truth for your metadata and context, enabling export to other formats as needed.

Apache Ossie entered the Apache Incubator in July, formerly Open Semantic Interchange (OSI), backed by Snowflake, Dremio, dbt Labs, and Salesforce (only vendors, no end users, no consultants). It standardizes metrics and dimensions so that a metric means one thing across your data warehouse, your BI tool, and whatever agent is querying them.

Google introduced Open Knowledge Format (OKF) on June 12. An OKF bundle is a directory of markdown files with YAML frontmatter, one file per concept, cross-linked. Double parsing is required to get it all.

Both are vendor-neutral and both are also solving a slice of a problem the data contract community has been working on since 2021, which raises a question worth answering carefully rather than territorially: what is the relationship between these specifications and the combination of Open Data Contract Standard (ODCS) and Open Data Product Standard (ODPS)?

A few other initiatives are announcing themselves as the definitive layer for AI-ready data every few weeks. Let’s hurry to wait.

A Meta Standard to Rule Them All

Let’s define what a meta standard is.

A meta standard is where information is authored and the source of truth. Everything else is derived from it.

If ODCS is where the information originates, then every other representation of that dataset, every semantic model, every knowledge bundle, every catalog entry, should be a projection of the contract, generated for a specific need.

And projections can be lossy. Let me walk you through one.

Walkthrough

Here is a contract in ODCS v3.2. It describes a very basic orders table with an id and an amount. It includes a context block for AI/agentic consumers: instructions for usage guidance, verifiedStatements for curated hints/question and answer pairs, and constraints for the things a consumer must not do.

apiVersion: v3.2.0
kind: DataContract
id: c176de03-8503-4859-bd0f-218cc413d958
name: orders
domain: sales
status: active
schema:
  - name: orders
    properties:
      - name: order_id
        logicalType: string
        primaryKey: true
        description: Unique order id.
      - name: amount
        logicalType: decimal
        description: Order total.
        quality:
          - rule: nonNegativeCheck
            description: Order total must not be negative.
            dimension: validity
            severity: error
            businessImpact: operational
            schedule: 0 20 * * *
            scheduler: cron
context:
  instructions: "Use for revenue analysis and order trends. Do not use for individual customer PII queries."
  verifiedStatements:
    - question: "What counts as a completed order?"
      answer: "An order with status = 'shipped' or 'delivered'."
  constraints:
    - "Always aggregate to at least country level."
    - "Do not join with PII tables without approval."

Now project it two ways.

Bitol ODCS v3.2 + ODPS v1.1 mapped to Apache Ossie / Google OKF.

The OKF Bundle

To OKF, as a bundle:

orders_bundle/
├── index.md
└── tables/
    └── orders.md

And then the description in orders.md:

---
type: BigQuery Table
title: Orders
description: Order transactions for the sales domain.
resource: warehouse://sales.orders
tags: [sales, orders]
timestamp: 2026-06-01T00:00:00Z
---

# Schema

| Column   | Type    | Description      |
|----------|---------|------------------|
| order_id | STRING  | Unique order id. |
| amount   | NUMERIC | Order total.     |

Use for revenue analysis and order trends. Do not use for individual
customer PII queries.

The columns survive with their descriptions intact, and OKF’s # Schema convention gives them a proper home. After that, the projection thins out fast. The nonNegativeCheck rule is gone, along with its severity, its business impact, and the fact that it runs nightly on a schedule. OKF has no frontmatter field and no body convention for any of that. The instructions text survives as prose in the body, with no field boundary marking it as guidance rather than description. verifiedStatements has nowhere to go at all. Neither does constraints, so a rule about aggregating to country level becomes a sentence in a paragraph, indistinguishable from a simple commentary.

To Ossie, as a semantic model:

semantic_model:
  - name: sales_analytics
    datasets:
      - name: orders
        source: sales.public.orders
        primary_key: [order_id]
        fields:
          - name: order_id
            description: Unique order id.
          - name: amount
            description: Order total.
        ai_context:
          instructions: "Use for revenue analysis and order trends. Always aggregate to at least country level. Do not join with PII tables without approval."

Columns and descriptions again map cleanly: fields was here for this. The quality rule again has nowhere to land, because Ossie’s field object has no key for quality, severity, or schedule, and the spec is explicit that it defines meaning rather than trust.

The context block is the interesting part here. Ossie has ai_context, which is aiming at the same target, and instructions maps across almost exactly. But ai_context supports instructions, synonyms, and examples, and nothing else. So the constraints get flattened into the instructions string, where a prohibition reads identically to a suggestion. And verifiedStatements, which exists so that an agent stops re-deriving an answer someone already curated, maps to nothing. Ossie has example questions. It does not have curated answers.

Both projections drop the same information, for entirely reasonable reasons. Neither specification set out to carry governance. Ossie’s own community has already opened a discussion about whether a semantic model should carry a reference back to its contract.

Summary of the Loss

If I look a little deeper at both specs, I can list the losses by OKF and Ossie, categorically:

Quality rules and their execution metadata,
Service-level agreements (SLA),
Ownership, roles, accountable parties,
Contract status and version,
Curated question-answer pairs,
Machine-readable prohibitions,
Terms of use and access restrictions, and
The identity link back to the contract.

Many other rich concepts in the Bitol standards, like authoritativeDefinitions and customProperties do not have an equivalent. Governance by tags, a popular ODCS/ODPS practice, is also not doable.

Adopt the Bitol Standards

A friend of mine in Sydney and I have a running joke: if a project has “Open” in the name, it usually is… not. Bitol and OpenLineage survive the joke, which is convenient for me but… suspicious for you?

ODCS and ODPS are part of Bitol. They are truly open standards under the Linux Foundation AI & Data, governed in the open, with no vendor holding the pen or users dictating their will. Thank you to that community, and to the Bitol TSC, for keeping it that way.

I welcome new standards and initiatives. It fosters the dialog and the co-construction of something better. This dialog often happens on Bitol’s Slack channels, which are part of the 8900+ members of the DML community.

Come and join us in this community, adopt the Bitol open standards to maximize the return on your investment.