Snowflake Business Ontology: What It Does, What It Can't Decide

Snowflake just gave every business definition an owner and an approval status. Only approved definitions reach AI agents.

That is the most important part of the Snowflake Business Ontology announcement on 3 November 2026. It is also the part most people will skip past, because it sounds like paperwork. It is not paperwork. It is Snowflake admitting, in product form, that the hard problem in AI analytics is not generating definitions. It is deciding which one is true.

Snowflake built the approval workflow. It did not build the decision. This article explains what Snowflake Business Ontology does, how it relates to Semantic Views and Cortex Sense, and what your data team should prepare before the public preview opens.

What Snowflake announced

Business Ontology is part of Snowflake Horizon Context, which sits inside Horizon Catalog. Snowflake presents it as one of three layers that work together:

1. Cortex Sense infers context automatically from query history, dashboards and dbt models. It drafts definitions, flags conflicting knowledge and asks teams which source to trust. Public preview soon.
2. Business Ontology governs business meaning: terms, entities, relationships and metrics, each with an owner and an approval status. Public preview soon.
3. Semantic Views execute the metrics. They package measures, dimensions and joins so agents, BI tools and SQL compute the same number. Already available.

Horizon Context also adds metadata connectors for Tableau, Power BI, dbt, SQL Server, Sigma, Omni and PostgreSQL, plus lineage across platforms. Agents outside Snowflake can query Semantic Views through MCP, with Horizon Catalog governing access.

Snowflake says the layers do not have to be adopted in order. Start with whichever one solves your most urgent problem.

There are no general availability dates and no pricing yet.

Snowflake Business Ontology vs Semantic Views

The distinction is simple once you see it. The ontology governs what a metric means. The semantic view governs how it is calculated.

	Business Ontology	Semantic Views
Answers	What does "net revenue" mean, for whom, and who owns it?	How is net revenue calculated, and at what grain?
Contains	Terms, entities, relationships, metric definitions, scope, owner, approval status	Tables, joins, dimensions, metrics, SQL expressions
Tied to a data model?	No, independent of any single model	Yes, bound to tables in Snowflake
Who maintains it	Business owners and data stewards	Analytics engineers
Open standard	Import and export to Apache Ossie and RDF	Import and export to Apache Ossie
Status	Public preview soon	Available

The ontology links to the semantic view that implements a definition, but it does not change the calculation. That separation is healthy. Finance should own what revenue means. Analytics engineering should own the SQL. In most companies I have worked with, both lived in the same LookML file or the same stored procedure, and nobody could tell which part was policy and which part was implementation.

For a deeper look at the calculation layer, see our Snowflake Semantic Views practitioner guide.

How it works in practice

Snowflake's own example is net revenue. Finance defines it once, scopes it to finance, names an owner, gets it approved, and links it to the semantic view metric that calculates it. Every agent and team that asks about net revenue then gets that approved definition.

The second example is more interesting. A restaurant group can keep separate definitions of same-store sales per brand, each approved separately, each linked to its own view. That is a realistic admission that a single source of truth does not always mean a single definition. It means a single, governed answer to "which definition applies here?"

When an approved definition conflicts with something Cortex Sense inferred from query history, agents use the approved one, and Cortex Sense learns from the correction. Horizon Catalog controls who can create, edit and approve definitions. AI suggestions and imported definitions are starting points for review, not answers.

Read that last sentence again. It is the whole architecture in one line.

The hybrid center, now a product

A week earlier, Josh Klahr from Snowflake described the market for AI context on two axes: inferred versus human-curated context, and raw SQL versus compiled semantics. His argument was that neither extreme works. Fully inferred definitions hardcode the model's misunderstandings. Fully manual modeling cannot keep up with the questions people ask.

Business Ontology is that argument shipped as software. Cortex Sense does the inferring. Business Ontology does the certifying. Semantic Views do the compiling. Agents get approved meaning and deterministic calculation for the metrics that matter, and inferred context for everything else.

It is the same conclusion the open standards reached. Apache Ossie is adding compliance tests so a metric computes the same number on every platform. Google's Open Knowledge Format added verified status and attested computations. I compared the two in Ossie vs OKF. Snowflake shipping Ossie import and export in both the ontology and Semantic Views is the strongest signal yet that the standard is real. I made the case for why that matters in Apache Ossie: The Rename Is Not the Story.

What Business Ontology does not decide

Here is the gap.

We recently ran a Logic Scan for a wholesaler with 172 objects across SQL Server, SSIS and SSRS. We found 14 definitions of revenue. Cortex Sense would likely find many of them too, if the logic were visible in Snowflake query history. Business Ontology would then give finance a clean place to approve one.

But somebody still has to sit in the room and decide. Which of the 14 is the board number? Which two are dead code that still feeds a monthly report? Which one is right for sales commissions but wrong for the annual accounts? That conversation is not a feature. It is data governance work, and it is where most AI readiness projects stall.

Three specific limits to be aware of:

Metadata is not logic. The new SQL Server connector brings tables, schemas and lineage into Horizon Catalog. That is useful. It does not untangle a stored procedure with five temp tables and a hardcoded exclusion list from 2014. The business logic in legacy BI lives in procedures, load scripts, report-level calculations and universes. Getting it out is extraction work before it is catalog work.

Approval is not reconciliation. An approved definition tells you what revenue should mean. It does not prove that the migrated semantic view produces the same number as the report finance trusted for ten years. That proof requires running both side by side and signing off only when the core KPIs match.

Ownership is political. Business Ontology assumes every definition has an obvious owner. In practice, revenue has three: finance, sales operations and the CFO's office. Naming one is a decision the tool records, not a decision it makes.

How to prepare before the public preview

If you run on Snowflake, or plan to, five things are worth doing now:

1. Inventory where your core metrics are defined today. Not the dashboards. The definitions. Include stored procedures, SSRS reports, Excel models and BI tool calculations. Count how many versions of revenue, margin and churn exist.
2. Pick owners before you pick tools. For your top 20 metrics, agree who approves each definition. If you cannot agree on that in a meeting, no ontology will agree on it for you.
3. Separate meaning from calculation. Write down what each metric means in plain language, separately from the SQL. That is your Business Ontology entry. The SQL becomes your semantic view.
4. Put the definitions in Apache Ossie. Both Business Ontology and Semantic Views import Ossie. Defining your model in the open standard means you load it into Snowflake now and keep the option to move it later.
5. Keep your reconciliation checks. For each approved metric, store a few test questions with known answers from the old report. When the definition or the data changes, rerun them. That is what turns approval into lasting trust.

We have seen this pattern before

Every platform shift brings the same promise: this time the tooling will sort out the definitions. In 2018 it was the data catalog. In 2022 it was the modern BI tool with a semantic layer. In 2026 it is AI that drafts the ontology for you.

Each generation of tooling gets better. Business Ontology is a genuinely good design: owner, scope, approval, link to the calculation, open export. But each generation also confirms the same lesson. Tools record decisions. People make them. Intelligence allocated to layer four does not fix a layer two problem.

What this means for your data strategy

Snowflake Business Ontology makes the semantic layer and the governance around it a first-class part of the data platform. That is good news for any data team that has argued for a governed single source of truth and lost the budget discussion. The platform now has a place for exactly that work.

The work itself has not changed. Find the definitions. Decide which one is true. Prove the new number matches the old one. Give it an owner.

This is what we do at Unwind Data. We extract business logic from SQL Server, Qlik, SAP BusinessObjects, Tableau and Looker, reconcile it with the people who own the numbers, and deliver it as an Apache Ossie model ready to import into Semantic Views and Business Ontology. A Logic Scan shows you in five working days how many definitions you actually have.

Snowflake built the approval button. Somebody still has to know what to approve.