Snowflake Business Ontology vs semantic views: what each layer does

Snowflake Business Ontology is a governed list of what your business terms mean, kept in Horizon Catalog, so that every AI agent asking about "net revenue" starts from the same approved definition. It does not calculate anything. Semantic views still do the maths, and the ontology links each approved term to the semantic view, table or column that implements it. Snowflake announced it at Expedition on 3 November 2026, and it is in private preview for selected accounts.

The problem it answers is old, and agents made it louder. Ask 2 analysts for last quarter's revenue and you may get 2 numbers, one with refunds taken out and one without. Ask 2 agents and you get the same split, faster, with more confidence and no one to ask why. Snowflake's own blog puts it plainly: without governed context, agents may give different answers to the same question.

Business Ontology, semantic views and Cortex Sense

Snowflake now has 3 layers between a question and a table, and each answers a different part of it.

The order matters when they disagree. An approved definition in Business Ontology overrides what Cortex Sense inferred. And the ontology never overrides a semantic view's calculation: Snowflake says it links to the view but does not change the calculation. The formula you write on a metric node is documentation. The number comes from the view.

Pick a question and switch the ontology off and on to see which layer supplies what.

Try itWhere does the agent's definition come from?

Question

·Net revenue·Active customers·Gross margin

OffOn

Approved meaning

1. 1

   Business Ontology

   Looks up "Net revenue" and finds the approved node. Finance's approved definition: sales after refunds and discounts, owned by Finance.

2. 2

   Semantic view

   The finance semantic view's net_revenue metric does the sum.

3. 3

   Tables

   The query runs with the caller's own privileges on the bound objects.

What goes into the ontology

An ontology is made of nodes, relationships between them, and representations that tie them to real objects.

• Nodes are the concepts. Each has a kind: Term (the default), Metric, Entity, Dimension or Policy. They sit in a domain, such as Finance.
• Relationships are directed links between 2 nodes. Snowflake's examples are "Order has part Line Item" and a Gross Margin metric that derives from Net Sales and Cost of Goods Sold.
• Representations bind a node to the table, view, column or semantic view that implements it. The asset keeps its own lifecycle, so if you rebuild a semantic view the definition survives.

Every node is a draft until a role with the MODIFY privilege approves it, and only approved nodes are served to Cortex. Roles with SUGGEST can propose changes for review, and READ lets a role use what is published. That split is the point of the feature: the people who know what "active customer" means approve it, even if they never write the SQL behind it. This is the same idea as a Semantic LayerSemantic LayerOne shared definition of business terms and metrics, such as revenue or active customer, that reports, dashboards and AI assistants all read instead of writing their own., with a governance step on top.

How to build one during the preview

In the preview, the full authoring tool is Snowflake CoCo, the coding agent for data teams, through its business-ontology skill: $business-ontology in the CoCo CLI, or / and then business-ontology in CoCo Desktop. It can create nodes, bind them to assets, approve suggested relationships and import a glossary you already have. Snowsight can browse the ontology, create term, metric and entity nodes and add synonyms, but not everything else.

There are no SQL commands for it yet, and a few limits to plan around:

• A domain cannot be renamed, and there are no subdomains. Choose domain names with care.
• A representation is not checked again when its table or view is dropped or renamed. A rename can leave a definition pointing at nothing.
• It is not a graph database: no SPARQL and no OWL reasoning.

How a Cortex Agent reads it

A Cortex Agent reaches the ontology through a search tool. In the agent's spec it is a tool of type snowscope_search named business_ontology, with the corpus businessOntology, switched on by experimental flags:

experimental:
  EnableSnowscopeBusinessOntologySearch: true
  EnableStandaloneExecuteSqlTool: true
  FallbackWarehouse: <warehouse_name>
tools:
  - tool_spec:
      type: snowscope_search
      name: business_ontology
tool_resources:
  business_ontology:
    corpus: businessOntology

Search returns each approved node's name, kind, definition, formula and synonyms. It does not return data or the bound objects; the agent gets those through a SQL tool, and its queries run with the caller's own privileges. 4 details from Snowflake's page catch people out:

• CREATE AGENT accepts a misspelled flag, tool type or corpus without an error. Run DESCRIBE AGENT to see what was stored. The CLI spelling business-ontology is accepted as a corpus and returns nothing.
• To find a node, the role needs READ, SUGGEST, MODIFY or OWNERSHIP on its domain. USAGE is not enough.
• A newly approved node can take up to 6 hours to show up in search.
• Ontology search is verified in the Snowsight agent playground and through DATA_AGENT_RUN. The Cortex Agents Run API, the SQL REST API and CoWork can return no ontology results yet.

Snowflake recommends one domain per agent. A finance agent reads the Finance domain; a sales agent reads Sales.

What to do if you are not in the preview

The preview is for selected accounts only. The work that makes an ontology useful can start now anyway, because it is the same work either way.

1. List the 20 terms people argue about. Revenue, active customer, churn, margin. If 2 dashboards disagree on one, it belongs on the list.
2. Write each definition in a sentence, with an owner. A term with no owner will not stay approved.
3. Put the calculations in semantic views. That is the layer agents compute from, and it is available today. Snowflake added level of detail expressions to semantic views in preview on 2 November.
4. Name the domains. They cannot be renamed later, so settle them before anything is built.

When access comes, CoCo can import an existing glossary, so a list kept in a spreadsheet or a catalog is not wasted.

If you are weighing Snowflake against other warehouses for this kind of work, Snowflake vs Databricks prices the same SQL hours on both, and our Snowflake cost calculator shows what a warehouse running agent queries all day adds up to.