The people who understand what enterprise data means are the people who should define it. The tools to make that possible now exist and the organisations using them are building AI systems that stay current, stay trusted, and scale without an engineering bottleneck.
Every organization has people who know exactly how the business works. The problem is that every time the business changes, they have to explain it to IT, wait for development, test the result, and then explain what was lost in translation.
The reliability engineer who has spent fifteen years understanding which asset failure modes matter, which operational thresholds define risk, and how maintenance history relates to expected service life — she holds knowledge that no schema can capture and no data engineer can fully replicate. When an AI system needs that knowledge, the standard path is a requirements document, a development cycle, and an approximation.
The approximation is the problem. AI systems grounded in approximate domain knowledge produce results that domain experts look at and say “not quite right” and the cycle of explanation and re-translation begins again. The bottleneck is not engineering capability. It is the gap between the people who understand the business and the systems that are supposed to represent it.
|
The people who understand what enterprise data means are the people who should define it. |
PART ONE
Why business knowledge rarely makes it into AI systems accurately
The translation chain between domain experts and AI systems loses precision at every step. Not through carelessness, but through a structural mismatch between how domain knowledge exists in the heads and working practices of experienced people and how it needs to be expressed for AI systems to use it reliably.
|
The traditional translation path |
Where precision is lost |
|
Domain expert explains requirements in a meeting |
Nuance and conditionality accumulated over years compresses into an hour |
|
Data engineer writes a specification |
The specification captures what was said, not necessarily what was meant |
|
Engineer translates specification into schema and logic |
Technical constraints shape the model; domain exceptions are approximated |
|
AI system is trained or configured on the resulting model |
The AI inherits all previous approximations; errors compound |
|
Domain expert reviews output and finds it “not quite right” |
The cycle begins again. The gap between intent and implementation persists |
The result is AI systems that are technically coherent but operationally imprecise and a cycle of review and revision that is expensive, slow, and frustrating for everyone involved. The domain expert knows what is wrong. The engineer does not have the domain knowledge to fix it accurately. And so the cycle continues.
PART TWO
What changes when domain experts author the model directly
Domain expert authoring of business context collapses the translation chain. When a reliability engineer can define what “critical asset” means directly — specifying which asset classes qualify, which operational conditions apply, and how the classification connects to maintenance scheduling — the AI system receives the domain expert’s model, not an approximation of it.
The no-code tooling is what makes this practically achievable. It is not the story itself, it is the enabler. The story is that business-owned semantic models are more accurate, more trusted, and more maintainable than models built by engineers working from requirements documents. The tools exist now to make domain expert authoring feasible at enterprise scale.
Business-owned context stays current without engineering bottlenecks
The most operationally significant benefit of domain expert authorship is what happens when the business changes. A new regulatory requirement changes a compliance threshold. A product line is discontinued. An asset class is redefined. Under the traditional model, these changes require an engineering ticket, a development cycle, and a deployment window. Under domain expert authorship, the person who understands the change makes it directly in the model.
Once approved and published through the organization’s governance process, the updated definition becomes available to the AI systems, Genie spaces, agents, and analytics workflows that depend on it — without an engineering backlog, without a sprint assignment, and without a deployment window.
|
The business context owned by the business stays aligned with the business. Context maintained by engineering teams on behalf of the business drifts from the moment it is written. |
PART THREE
Who benefits and what changes for them
The value of business-owned context authoring is specific to the domain experts who hold business knowledge. Here is what changes for the roles most commonly involved.
|
Reliability Engineer / Operations Manager Problem: Deep knowledge of asset failure modes and maintenance logic lives in their head and informal documentation. AI maintenance systems built without it produce recommendations that operations teams do not trust. Outcome: Authors the asset classification, failure mode relationships, and maintenance rules directly in the semantic model. AI recommendations align with operational reality. Trust in AI outputs increases. |
|
Compliance Lead / Regulatory Affairs Problem: Precise conditional logic of regulatory requirements is currently approximated by engineers, leading to AI compliance tools that either over-flag or miss edge cases. Outcome: Encodes regulatory logic — including conditions and exceptions — directly into the business-owned semantic model. AI compliance tools operate from their definition, not an approximation of it. |
|
Business Development Director / Commercial Leader Problem: Commercial intelligence about which clients are strategic, which past projects are relevant, and which relationships matter exists as institutional knowledge rather than in systems AI can access. Outcome: Models client relationships, project relevance criteria, and commercial intelligence rules directly. Genie and AI copilots draw from those definitions to surface relevant context for proposals and client conversations. |
|
Category Manager / Supply Chain Planner Problem: Understanding of how promotions interact with inventory, which signals indicate stock-out risk, and how supplier relationships affect replenishment drives better decisions when applied, but is difficult to systematize. Outcome: Defines demand signals, inventory thresholds, and supplier relationship logic in the business-owned model. Planning intelligence becomes systematic and accessible to the whole team. |
PART FOUR
The capabilities that make domain expert authoring real
On the Databricks Lakehouse, Kobai provides three capabilities that together give domain experts the ability to create, govern, and operationalize business-owned context and make it available to every AI consumer on the platform.
Kobai Studio: Domain experts define the semantic model
Studio is the visual authoring environment where domain experts define the business-owned semantic model. Entities, relationships, properties, and business rules are declared using a visual canvas — the same whiteboard thinking that domain experts already use in workshops and planning sessions, formalized into a model that AI systems and analytics tools can consume. The model is stored as a governed object within Unity Catalog. Changes are versioned and auditable. The domain expert owns the model. The platform enforces its use.
Kobai Precursor: AI-assisted mapping of existing data sources
The hardest part of domain expert authorship is not defining what entities mean, it is connecting that definition to the data that already exists across multiple source systems. Kobai Precursor dramatically reduces the effort required for this mapping step while keeping domain experts in control. Precursor uses AI to analyze existing Delta Tables on the Databricks Lakehouse, recommend how source columns map to the entities in the semantic model, and surface those recommendations for domain expert review and approval.
The domain expert applies their knowledge to validate, refine, and approve. The result is a business-owned semantic model that is connected to real data, significantly faster than traditional data engineering approaches and without sacrificing the domain precision that makes the model trustworthy.
Kobai Tower: Explore and validate without SQL
Business users do not just author the model. They also need to explore and validate it to confirm that the business context they have defined looks correct when applied to real data, and to navigate the connected picture their domain represents. Tower provides that exploration capability without requiring SQL skills or technical team support. Business users see the model working against their data, in their language, governed by their Unity Catalog permissions.
PART FIVE
What business-owned context means for Genie and enterprise AI
As organizations deploy Databricks Genie across teams and domains, maintaining consistent business context across Genie spaces becomes the central operational challenge. Business-owned semantic models provide shared business context that can be reused consistently across Genie deployments, so that every team drawing on the same entities and business rules gets answers grounded in the same shared understanding.
The same business-owned model that powers Genie consistency also serves AI agents, AI/BI workflows, and any other AI consumer on the Databricks platform. Domain expert authorship at the model level produces AI consistency at the enterprise level. Every new AI use case connects to the existing business-owned context rather than rebuilding it from scratch.
PART SIX
The commercial case: Why executives should care
Every argument for domain expert authoring of business context has an engineering benefit. But the executive case is different and stronger.
|
When business experts own the context |
The commercial outcome |
|
New AI projects start faster |
Context already exists for adjacent use cases. New initiatives connect to the existing model rather than waiting for a data engineering cycle to build context from scratch. |
|
Business changes reflected in AI immediately |
When strategy shifts, a market changes, or a regulatory requirement updates, the people who understand the change can update the model directly. AI reflects the new reality without an engineering queue. |
|
Less engineering backlog |
Data engineering effort shifts from encoding business logic to higher-value data platform work. The backlog of context-related change requests shrinks because domain experts handle their own domain. |
|
Better AI adoption across the business |
Business users trust AI answers more when they know the AI is reasoning from a business context that people like them defined and validated. Adoption follows trust. |
|
Less duplicated business logic |
Business rules defined once in the shared model are not independently encoded in twenty separate pipelines and dashboards. Maintenance cost and definitional drift both reduce. |
|
Greater confidence in AI answers |
When executives ask “why did the AI recommend this?” The answer traces back to the business context that domain experts own, validate, and maintain. That traceability is what makes AI defensible in the boardroom. |
Databricks + Kobai: Putting business experts in control of business context
Kobai helps organizations put business experts in control of business context. Domain experts author the semantic model using Kobai Studio. Kobai Precursor dramatically reduces the effort required to connect that model to existing Databricks data sources while keeping domain experts in control throughout. Business users explore and validate the model through Tower without SQL dependencies. And every AI consumer on the Databricks platform — Genie, agents, AI/BI, and applications — draws from the same business-owned, governed context.
Graph structures are built directly within Databricks under Unity Catalog governance. The business-owned semantic model is a Unity Catalog object, subject to the same discovery, lineage, and access controls as all other Lakehouse assets. Business ownership of context and platform governance reinforce each other.
|
To explore how Kobai can help your organization put business experts in control of business context on the Databricks Lakehouse, visit kobai.io or contact us at contact@kobai.io. |