What Is Apache Ossie? The Open Standard for Semantic Models, Explained

What Apache Ossie is, in 60 seconds

Apache Ossie is an open specification for describing a semantic model in a YAML or JSON file, so that BI tools, query engines and AI agents can exchange the same definitions instead of each keeping its own copy. The project describes itself as an effort to standardize semantic model exchange across analytics, AI and BI platforms. It is licensed under Apache 2.0 and the repository had about 2,500 stars on 19 October 2026.

A file holds five things:

• datasets – logical tables with a source and a primary_key;
• fields – columns and computed expressions, each with one or more SQL dialects;
• relationships – joins between datasets, written as from, to and the key columns on both sides;
• metrics – aggregates defined once, such as SUM(store_sales.ss_ext_sales_price);
• ai_context – instructions and synonyms meant for an AI agent reading the model.

It is a format, not a runtime. Nothing executes an Ossie file; a tool reads it and builds its own objects from it, such as a Snowflake semantic view.

From OSI to Ossie

Ossie was called the Open Semantic Interchange (OSI) until July 2026, when the project entered the Apache Incubator under the new name. The Apache site dates its announcement 10 July 2026, while Snowflake’s post about it is dated 8 July, so we quote the month and not the day. Searches for “OSI semantic model” and “Apache Ossie” lead to the same repository.

“Incubating” is the label the project carries on its site and in its README, and it is the right way to read everything below.

The problem: one metric, three numbers

Ask three tools for revenue and you can get three answers, each defensible. We checked this on the OWOX demo shop, which is synthetic data in a Google BigQuery project we can query. Every order has a status: Completed, Cancelled or Returned. Across 18,182 orders from 1 January 2024 to 19 October 2026, “revenue” is:

The gap between the first and the last is 1,352,632.69, about 15% of the larger number. None of the three is a bug. Each tool just picked a rule and never wrote it down where the others could read it. When one of those tools is an AI agent answering a question in chat, it picks the rule that looks most natural to it.

An Ossie file is where the rule gets written down once, next to the join logic it depends on, in a form every participating tool can parse.

Writing the three rules down

To see what that looks like, we wrote the three rules as a small Ossie model of the demo shop: two datasets, orders and purchases, one relationship on order_id, and three metrics.

metrics:
  - name: gross_revenue
    expression:
      dialects:
        - dialect: ANSI_SQL
          expression: SUM(purchases.line_revenue)
  - name: revenue_excl_cancelled
    expression:
      dialects:
        - dialect: ANSI_SQL
          expression: SUM(CASE WHEN orders.status <> 'Cancelled' THEN purchases.line_revenue END)
  - name: net_revenue
    expression:
      dialects:
        - dialect: ANSI_SQL
          expression: SUM(purchases.line_net_revenue)

The repository’s validation/validate.py, which checks the schema, unique names, relationship references and the SQL syntax of every expression, passed the file. The canvas read it as two datasets with three and seven fields (the three metrics land on purchases as calculated fields) and one relationship, with nothing under “Not imported” and no warnings.

Then we ran the three formulas against the demo shop in BigQuery, limited to orders up to 19 October 2026, because the shop adds rows every day. They return 8,959,480.25, 8,045,288.81 and 7,606,847.56, the three numbers from the table above. The point is not that Ossie computes them. It does not. The point is that the file holds the three rules side by side with their names, so “revenue” in a chat with an agent can be resolved to one of them on purpose. In our model, the ai_context says to default to net_revenue unless the question says every order line.

One caution from the same run: a metric’s meaning here depends on the join. revenue_excl_cancelled reads orders.status, so it only means something because purchases_to_orders joins the two datasets. A tool that ignores relationships would compute a different number from the same formula.

What is inside an Ossie file

We use the official TPC-DS example from the apache/ossie repository, examples/tpcds_semantic_model.yaml, a retail model of 672 lines, 619 of them non-empty. The file starts like this:

version: "0.2.0.dev0"

name: tpcds_retail_model
description: TPC-DS retail semantic model for sales and customer analytics
ai_context:
  instructions: "Use this semantic model for retail analytics. ..."

datasets:
  - name: store_sales
    source: tpcds.public.store_sales
    primary_key: [ss_item_sk, ss_ticket_number]

Three details are easy to miss.

Relationships are explicit joins. The model declares four, each from the fact table to a dimension:

relationships:
  - name: store_sales_to_date
    from: store_sales
    to: date_dim
    from_columns: [ss_sold_date_sk]
    to_columns: [d_date_sk]

Metrics are written against datasets, not tables. total_sales is SUM(store_sales.ss_ext_sales_price) in ANSI SQL. The file lists eight metrics, and three of them, cumulative_sales, brand_rank_in_store and monthly_sales_change, use window functions such as LAG(...) OVER (...).

ai_context carries synonyms. total_sales is tagged with “total revenue”, “gross sales” and “sales amount”, so an agent asked for “gross sales” can find the metric. That is the mechanism behind the claim that the standard helps AI agents, and it is also all it is: text attached to a definition.

What the file looks like as a model

A 619-line file is hard to review. We opened the same file on the OWOX Model Canvas, a free browser tool at model.owox.com that needs no login, by pointing its link at the file on GitHub. The import dialog read the file as Apache Ossie and reported, before we clicked anything:

• five datasets: store_sales with 17 fields, date_dim with 5, and customer, item and store with 6 each;
• four relationships, which will import as joins;
• Not imported (2): the unique keys on customer, and the SALESFORCE and DBT custom extensions;
• Warnings (3): one line each for cumulative_sales, brand_rank_in_store and monthly_sales_change, saying window functions are not supported by OWOX and would be refused on push.

After the import, store_sales sits in the middle with four edges out to the dimensions, each labelled with its join keys, for example ss_item_sk = i_item_sk, and read as many-to-one. That is the whole model in one picture: a fact table and four lookups, which a reader of the YAML would need several minutes to reconstruct.

The warnings are the useful part. They are a list of the places where the file says more than a given tool can act on, and a tool that stays silent about them is one you cannot trust with a metric. The canvas shows the check on one example; it is not proof that any other tool behaves the same way.

Who supports it today

The ecosystem page on ossie.apache.org lists 73 organizations. Most are a logo with no stated status, so we leave them out. These are the ones whose own documentation we could read in October 2026:

The last column is the finding that matters.

What Ossie does not do yet

The version you can download is not the version most vendors read. The official examples and the spec on the default branch are 0.2.0.dev0. That draft is a breaking change: earlier versions wrapped a model in a semantic_model array, and the current schema accepts only a flat document with the model’s properties at the root. The spec says so in its migration notes, and its first line calls itself a draft that may change before 0.2.0 is released. Snowflake’s procedure documents support for 0.1.1 and dbt documents 0.1.0 and 0.1.1. We did not run either against the TPC-DS file, so we cannot say how they fail. We can say that nothing in their documentation promises that the file at the top of the official examples folder will load.

There is no stable release. The Apache repository lists no releases, and the specification on its default branch marks itself as a draft. That sits oddly beside January 2026, when Snowflake’s announcement called the OSI specification finalized: the first line of the format, 0.1.x, was declared done under the old name, and the Apache version is rewriting it.

One file is one model. The 0.2.0.dev0 spec defines no bundle format and no references between models. A company with a dozen models has a dozen files and a naming problem the format does not solve.

The format does not run anything. It cannot tell you that two definitions of revenue disagree. It gives them one place to be written and compared. Whether a tool lets one definition win, and which, is that tool’s decision.

Window functions and per-vendor extras do not travel. The canvas imported all eight metrics but warned that three of them, the window functions, would be refused on push, and neither the SALESFORCE nor the DBT extension block came across. Both are expected, and both show that “portable” means a common core, not everything in the file.

So is it ready for production? For reading and reviewing a semantic model, yes: it is plain text you can diff. For making Snowflake, dbt and a BI tool agree on one definition of revenue, the honest answer today is that the vendors have not settled on one version of the format.

Where this leaves you

Three things to do this week, in order of effort. First, find out which Ossie version each of your tools reads; the table above is the model for the question to ask. Second, write one metric you already argue about, in the form shown earlier, and run it through the repository’s validator, which takes a minute and tells you whether the SQL parses. Third, open the file as a diagram and read what the importer says it cannot carry before you decide the file is a source of truth.

The question to ask is not whether to adopt Ossie. It is whether the model your tools share is written down anywhere a person can read it. If your definitions live in a BI tool’s internal objects, an Ossie file is a way to get them out as text. If you already keep a data model of your own, Ossie is one more format to write it in.

OWOX’s own word for the thing is data model, and semantic layer vs Data Marts explains where we draw that line; Ossie’s own word is semantic model, and we use it here for the standard. For the neighbouring format, what OKF is covers Google’s markdown approach, and OKF vs dbt exposures vs LookML compares it with the tools you may already use. To see an Ossie file as a diagram, paste a GitHub link into the Model Canvas, which imports Apache Ossie (incubating) and OKF.

Data ModelingBenefits of Data Modeling for Business ReportingMarch 3, 2025→Data ModelingBest Data Modeling Tools in 2026July 21, 2026→Data ModelingBest Free ERD Tools in 2026July 10, 2026→

See all articles →