A global energy operator significantly reduced data integration time, improved data quality, and enabled hundreds of business users to explore connected operational data without SQL. Most significantly, their AI assistant became the first in the organization to be accepted by the compliance team for use in a regulated operational workflow.
One of the world’s largest energy companies reduced data integration time by up to 40%, reported a significant improvement in data quality, and enabled more than 700 business users to explore connected operational data without writing SQL. Most significantly — and the outcome that mattered most to the organization — their AI assistant became the first AI system in the company’s history to be accepted by the compliance team for use in a regulated operational workflow.
These are customer-reported outcomes from a deployment on the Databricks Lakehouse. This is the story of how they were achieved.
|
40% Integration time reduction Customer-reported |
35% Data quality improvement Customer-reported |
700+ Business users on Tower No SQL required |
|
For the first time in this organization’s history, an AI system was accepted by the compliance team for use in a regulated operational workflow. |
Operational questions that required days to answer
Consider a question that any operations team in a large energy company might need to answer on a given day:
|
“Can we continue operating Pump A after this vibration anomaly if maintenance is scheduled for next week and the inspection certificate expires tomorrow?” Answering that question requires connecting sensor data from the operational historian, the maintenance schedule from the CMMS, the inspection record from the engineering document system, and the regulatory threshold from the compliance framework. Four systems. Four schemas. No shared language between them. |
Before this deployment, that question took hours or days. The data existed across more than 40 Delta Tables spanning operational, engineering, regulatory, and supply chain domains. Each had been built and maintained independently. Entity identifiers did not align between systems. The relationship between a sensor reading and the inspection record for the same physical component had to be reconstructed manually every time it was needed.
AI initiatives built within individual domains performed well. But the moment a question crossed a domain boundary — connecting operational data with maintenance history, regulatory requirements, and workforce certifications simultaneously — the AI system could not answer it reliably. And without traceable lineage from AI output to source data, the compliance team could not validate any AI recommendation for use in regulated workflows.
|
The situation before |
The operational impact |
|
40+ Delta Tables with no shared entity model |
Every cross-domain question required bespoke data assembly by engineering teams |
|
AI copilots working within domains only |
Cross-domain operational intelligence remained inaccessible to AI |
|
No governed lineage from AI output to source data |
Compliance team could not validate AI recommendations for regulated use |
|
700+ potential users locked behind SQL requirements |
Operational intelligence required analyst mediation to access |
Building shared context on the Databricks Lakehouse
The deployment began with a scoping exercise: identifying the 3–5 cross-domain operational questions that mattered most to the business, and working backward to the data connections required to answer them. Those questions became the acceptance criteria for the entire project.
Mapping 40+ Delta Tables to a shared operational model
The first task was connecting data from systems that had been built independently over decades. AI-assisted mapping tooling analysed the existing Delta Tables and recommended how to source data across the operational historian, CMMS, ERP, and engineering systems connected to a shared entity model. Domain experts — maintenance engineers, operations managers, and compliance leads — reviewed and approved the recommendations rather than writing the mappings from scratch.
The time required to connect 40+ data sources was significantly shorter than conventional integration approaches. This accelerated mapping is what the customer reported as a reduction in integration time of up to 40%.
Domain experts defined the model, not data engineers
The decision that shaped everything else was who would author and maintain the shared context model. Rather than encoding domain knowledge into pipeline logic maintained by data engineers, the organization gave maintenance engineers, operations managers, and compliance leads a no-code visual environment to define and maintain the entities, relationships, and business rules that governed their domain.
The result was a model that reflected how the organization actually operated, maintained by the people who understood it best. When a regulatory threshold changed, the compliance lead updated the relevant rule. When a new asset class was introduced, the maintenance engineer extended the model. Changes became available to all AI consumers once approved through the organization’s governance process.
Built directly within Databricks — no separate platform
The shared context model was built directly within the Databricks Lakehouse under Unity Catalog governance. Unity Catalog access controls applied automatically to every query through the model. When a user or AI system queried through the shared context, they received data bound by their Unity Catalog permissions. Governance was inherited from the platform, not configured separately.
What changed operationally
The pump question answered in minutes, not days
The operational question that previously required assembling context from four systems over hours or days became answerable directly. An operations team member could ask “can we continue operating Pump A?” and receive an answer that drew simultaneously from sensor data, maintenance records, inspection certificates, and regulatory thresholds — with traceable lineage back to each source. The data had not moved. What changed was the ability to traverse the relationships between it in real time.
AI accepted by compliance — a first for the organization
The outcome that most distinguished this deployment was not an efficiency metric. It was that the AI assistant powered by the shared context model became the first AI system in the organization’s history to be accepted by the compliance team for use in a regulated operational workflow.
The reason was traceability. Every AI answer carried lineage back through the shared context model to the specific data records and business rules that produced it. The compliance team could inspect how a recommendation was made, which entities were involved, and which regulatory thresholds applied. The AI did not just give an answer. It gave an answer that could be validated, challenged, and defended.
|
Why this matters beyond this deployment AI systems that cannot explain their reasoning will not be trusted for consequential decisions in regulated industries. This deployment demonstrates that traceable AI — grounded in a governed shared context model — can achieve compliance acceptance that AI built on opaque pipeline logic cannot. That is a meaningful shift for any energy, industrial, or regulated enterprise considering AI for operational workflows. |
700+ business users accessing intelligence without SQL
Persona-specific views for operations, maintenance, regulatory, and supply chain teams gave more than 700 business users access to cross-domain operational intelligence governed by their Unity Catalog permissions. Insights that previously required a data engineering ticket became self-service queries. Operational decisions that had depended on analyst intermediation became direct.
Databricks platform investment increased, not diverted
Because the shared context model was built directly within the Databricks Lakehouse — executing on Databricks compute, governed by Unity Catalog, stored as Delta tables — every semantic query continued to execute on Databricks compute. The customer’s investment in the Databricks platform increased rather than being diverted to a separate graph platform. For Databricks field teams, this is a meaningful distinction: Kobai extends what Databricks already does rather than routing workloads elsewhere.
Three lessons from this deployment
|
Lesson |
What it means |
|
Start with the questions, not the data |
The 3–5 target questions defined at the outset became the acceptance criteria for the entire deployment. Every design decision was evaluated against whether it helped answer those questions. This focus prevented scope creep and kept the project on a timeline the business could support. |
|
Domain experts must own the model |
The decision to give compliance leads, maintenance engineers, and operations managers direct authoring tools was the primary reason the model reflected operational reality. Domain expert ownership is not a nice-to-have. It is what makes shared context trustworthy at scale. |
|
Governance inherited is governance sustained |
Building within Unity Catalog meant the access policies, lineage, and audit capabilities already in place extended automatically to every semantic query. There was no parallel governance configuration to maintain and no governance drift over time. |
Databricks + Kobai: Semantic context for energy operations
Databricks provides the Data Intelligence Platform. Kobai helps enterprises create, govern, and operationalize the shared business context that makes every AI capability on that platform more consistent, more trustworthy, and more useful.
To explore how Databricks + Kobai can help your energy or industrial organization build shared context on the Lakehouse, visit kobai.io or contact us at contact@kobai.io. The Semantic Graph Pilot on the Databricks Marketplace provides a structured 2–4 week path to demonstrating this in your own environment.
|
The biggest lesson from this deployment wasn’t that another technology was added. It was that once a shared business context existed, every AI capability on Databricks became more useful, more trusted, and easier to scale. |