Snowflake Business Ontology: Grounding AI Agents in Verified Business Definitions

Why the Same Metric Yields Different Answers for AI Agents

Enterprise operational analysis often involves a single metric with multiple calculation rules. Net Revenue, for example, may be defined by Finance as recognized revenue minus refunds and discounts, while Sales defines it as contracted amount minus discounts. Both are called Net Revenue, but their scope, basis, and use cases differ.

Human analysts resolve this by confirming the statistical caliber before choosing a data model. AI agents, however, rely on database schemas, field descriptions, historical SQL, and BI reports. When multiple systems share the same metric name, an agent may write correct SQL yet pick the wrong business definition, producing answers that do not match the actual need.

Semantic layers have unified metric formulas, dimensions, and table relationships, allowing different applications to reuse the same calculation logic. Yet large enterprises often run several data models simultaneously, with Finance, Sales, and Marketing each maintaining their own business definitions. A semantic layer ensures a metric is computed by its rule, but cannot decide which definition applies to the current question.

Snowflake's Business Ontology adds a governed business-definition management layer on top of the semantic layer. Finance can maintain Finance.Net Revenue and Sales can keep Sales.Net Revenue, each with its own domain, calculation rules, and owner, without forcing a merge.

When an agent receives "What was last quarter's net revenue?" it first retrieves relevant business definitions. If the user does not specify a caliber, the agent can infer from business context or ask whether Finance or Sales revenue is needed. The guesswork previously required of the model now has an explicit basis.

How Snowflake Helps Agents Find Trusted Business Definitions

Business knowledge is scattered: databases store tables and fields, BI systems hold metric formulas, transformation jobs embed calculation logic, while the rules governing metric usage often live only in documents and tribal knowledge. Snowflake places Business Ontology inside Horizon Context to connect these fragmented contexts.

Horizon Context, built on Horizon Catalog, integrates metadata, usage records, and lineage of enterprise data assets, and uses connectors to pull context from Tableau, Power BI, dbt, and other systems. This enables the platform to discover relationships among data assets, forming a foundation for business definitions.

Snowflake splits discovery, confirmation, and calculation across three components: Cortex Sense, Business Ontology, and Semantic Views.

Cortex Sense analyzes table structures, historical SQL, reports, and transformation logic to infer which fields belong to the same business concept and how metrics relate. For instance, if multiple reports use similar revenue calculations, the system proposes candidate metric definitions. These inferences are only references; similar field names do not guarantee identical business meaning, and repeated use does not prove formal endorsement.

Business Ontology is where candidates are reviewed, approved, and maintained by the responsible business stewards. Approved concepts store their domain, business meaning, calculation rules, and linked data assets, becoming the primary source agents can trust when retrieving business knowledge.

Semantic Views continue to handle the actual metric computation. An agent first uses the ontology to identify the correct business metric, then calls the corresponding semantic view for the result, keeping definition management separate from data calculation.

This division lets enterprises leverage existing assets: teams with a semantic layer can extract candidate concepts; those with a business dictionary can import definitions; teams lacking a knowledge base can use Cortex Sense to discover initial relationships. No existing data model must be discarded, but a continuous review and maintenance process for critical definitions is required.

Connecting Data and Managing Definition Changes in the Ontology

Business Ontology is not merely a dictionary; it uses a graph structure to explicitly express relationships among concepts and between concepts and actual data assets.

The graph consists of concept nodes, typed relationships, and data-asset mappings. Customers, orders, revenue, business metrics, and policies become concept nodes, each recording its type, definition, and domain. Net Revenue can be a Metric concept linked to its formula and exclusion conditions; Revenue Recognition Policy can be a Policy concept stating the rules the metric must follow.

Concepts connect via typed relationships such as DERIVES, MEASURES, APPLIES_TO, and EQUIVALENT_TO, describing metric derivation, measured objects, policy scope, and concept equivalence. Agents can therefore not only read a textual description of Net Revenue but also traverse its links to other metrics, business objects, and policy rules. Truly equivalent concepts can be linked as equivalent; same-name metrics with different calibers remain distinct.

Business concepts must connect to physical data to participate in analysis. Snowflake uses Representation mappings to link approved concepts to underlying tables, views, fields, or Semantic View metrics. For Net Revenue, the ontology records the formal business meaning and points to the semantic view that implements the calculation logic. Agents retrieve the definition, then follow the mapping to the computation entry point. Definitions and calculation models can be maintained independently yet stay connected.

Because business knowledge becomes the agent's decision basis, control over changes is critical. If Net Revenue's calculation rule changes without Finance approval, the agent might unknowingly use the wrong caliber. Snowflake introduces Domain Stewards: new concepts are created as drafts and become official only after review; modifications to approved concepts do not overwrite the current version until the new version passes review. History and approval records are preserved for traceability.

Permissions are enforced at the business-domain level with USAGE, READ, SUGGEST, MODIFY, and OWNERSHIP roles, separating concept viewing, suggestion, formal maintenance, and ownership. Business users manage meaning and approval; data engineers handle calculation implementation; agents operate within granted scopes. Viewing a business definition does not automatically grant query access to underlying data, which remains governed by Snowflake's existing data-access policies.

How the Analysis Workflow Changes with the Ontology

Once business definitions, calculation models, and permission rules are linked, the agent's approach to operational analysis tasks shifts.

Snowflake provides a Business Ontology Skill that configures a business_ontology search tool for Cortex Agent, combined with Semantic Views for data analysis. The agent can search approved concepts accessible to the caller, retrieve their business definitions, domains, formulas, and related information, then select the appropriate computation entry point.

Using the Net Revenue example: when a user asks for last quarter's net revenue, the agent first queries the ontology for relevant concepts. Finding both Finance and Sales definitions, it can confirm the applicable caliber based on the task context. After the user chooses Finance Net Revenue, the agent invokes the corresponding Semantic View to compute the result, and returns the answer along with the indicator definition and data source used.

This adds a business-meaning validation step to data analysis. Previously, an agent might directly search tables, write SQL, and return results. With the ontology, it first determines the business domain, selects an approved definition, then executes the calculation. For well-governed metrics with clear calibers, results become more traceable to specific calculation rules and data assets.

The ontology does not guarantee error-free agents. Enterprises must still ensure formal definitions stay consistent with underlying calculation logic, handle metric changes promptly, and verify that agents correctly select and invoke tools. Snowflake has so far disclosed technical architecture and preview capabilities, but lacks extensive public production data proving concrete improvements in query accuracy, business conflict rates, or governance cost reduction. Business Ontology remains in private preview, with a public preview planned.

Early adopters such as dentsu and its subsidiary Merkle are exploring Business Ontology to manage cross-system business definitions, providing real-world direction, though long-term effectiveness in complex enterprise environments awaits further production validation.

As agents enter operational analysis and business processes, enterprise requirements for data platforms evolve. Beyond traditional governance questions — where data comes from, who can access it, whether calculations are correct — a new fundamental question arises: what do these data actually represent in business terms?

By linking business definitions, owners, approval records, and data assets, Snowflake gives the previously experience-dependent business calibers a systematic management approach. It cannot eliminate inherent business differences across departments, but it makes those differences explicitly identifiable, reviewable, and auditable.

When agents participate in enterprise decisions, reliable data computation is only the foundation. Ensuring every analysis has a clear, trustworthy business basis is the capability enterprises truly need to close.