Organizing Brownfield Data Across Multiple Plants.
Unity Catalog + Kobai: A Knowledge Graph Should Not Introduce a Second Governance Model
Unity Catalog + Kobai: A Knowledge Graph Should Not Introduce a Second Governance Model
7:41
How governance flows naturally from your Databricks Lakehouse into your knowledge graph and why that continuity is the foundation of trusted enterprise AI.
Most organisations that have invested in Unity Catalog do not want to recreate governance in a second system. The access policies, lineage maps, and audit trails they have built represent significant investment and they need any capability added to the Lakehouse to operate within that governance model, not alongside it.
Knowledge graphs have historically been the place where that continuity breaks down. A standalone graph database means mirroring Unity Catalog policies into a separate security model, managing two audit trails, and accepting that any delay between a policy change and its propagation to the graph is a compliance gap.
Kobai is designed around a different premise. The semantic knowledge graph runs as a schema directly within Unity Catalog. Governance flows into it natively through the same enforcement mechanisms, the same audit trail, and the same access controls that already govern the Lakehouse. The result is governed semantic reasoning without governance overhead.
|
Governance continuity is not a feature. It is the architectural condition that makes trusted enterprise AI possible at scale. |
What Unity Catalog provides and what the semantic layer adds
Unity Catalog governs data assets across the Databricks Lakehouse: access control, lineage, discovery, quality monitoring, and AI governance. It is designed to be the single control plane for everything in the Lakehouse.
What it does not provide natively is the semantic layer — the formal representation of what data means, how entities relate to each other, and how those relationships should be traversed to answer cross-domain questions. That is the role of a knowledge graph. And for governance continuity, the critical question is whether the knowledge graph operates within the Unity Catalog perimeter.
|
Unity Catalog provides |
Kobai’s knowledge graph adds |
|
Access control for tables, files, models, agents |
Semantic entity and relationship definitions that give those tables meaning |
|
Column- and row-level security on raw data |
Entity-level access aligned to business roles, not just schema structure |
|
Data lineage from ingestion to consumption |
Semantic lineage: AI answer → graph traversal → source entity → raw record |
|
Discovery and cataloguing of data assets |
Cross-domain entity navigation and relationship traversal |
|
AI governance for models and agents |
Governed, explainable AI answers grounded in a validated semantic model |
How governance flows into the knowledge graph
The integration between Kobai and Unity Catalog is architectural. Governance does not need to be configured separately for the semantic layer as it applies through the same mechanisms that govern the rest of the Lakehouse.
The knowledge graph as a Unity Catalog schema
Kobai’s Saturn engine builds and maintains the semantic graph index as a schema directly within Unity Catalog. Because the knowledge graph is a Unity Catalog object, the permissions and policies already defined apply to it. Access to source Delta tables determines access to the graph entities derived from them — governed at the data layer, inherited by the semantic layer.
Databricks compute as the enforcement point
Every graph traversal — whether from Tower, Episteme, a Notebook, or a published API — is translated to SQL and executed on Databricks compute. Unity Catalog’s access controls apply at execution. Every access point routes through the same enforcement layer. Lineage is captured natively in the Databricks audit trail.
User identity passes through to the Lakehouse
Kobai uses SSO with identity passed through to the Databricks backend. Governance policies applied to a semantic query are those of the authenticated user. A user whose Unity Catalog access is scoped to a specific region or business unit sees only the graph entities that correspond to their permitted data.
Governance across the semantic stack
Governance applies at each layer of the Kobai architecture, from raw data through the semantic model to the AI answer.
|
■ Data layer Raw Delta tables governed by Unity Catalog. Access policies defined in Unity Catalog apply to every downstream graph query — no separate data access configuration. |
|
▶ Semantic model layer The ontology is stored as a Unity Catalog schema. Changes are versioned. Every modification is auditable. Domain experts author the model; Unity Catalog tracks it. |
|
● Graph query layer Graph traversals execute as SQL on Databricks compute. Access controls apply at the point of execution. Every entity returned is bound by the querying user’s permissions. |
|
◆ Visualisation layer Tower persona views are governed by Unity Catalog policy, not application-level filtering. Each team sees the entities they are authorised to access — enforced natively. |
|
▲ AI answer layer Episteme’s AI answers carry full semantic lineage back to source Delta records. Every answer is traceable, auditable, and bounded by the user’s access scope. |
The risk of governance divergence
When knowledge graph capabilities are added outside the Lakehouse governance perimeter — in a separate graph database with its own security model — three operational consequences follow.
- Access policies must be maintained in two places. Every change to Unity Catalog permissions must be mirrored manually. The gap between systems is a compliance exposure.
- Audit trails are fragmented. Compliance teams must reconcile activity from two separate systems to produce a complete picture of data access.
- Governance divergence compounds over time. As the graph store diverges from the source Lakehouse — in data currency, access policies, and lineage records — the compliance risk accumulates.
|
Governance that is maintained in two places will eventually diverge. The organisations best positioned for trusted enterprise AI are those that keep the semantic layer within the same governance model as the data it describes. |
Governance continuity in regulated industries
Governance continuity is particularly consequential where AI explainability and data access auditability are regulatory requirements, not architectural preferences.
|
Industry |
Governance requirement |
What governance continuity enables |
|
Life Sciences |
AI outputs for regulatory workflows must trace to authorised source data |
Episteme answers include semantic lineage to source Delta records; Unity Catalog policies govern which data each user’s AI query can access |
|
Aerospace & Defence |
Role-restricted data must remain inaccessible regardless of query structure |
Graph traversals respect Unity Catalog row- and column-level policies; clearance boundaries are enforced at execution, not filtered in the application layer |
|
Financial Services |
AI answers in risk workflows must be auditable end-to-end |
Semantic lineage from AI answer to source record is captured natively; audit logs appear in the existing Databricks audit trail |
|
Energy & Utilities |
OT and IT data must be governed consistently across operational boundaries |
Kobai’s semantic model unifies OT and IT data within a single governance perimeter; Unity Catalog policies apply across all data types and query interfaces |
Unity Catalog governance across every Kobai touchpoint
|
Kobai access point |
Governed by |
What is enforced |
|
Kobai Studio |
Unity Catalog schema-level access |
Who can view or modify which domains of the semantic model |
|
Saturn (graph queries) |
Unity Catalog table and row policies |
Data access per authenticated user at graph traversal |
|
Tower (visualisation) |
Unity Catalog via SSO user passthrough |
Persona views bounded by each user’s permitted data scope |
|
Episteme (AI answers) |
Unity Catalog at SQL execution |
AI context retrieval bounded by the querying user’s access |
|
Genie integration |
Unity Catalog via Kobai semantic views |
Conversational AI operates within the governed semantic layer |
|
APIs and Notebooks |
Unity Catalog via Databricks compute |
Programmatic graph access subject to the same policy enforcement |
Trusted enterprise AI starts with governance continuity
Trusted enterprise AI is not primarily a question of model capability. It is a question of whether the answers AI produces can be traced, audited, and defended — and whether the governance model that protects the underlying data extends naturally to the AI systems built on top of it.
When the semantic knowledge graph operates within Unity Catalog, inheriting access controls, contributing to the same lineage record, and executing within the same audit perimeter, that continuity is the default. AI answers are explainable not because traceability was added as a feature, but because the architecture makes them traceable by design. Compliance confidence follows from the architecture, not from additional tooling.
That is what governance continuity enables: semantic reasoning within the Lakehouse, explainable AI within the governance model, and operational trust built on architecture rather than assurance.
To explore how governance flows into a semantic knowledge graph on your Databricks Lakehouse, visit kobai.io or contact us at contact@kobai.io.
COMMENTS
