In a recent project, I built the business context layer for Genie. At the time, I struggled to find practical guidance on how the different components fit together.
We were building a sales model, and I also had to develop its semantic layer. While testing Genie, I noticed it answered many questions incorrectly because it lacked enough business context to respond accurately.
That clarified the task for me. We needed to explain what the data meant and give Genie definitions it could use. A question about “sales” can sound simple, but the answer depends on what we count as a “sale”.
This article focuses on how Genie Ontology brings that context together: how it discovers knowledge, how we define and govern it, and how agents use it. The companion article walks through the configuration using a simplified sales model.
The question behind both is simple: an AI agent may know SQL, but does it know what our company means by “sales”?
First, which Genie are we talking about?
Before getting into the ontology, it helps to separate the different Genie experiences. Each one supports a different part of working with data:
These experiences use Genie Ontology as a shared business context layer. Each one uses that context for a different job. When we define metrics, document concepts, and connect assets, the work can benefit the broader Genie family instead of only one interface.
Feature status as of October 12, 2026: Genie Ontology is in Public Preview; Domains became generally available (GA) on October 8th. Pages and Genie App Builder are in Beta. ZeroOps was initially announced in private preview. Availability may vary by cloud, region, and workspace configuration.
What is an ontology?
A practical way to think about an ontology is to start with a problem many organizations had long before AI: different teams using the same word in different ways.
For example, Sales might call someone an "active customer" if they bought something in the last 90 days. Finance might use the same term for a customer who is still being billed. Operations might use it for someone with an ongoing service. None of these definitions has to be wrong. The problem starts when people use the same term as if it always means the same thing.
Traditionally, teams resolved this with meetings, documents, glossaries, and agreements. People had to decide which concepts mattered, how each department defined them, which differences were intentional, and which definition applied to each kind of question.
In that sense, an ontology makes those agreements explicit. It organizes concepts, relationships, owners, and conditions of use so that people and systems can use the information with a shared understanding.
The representation can vary. What matters is making context visible when it was previously spread across different places.
Why AI needs business context
The missing context I encountered made me realize that defining business meaning was part of the work.
For example, one sales definition may include tax while another excludes it. Both can produce valid SQL and different totals. The agent needs to know which definition applies.
Adding instructions can help, but we also need to decide where each rule belongs and who maintains it. A long prompt can mix current rules with outdated information and become difficult to review.
That is the focus of context engineering: deciding what information enters the model's context, how it is selected and prioritized, and how it is maintained over time.
For an organization, this is about more than giving AI access to data or a prompt. We need to decide which definitions are valid, which sources have authority, which permissions apply, and how to handle conflicting rules from different teams.
Genie Ontology helps apply this business context within Databricks. It gives AI experiences a clearer, governed basis for selecting knowledge. Governance still requires ongoing work. Definitions, assets, and permissions need maintenance, and a convincing answer isn't automatically correct.
How Genie Ontology is organized
Databricks presents Genie Ontology as a context layer shared across the Genie family. This diagram gives us a starting point for understanding its structure:
The layer combines two types of context: inferred context, extracted from existing assets and how they're used, and defined and governed context, where the organization makes its business definitions explicit. The two work together.
To explore them, we will follow three connected tasks: discovering knowledge, defining and governing it, and using it to answer questions. This is a way to organize the explanation, not three separate product layers.
1. Discovering knowledge
Much of our business knowledge already appears in everyday work, such as the rules behind a dashboard metric. Even when it is not formally documented, teams rely on it to understand their data.
Genie Ontology extracts and maintains pieces of this knowledge, called snippets. I find it useful to separate two questions: how Genie gets knowledge from existing work, and how it selects the knowledge needed for a specific question.
Getting knowledge from existing work
Genie gets context from tables, SQL queries, dashboards, and pipelines, as well as other assets such as metric views, Genie Agents, notebooks, and documentation. Connected applications can also contribute knowledge to Genie Ontology. Depending on the available sources and access permissions, inferred context can extend beyond workspace assets.
It helps to distinguish the source asset from the knowledge inside it. A query is an asset; the metric definition expressed through its calculations and filters is business knowledge. A notebook can contain both code and explanations of the decisions behind that code.
Not every line in a source becomes a snippet. The useful parts help Genie understand a question, such as a business definition or rule.
What knowledge can it recover?
Snippets can capture metric definitions, business rules, and reference sources, along with relationships between concepts, metrics, tables, and teams.
Joins matter because they show how data is connected in an analysis. Still, seeing a join between two tables doesn't establish its cardinality or prove it works in every context. It may depend on filters, time conditions, or a specific level of detail.
Choosing context for a question
When Genie receives a question, it looks for relevant knowledge snippets in the ontology. That selection combines three considerations: which information relates to the question, which sources the user can access, and which sources have greater authority.
Relevance helps identify related definitions, rules, and references. Permissions limit which snippets Genie can use based on access to their source assets. Among relevant, accessible sources, OntoRank helps prioritize knowledge when multiple alternatives or conflicting definitions exist.
OntoRank: how knowledge is prioritized
OntoRank considers more than word matching. It evaluates relevance and source authority within the organization.
It also assesses a source through its connections to other assets. Links to certified or widely used assets can indicate a source's authority within the organization.
Several signals contribute to this assessment:
These signals help prioritize a source. They do not prove that a definition is correct for every question. A popular calculation, for example, still needs its meaning reviewed.
Databricks does not publish the full OntoRank formula or its weights. These signals help us understand the factors involved, but they do not let us predict exactly which source will be selected in every case.
2. Defining and governing knowledge
Databricks also gives us tools to shape how agents interpret our data. We can make explicit what a metric means, which business area an asset belongs to, and which definitions the organization accepts as valid.
This is where metric views, domains and subdomains, Pages, and certifications in Unity Catalog semantics come in. Together with table and column metadata, they let us add context deliberately and assign clear responsibility for maintaining it.
For me, this part is essential. If a definition is critical to the business, we should define and govern it directly. Inferred context can expand the available knowledge, while these tools let us establish and maintain the definitions we want to share. That guides the agent, but we still need to evaluate its answers.
Reusable calculations and business explanations
Building the semantic layer was part of my task, and metric views caught my attention. The advantage I saw was reusing a metric without creating a separate aggregated view for every way to analyze it.
A SQL view that returns sales totals by region has that grouping built into its query. With a metric view, we define the measure separately from the fields used to group and filter it. Consumers can use the same measure at different levels of detail, as long as the required fields are available.
This does not mean all use cases neezd the same definition. When two questions use different business rules, you still need to model that difference explicitly.
Pages helped me with another part of the problem. In the project, I used them to explain business knowledge that was already embedded in the code, including definitions beyond metrics. The logic existed, but understanding it often meant reading the implementation.
For a metric, the Page can explain its meaning and conditions of use, while the metric view defines the calculation. If the rule changes, you need to review both. A formula alone may not explain why a definition exists or which questions it should answer.
Organization and authority
Domains help people find related assets by business area. Governed tags keep classifications consistent, while certification adds a trust signal. None of these replaces checking the underlying data and calculations.
A Certified status indicates that an asset meets the organization's standards; assigning it does not run quality checks. Similarly, metadata describes expected behavior but does not enforce it. Databricks primary and foreign keys are informational, so declaring them does not automatically check uniqueness or referential integrity.
We also need to assign owners and keep definitions current. Several definitions may be valid across the organization. The goal is to clarify their scope, rather than force every team to use one interpretation.
3. Using and evaluating knowledge
How Genie works with this context
Databricks describes Genie as a compound AI system: several components working together to interpret a question and build an answer. Within an agent system, the agent harness, also called scaffolding, is the software that coordinates context, tools, and task execution.
To respond, Genie combines the business knowledge provided by Genie Ontology with its own context. Depending on the experience, that may include Unity Catalog metadata, specific configuration, or conversation history.
In Genie Agents, for example, Agent mode can involve several iterations. Genie prepares a plan, explores hypotheses through queries, and uses the results to decide what to do next. It then presents a report with findings, citations, and visualizations.
This division is useful: Genie Ontology provides business context, OntoRank helps prioritize it, and the harness coordinates its use alongside tools throughout the task. Permissions limit which information can be used. Citations help us review an answer's sources, though they don't show every candidate the system considered or rejected.
Context specific to each Genie Agent
Alongside shared context, each Genie Agent may need information specific to the questions it will receive. We can configure datasets, instructions, and SQL examples, and use its knowledge store to add relevant descriptions, relationships, and expressions.
This configuration is maintained inside the agent. Improving a description there does not automatically update Unity Catalog metadata. However, the definitions, examples, and instructions we add can also provide knowledge for Genie Ontology to extract. So the work can help beyond that agent, even though it does not update the original metadata.
That is why it helps to decide where each definition belongs. A rule needed by several consumers should live in a shared place. Agent instructions can guide how to interpret questions, ask for clarification, and present answers.
Permissions also limit the available context
Permissions determine more than which data we can query. They also affect the knowledge Genie can use to interpret a question. If two users have access to different sources, the context available for their answers may differ.
Respecting permissions and personalizing ranking are different things. Limiting context to sources a user can access does not mean definitions are automatically ranked according to that user's team or role. If two teams need different interpretations, we need to make their scope clear and evaluate the answers.
Reusing context through other tools
Reuse can happen at different levels. A SQL query or a compatible BI tool can consume a metric view's calculation. An external agent can use Genie One through MCP to ask questions, with Genie Ontology interpreting them and respecting the caller's permissions.
These are different forms of consumption. Reusing a metric does not mean having direct access to all ontology snippets or its ranking mechanism. When choosing an integration, we need to distinguish whether we want a shared calculation, an answer from Genie, or access to a specific source.
Evaluating answers
The incorrect answers I saw in the project made evaluation part of the work. Making context available does not tell us whether Genie uses it correctly.
We need to check both the result and the business definition behind it, using agreed answers and reviewing the sources and generated queries. When an answer fails, we need to understand whether the problem comes from the definition, the available context, or how it was used.
These checks need to continue as definitions and configurations change. The practical walkthrough shows how to apply them to the sales example.
Context needs to be built and maintained
For me, the key question is whether another person, or an agent, can use a definition correctly without relying on an explanation that exists only in someone's head. Someone needs to keep that definition aligned with the calculation and review it when the business changes.
That is the work behind the ontology. Discovering existing knowledge helps, but we still need to decide what it means, who maintains it, and how to check that Genie uses it correctly.
The companion article, Building Business Context for Genie: A Practical Walkthrough in Databricks, takes these ideas into the interface, from table metadata to a reusable metric, a Domain, a Page, and certification.
TL;DR
This article grew out of a project where missing business context led to incorrect Genie answers.
Discover knowledge: Genie Ontology extracts knowledge from supported assets. OntoRank helps prioritize relevant, authoritative sources within the user's permissions.
Define and govern it: metadata describes data, metric views define calculations, Pages explain business concepts, and Domains organize assets. Certification adds an authority signal.
Check how it is used: agents combine shared and local context. Evaluate calculations and interpretations, review sources, and repeat checks when definitions change.
The important work is agreeing on what a definition means, when it applies, and who keeps it current.
