Open Semantic Interchange (Apache Ossie): what it is, and what it isn't yet

In one line: OSI lets BI and AI tools exchange the structure of a semantic layer model. Everything else, such as identity, governance, glossary and lineage, is out of scope or still on the roadmap.

Status

Started by Snowflake with dbt Labs, Databricks, Salesforce and others; the first spec went public in January 2026 under Apache 2.0.
Now Apache Ossie, in the Apache Incubator. Oracle, Cloudera, Dataiku, Denodo and Dremio are among the later joiners.
Only formal release: 0.1.1 (December 2025). The in-development 0.2.0.dev0 has already made one breaking change: one model per document, with the old semantic_model array removed. The spec itself says not to depend on it in production.

The whole model

Construct	What it holds
Semantic model	`version`, `name`, `description`, `ai_context`, and the lists below
Datasets	Logical entities pointing at a physical `source`, with primary and unique keys
Fields	Row-level attributes defined by an expression, in one or more SQL dialects
Relationships	Foreign-key joins between datasets, simple or composite
Metrics	Aggregate expressions at model level; may span datasets
`ai_context`	Instructions, synonyms and example questions, on almost any object
`custom_extensions`	Vendor-tagged JSON for anything the core doesn't cover

Supported dialects include ANSI SQL, Snowflake, Databricks, BigQuery, DAX, MDX, Tableau and Ossie's own portable SQL.

What it does not cover (yet)

Stable identifiers. Objects are identified by name; stable IDs are an open discussion.
Governance. No owner, steward, certification or criticality field.
Sensitivity. PII and confidentiality flags are proposals only.
Meaning. No business glossary or ontology; the project describes its own scope as structural, not conceptual, interoperability. An ontology working group is active.
Lineage. Use OpenLineage.
Storage and versioning. No registry and no model versioning. The document's version is the spec version, not yours. Catalog integration and a semantic registry are roadmap items.

A governed field, the practical way

Carry your governance in an extension until the spec grows the slots:

- name: mortgage_outstanding_balance
  expression:
    dialects:
      - dialect: ANSI_SQL
        expression: outstanding_bal_amt
  datatype: Decimal
  description: Unpaid principal on the mortgage as of the reporting date, excluding escrow.
  ai_context:
    synonyms: ["UPB", "outstanding principal"]
  custom_extensions:
    - vendor_name: ACME_CATALOG
      data: '{"global_id":"BE-000123","cde":true,"status":"certified","model_version":"2026.10.1"}'

Where to store and version OSI files

Nothing is standardized, so do what works today:

Generate OSI from your catalog, the system of record. Never hand-edit.
Keep it in Git, one file per model. CI runs the project's validator (schema, unique names, references, SQL syntax).
Tag a release when stewards approve a change set.
Deploy outward with the community converters (Snowflake Cortex Analyst, GoodData, Salesforce, Apache Polaris).

Verdict

Don't build your core model on it. It is pre-1.0, has broken its schema once, and lacks IDs and governance.
Do export to it. It is cheap, and the BI and AI vendors are converging on it.
Join the working groups if you can. Governance, identity and catalog integration are exactly where regulated industries have the most to say, and they are under-represented.

Three scales

Business: if you run dbt or a single BI tool, OSI is mostly invisible; it matters when you add a second tool or an AI analyst.
Enterprise: OSI is one outbound channel among several, next to lineage, events and an agent interface. See the consumption pattern.

Sources

Apache Ossie: Core Metadata Specification accessed 2026-10-07
Apache Ossie Roadmap accessed 2026-10-07
OSI Community Update: What's New and What's Next (April 2026) accessed 2026-10-07
Snowflake: OSI specification now live accessed 2026-10-07