Ossie vs OKF: Semantic Model or Markdown Context?

We recently ran a Logic Scan for a wholesaler of technical parts. 172 objects in SQL Server, SSIS and SSRS. We found 14 different definitions of revenue.

Not 14 metrics. One metric, written 14 ways, by people who each had a good reason at the time. Ask an AI agent "what was revenue last year?" on top of that environment and it will pick one of the 14. It will not tell you which.

Two open standards are now trying to make that problem impossible, starting from opposite ends. Apache Ossie starts from the semantic model. Google's Open Knowledge Format (OKF) starts from markdown. This article puts Ossie vs OKF side by side: what each one is, where each fits in your data architecture, and why you will probably end up using both.

Why Ossie vs OKF is suddenly a real question

Josh Klahr, who leads analytics product management at Snowflake and sits on the Ossie podling management committee, summarized it well this week. His point: a semantic view is two things. It is metadata an agent reads, and it is a compilable execution harness, "so the metric that runs is the one that was defined, not the one an LLM rebuilt from a description."

Ossie started with the first half. OKF started with neither, just markdown files. And yet both have now arrived at the same conclusion: describing a metric is not enough. The agent has to execute the definition as written.

For anyone responsible for data governance and AI readiness, that convergence matters more than which format wins. It tells you what your data foundation has to deliver before agents touch it.

What Apache Ossie is

Apache Ossie is the specification formerly known as the Open Semantic Interchange (OSI). Snowflake launched it with a group of BI and data vendors, and in July 2026 it entered the Apache Incubator. I wrote about why that rename mattered at the time: no single vendor controls the spec anymore.

Ossie is a declarative YAML format for semantic models. A model contains datasets, fields, relationships and metrics. Expressions are tagged by SQL dialect, so a metric can carry a portable ANSI version and vendor-specific versions side by side. A simplified example, in the style of the spec's own compliance fixtures:

version: "0.2.0.dev0"
name: finance
datasets:
  - name: revenue
    source: finance.recognized_revenue
    fields:
      - name: amount
        expression:
          dialects:
            - dialect: ANSI_SQL
              expression: amount
      - name: is_credit_note
        expression:
          dialects:
            - dialect: ANSI_SQL
              expression: is_credit_note
metrics:
  - name: net_revenue
    expression:
      dialects:
        - dialect: ANSI_SQL
          expression: SUM(CASE WHEN revenue.is_credit_note = false THEN revenue.amount ELSE 0 END)

The point of Ossie is interchange. You define the business logic once and move it between Snowflake Semantic Views, dbt, Omni, Looker, Cube and the other tools in the ecosystem through converters, instead of rebuilding it every time you change platform.

The second half is now under way. The repository has a portability ladder (M0 to M3) with a grader that scores how faithfully a model survives a round trip through each converter, element by element. The roadmap names a standard semantic query language and a reference engine as goals. That is the "execution harness" half Josh refers to: not just exchanging the definition, but guaranteeing it computes the same number everywhere.

Adoption is no longer theoretical either. On 3 November 2026, the same day Josh posted, Snowflake announced that both its new Business Ontology and its existing Semantic Views import and export Ossie definitions. A model you write in Ossie today loads straight into the largest data cloud that backs the standard.

What the Open Knowledge Format (OKF) is

OKF comes from Google Cloud. Version 0.1 appeared in June 2026, version 0.2 on 24 July 2026. Google's framing: the context AI agents need "should live in a format, not in a proprietary service, and not scattered across unstructured text blobs."

An OKF bundle is a folder of markdown files with YAML frontmatter. Tables, metrics, policies, runbooks and computations each get a file. Google's sample bundle looks like this:

acme_retail/
├── index.md, log.md
├── tables/ orders.md
├── metrics/ revenue.md, gross-margin.md, gross-margin-legacy.md
├── computations/ revenue-ytd.md, gross-margin-period.md
├── skills/ run-on-bq.md
├── attesters/ sql_equality.py
└── policies/ revenue-recognition.md, margin-standard.md

Version 0.2 added five trust signals in the frontmatter: provenance (sources), trust (generated and verified, where a human reviewer upgrades the trust tier), freshness (stale_after), lifecycle (status: draft, stable, deprecated) and attestation.

Attestation is the interesting one. An attested computation carries the sanctioned SQL itself. The agent may only fill in typed parameters, such as the fiscal year. An executor runs the query and returns a receipt with the job ID, the SQL that actually ran and the result. Then a deterministic attester, with no LLM involved, checks that what ran equals what was defined. If the check fails, the consumer refuses to show the number.

Google is explicit that attestation and verification are different things. Verification confirms the definition still matches policy, slowly, at document level. Attestation confirms that a single run produced the value correctly, every time.

Ossie vs OKF side by side

	Apache Ossie	Open Knowledge Format (OKF)
Origin	Snowflake and partners, now Apache Incubator	Google Cloud
Format	YAML semantic model	Markdown files with YAML frontmatter
Core unit	Datasets, fields, relationships, metrics	Concepts: tables, metrics, policies, computations, skills
Primary job	Move business logic between BI and AI platforms without rewriting it	Give agents all the context they need, including what never fits a model
How it guarantees the number	Compilation: the metric is generated from the model, tested across converters	Attestation: the sanctioned query is checked after every run
Strength	Joins, grain, composable metrics, slicing by any dimension	Business rules, exceptions, ownership, freshness, provenance
Weakness	Cannot hold the prose: the "why" behind a definition	Each attested computation is one fixed query, not a model you can slice freely
Maturity	Incubating, spec at 0.2 development version	v0.2, additive and backward compatible

Semantic model or markdown context? The honest answer is both

The screenshot that started this discussion shows the same revenue metric twice: once as an OKF attested computation, once as a Snowflake Semantic View. Same SUM, same table, same fiscal year filter. That is the convergence in one image.

But look closer and they solve different problems.

The semantic model wins when people slice. Revenue by region, by product line, by month, by customer segment. A semantic layer compiles the right joins and the right grain for every combination. An attested computation is one sanctioned query with parameters. You would need a separate file for every cut, which is exactly the hand-coding bottleneck that made governed BI slow in the first place.

Markdown wins when the knowledge is not a formula. Why finance excludes intercompany transactions. Why the 2025 margin numbers use the old cost allocation. Who owns the churn definition and when it was last reviewed. I have never seen a semantic model hold that well, and I have built a lot of them since my years as a Looker partner. In most migrations that context lived in one person's head or one Confluence page nobody updated.

So the practical architecture looks like this:

• Ossie for the metrics. The governed definitions of revenue, margin, churn and the rest of your core KPIs, portable across platforms.
• OKF-style markdown for everything around them. Policies, exceptions, ownership, deprecated definitions kept for reproducibility, freshness dates.
• Attestation for the high-stakes numbers. The board-deck metrics and anything that drives a payout get a deterministic check, not just a definition.

That is also roughly where Snowflake, Omni and Anthropic's own internal analytics have landed: a governed semantic layer first, with an agent allowed to fall back on reference docs and lineage for questions nobody modeled. Josh calls it the hybrid center. I wrote about the underlying choice in semantic layer vs text to SQL.

We have seen this pattern before

In 2018 every company hired data scientists before it had clean data. In 2022 every company bought a modern BI tool and migrated dashboards one to one, carrying the metric chaos with them. In 2026 every company is deploying AI agents on top of business logic nobody has written down.

Each wave puts the intelligence in the wrong layer. Agents are layer four. The definitions they depend on are layer two. Ossie and OKF are both, in their own way, an admission that layer two has to be fixed first. Start at one, not at four.

The part neither standard solves

Both specs assume you already know what the right definition is.

Google's sample bundle has a clean revenue.md and a neatly deprecated gross-margin-legacy.md. Real environments do not. Our wholesaler had 14 revenue definitions spread across stored procedures, SSIS packages and report-level calculations. Some were wrong. Some were right for one department. Two were dead code that still fed a monthly report.

You cannot attest a computation until someone decides which computation is sanctioned. You cannot export a semantic model until someone has untangled the procedure that defines it. That work is extraction plus judgment, and it is where most AI readiness projects actually stall.

Tools can now automate a lot of the extraction for modern BI platforms. The judgment does not automate. Somebody has to sit with finance, compare the old report with the new number and sign off when they match.

What this means for your data strategy

If you are planning a BI migration or an agent rollout in the next year, four practical points:

1. Do not bet on one format. Ossie is incubating and OKF is at v0.2. Both will change. Put your logic in an open, declarative form now so converting later is cheap.
2. Separate the formula from the context. Metrics go in a semantic model. Rules, owners and exceptions go in markdown next to it. Do not try to force one into the other.
3. Turn reconciliation into an asset. Every migration already compares the old number with the new one. Keep those checks. A metric with an owner and a few test questions with known answers is an attester in everything but name.
4. Find your 14 definitions first. Before any agent goes live, inventory where your core metrics are defined today. That is the single source of truth problem, and no standard fixes it for you.

This is what we do at Unwind Data. We extract business logic from SQL Server, Qlik, SAP BusinessObjects, Tableau and Looker, deliver it as an Ossie semantic model with the surrounding knowledge in markdown, and sign off only when the core KPIs reconcile with the old report. A Logic Scan shows you in five working days how many definitions you actually have.

The standards are converging. The bottleneck is not the format. It is knowing which number is true.