Genie Ontology Doesn't Replace Your Semantic Layer. It Ranks It.

I asked Genie One for last quarter’s ticket revenue. It said $74,162. The right answer was $64,954: refunded sales still carried their full amount, and Genie counted them. After I added a certified metric view and a few descriptions, a retest about 30 minutes later came back with $64,954, straight from the metric view.

That gap is what this post is about. In the small professional circles I move in, the word of the year is “context”. Every data platform now has an AI coworker, and every AI coworker is only as good as the context it’s given.¹

Databricks’ answer is Genie Ontology: a “living context graph” of how your company works. It learns on its own from your tables, queries, dashboards and agents, so Genie can start answering questions before you model anything.

Useful. But Databricks is upfront that it’s only half the picture. There’s a second layer, the context you define and govern, and that’s the one doing the steering. Certification “steers Genie One toward the assets your organization vouches for”. Pages take priority over what Genie infers.

My argument, in one line:

Genie Ontology doesn’t replace your semantic layer. It ranks it.

I didn’t want to just argue it, so I tested it. Everything I added is below, with Genie’s answers before and after.

What Databricks means by a semantic layer

“Semantic layer” means different things to different vendors, so here’s Databricks’ version. They call it Unity Catalog semantics: “a collection of tools to help you define standard business metrics, terms, and organizational structures on top of your catalog data”, so that “both human users and AI tools interpret your data consistently under a single governance model”.

It has four parts:

Databricks describes these together as “the human-modeled layer of the Genie Ontology”. So the semantic layer is the curated half of the ontology. The other half is what Genie infers on its own.

One practical note: five of my nine additions were plain table and column descriptions. Those aren’t one of the four parts above; they’re ordinary Unity Catalog metadata. Genie reads them too: on retesting after I added them, it found the three tables it had missed.

What the ontology does

In plain terms, Genie Ontology does three things.

It gathers two kinds of context. What you curate: metric views, domains, Pages and certification in Unity Catalog. And what it infers: snippets of meaning pulled from your existing tables, dashboards, SQL queries and Genie Agents.

It ranks them. Databricks calls the scoring OntoRank and describes it as “similar to PageRank”: where a definition came from, who wrote it, how often it’s used, how closely it ties to certified assets, and how fresh it is.

It respects permissions. Genie only uses context from assets you’re allowed to see.

Why enrichment matters

Every one of those ranking signals measures how much a definition is trusted. Those signals don’t establish business correctness. Definitions still need validation against agreed rules and reference results.

Picture a revenue query written in a hurry that quietly counts refunds. It gets copied into a dashboard, then a dozen more. Usage is only one of the signals, but repeated reuse could strengthen the wrong definition’s usage signal, which makes an explicit, governed alternative more important.

The test

I built a small, made-up rail ticketing dataset on Databricks Free Edition: four tables, no descriptions, no metric views. Each table hid a trap a new analyst would fall into: refunds left in the sales table, an “active customer” term with two meanings, duplicate card taps, a column called delay_mins that actually holds seconds, and a fare-free month that isn’t recorded anywhere.

I asked Genie One five plain questions, the way a business user would, with no table names. Then I enriched the ontology (one certified metric view, four table descriptions and one column description; seven SQL statements) and asked again. After that I added a sixth question, the Northern line delay, to test the column description on a question Genie hadn’t seen. The Page test came last. Each step below shows exactly what I added, as it appears in Catalog Explorer.

453 vs 455: Genie counted from today’s date, two days after my reference date. Same definition.

Limits. One small test, on Free Edition, against a Public Preview feature. I changed several things at once and didn’t repeat runs, so I can’t separate indexing time, ranking, certification and conversation recall. Treat these as observations, not benchmarks. I tested one Page; a second one wouldn’t publish from the editor during the test, so I’m reporting one result, not a pattern.

Within half an hour, five of the first six matched my reference answers. The sixth used the right definition but counted from a different date. The Page test was right within five minutes. Remember, Genie started out unable to find most of the data at all. Here’s what I changed, one step at a time.

What I changed and what happened

1. Describe every table in business words

Before enrichment, Genie couldn’t find three of the four tables. It didn’t give wrong answers. It gave none. Its search came back empty for customers, trips and delays.

Here’s what I added, in Catalog Explorer:

It’s plain English: “Passenger trips on the rail network, one row per card tap-on. No primary key. Card readers double-write about 7% of taps as exact duplicate rows, so count trips with COUNT(*) over SELECT DISTINCT *, never a plain COUNT(*).”

After that, the same question found the right table, and the warning about duplicate taps produced the right count:

So in this test, descriptions did two jobs: they helped Genie find the data, and they told it how to read it. I wouldn’t claim every undescribed table is invisible. Here, three of four were.

One limit: removing exact duplicates was right for my made-up data because I knew how they were created. In production I’d fix duplicates in the pipeline and serve a clean trips table. A table description shouldn’t carry the whole burden of data quality. I’d also leave out the “about 7%”. It’s true this month and wrong the next, and Genie only needs the rule: exact duplicates exist, so remove them before counting.

2. Write down the definition people argue about

“Active customer” meant two things in my data: billed in the last 90 days (Finance) or travelled in the last 30 (Operations). Before enrichment, Genie couldn’t even find the customers:

I added one sentence naming the official definition and its owner:

Genie used it, and even explained the alternative:

The ontology can rank definitions, but it can’t settle an argument. Write the answer down, name the owner, and Genie will use it. At scale, this is what Pages are for.

3. Put warnings where Genie reads them

The delay_mins column holds seconds. I added a column description saying so:

On a new question, Genie read it and converted:

“I can see that the delay_mins column actually contains seconds (not minutes, despite the name)”. That sentence came straight from the column description.

The description works as a warning. In production I’d also fix the name: a delay_secs column, or a governed measure in minutes. Otherwise every downstream user has to remember the same exception.

4. Certify a metric view, and record what the data can’t tell you

Nothing in the data explains why March revenue fell. Before enrichment, Genie noticed the pattern and guessed:

I created a revenue metric view (paid sales only), certified it (that’s the blue tick), and noted in its description that March was a fare-free month:

In the lineage graph, the metric view carries both signals Genie can see: the certified tick and the Rail Operations domain tag (added in step 6).

I also pointed the sales table at it, and wrote down the fare-free month there too:

A few minutes later:

Genie used the certified metric view (it’s one of the two cited sources), got the numbers right ($20,194 in February to $5,975 in March), and gave the reason I’d recorded. Credit where it’s due, but no more: it retrieved that reason. It didn’t work it out.

And look at that $5,975. My note says March was fare-free, yet the data still holds March sales. That’s a flaw in my made-up data, and Genie repeated the note without questioning it. A real business note has to explain the whole drop, because Genie will cite it as confidently as a correct one.

A note in a description was fine for one made-up month. It won’t hold up in real life, where every promotion, strike and outage would pile into the same paragraph and nobody would own it. In production I’d keep events like this in their own table, with dates, scope and an owner, and have the description point there.

This is what ranking looks like from the outside. Two sources could answer a revenue question: the raw ticket_sales table, where refunded sales still carry their full amount, and the certified metric view, which excludes them. With only the raw table, Genie summed it and reported $74,162 for last quarter. Once the certified view existed, a retest about 30 minutes later queried it instead and reported the correct $64,954 (shown in step 5).

What I can’t tell you is why it switched. I added the metric view, certified it and pointed the sales table at it in the same round. The test shows which source Genie picked, not which of those changes made it pick it.

5. Enrich before people start asking

Alongside the ontology, Genie One has a second, separate kind of context: your own chat history. Databricks documents this as “Recall past conversations”: Genie One “remembers your past conversations and can draw on them to shape its answers”. It only uses your own conversations, it’s always on, and when it uses one it cites it as a source.

Sometimes that helps. For the Northern line question, Genie read one of my earlier chats about delays to find the right table, then read the column description to get the units right:

But when I’d already asked the same question, the earlier conversation seemed to steer the new answer. Genie did run fresh SQL against current data, but it repeated the earlier approach. The Coastal line, which I’d asked about before adding the column description, averaged delay_mins without converting and came back at 187.8 “minutes”, citing “Previous analysis”:

Revenue did the same. It re-ran the earlier query on the raw table, refunds included, and cited “Previous ticket revenue query” (the documented past-conversation citation), even though a certified metric view now existed:

Then I asked both again about 30 minutes after enriching. This time the answers were correct. Coastal came back at 3.1 minutes, after Genie read the table details and divided by 60:

And revenue came back at $64,954, queried straight from the certified metric view, with no past conversation consulted:

So past conversations are a context source too, and for a while an early wrong answer can outlast the fix for the person who asked it. In my test the correct answers appeared on retesting about half an hour later. I can’t say whether that was indexing, recall or ordinary variation, so don’t treat 30 minutes as a rule. Because memory is per user, this affects each person’s own history rather than the whole organisation. It’s still the best argument for enriching before rollout: the first answers people get are the ones they’ll keep building on. And when you fix context after rollout, retest the questions people already got wrong answers to, not just fresh ones. Check the citations too. A past-conversation citation shows that earlier context influenced the answer. Inspect the executed SQL to establish whether Genie also queried current data, and how. In my test a brand-new chat didn’t avoid this, because memory spans chats.

6. Publish a Page for each business term

Last, I tested the newest part of Unity Catalog semantics: Pages, which are in Beta. Databricks says that when Genie One answers a question about a concept defined in a Page, “it prioritizes the Page’s definition over context it infers automatically, and cites the Page so users can confirm the source”. I wanted to see that happen.

I picked a term that appears nowhere in my data or descriptions: on time. I first grouped the five assets into a domain, Rail Operations, which is where Pages live:

Before the Page existed, Genie had to guess what “on time” meant. It guessed “no delay at all” and reported 60.68%:

Then I published one Page defining on time as “departed less than 2 minutes late”:

About five minutes later, the same question:

“Found 1 ontology result… Great! I found a glossary page defining ‘on time’.” Genie applied it and answered 64.35%, which matches the reference of 64.35% exactly. And the answer carries a Genie Ontology citation that opens to the Page itself:

That’s Databricks’ documented behaviour, start to finish: Genie searched the ontology, found the Page, used its definition over its own guess, and cited it. Thirty minutes later it still held: the Coastal line came back at 64.35% citing the Page, and a line I’d never asked about, the Valley line, came back at 63.74%, exactly the correct figure, also citing the Page. For contrast, I asked about “peak-hour trips”, a term I didn’t write a Page for. Genie found no definition and asked me which hours count as peak. Fair enough. That’s the gap a Page fills.

What took time

Not everything landed straight away:

• Some corrections only appeared on retesting about half an hour later. In the first fifteen minutes, two brand-new questions (Q2 revenue and the Valley line’s delay) still came back “couldn’t find any data”, and two older questions repeated earlier answers. Asked again about 30 minutes after enriching, every one was right: $65,686 for Q2 from the certified metric view (reference: $65,686), and 3.2 minutes for the Valley line (reference: 3.18).
• Answers varied between runs in that first half hour. Check the SQL and the citations, not just the number.

Curate once, and it pays off outside Genie One

I only tested Genie One, but most of what I added isn’t tied to it. I think that’s the part people miss.

The metric view is the clearest case. You can query a metric view from “SQL editors, notebooks, dashboards, Genie Agents, and alerts”, and from Power BI and Tableau too. So the refund rule lives in one place. A dashboard querying the same metric view with the same filters should return the same $64,954, and nobody has to remember to filter out refunds again.

Genie Agents get the same benefit. Databricks says “Genie One and Genie Agents are powered by Genie Ontology”. Without a governed metric, every agent needs its own instructions saying “exclude refunds” and “delay_mins is in seconds”, and those copies drift apart. With one, the agent can lean on the metric view and the descriptions, and its instructions can stick to what’s specific to its audience.

It works the other way round too. Dashboards and Genie Agents are among the things the ontology learns from, so ones built on certified assets should add weight to the right definition rather than the hurried one. As Databricks puts it: “the work you do to model a metric also makes it easier for an agent to find and use it correctly.”

A caveat: I didn’t build a dashboard or an agent for this test, so this section comes from the docs, not my screenshots. And Pages are only documented for Genie One so far.

Don’t document everything

The opposite mistake is tempting: describe every column, write a Page for every term. But the ontology ranks whatever you give it. A description written in 2023 and never updated is a confident, citable source. Two teams writing two Pages for “active customer” hand the ranking a tie to break.

Bad metadata is worse than none, because it looks like someone checked. The goal is the right metadata, owned by someone, on the questions people actually ask.

Databricks puts it as “model the ‘head’ and let Genie Ontology infer the ‘tail’”: curate the few metrics that must never be wrong, and let the ontology learn the rest from use. Simon Whiteley at Advancing Analytics turns that into a strategy: a walled garden of curated assets, a park of well-kept ones, and a woodland of everything else. This test is a small look at what the walled garden does in practice.

A checklist to start with

1. Start with the questions people actually ask. Genie Agents’ question history and your most-viewed dashboards will show you which ones matter.
2. Describe the tables behind them in business words, including their traps.
3. Write down contested definitions as Pages, in a domain, with a named owner.
4. Add column descriptions for anything whose name misleads.
5. Certify a metric view for every headline metric. Things that happened, like a promotion month, go in an events table, not a description.
6. Do all of this before rollout, then test your top questions, including ones people already asked before the fix. Read the SQL and citations, not just the number, and fix the source when an answer is wrong.

The bigger point

Genie Ontology does the part nobody had time for: it reads everything and works out what’s likely to matter. What it can’t do is know which of your habits are actually true. That part is still our job.

Automatic context gets you started. Curated context decides what wins.

Test run on Databricks Free Edition with synthetic data, 2 October 2026. Questions were asked in plain language, with no table names. Screenshots are from Genie One, cropped to the chat area.