Skip to content
Blog/Expedition 26/Meaning Before Metrics: How We Built a Governed Business Ontology for AI Agents
Nov 3, 2026/11 min readExpedition 26

Meaning Before Metrics: How We Built a Governed Business Ontology for AI Agents

Purvaja Narayanaswamy +2

 

Business Ontology is in private preview, and product behavior may change.

Remember your first week? Someone asks for net revenue. You find a Finance column, a Sales column, a semantic view, and a dashboard — all labeled the same, but calculated differently. Finance means recognized revenue after refunds and discounts; Sales means bookings net of discounts at signing. Both are right. You learn which one to use by asking a colleague — and, over time, who owns the definition and can approve a change.

An AI agent is a new hire on day one, every time. It can read the warehouse and write SQL, but it cannot ask that colleague. Faced with several plausible definitions, it may choose one and sound certain.

Business Ontology gives the agent that missing onboarding: steward-approved meaning, clear ownership and connections to the data.

 

Figure 1
Figure 1. Snowflake Cortex Sense contributes broad inferred context, Business Ontology contributes approved meaning and semantic views contribute governed computation. These are complementary capabilities, not required setup steps.

1. Model business meaning — not just definitions

“Net revenue” is more than a glossary entry. A useful model captures what the term means, what kind of concept it is, what it relates to, which policies apply, where it is implemented and who owns it.

Business Ontology represents that knowledge as a graph:

  • Nodes are concepts, such as Net Revenue or a revenue-recognition policy.
  • Edges connect concepts with a directed, typed relationship. For example, Gross Revenue DERIVES Net Revenue, and a recognition policy APPLIES_TO Net Revenue.
  • Representations point from a concept to an asset that describes or implements it, such as a metric in a semantic view. A representation is a reference; it does not run the metric.

Each concept belongs to one domain, and its domain is part of its qualified name: Finance.Net Revenue or Sales.Net Revenue. That distinction lets teams use the same words without overwriting each other’s definitions.

 

Figure 2
Figure 2. Finance and Sales own separate Net Revenue concepts; the Finance concept connects to its policy, source concept and implementing semantic-view metric.

Why keep the model in Snowflake?

Snowflake Horizon Catalog already knows about tables, views, columns, semantic views, connected BI assets and roles. Keeping business meaning alongside that metadata makes useful checks possible: a representation can be validated against an existing asset, and access to definitions can follow role-based permissions. If the underlying asset changes, the connection can be checked again.

Teams can work with the graph in the Business Ontology page in Snowsight or use the business-ontology skill in Cortex Code to create domains, draft concepts, import an existing external glossary or ontology through the supported file-import path, bootstrap from semantic views and build agents.

Concepts can be drafted by hand, imported from an existing external glossary or ontology, proposed from semantic views or promoted from Snowflake Cortex Sense (public preview soon). Import is designed to give customers a way to build on definitions they have already created rather than starting from semantic views or retyping their vocabulary. Imported concepts still enter steward review before they become approved, and can then be connected to assets that are in Horizon Catalog. Each proposal records its source. Automation can suggest concepts from patterns in the data, but matching names or lineage are evidence — not proof that two assets mean the same thing. A steward decides what belongs in the model and which definition the business stands behind.

2. Govern the model and its owners

Every concept has a kind, such as term, metric, entity, action, policy, dimension or measure. Only metrics can have a formula, exclusions and formula provenance. The ontology stores a formula as written; it does not execute it. Semantic views remain responsible for governed calculations. Policy concepts capture rules an agent should apply, such as reporting revenue when it is recognized.

Concepts can also have a scope for distinctions within a domain—for example, “Daily Active Users” for two products. When teams use the same name to mean different things, use separate domains instead.

The relationship types are a short, fixed set, including IS_A, HAS_PART, DERIVES, MEASURES, APPLIES_TO, EQUIVALENT_TO and RELATED_TO; custom relationships require a label.

The value is not in giving an agent more ways to say “related.” An agent can generate plausible relationship labels on its own; that is not a governed fact. A typed edge earns its place when a steward approves what it means and the system can validate, audit and use it consistently. If a relationship does not change how a concept is interpreted, governed or retrieved, it probably does not belong in the ontology.

Representations can point to tables, views, columns, semantic-view dimensions, facts or metrics, and connected BI assets. Their type distinguishes, for example, an asset that IMPLEMENTS a concept from a dashboard that is merely RELATED_DASHBOARD to it.

Approval belongs to the domain steward

A definition that anyone can easily change is not a reliable source for an agent. New concepts start as drafts. Changes to approved concepts appear as proposed edits; agents continue to use the approved version until a steward accepts the change. History stays with the concept, and same-domain duplicates can be merged without crossing domain boundaries.

Approval belongs to the domain steward — not necessarily an account administrator. The steward is accountable for the business meaning and close enough to the data to validate it. Account-level privileges may be required to create a domain, but they do not make someone the approver.

A domain is a container with an owner, and domains can nest, such as Finance.Revenue.EMEA. Each concept has exactly one home. If two teams mean the same thing, connect their concepts with EQUIVALENT_TO; if they mean different things, keep separate concepts and owners.

In the preview, domain permissions include:

  • USAGE: navigate the domain path.
  • READ: see approved concepts.
  • SUGGEST: propose drafts and edits.
  • MODIFY: steward actions, including approval and curation.
  • OWNERSHIP: required to drop a domain.

Permissions do not automatically flow to child domains, and a role must be able to navigate the parent path. Drafts are visible only to their author and domain stewards until approval. For roles without access, a concept behaves as if it does not exist.

Here is an illustrative conceptual model — not executable or importable:

 

domain: Finance
concepts:
  - name: Gross Revenue
    kind: metric
    definition: Invoiced amount before refunds and discounts.
    formula: SUM(invoice_amount)
  - name: Net Revenue
    kind: metric
    definition: Recognized revenue after refunds and discounts.
    synonyms: [net sales, recognized revenue]
    formula: SUM(invoice_amount) - SUM(refund_amount) - SUM(discount_amount)
    exclusions: [intercompany invoices, test accounts]
relationships:
  - source: Finance.Gross Revenue
    type: DERIVES
    target: Finance.Net Revenue
representations:
  - concept: Finance.Net Revenue
    semantic_view: FINANCE.REPORTING.REVENUE_SV
    metric: INVOICES.NET_REVENUE

 

Sales can define Sales.Net Revenue as bookings net of discounts at signing. Neither team overwrites the other.

3. Give agents an approved source of meaning

The business-ontology skill can build a Cortex Agent with a business_ontology search tool alongside semantic-view tools. The agent can work across domains and nested subdomains, searching approved concepts the caller is allowed to see rather than being confined to a single team’s domain. Search returns matching concepts’ domain-qualified names, kinds, definitions, formulas and synonyms; results are filtered by the caller’s role and required domain-path access.

The agent’s instructions should give each source a clear job:

  • The ontology determines what a business term means.
  • A semantic view is authoritative for a number it covers. The agent uses its metric and can compare it with the ontology formula as a cross-check.
  • Cortex Sense, when enabled, adds inferred estate context and helps with questions beyond governed semantic-view coverage.

For example:

User: What was net revenue last quarter?

Agent: I found two approved definitions. Finance.Net Revenue is recognized revenue after refunds and discounts. Sales.Net Revenue is bookings net of discounts at signing. Which one do you mean?

User: Finance.

Agent: Using Finance.Net Revenue, computed by INVOICES.NET_REVENUE in FINANCE.REPORTING.REVENUE_SV. This is a governed number. It excludes intercompany invoices and test accounts.

The steward-approved ontology gives the agent canonical, domain-qualified meanings to use when a question is ambiguous. If a term has multiple approved meanings—such as Finance.Net Revenue and Sales.Net Revenue — the agent can present those options and ask which one the user means. When the context is sufficient to choose, it should state which canonical definition it used and why, rather than silently guessing.

Citations then show how the answer was grounded. They should carry provenance and governance signals: the approved definition and any policy that informed the interpretation, plus the source of each number. Label a number governed when it comes from a semantic-view metric, derived when calculated from governed components (show the formula), or exploratory when based on ad hoc SQL (show the query). This lets readers see where the answer came from and how much to trust it.

 

Figure 3
Figure 3. The agent pauses on two domain-qualified definitions, then uses the selected Finance metric.

4. Combine semantic views, Cortex Sense and Business Ontology

These capabilities solve different problems:

  • Semantic views provide governed computation: joins, filters and aggregations. When a semantic view covers a number, it is authoritative for that calculation. The ontology connects concepts to semantic-view assets through representations; one view can implement many concepts, and one concept can be implemented by multiple views.
  • Cortex Sense provides broad discovery. It is designed to infer context from schemas, query patterns, semantic views, dashboards, transformation logic and connected sources. It can surface possible entities, metrics, relationships and conflicts across an estate, including areas no one modeled by hand. A builder can promote a useful finding into the ontology as a draft for steward review.
  • Business Ontology holds the smaller set of accountable, approved definitions: what concepts mean, who owns them, which policies apply and which assets implement them.

The representation between an ontology concept and a semantic-view metric also enables checks for changed formulas, drifting descriptions, or metrics that have disappeared.

 

Figure 4
Figure 4. Cortex Sense contributes inferred context; builders can promote selected concepts for steward approval. Representations connect approved concepts to semantic views. The connections are not required setup steps.

You do not have to set these up in a particular order. Import an existing glossary or ontology if your organization already has one. Bootstrap from semantic views if you have them, or start with Cortex Sense and promote what matters if you do not. You can also hand-author the few definitions that cause the most confusion.

Getting started with Business Ontology

Business Ontology and Cortex Sense are coming to public preview soon. Once you have them enabled in your account:

  1. Open the business-ontology skill in Cortex Code. Create a domain and draft a few metrics, or review concepts proposed from your semantic views.
  2. Browse the result in the Business Ontology page in Snowsight.
  3. Ask the skill to build an agent on the ontology and your semantic views. Compare its answer to your existing agent’s answer to the same ambiguous question.

If you do not have a semantic layer yet, you may be able to bootstrap with Cortex Sense, review what it discovers, and promote the concepts that deserve an accountable definition. If you already govern business definitions elsewhere, import them and connect them to your Snowflake assets. Human new hires eventually learn what net revenue means. With approved meaning and governed computation, agents can start with that context on day one.

5. Where this goes next: an enterprise-grade context layer

Today's agents answer questions. Tomorrow's will also take actions, feed BI and applications, and hand work to other agents. Every one of them will need the same answer to two questions: what does this mean, and can I trust it? We think that answer belongs in one governed place, next to the data it describes, not scattered across prompts, wikis and tool configurations.

That's the direction for Snowflake Horizon Context: a context layer where approved meaning and governed computation live together. Cortex Sense is designed to infer as much as it can, automatically. Business Ontology can hold the definitions that need an owner and an audit trail. Semantic views compute the numbers. For that to be enterprise-grade, context has to meet the same bar as the data itself:

  • Governed: Access to meaning follows the same role-based controls as access to data. An agent sees only the definitions its role is entitled to.
  • Accountable: Every approved definition has an owner, a history and a record of who approved each change.
  • Connected: Definitions point at the assets that implement them, and changes on either side surface for review instead of drifting silently.
  • Continuously improving: Discovery, corrections and conflicts should flow into review as part of everyday use, while people stay in charge of what becomes official.

Further reading

Forward-looking statements: This article may contain forward-looking statements, including about future product offerings, and is not a commitment to deliver any product offerings. Actual results and offerings may differ. See our latest 10-Q for more information.

Share this post

Subscribe to our blog newsletter

Get the best, coolest and latest delivered to your inbox each week

Where Data Does More

Start for free
Watch a demo