Short answer: Snowflake Business Ontology is a governed graph of business concepts in Horizon Catalog, in private preview since 3 November 2026. Domain stewards approve terms and metrics, with owners, variants and an audit log, across assets in Snowflake and, through metadata connectors, outside it. It does not execute metrics. Snowflake Semantic Views calculate them, on data Snowflake can query, so one approved definition does not make Databricks, BigQuery and Postgres return the same number.
Snowflake shipped Business Ontology into private preview on 3 November 2026. Its engineering blog states the limit that matters to anyone running data on more than one platform: "The ontology stores a formula as written; it does not execute it." Governed calculation stays with Snowflake Semantic Views. This post explains what Business Ontology certifies, how the three Snowflake layers divide the work, and what happens to an approved definition when the data it describes lives in Databricks, BigQuery or Postgres.
| Capability | Snowflake Business Ontology (private preview) | What a cross-engine semantic execution layer adds |
|---|---|---|
| Approve a business definition once | Yes. Steward-approved concepts with owners, domains and variants | Consumes the approved definition as the source of meaning |
| Discover assets outside Snowflake | Yes. 18 metadata connectors including Databricks, BigQuery, Oracle, PostgreSQL | Connects to the same engines to run queries, not only to read metadata |
| Calculate the governed metric | Snowflake Semantic Views, on data Snowflake can query | Compiles the same definition into SQL for each engine where the data sits |
| Apply access policy at query time | Horizon Catalog governs access inside Snowflake | Injects row, column and attribute policies into the compiled query on every engine |
| Give the same answer on two engines | Not documented | Same compiled logic, same policy, one audit trail across engines |
The problem Snowflake is solving
Ask three teams what "net revenue" means and you get three formulas, each defensible inside its own department. An AI agent asked the same question picks one of them, or invents a fourth, and returns a number with full confidence. Gartner put this plainly at its Data and Analytics Summit in May 2026: without a clear understanding of the relationships and rules in an organisation's data, agents cannot operate accurately and are far more likely to hallucinate. Gartner predicts that organisations prioritising semantics in AI-ready data will raise agentic AI accuracy by up to 80 percent and cut costs by up to 60 percent by 2027 (Gartner press release, 11 May 2026).
An MIT Technology Review Insights survey of 400 senior data and technology executives found that 55 percent named lack of business context as the top reason agent-generated insights fall short (MIT Technology Review Insights, 2 November 2026). Snowflake sponsored that study and published it the day before Expedition, so read it as the company framing the problem it was about to answer. The framing is still correct. Two of Snowflake's launch customers, dentsu and Merkle, describe semantic drift across multi-partner data environments as the risk they bought the product to contain (Snowflake press release, 3 November 2026).
What is Snowflake Business Ontology?
Business Ontology lives inside Horizon Context, the part of Horizon Catalog that holds governed business context. It is a graph. The nodes are concepts of a fixed set of kinds: term, metric, entity, action, policy, dimension and measure. Only metrics carry a formula, exclusions and formula provenance. The edges are directed, typed relationships from a short list (IS_A, HAS_PART, DERIVES, MEASURES, APPLIES_TO, EQUIVALENT_TO, RELATED_TO), with custom relationships allowed if they carry a label (Snowflake engineering blog, 3 November 2026).
Three design decisions shape it.
Every concept has one home domain. The domain is part of the qualified name, so Finance.Net Revenue and Sales.Net Revenue coexist as separate approved concepts. Domains nest. Duplicates inside one domain can be merged; duplicates across domains cannot. Snowflake's own example is a restaurant group whose same-store sales definition differs by brand, with each variant approved on its own.
Approval belongs to the domain steward. New concepts start as drafts. An edit to an approved concept becomes a proposed edit, and agents keep using the approved version until a steward accepts the change. Preview privileges run from USAGE and READ through SUGGEST (propose drafts) to MODIFY (steward actions) and OWNERSHIP. Drafts are visible only to the author and the stewards. For a role without access, the concept behaves as if it does not exist.
Representations are references. A concept points at the asset that implements it: a table, a column, a semantic-view metric or a connected dashboard. The engineering blog is explicit: "A representation is a reference; it does not run the metric." Representations do give Snowflake something to check against, so the platform can flag changed formulas, drifting descriptions and metrics that have disappeared. Every change is logged, so the question "what did net revenue mean in Q2, and who approved it" becomes a lookup.
Definitions come in through the Business Ontology page in Snowsight, through a skill in Cortex Code, by bootstrapping from existing Semantic Views, by promotion from Cortex Sense, or by importing an external glossary. Snowflake says a third-party catalog or spreadsheet can be migrated in a single guided session, with everything landing as a draft. Concepts and relationships import and export through Apache Ossie (incubating) and RDF (Snowflake product blog, 3 November 2026).
What Snowflake has not published: a general availability date, pricing, edition requirements, or an executable public specification. The YAML in its blog is labelled illustrative and not importable. Product behaviour may change during preview.
Three layers, three responsibilities
Snowflake's press release states the division of labour in one line: "A Business Ontology governs the official meaning, a Semantic View calculates it, and Cortex Sense infers what isn't already defined." The product blog adds that the three layers are not sequential.
| Layer | Job | Status (as of 4 November 2026) |
|---|---|---|
| Cortex Sense | Infers context from schemas, query history, dashboards and dbt models; can draft ontology entries | Announced June 2026; public preview "soon" |
| Business Ontology | Holds the approved meaning, ownership, domains, variants and relationships | Private preview; public preview "soon" |
| Semantic Views | Calculates governed metrics; the only layer that runs SQL | Generally available since June 2025 |
The agent instruction pattern Snowflake describes follows from this. The ontology decides meaning. A Semantic View is authoritative for any number it covers. Cortex Sense fills gaps beyond governed coverage. Answers come back labelled governed (from a semantic-view metric), derived (calculated from governed parts, formula shown) or exploratory (ad hoc SQL, query shown). When an approved definition conflicts with a Cortex Sense inference, the approved definition wins and Cortex Sense learns from it.
This is good design. The labelled answer alone would improve most agent deployments we see. It also makes the boundary easy to locate: everything that executes, executes in a Semantic View.
The execution boundary
Snowflake's press release says an organisation can define a version of a metric once and "apply it across an organization's data inside and outside of Snowflake." The reach of that sentence depends on which of three situations you are in.
Data physically outside Snowflake, queried through Snowflake. Iceberg tables and external tables let Snowflake compute over data it does not own. A Semantic View over an Iceberg table is a normal Semantic View. Business Ontology governs it like any other. The execution engine is still Snowflake.
Data outside Snowflake, discovered but not queried by Snowflake. Horizon Context's 18 metadata connectors read metadata from Power BI, Tableau, dbt, SQL Server, Oracle, Databricks, BigQuery, MySQL and PostgreSQL without copying data (Snowflake release notes, 12 October 2026). An approved concept can carry a representation pointing at a Databricks table or a Power BI measure. That is governance of meaning across the estate, and it is valuable: one catalog entry now says what the term means and who owns it. The number itself is still produced by whatever engine runs that table or measure, with whatever logic that engine holds.
An agent outside Snowflake that wants the governed number. Snowflake's product blog says agents outside Snowflake query Semantic Views through the Model Context Protocol, with Horizon Catalog governing access. Snowflake's agent documentation confirms that a Cortex Agent can route across multiple Semantic Views to answer a request (Snowflake docs, Cortex Agents). So an external agent, whether Claude, ChatGPT or an in-house orchestrator, reaches a governed answer by calling into Snowflake, which computes it on data Snowflake can query. Whether a third-party agent can read the ontology graph directly, rather than through a Cortex Agent, is not documented in the materials Snowflake has published.
Business Ontology extends governance reach across the whole data estate. Governed execution reach stops at the edge of what Snowflake compute can query. For an enterprise where transaction data sits in Databricks, finance reporting runs on BigQuery and operational systems run on Postgres, an approved definition of net revenue tells everyone what the term means. It does not make those three engines produce the same number.
Snowflake has not said this is impossible. It has not documented a way to do it, and the engineering blog's wording ("it does not execute it") suggests execution outside Semantic Views was never the design goal.
Apache Ossie: portability of definitions is not portability of outcomes
The obvious response is that Ossie solves this. Export the approved definition, convert it, run it elsewhere. Ossie deserves a fair description, because it is further along than its incubating status suggests.
Apache Ossie (incubating, formerly Open Semantic Interchange) is a vendor-neutral YAML and JSON specification for semantic models. It entered the Apache Incubator in July 2026 with contributors from Snowflake, Databricks, dbt Labs, Salesforce, Oracle, ThoughtSpot and others (Snowflake blog, July 2026). The repository already carries reference converters for Databricks Unity Catalog Metric Views, dbt MetricFlow, GoodData, Polaris, Salesforce and NVIDIA's semantic framework, and its expression dialect list now covers Snowflake, Databricks, BigQuery, Tableau and ThoughtSpot (Apache Ossie repository).
So there are three levels of portability, and Ossie addresses the first two:
- Syntactic. Can the definition be written in a common format? Yes.
- Implementation. Can it be translated into the target engine's native semantic objects? Increasingly, yes.
- Execution equivalence. Does the translated definition produce the same result, under the same business rules and the same access policy, on a different engine? This is where the converters stop.
The converter documentation says so itself. When a SQL expression cannot be parsed, it is carried through verbatim as opaque text. Metrics that cannot be queried through the target's model raise a LOSSY warning. The Ossie-to-Snowflake converter produces Cortex Analyst semantic model YAML, which is the older format that Snowflake now recommends replacing with Semantic Views (Apache Ossie converter docs). Two engines can each load a faithful copy of the same metric and still disagree, because NULL handling, date boundaries, join cardinality, currency conventions and exclusion rules are properties of the execution, not of the definition.
Business Ontology and Semantic Views also export different things. Business Ontology exports concepts and relationships. Semantic Views export executable models. Both go through Ossie, but they are different objects, and whether approval status, variants and policy survive the round trip is one of the open questions Snowflake has not answered yet.
The field in November 2026
Snowflake is not alone, and the launches cluster tightly. Databricks made Unity Catalog Business Semantics generally available earlier in 2026 and open sourced the core Metric Views implementation in Apache Spark (Databricks blog). Then four offerings arrived within 28 days.
| Offering | Announced | Where governed execution happens | Status |
|---|---|---|---|
| Dell Unified Semantic Layer | 6 October 2026 | Inside the customer's data centre, on the Dell AI Data Platform | First half of 2027 |
| Oracle Business Semantic Layer | 26 October 2026 | Oracle Autonomous AI Lakehouse | Within the next 12 months |
| NVIDIA Auto Ontology | Released 1 November 2026 | Open-source framework; agents generate SQL with provenance against connected sources | Available, Apache 2.0 |
| Snowflake Business Ontology | 3 November 2026 | Snowflake Semantic Views | Private preview |
Each platform vendor has anchored governed meaning to its own compute. That is the pattern Gartner described in its 2026 Hype Cycle for AI Governance Technologies, where the vision of a universal semantic layer is said to remain unrealised because of technological limits and vendor walled gardens (quoted by Strategy, a vendor named in that report, since the report itself is paywalled: Strategy blog, 7 August 2026).
NVIDIA Auto Ontology is the outlier worth watching. It is open, it reads from Postgres, Databricks, Snowflake and DuckDB, and it exposes context over MCP. As of this week NVIDIA has published an evaluation harness but no accuracy results, and the framework's job is to generate an ontology and validate the SQL agents produce from it. Building the starting ontology is the easier half. Deciding which of two approved definitions wins when an executive asks a company-wide question, and then proving both engines computed it the same way, is the part none of the November launches address.
The three problems an enterprise still has to solve
Go back to the net revenue example. Finance defines it as revenue minus refunds minus discounts. Sales defines it as bookings minus discounts. Business Ontology preserves both, with owners and domains, and that is the right first step. Now an executive asks an agent: what was the company's net revenue last quarter?
There are three separate problems hiding in that question.
| Problem | What has to be solved | Where Snowflake's November launch lands |
|---|---|---|
| Definition governance | Who owns and approves a definition? | Solved. Stewards, domains, drafts, audit log |
| Semantic reconciliation | How are equivalent, overlapping or conflicting definitions resolved for a question that spans domains? | Partly. Variants and EQUIVALENT_TO relationships exist; the decision is still a human's |
| Execution governance | How does the chosen definition produce the correct number, with the right access policy, on every engine where the data lives? | Inside Snowflake compute only |
An analyst at Unwind Data put the second problem well: Snowflake built the approval workflow, it did not build the decision (Unwind Data, 4 November 2026). The third problem is the one that grows with every additional platform. Governance that stops at approval creates a queue. At 15,000 concepts across 50 domains with hundreds of agents consuming them, someone has to find the equivalents, rank the conflicts and retire the obsolete definitions, and the steward model on its own does not do that.
Evidence that governed execution is what moves accuracy comes from dbt Labs' April 2026 benchmark, which is vendor-run but the most detailed public test available. On a modelled project, Claude Sonnet 4.6 went from 90.0 percent accuracy with raw text-to-SQL to 98.2 percent through a semantic layer, and GPT-5.3-Codex went from 84.1 percent to 100 percent. Questions outside the modelled scope scored zero through the semantic layer, because the layer refused rather than guessed (dbt Labs, 7 April 2026). The gain comes from executing against governed definitions, and the refusal behaviour is a feature. Neither effect appears until the definition reaches the engine.
The model that scored 84 percent and the model that scored 100 percent were the same model. What changed was whether the business definition reached the query.
Where Colrows fits
Colrows is a semantic execution layer. It is the piece that takes a governed definition and runs it, the same way, wherever the data is.
Colrows does not replace Business Ontology. If your organisation has already invested in Snowflake governance, the approved concepts, owners and domains are the right source of meaning, and the semantic model Colrows maintains is designed to hold definitions you bring to it. Colrows' own semantic assets (definitions, verified queries, policies, version history) export as JSON and other formats and stay with the customer, which is the same portability principle Snowflake is adopting with Ossie.
Colrows compiles questions into governed SQL. A question in plain language is resolved at compile time into governed SQL for the engine where each table lives. Colrows connects to Snowflake, Databricks, BigQuery and Redshift and queries data in place, without copying it out of the source system. Joins across those sources are resolved at query time with a join-path proof, so an agent asking for net revenue by region when revenue sits in Snowflake and region hierarchy sits in BigQuery gets one compiled plan, not two guesses stitched together by a language model.
Policy travels with the definition. Role, attribute, row and column policies are injected into the compiled query on every engine. A restricted row is never read, so an agent cannot see it, summarise it or leak it, whichever platform holds it.
The same answer is reproducible. Every answer carries an audit trail and a point-in-time version of the definitions used, so "what did net revenue mean in Q2" is answerable on Databricks and BigQuery as well as on Snowflake, from the same log.
Reconciliation is part of the job. Colrows builds roughly 80 percent of its semantic layer automatically from the connected schemas (measured as the share of definitions and relationships it proposes without a human writing them). When two sources contradict each other, it resolves the contradiction where the evidence is clear and flags it for a person where it is not. That is the piece between approval and execution that the steward model leaves to a queue.
Agents and layer come from one place. Colrows ships the data agents (analytics, reporting, pipeline root-cause) alongside the semantic execution layer, so there is no integration seam between the vendor who holds the definitions and the vendor whose agent runs the query.
One caveat. The strongest claim in this post, that two engines return the same governed number from one definition, is something we demonstrate rather than assert. We make it on live engines in a technical review, with your definitions, so you can check NULL handling, date boundaries and policy filters yourself. For a Snowflake-first shop evaluating the layer underneath, our guide to choosing a semantic layer for AI agents in 2026 sets out the questions to ask any vendor, including us. If you are weighing retrieval against governed execution, RAG versus a semantic layer covers the architectural trade.
What to do with this if you run Snowflake plus something else
- Join the Business Ontology preview when it opens. The steward model, domain-qualified names and audit log are worth having even if you never consume them from outside Snowflake.
- Inventory where each governed metric executes. For each one, note the engine. If more than one engine appears, you have an execution governance problem that approval will not fix.
- Test one metric through Ossie end to end. Export it, convert it, run it on the second engine, and compare results on a month with refunds and a currency change. The gap, if there is one, is your business case.
- Decide who owns reconciliation. Not approval, reconciliation: the resolution of competing approved definitions for cross-domain questions. If the answer is "a committee," plan for the queue.
Ready to see one definition execute on two engines with the same policy and the same audit trail? Book a technical architecture review and bring your own net revenue formula.
Status note
Snowflake Business Ontology is in private preview as of 4 November 2026, with public preview announced as "soon" and no general availability date or pricing published. Product behaviour may change. This post will be updated as Snowflake publishes specifications and availability.
Snowflake Business Ontology: frequently asked questions
What is Snowflake Business Ontology?
A governed graph of business concepts inside Horizon Context, part of Snowflake Horizon Catalog. Domain stewards approve terms, metrics, entities and other concepts, with owners, variants, typed relationships and an audit log. It entered private preview on 3 November 2026.
How is Business Ontology different from Snowflake Semantic Views?
Business Ontology holds the approved meaning. Semantic Views calculate governed metrics and are the layer that runs SQL. In Snowflake's words, "The ontology stores a formula as written; it does not execute it."
What is Cortex Sense?
The Snowflake layer that infers context from schemas, query history, dashboards and dbt models, and can draft ontology entries. It was announced in June 2026, with public preview "soon". When it conflicts with an approved definition, the approved definition wins.
Can Snowflake Business Ontology execute metrics on Databricks or BigQuery?
Not as documented. Its 18 metadata connectors read metadata from Databricks, BigQuery, PostgreSQL and others, so an approved concept can point at assets there. Governed calculation runs in Snowflake Semantic Views, on data Snowflake can query.
Does Apache Ossie make semantic definitions portable?
Partly. Ossie gives definitions a common YAML and JSON format and reference converters to engine-native objects. It does not guarantee the same result on another engine: unparseable SQL passes through as opaque text, and lossy conversions raise a LOSSY warning.
Can external AI agents access Snowflake Business Ontology through MCP?
Agents outside Snowflake can query Semantic Views through the Model Context Protocol, with Horizon Catalog governing access. Snowflake has not documented whether a third-party agent can read the ontology graph directly.
Sources
- Snowflake press release, 3 November 2026
- Snowflake engineering blog, 3 November 2026
- Snowflake product blog, 3 November 2026
- Snowflake release notes, Horizon Context preview, 12 October 2026
- Snowflake docs, Cortex Agents
- Snowflake blog on Apache Ossie, July 2026
- Apache Ossie repository and converter docs
- Gartner press release, 11 May 2026
- MIT Technology Review Insights, 2 November 2026 (sponsored by Snowflake)
- Strategy blog quoting Gartner Hype Cycle for AI Governance Technologies 2026, 7 August 2026
- dbt Labs benchmark, 7 April 2026
- Databricks blog, Unity Catalog Business Semantics GA
- Oracle press release, 26 October 2026
- Dell press release, 6 October 2026
- NVIDIA Auto Ontology repository
- Unwind Data, 4 November 2026
