An approved business definition needs a test that shows an agent actually used it. Snowflake announced Business Ontology on November 3, with public preview described as coming soon. For enterprise data teams evaluating it, the governance question is how to connect a definition's domain, approval and version to the answer an agent produces, particularly after that definition changes.
The product announcement describes a place to define and approve business concepts and connect them to the data and calculations that implement them. A shared meaning can reduce conflicting interpretations, but teams still need to establish which meaning applied to a particular task. Maetra's analysis below proposes a small acceptance test for that dependency. It is not a claim that Maetra has tested the preview or that every proposed evidence field is a built-in Snowflake feature.
The announcement separates meaning from calculation
Snowflake describes Business Ontology as part of Horizon Context within Horizon Catalog. It distinguishes approved business meaning from the calculations in Semantic Views and the inferred context supplied by Cortex Sense. Its examples allow intentional domain or brand differences, with owners approving the relevant definitions. These are vendor descriptions of the intended architecture, not independent accuracy measurements.
Snowflake's broader release places the ontology alongside Cortex AI Gateway controls. Those announcements span different availability stages. Business Ontology's planned public preview should not be confused with general availability of other gateway capabilities.
Constellation Research's coverage independently reports the announcement and emphasizes the continuing work of ownership, mappings and change tests. It does not establish that the product guarantees correct answers. Buyers should confirm their actual access and supported behavior before making a production plan dependent on the announced capability.
A revenue question can hide several authorized meanings
Consider a hypothetical agent asked to explain quarterly net revenue for a regional finance team. Finance has approved a definition that includes a particular treatment of refunds. A sales analysis uses a different, separately approved concept. Both definitions can be legitimate in their own domains.
The task is incomplete if it says only “use approved revenue.” It needs the reporting period, organizational domain, relevant definition and intended treatment of ambiguity. An agent that substitutes the sales concept could produce a plausible answer while failing the finance task.
The same problem can appear after a change. A definition may be approved today for future reporting while yesterday's report must remain interpretable under its original basis. Updating a shared definition without preserving the answer's context can make a later comparison difficult. That is why Maetra recommends retaining a reference to the definition used, with an effective date or version where the implementation supports it.
This recommendation concerns the business meaning attached to a task. It does not imply that ontology approval authorizes every downstream operation. Sending a report externally or changing a financial record can require separate access and policy decisions.
Run three acceptance cases before trusting a shared term
Use a small, known dataset and expected results agreed by the business owner. Keep each test bounded so a reviewer can distinguish meaning selection from calculation and delivery.
First, test the intended domain. Ask the finance question using a definition the owner has approved for that context. Preserve the selected concept, relevant data references, calculation reference and result. If the agent cannot reveal which definition it used, record that as an evidence gap.
Second, introduce an intentional conflict. Give the test access to two legitimate definitions with different scopes. Ask an ambiguous question. Agree in advance whether the expected behavior is clarification, a clearly labeled choice or a refusal to produce a definitive figure. Evaluate against that expectation rather than rewarding a confident answer.
Third, change the definition and repeat the task. In a safe test configuration, update the approved meaning or its mapping. Check whether a new answer uses the intended revision and whether the previous answer can still be explained. Where version references are unavailable, preserve a controlled snapshot and record that limitation.
These are suggested evaluation cases, not promises about the preview's behavior. A passing result demonstrates the tested configuration on the selected data. It does not justify a broad claim about every business domain, agent or future update.
Put the dependency in the task record
The data owner should be able to identify the definition and its scope. The engineering owner should be able to identify the path from that definition to the calculation. The person accepting the agent's output should be able to see whether the result meets the task's agreed conditions.
Keep those references with the task and its observable outcome. If a mapping changes, flag the affected tests for review instead of assuming that approval of the wording covers the implementation. A correct calculation of the wrong concept is still an unsuitable answer.
Maetra's task-alignment analysis explains the distinction between satisfying an assigned objective and obtaining authorization for an action. Task Guard covers alignment, scope changes and effect verification; Audit supports inspectable history. For one analytics workflow, use the Task Guard documentation to define the expected meaning and outcome before evaluating an agent's answer.
Sources
- Snowflake, Business Ontology, November 3, 2026. Primary product announcement; public preview coming soon.
- Snowflake, Expedition announcement, November 3, 2026. Primary source for the broader release and availability qualifications.
- Constellation Research, Snowflake context and governance coverage, November 3, 2026. Independent reporting and analysis of the announcement.