Do I need to manually build and maintain an ontology for AI?

Summary

• No, not by hand and not from scratch. A hand-authored ontology, where every business term and relationship is defined and maintained manually, is slow to build and drifts out of date as your data changes. Modern context layers build and maintain most of it automatically.
• The pragmatic pattern is to curate the head and infer the tail. You define the few concepts that must be authoritative and governed, and the context layer infers the broader web of meaning from assets you already have.
• On Databricks, Genie Ontology does this automatically. It's in Public Preview and builds a context layer from your governed assets, so Databricks Genie can interpret questions the way your teams mean them, with no formal ontology to hand-build.
• It stays permission-aware. Context snippets are gated by Unity Catalog permissions, so Genie only uses knowledge from assets a user is allowed to see.
• You still curate the authoritative core: metric definitions, glossary terms, and domains you want governed. That modeled context plus the inferred context together form the ontology.

Do I need to manually build and maintain an ontology for AI?

No. You don't need to hand-build and maintain a formal ontology for AI to understand your business. The old approach, where a team defines every entity, attribute, and relationship by hand and then keeps it current forever, is slow to stand up and tends to drift the moment your tables, metrics, or business rules change. The practical answer today is a context layer that builds most of the ontology automatically from the assets you already govern, while you curate the handful of definitions that must be authoritative. On Databricks, that automatic layer is Genie Ontology, which is in Public Preview.

What an "ontology for AI" really means

An ontology, or semantic layer, is the map of what your business terms mean and how they relate: what counts as an "active user," how "revenue" is calculated, which table is the authoritative source for a concept. AI agents need that context to answer data questions the way your teams intend, rather than guessing from column names. The trouble with building it entirely by hand is maintenance. Definitions multiply, ownership blurs, and a static model can't track how people actually query the data. A better design curates the critical concepts deliberately and infers the rest, a pattern Databricks describes as "model the head, let Genie infer the tail." See operationalizing Genie Ontology in your data stack.

What to look for in an automatic context layer

If you're weighing whether a platform can spare you from hand-maintaining an ontology, these capabilities are what matter:

Capability	Why it matters
Automatic extraction from existing assets	Builds context from the tables, metrics, dashboards, and queries you already have, so you don't start from a blank page
A place to state authoritative definitions	Lets you govern the concepts that must be exact, like key metrics and certified sources, instead of leaving everything to inference
Permission-aware context	Ensures the AI only uses knowledge from data a given user is allowed to see
Conflict resolution and ranking	Picks the most authoritative definition when sources disagree, rather than blending them
Grounding in governed data	Ties meaning back to catalogued, lineage-tracked assets so answers stay traceable

How Databricks approaches this with Genie Ontology

Genie Ontology (in Public Preview) is a context layer that gives Databricks Genie a business-aware map of your organization without a formal ontology to hand-build. It combines two kinds of context:

• Modeled context you govern. Unity Catalog semantics such as metric views and domains, plus the Unity Catalog Business Glossary, let you state authoritative meaning explicitly and keep it version-controlled. This is the head you curate. See Unity Catalog business semantics.
• Inferred context that builds itself. Genie continuously extracts snippets from assets already connected to Databricks, including metric views, dashboards, SQL queries, and Genie Agents. Examples are metric definitions, authoritative sources, and business rules. Each snippet gets an authority score based on where it came from, how often it's used, and how fresh it is, and snippets are gated by Unity Catalog permissions so Genie only uses what a user may see. Read the Genie Ontology documentation.

At query time Genie ranks the most relevant snippets by authority, resolves conflicts, and answers using only permitted sources. Because it injects focused context instead of crawling everything, answers stay grounded in your governed data, and the ontology improves as your team uses Genie rather than requiring a standing modeling project. For how this fits into the assistant experience, see Genie Ontology in chat.

FAQs

So do I ever build an ontology manually?

Not from scratch. You curate the authoritative core, meaning your key metric definitions, glossary terms, and domains, and Genie Ontology infers the wider set of relationships automatically from your governed assets and usage.

Is Genie Ontology generally available?

No. Genie Ontology is in Public Preview. Availability and behavior may change before general availability, so confirm current status in the documentation.

Does an automatic ontology respect data permissions?

Yes. On Databricks, context snippets are gated by Unity Catalog permissions, so Genie only uses knowledge extracted from assets a given user is allowed to access.

How is the ontology different from a business glossary?

The ontology infers meaning automatically from your assets and usage, while the Unity Catalog Business Glossary lets you state meaning explicitly through version-controlled concepts, domains, and links to specific tables and columns. They work together: the glossary governs the definitions you curate, and the ontology fills in the rest.