Databricks announced Genie Ontology at the Data + AI Summit in June 2026, and the reaction was unanimous excitement. A living context graph that learns your business automatically and grounds every Genie answer in it. You won’t need any manual curation, or buy any separate semantic tool, and it respects your existing permissions and access rights. Wow, right?
Now the part that some people missed: you can't use it yet. Databricks Genie Ontology was announced, demoed on stage, and described in a blog post. That’s it. The gated public preview means that Databricks only turned it on for a couple of companies for testing. General access hasn’t even been announced yet. We think it’s still coming in 2026.
So this post isn't a hands-on tutorial. We’re doing a get-ready-now guide, because this gap between announcement and access is the most useful window of time you're going to get.
Here's what your homework looks like:
First, a refresher on what an ontology is
We wrote about AI ontologies last year.
Short version: an ontology is a formal description of the things in your business, how they relate, and the rules they obey.
For example in a Healthcare institution, the things could be: Patient, Bed, Diagnosis. Actions: AdmitPatient, BookOperatingRoom. And the relations between them, definitions of the rules they obey as per the institution’s policies and processes. These keep the whole thing logically consistent.
In reality, data and AI ontologies are often implemented as knowledge graphs.
Traditionally you'd write that in OWL and RDF, store it in Neo4j or Neptune, and let agents query it with SPARQL or Cypher. That's how we’ve done it on real projects.
And the best part: the knowledge graph can be continuously updated, so the info your automations are built on is always fresh.
Worth saying out loud: a lot of what vendors now call a "proprietary ontology" is a semantic data model with better branding. That's not an insult. Semantic data models are incredibly cool and powerful.
Knowledge graph vs context graph—not the same thing?
These two terms get used interchangeably nowadays. Structurally they look alike. Nodes, edges, relationships. The big difference is when the graph gets assembled and what question it answers.
A knowledge graph answers: what's generally true about this domain? Built once, updated over time, valid always as the big picture. Think long-term memory.
A context graph answers: what does this specific task need, right now? Assembled on demand, discarded after that one decision, containing only the connected pieces needed to make it. Think working memory.
Databricks Genie Ontology sits on both sides of that line. It maintains a persistent learned layer, then pulls a scoped subgraph for whatever question just came in. Databricks calls this a context layer, and that's probably the right word. (Unless they decide to rename it as well.)
What Databricks announced for Genie Ontology
Two things feed Genie Ontology on Databricks, and they work very differently.
Unity Catalog Semantics is the part you can actually build. Metric views. Glossary pages. Domains! This is modeled, deliberate, governed manually. You decide what goes in it.
The Genie Knowledge Store is the part that gets inferred automatically from Databricks’ system. Expressions, concepts pulled out of your tables, queries, dashboards, pipelines, and all your connected business apps. You don't build anything, just feed it.
Here's the important asymmetry: the inferred half doesn't exist for you yet, but the authored half largely does. Domains are in public preview. Metric views are in public preview. Glossary is preview-coming-soon.
Every one of those is available or nearly available right now, independent of Genie Ontology, and every one of them is useful on its own merits. What you can do today: aligning about your approach internally and starting to prepare the data.
The clever bit is how the system settles disagreements. When two definitions of "revenue" exist, Genie Ontology weighs where each came from, how authoritative the author is, how often people rely on it, how tightly it connects to certified assets, and how fresh it is. They described it as “something like PageRank for definitions.” Genie answers from whichever carries the most weight, filtered by what you personally have permission to see.
Magic isn’t real, bottlenecks remain
Ranking the most trusted definition is not the same as having a correct one. If your data doesn't reflect your reality, the graph you generate from it won't be helpful, and potentially can even be harmful.
Move business data to Databricks
Don’t leave important stuff out! If Genie can only answer a narrow set of topics, because only a slice of your business made it into Databricks, then people learn to be choosy about what they ask. If you move more of the business data into the platform, usefulness and usage will climb fast, because now you can ask it anything.
That's the whole game. Coverage first, then quality follows. You can’t skip the data consolidation, nor the data quality parts of the work. The AI is still only as smart as the data it’s working from.
Clean your data
There’s a second failure mode that’s way subtler. An inferred graph can still inherit your organizational disagreements despite the smart ranking.
If Finance and Sales define "active customer" differently and both definitions are floating around in dashboards and queries, the ranking will pick a winner. But a winner does not equal real consensus between your teams, it's just a popularity contest with a forced tiebreaker, and it may happen that nobody in the room is happy with the outcome. So you better start cleaning up your data, and define who does what, before an agent “decides” for you. (If this even needs to be said: Don’t let the AI decide for you!)
How to prepare your teams for Genie Ontology
Most of this list has nothing to do directly with Databricks (some does tho). That's the point. You can do these while waiting for public access.
Business homework—people agreeing:
- Stakeholder alignment. One definition of "active customer" that Finance and Sales both sign.
- Glossary and taxonomy. Authoritative concepts, named owners, a review cadence so definitions don't just rot.
- Domain design. How the business actually divides itself, which is rarely how the org chart does.
- Certification and stewardship. Who says an asset is trustworthy, and what that signature means.
- KPI inventory. Prioritize which metrics matter enough to model first. (You probably shouldn’t do all of them at once.)
Engineering homework:
- Source consolidation: Get the rest of the business data onto the platform. The context layer only learns from what it can reach, so this item dwarfs everything else.
- Dimensional modeling: Facts, conformed dimensions, grain.
- Metric views: Measures, dimensions, relationships mapped to real KPIs.
- Query and asset hygiene: The ontology weighs how often a definition gets used, how tightly it ties to certified assets, and how fresh it is. That means your abandoned dashboards and one-off exploratory queries are training signals. Retire what's dead, certify what's good.
- Unity Catalog governance, permissions, lineage: Genie Ontology is permission-aware, so your ACLs shape what agents can see and reason over.
- Eval harness: Question sets that verify what Genie actually returns.
The business decides what a "customer" is, engineering enforces it in the model. Get that handoff right, so your data foundations are actually clear and useful.
Who does this work?
If you're staffing this, the main player you're looking for is an analytics engineer with semantic architecture instincts. Some parts may need a platform engineer. Others, a BI developer. But always have a technical person in the room who can talk to Finance, or Management executives. Maybe bring a Forward Deployed Engineer into the fold, so that you can always leave meetings with an agreed definition of churn, and then ship it as a governed object.
Broadly, your engineer needs dimensional modeling and grain discipline, strong SQL, a working understanding of governance operating models, and enough facilitation skill to force decisions out of ambiguous meetings.
On the platform: Unity Catalog privileges and lineage, domains and tags, metric view authoring and materialization, plus Genie Agents, Lakehouse Federation and Lakeflow Connect for everything that lives outside Databricks.
And you need stakeholders with authority, domain owners who can settle definitional disputes. Don’t model the same KPI three different ways, or the ontology will learn the mess.
And where to start?
Build the things that pay off either way: governance, strong foundations, agreed definitions, cleaned up domains.
Run the consolidation work in parallel, on its own track. It's the least glamorous item on the list and the most important, the one that gates everything else, and it pays for itself whether or not Genie Ontology turns out the way the Databricks keynote promised.
When access does open up, the companies that get value in the first month will be the ones who already know what their words mean. Ontology really is the easy part. Knowing your own business well enough to describe it never was.
