The model is swappable the ontology compounds

cpard1 pts0 comments

The model is swappable, the ontology compounds

OpinionThe model is swappable, the ontology compounds<br>Kostas Pardalis<br>Co-Founder

June 19, 2026

The model is becoming the swappable part.

The ontology is what compounds.

That, to me, is the important idea behind Databricks’ Genie Ontology. The persistent state that gets smarter with every query, every certified metric, every dashboard, every lineage edge, every business definition, and every correction from a human is the actual moat.

This is why Ali Ghodsi calling the Genie Ontology the “secret sauce” matters.

It signals that the industry is moving into a new phase. For the last couple of years, a lot of the conversation around AI products has been about models: which model is better, which model is cheaper, which model has the larger context window, which model is better at reasoning, coding, retrieval, or tool use.

That still matters, but I think the center of gravity is shifting.

For enterprise AI, the durable value will not live only in the model. It will live in the governed context layer around the model.

The model can be replaced but the context compounds.

And that is why ontologies, which for years were treated as important but somewhat niche, are about to become much more central to how companies think about AI systems.

So, what is the Genie Ontology, and why is it interesting?

Based on what Databricks has shared so far, and what I managed to learn during the Databricks conference, here is my current mental model.

What is Databricks Genie Ontology?

The simplest way to think about Genie Ontology is this:

Humans define the canonical business meaning.

Machines learn how that meaning shows up across the company.

Humans correct the machine when it drifts.

The system gets better over time.

My current mental model is that there are two interacting layers.

The first layer is the governed semantic foundation.

The second layer is the machine-learned ontology that continuously builds enterprise context on top of that foundation.

Layer 1: The governed semantic foundation

The first layer is human-defined and curated.

This is the part that lives in and around Unity Catalog. It includes things like business glossaries, domains, and metrics.

The business glossary defines authoritative concepts, terms, and taxonomies. In theory, if a company already has some of this work done elsewhere, those definitions can be imported or migrated into the governed layer.

Domains group assets in a way that maps to the business. They create ownership and stewardship boundaries. They also help communicate which assets are trusted, certified, or relevant to a specific part of the organization.

Metrics define reusable business measures like revenue, churn, active users, gross margin, pipeline, or retention. The important part is that these are not just random SQL snippets copied across dashboards. They are governed objects that can be reused consistently by BI tools, agents, notebooks, dashboards, and downstream applications.

This layer matters because AI cannot answer business questions reliably if the business itself has not defined what the words mean.

If “revenue” means one thing to finance, another thing to sales, and a third thing to the product analytics team, the model is not going to magically fix that. At best, it will pick one definition. At worst, it will confidently mix them together.

So the governed layer provides the canonical starting point.

But that is not enough.

Because the official definition of the business is only one part of the story. The other part is how the business actually operates.

That is where the machine-learned layer comes in.

Layer 2: The machine-learned enterprise context graph

The Genie Ontology appears to use the governed semantic foundation as input into a broader, continuously learned enterprise context layer.

This is the part that tries to understand how the company actually works by looking across tables, queries, dashboards, pipelines, documents, connected applications, and workplace tools.

In other words, it is not just looking at schema, it is also looking at usage and that distinction is important.

A schema can tell you that a table has a column called customer_id.

It cannot tell you whether that column is trusted, whether the table is deprecated, whether analysts actually use it, whether executives rely on a dashboard built from it, whether another team has a better version, or whether the metric calculated from it is the one the business actually considers authoritative.

To know that, you need more than metadata, you need context.

That context comes from many places: lineage, query history, dashboards, pipelines, documents, certifications, permissions, domains, connected apps, and the way people actually interact with the data.

This is where Databricks is making a very interesting bet.

The system is not just retrieving data at query time. It is building a persistent representation of the enterprise...

model ontology business layer context part

Related Articles