Skip to main content

How can I use existing dashboards, queries, pipelines, and documents as context for AI?

Summary

  • You don't need to hand-build a knowledge base. A learned context layer reads the dashboards, SQL queries, notebooks, pipelines, and documents your teams already produce and turns them into reusable business context for AI.
  • Databricks Genie Ontology automatically and continuously extracts business knowledge (metric definitions, authoritative sources, and business rules) from assets connected to your workspace, so agents and analysts answer from definitions your business trusts.
  • It combines two layers: governed Unity Catalog semantics you model deliberately (Metric Views, Domains, Business Glossary Pages) and inferred context Genie learns automatically, the "model the head, infer the tail" approach.
  • It is authority-aware and permission-aware: Genie scores inferred knowledge by the usage and authoring of the underlying asset, and Unity Catalog permissions gate every snippet so users only see context from assets they can access.
  • Genie Ontology is in Public Preview; contact your Databricks account team to enable it.

How can I use existing dashboards, queries, pipelines, and documents as context for AI?

You don't have to hand-build a knowledge base for AI to reason about your business. The assets your teams already produce, dashboards, SQL queries, notebooks, pipelines, and documents, encode how your organization actually defines and measures things, and a learned context layer can read them and turn them into reusable business context. Databricks does this with Genie Ontology, which automatically and continuously extracts knowledge from the assets connected to your Databricks workspace so agents and analysts answer from definitions your business trusts. Genie Ontology is in Public Preview.

What is a learned context layer?

A term like "revenue" or "active customer" usually has several definitions scattered across dashboards, queries, and docs, and an AI with no trusted source can answer confidently but wrongly. A learned context layer fixes that by inferring business knowledge from the assets you already have and keeping it current as those assets change. It captures three kinds of knowledge: metric definitions (for example, that an "active user" is a distinct user deduplicated across platforms), authoritative sources (that revenue questions should be answered from a specific certified source), and business rules (that a "qualified lead" only counts once a demo is booked). The goal is to reuse existing work rather than curate a separate ontology by hand.

What to look for in a context layer

Capability Why it matters
Learns from existing assets Dashboards, queries, notebooks, pipelines, and documents already hold your definitions; re-authoring them by hand is slow and goes stale
Authority ranking When several definitions exist, the layer should score by source, usage, and freshness and pick the one your business trusts
Permission-aware Context must respect access controls so a user only sees knowledge drawn from assets they are allowed to see
Governed plus inferred Deliberately modeled definitions and automatically inferred knowledge should combine, so you certify what matters and let the rest be learned
Consumable anywhere The same context should ground natural-language questions, BI, and agents through open interfaces

How Databricks approaches this with Genie Ontology

Genie Ontology combines two kinds of context. The first is modeled Unity Catalog semantics you define and govern deliberately: Metric Views for reusable metric definitions, Domains for business-aligned collections of assets, and Business Glossary Pages for certified terms. The second is inferred context that Genie extracts automatically from existing assets and usage, including dashboards, SQL queries, notebooks, pipelines, metric views, and Genie activity. Databricks frames the approach as modeling the head and letting the ontology infer the tail: you certify the definitions that matter most and let the system learn the long tail from what you already have. See Operationalizing Genie Ontology.
Two properties make this usable in an enterprise. Genie determines the authority of each piece of inferred knowledge from the usage and authoring of the underlying asset, so when definitions conflict it answers with the one your business relies on. And every snippet is gated by Unity Catalog permissions, so the ontology only draws on assets a given user is allowed to see. Useful inferred concepts can be promoted into governed Pages, and governed definitions enrich the inferred layer in turn. The result grounds Genie's natural-language answers and is addressable from agents and clients through Genie and its MCP interface. See the Genie Ontology documentation. Genie Ontology is in Public Preview; contact your Databricks account team to enable it.

FAQs

What assets can Genie Ontology learn from?

It extracts inferred knowledge from assets connected to Databricks, including dashboards, SQL queries, notebooks, pipelines, metric views, and Genie usage, and it works alongside governed definitions in Metric Views, Domains, and Business Glossary Pages.

Do I have to build the ontology by hand?

No. Genie Ontology infers business knowledge automatically and keeps it current. You can also model the definitions that matter most as governed semantics and let the system learn the rest.

How does it choose between conflicting definitions?

It scores inferred knowledge by the usage and authoring of the underlying asset, favoring definitions that are widely used, tied to trusted sources, and current, so answers reflect the definition your business trusts.

Is context governed and permission-aware?

Yes. Unity Catalog permissions gate every snippet, so a user only sees context drawn from assets they can access.

Is Genie Ontology generally available?

Genie Ontology is in Public Preview. Contact your Databricks account team to enable it.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.