The Challenge: Business Questions Without Shared Meaning
Picture a regional sales director at a mid-size pharmaceutical distributor. She opens an AI assistant connected to the company’s Databricks lakehouse and types one line:
“Which products are underperforming in the Western region?”
Ten seconds later, she has an answer: a table, a chart, a confident paragraph of commentary. It looks finished. It looks correct. Yet nobody in that exchange agreed on what half the words mean:
- “Underperforming”: compared to what? Last quarter, last year, or the annual forecast?
- “Products”: SKUs, brand families, or therapeutic categories?
- “Region”: sales territory, distribution area, or the finance team’s reporting geography? These don’t line up.
- Which table? The nightly ERP pipeline, or the spreadsheet extract someone has patched by hand since Q2?
None of this was in the question, and all of it changes the answer. Faced with the gap, an AI system will often skip the clarifying question, pick an interpretation, and state it with total confidence.
Databricks is targeting this gap with Genie Ontology, announced at its June 2026 Data + AI Summit and currently in Public Preview.
The Limits of Direct Data Access
The instinct is always the same: connect the model to the warehouse, let it write SQL, done. It is reasonable, and it is also where many enterprise AI projects quietly stall.
A raw table stores values, not meaning. A column called region_id doesn’t know that Finance and Sales draw regional boundaries differently. A column called status doesn’t know that “active” meant “logged in this week” to the engineer who built the table in 2022, and now means “has an open subscription” to the product team. That meaning lives elsewhere: a Confluence page, a Slack thread from eighteen months ago, the head of the one analyst who has been here since the acquisition.
Two earlier approaches tried to close the gap and fell short:
- Text-to-SQL read schemas and guessed joins and definitions from structure alone. It handled easy questions and fell apart on the questions a real business asks, so teams rarely trusted it beyond a demo.
- Retrieval-augmented generation (RAG) pulled in surrounding documentation, but it is a similarity engine: it finds text that looks like your question. It can’t tell which of five similar definitions your company trusts, or how “customer,” “account,” and “invoice” relate in your business. It retrieves; it doesn’t reason about authority.
Introducing Genie Ontology: A Business Map for AI Agents
Start with the word itself. An ontology is simply a map of the important things in a business and how they connect. It is not a data dictionary or a glossary of column names. It has three building blocks:
- Entities: the things a business works with, such as a Distributor, a Product, a Region.
- Relationships: how entities connect, such as a distributor sells products into regions.
- Concepts: the meaning built on top, such as Sales or Active Customer.
Think of a family tree: it connects people rather than just listing their names. Figure 1 shows the three building blocks.
Genie Ontology is Databricks’ version of this map. It is a unified context layer that gives Databricks’ Genie AI experiences (Genie One and Genie Code) a business-aware view of your organization, so context curated once applies across both.
It sits between the AI agent and your raw tables. Instead of reading columns and inferring meaning on the fly, the agent first asks the ontology, “What does this term mean, and which source should I trust?” and only then computes an answer. Figure 2 contrasts the two approaches.
Nobody has to hand-build this map from scratch. According to Databricks, it is assembled automatically and kept current from assets an organization already has: tables, dashboards, saved queries, pipelines, and a growing list of connected business apps.
Sources of Context: Modeled and Inferred
The ontology draws on two kinds of context, and the difference matters.
Modeled (Unity Catalog semantics) | Inferred context | |
Who creates it | People deliberately model, govern, and certify it | Genie extracts it automatically from existing assets and how they are used |
Built from | Metric views, domains, Pages, certification and deprecation flags | Metric views, dashboards, SQL queries, and Genie Agents (formerly Genie Spaces) in active use |
Trade-off | Highly trusted, but limited to what someone took the time to define | Reaches what nobody wrote down, but must be ranked for trust |
The modeled building blocks:
- Metric views: governed, reusable definitions of business metrics.
- Domains: business-aligned groupings of related data assets.
- Pages: governed write-ups that define a business concept or term as an authoritative reference, with related assets linked.
- Certification and deprecation flags: mark assets as trusted or outdated.
Metric views appear in both columns: people author them deliberately, and Genie also learns from them. Databricks gives three examples of inferred snippets: a metric definition (“an active user is a distinct user, deduplicated across platforms”), an authoritative-source pointer (“revenue questions should be answered using the curated Finance Genie Agent”), and a business rule (“a qualified lead only counts once a demo is booked”).
For our distributor, the modeled layer might hold a certified metric view that defines “Net Sales” once, with an agreed formula and allowed dimensions (product, route, region). The inferred layer might notice that regional managers keep running a SQL query that filters out returns before calling something “sales,” and treat that pattern as a signal worth surfacing, even though nobody ever certified it. A traditional metadata catalog usually can’t produce that second kind of context, because nobody sat down to write it. Figure 3 shows how the two combine.
The Role of Unity Catalog: Foundation and Gatekeeper
“Genie Ontology” and “Unity Catalog” are easy to conflate, but they are not the same thing. Unity Catalog is the governance and semantics foundation; Genie Ontology is built on top of it.
- The modeled half of the ontology lives in Unity Catalog. Metric views, domains, and Pages are Unity Catalog features, stored, governed, and permissioned like any other governed asset. Genie Ontology treats these definitions, especially once certified, as some of its highest-trust inputs.
- Access control is not bolted on afterward. Every snippet the ontology holds, modeled or inferred, is gated by the same Unity Catalog permissions that govern the underlying assets. If a regional manager can’t see finance’s cost-of-goods table, the ontology won’t use a definition extracted from it when answering that manager, however relevant it looks.
Resolving Conflicting Definitions with OntoRank
Suppose three things in the organization all claim to define “Sales”:
- Definition A: buried in a dashboard built two years ago. It filters differently than everyone assumes, and nobody remembers why.
- Definition B: an analyst’s ad-hoc SQL query. Correct for the report it was written for, reused informally ever since.
- Definition C: a certified metric view in Unity Catalog, reviewed by finance and tied to the general ledger.
All three are valid candidates for “what were our sales in the Western region last month?” A plain retrieval system would grab whichever wording most resembles the question, which says nothing about which one the company trusts.
Databricks’ answer is OntoRank, which it describes as inspired by Google’s PageRank. PageRank ranked web pages by authority rather than keyword matching; OntoRank ranks business definitions instead. Each snippet receives an authority score. Databricks’ OntoRank explainer lists five signals:
- Source authority: where the definition came from.
- Author relevance: the standing of the person or team behind it.
- Usage frequency: how much people actually rely on it.
- Asset certification: whether the asset is certified.
- Freshness: how recent it is.
The core Genie Ontology documentation summarizes the same idea more briefly, as source, usage, and freshness. Teams don’t tune the weights directly; they influence ranking by certifying trusted assets and retiring stale ones. When definitions conflict, Genie ranks them by these scores and uses only the sources the person asking is permitted to see (Figure 4).
Here, Definition C should win most of the time: it is governed, actively used, and tied to trusted, current data. The old dashboard should lose even if its wording matches the question better.
Key idea: matching words is easy; matching trust is the hard problem, and it is the one OntoRank is built to solve.
Genie Ontology and Semantic Layers: Extending, Not Replacing
Teams that have already built metric views often ask whether this makes them redundant. It doesn’t. Metric views are a semantic layer, and a good one: they let you define “Net Sales” once so every dashboard shows the same number. Genie Ontology treats those certified definitions as some of its highest-trust inputs.
The catch is that a metric view only knows what someone took the time to define. Most business knowledge never gets that treatment: nobody writes a certified metric view for “this key was never documented” or “GMV and net revenue are close but not the same.” That knowledge is real, but it is scattered across queries, Slack threads, and people’s memory.
Metric views (semantic layer) | Genie Ontology (context layer) | |
Knows about | Metrics someone formally defined and certified | Certified definitions plus context inferred from queries, dashboards, and usage |
Without a certified definition | Nothing to say | Looks at every plausible source, even unofficial ones, and ranks them |
Role | The strongest foundation you can build | Extends that foundation to everything else |
Worked Example: Resolving One Question in Five Steps
Back to the director’s question: “Which products are underperforming in the Western region?” With Genie Ontology in the loop, roughly this happens before any SQL runs:
- Apply permissions. The candidate context is narrowed to what the director may see. Her role covers the regional sales domain but not finance’s margin data, so any definition sourced from margin-restricted assets is dropped, even if it looks relevant.
- Resolve “products.” A domain groups product-related tables and metric views. The ontology resolves “products” to SKU-level records, the certified grain of the Sales domain.
- Resolve “Western region.” Inferred context shows that most recent, high-usage queries join through the Route → Area → Region chain (operational geography), not finance’s separate reporting-region mapping. Usage and recency make that pattern outrank the older, less-used alternative.
- Resolve “underperforming.” No certified metric view defines it, so the ontology falls back to inferred snippets. A widely used Genie Agent built by the sales-ops team defines it as “below 80% of the same period last year,” and that snippet ranks highest on usage and source authority.
- Answer, with citations. Genie returns the products below the resolved threshold and shows which sources defined each term, so the answer can be checked rather than just trusted.
The last step matters most. An answer with visible sourcing is one someone can push back on. Without it, it is just a number wearing a confident tone.
Genie Ontology in the Databricks Ecosystem
Genie Ontology isn’t a standalone product you install. It is infrastructure that other Genie surfaces plug into:
- Genie One is the AI assistant for business users and the primary business-facing surface for the ontology. Per Databricks’ documentation, it first checks existing Genie Agents for a match, and only then searches dashboards, queries, and metric views directly. A well-built Genie Agent effectively jumps the queue.
- Genie Code applies the same context to coding tasks, so a developer writing a query gets the same business definitions a business user would get in chat.
- Genie Agents are reusable, purpose-built agents teams can build and share. They relate to the ontology in two ways: Genie learns from existing Genie Agents when assembling inferred context, and Databricks’ launch announcement says Genie Agents are themselves powered by Genie Ontology. However, the current documentation names only Genie One and Genie Code as the surfaces that search the shared ontology, so check the documentation for your workspace before relying on how an agent’s own answers use it.
- Metric views and AI/BI dashboards are inputs rather than surfaces: certified metric views are among the highest-authority context, and dashboards are one of the assets Genie infers context from.
The pattern to remember: metric views, domains, and Pages are things you build; inferred context is something Genie extracts; and Genie Ontology merges both and hands the result to every Genie surface, so context curated once doesn’t have to be re-taught to each tool.
Limitations and Considerations
The gap between “the agent has more context” and “the agent is right” is where trust gets lost, so the limits deserve equal attention.
- It doesn’t fix bad data. If the underlying “Net Sales” table has a bug, a perfectly ranked, governed definition will confidently return a wrong number. Context layers resolve meaning, not correctness.
- It can’t learn rules that live only in someone’s head. If a rule never appeared in a query, dashboard, or certified metric, and exists only in what the finance controller remembers from a meeting three years ago, the ontology has no way to learn it.
- It doesn’t guarantee correct answers or replace human validation. Better context makes a wrong guess less likely; it doesn’t make the agent infallible. Ranking the most trustworthy definition is a different problem from verifying a specific computed answer, so spot-check anything that drives a real decision, especially while your coverage is still being built.
- It doesn’t replace data governance. It relies on governance (Unity Catalog permissions, certified metric views, domain structure) as its best input. Weak governance upstream means weaker context downstream.
Conclusion
- The bottleneck was business context, not the model. A table tells you what the numbers are, not what your company means by them.
- Genie Ontology merges modeled context (Unity Catalog) with inferred context (from existing assets and usage) into one layer for Genie One and Genie Code.
- OntoRank ranks definitions by trust signals, not wording similarity, and only after Unity Catalog permissions are applied.
- Metric views are the best foundation you can give it. The ontology extends them; it doesn’t replace them.
- Context solves understanding, not arithmetic. Verify “the agent has context” and “the agent is correct” separately.
Genie Ontology is a genuine, useful advance, and worth testing while it is in Public Preview if you build on Databricks. But it solves one specific problem: getting the AI to understand what you mean. It does not solve the older problem of making sure the AI’s math is right. Teams that treat those as two separate kinds of trust will get real value from it, rather than a more confident-sounding version of the same guessing problem.