Genie Ontology, the context layer under every Genie answer

Pull-quote: “Context is data. A context layer that ignores permissions leaks meaning even when it never leaks a row.”

Genie Ontology decides what context a Genie product receives about your business before it writes a single line of SQL, and it is in preview rather than generally available. Databricks announced it at Data + AI Summit on 16 June 2026 as a live, self-improving knowledge graph of business terms, entities, and metrics, built to ground the rest of the Genie family in verified definitions rather than inferred ones.

The word ontology is doing real work in that sentence. This is not a glossary and not a second semantic layer. It is a graph assembled automatically from what your organisation already produces, with a ranking algorithm called OntoRank deciding which pieces of it reach an agent, filtered by what the person asking is allowed to see.

This post is for the data platform owner or lead architect who has to answer two questions: what changes when this reaches general availability, and what should we do this quarter. It assumes Unity Catalog and some experience of semantic modelling. By the end you will be able to explain the mechanism, describe how it differs from the semantic layer you already govern, and name the preparation work that pays off whether or not you get preview access.

What you will be able to do

• Explain what Genie Ontology is, what OntoRank does, and why the pairing matters.
• State its availability accurately, so nobody builds a roadmap on a preview.
• Describe how permission-aware context injection works and why it is a governance requirement rather than a feature.
• Place Unity Catalog Metrics correctly as the semantic foundation the graph is fed from.
• Distinguish an authored semantic layer from an inferred ontology, and say which one settles a dispute.
• Run the preparation that makes the graph useful on day one instead of noisy.

What is Genie Ontology, and can you use it today?

Genie Ontology is a live, self-improving knowledge graph of business terms, entities, and metrics that grounds Databricks Genie products in verified definitions, and as of July 2026 it is in preview rather than generally available. It was announced at Data + AI Summit on 16 June 2026.

Say the preview part out loud in any internal briefing. Preview means the shape can change, the availability is not universal, and a dependency you commit to in a design document may not be there when you need it. The rest of the family is mixed: Genie One, Genie Agents, and Genie Code are generally available, while Genie ZeroOps and Genie App Builder are in private preview. Getting those statuses right is the difference between a credible plan and a plan somebody has to walk back.

The purpose is grounding. A natural-language question contains business words, and business words are ambiguous outside a shared context. Without a context layer, an agent resolves “active account” by inference from the names and text it can see. With one, it retrieves a verified definition. Databricks describes the goal directly: agents retrieve verified definitions through SQL rather than inferring meaning from scattered text.

What is the ontology built from?

It is built automatically from the artifacts your organisation already produces: tables, queries, dashboards, pipelines, and more than 50 connected applications including Jira, Slack, Google Drive, SharePoint, Confluence, and email. Nobody sits down and authors it.

That input list is the interesting part, because it changes what kind of object this is. A semantic model contains what someone decided to declare. This graph contains what your organisation actually does and says, including the parts nobody would have written down. The query an analyst ran forty times last quarter is evidence about which table is authoritative. A Slack thread arguing about whether cancelled orders count in revenue is evidence that the definition is contested. A Confluence page from 2023 is evidence too, which is exactly the problem ranking exists to solve.

So the honest way to describe the raw graph is this: it inherits your organisation’s disagreements along with its knowledge. That is not a criticism of the design. It is the reason the ranking step matters more than the extraction step, and the reason your authored definitions become more valuable rather than less.

How does OntoRank decide what an agent sees?

OntoRank is the ranking algorithm inside Genie Ontology: it extracts knowledge snippets, ranks the authoritative ones, applies permissions, and injects the result into the agent loop. Four steps, in that order, and the order is the design.

Extraction gathers candidate snippets of meaning from the sources above. Ranking decides which candidates are authoritative, informed by usage signals such as column usage metrics, so a heavily used column carries more weight than one nobody queries. Permission filtering removes anything the asking user is not entitled to see. Injection places what survives into the agent’s context.

The step that gets least attention is ranking, and it is the one that decides whether any of this helps. An agent handed a whole knowledge graph has to work out relevance itself from vector similarity, which is far less reliable than a ranking informed by authority and actual usage. A model’s attention is finite, so every irrelevant snippet injected into the loop competes with a relevant one. That principle is not specific to Databricks, and the context engineering budget covers it in general terms.

Why does permission-aware context matter more than it sounds?

Because context is data, and a context layer that ignores permissions leaks meaning even when it never returns a restricted row. Genie Ontology is permission-aware: an agent receives only context the asking user is allowed to see.

Consider what a definition can disclose. A metric named after an unannounced acquisition tells the person asking that the acquisition exists. A dimension named for a product line nobody has launched discloses the product line. A snippet lifted from a Jira ticket can carry a customer name, a legal matter, or a headcount plan into a conversation with someone who has access to none of those systems. None of that is a row from a governed table, and all of it is a disclosure.

This is why permission filtering has to happen inside the ranking pipeline rather than at the end. Filtering the answer is too late: by then the model has already read the context and can paraphrase it. The control belongs where OntoRank puts it, before injection. When you evaluate this in preview, that is the property to test deliberately: ask the same question as two users with different entitlements and compare not just the numbers but the vocabulary the answers use.

How does Genie Ontology relate to Unity Catalog Metrics?

Unity Catalog Metrics is the semantic foundation the ontology is fed from, which makes your metric definitions the preparation with the highest return today. The graph also consumes usage signals, such as column usage metrics, to weigh what is actually in use.

Read that as an instruction. Every measure you define once in Unity Catalog becomes an authoritative input to the ranking, inherited by dashboards, by Genie Agents, and by anything else that reads the catalog. Every measure that exists only inside a BI tool’s calculation pane, or only in the head of the analyst who built the report, contributes nothing except an inconsistency for the ranking to arbitrate. The teams who will get the most out of this layer are the ones who did the definitional work before it arrived.

The practical sequence is unchanged by the preview. Settle the contested measures. Define them as governed objects. Comment the columns people actually query. That work makes today’s Genie Agents better, which is covered in curating a Genie Agent that earns trust, and it makes tomorrow’s ontology better without a migration.

How is a live ontology different from the semantic layer you already govern?

An authored semantic layer states what you promise a term means, while a live ontology infers what your organisation appears to mean and ranks the evidence. One is a contract, the other is a retrieval layer over meaning, and a mature platform needs both.

The distinction has practical consequences. An authored definition is stable, reviewable, and arguable: you can point at a change, name who approved it, and reproduce a number from six months ago. An inferred one is current, broad, and probabilistic: it covers terms nobody got around to declaring, and it changes as usage changes. When the two disagree, the authored definition settles it and the disagreement itself is the signal, because it usually means people are using a term in a way your model does not describe.

Governance of the authored layer therefore becomes more important rather than less, because it is now feeding a ranking algorithm rather than only a dashboard. The ownership, review, and versioning practices for that layer are covered in ontology governance and the semantic layer.

What should you do now, while it is in preview?

Do the work that pays off either way, and none of it requires access. Five items, in order of return.

1. Settle three contested definitions. Pick the three measures that generate the most argument, decide them with the people who own the process, and define them as governed objects in Unity Catalog. This is the highest-value preparation because it feeds the semantic foundation directly.
2. Comment the columns people actually query. Usage signals mean heavily used columns carry weight. A heavily used column with no description is a strong signal attached to no meaning.
3. Audit what a connected application would expose. Before anyone connects Slack, Jira, or a shared drive, ask what a snippet from each would reveal and to whom. Decide which sources are in scope on purpose rather than by default.
4. Test your permission model as if context were data. Ask the same questions as users at three entitlement levels and compare the vocabulary as well as the figures. Any surprise you find now is a surprise you would otherwise find in production.
5. Name an owner for meaning. Someone has to be accountable for what a term means, arbitrate when the graph disagrees with the model, and keep a register of decisions. Without that role, an inferred layer becomes a second source of truth by accident.

Where this goes wrong

Treating the ontology as a fix for disagreement. The symptom is a team expecting the graph to decide what revenue means. The cause is confusing a ranking algorithm with a decision. Ranking surfaces the most authoritative existing answer, and if three exist you still have to choose one.

Building a roadmap on a preview. The symptom is a design document with a dependency that cannot be delivered on the date it is needed. The cause is reading Summit announcements as shipping notices. Genie Ontology is preview, Genie ZeroOps and Genie App Builder are private preview, and only Genie One, Genie Agents, and Genie Code are generally available.

Connecting every application at once. The symptom is context arriving from sources nobody reviewed, including a document store with mixed sensitivity. The cause is treating connection breadth as a benefit rather than a decision with a blast radius. Add sources one at a time, and ask what each one discloses.

Skipping metric definitions because the graph will infer them. The symptom is a context layer arbitrating between three implementations of the same measure. The cause is treating inference as a substitute for governance. Inference resolves ambiguity you left behind; it does not remove your obligation to define the thing.

No owner for meaning. The symptom is nobody able to say which definition is correct when a Genie answer and a dashboard disagree. The cause is an unowned semantic layer, which a live graph makes more visible rather than less.

Common questions

Is Genie Ontology generally available?

No. As of July 2026 it is in preview, having been announced at Data + AI Summit on 16 June 2026. Genie One, Genie Agents, and Genie Code are generally available, while Genie ZeroOps and Genie App Builder are in private preview. Quote those statuses precisely in any internal plan, because a reader who tries a preview feature and cannot find it stops trusting the rest of the document.

What does OntoRank actually do?

It extracts knowledge snippets from your data and connected applications, ranks the authoritative ones, applies the asking user’s permissions, and injects what survives into the agent loop. Usage signals such as column usage metrics inform the ranking, so a column many people query weighs more than one nobody uses.

Does the ontology replace my semantic layer?

No. Unity Catalog Metrics is described as the semantic foundation the ontology is fed from, which makes an authored layer an input rather than a casualty. Keep authoring definitions: they are what settles a dispute, and they are what a ranking algorithm treats as authoritative evidence.

Can the ontology leak sensitive information through a definition?

It is designed not to, because permissions are applied inside the ranking pipeline and an agent receives only context the asking user is allowed to see. The reason this matters is that context carries meaning as well as values, so a metric name or a snippet from a ticket can disclose something even when no restricted row is returned. Test it with users at different entitlement levels rather than assuming it.

What is the difference between a knowledge graph and an ontology here?

The ontology is the model of meaning: which business terms exist, what kind of thing each one is, and how they relate. The graph is the populated structure built from your artifacts according to that model. In everyday use Databricks describes Genie Ontology as a live knowledge graph of business terms, entities, and metrics, so the two words point at the same product.

Next steps

Pick the three measures your teams argue about most and define them in Unity Catalog this quarter. That is the whole recommendation, and it is deliberately small, because the definitional work is what determines whether a context layer helps you or arbitrates your inconsistencies. While you are there, comment the twenty columns your query history shows people actually use.

Then read Genie Code and agentic data engineering, which is where the same grounding shows up in the engineering surfaces rather than the business ones. If your organisation is rolling out the business-facing product first, Genie One for business teams covers what the people asking the questions will actually touch.

Zorost does this modelling work on client lakehouses as a trusted Databricks partner, where a measure is not considered defined until it exists as a governed object and the legacy report has been reconciled against it.