From PoC to Production: Lessons from Kobai Implementations Across Manufacturing and Energy

Most enterprise AI projects don’t fail during the PoC. They fail after the PoC succeeds. Technology is rarely the problem. Ownership, governance, trust, and adoption almost always are.

The hardest part of getting AI into production is not the technology. It is ownership, governance, trust, and adoption. These are the problems that a well-designed PoC surfaces early and a poorly designed PoC defers until they become production blockers.

Lesson 1

Start with a real operational question, not a data inventory

The most successful implementations begin with a specific operational question that the business is currently struggling to answer well. Not “we want better data” or “we want AI.” Something specific: “We need to know which supplier delays are correlated with OEE drops on Line 3, and how quickly we can identify the cause when it happens.” That question defines the scope. It becomes the acceptance criterion. If the deployed system answers that question more reliably and more quickly than the current process, the implementation has succeeded.

In manufacturing: starting with OEE and downtime correlation produces a clear, measurable outcome that operations leadership immediately recognizes as valuable — faster root cause identification, reduced unplanned downtime, improved throughput. In energy: asset risk and maintenance scheduling questions land with operations management because the operational impact is direct and visible.

Lesson 2

Test with your messiest data, not your cleanest

The brownfield data reality is not an edge case — it is the standard. Manufacturing and energy organizations have been running ERP, SCADA, maintenance, and quality systems for decades. Schemas have changed. Systems have been replaced. Field names are inconsistent across sites. If the PoC only works on the two data sources with clean, well-documented schemas, the production deployment will encounter the other eighteen sources and struggle.

A useful PoC design principle: identify the worst-quality data source that is essential to answering the target question, and include it in the pilot scope. The automated mapping assistance that handles that source will handle the well-structured sources easily. The reverse is not true.

Lesson 3

Domain expert involvement determines model quality more than engineering effort

The semantic model that connects supply chain, maintenance, asset, and production data is only as good as the business definitions it encodes. Data engineers can build technically correct mappings between schemas. Only the operations manager who has run the plant for fifteen years knows that “complete” in the maintenance system sometimes means the work was done and sometimes means the window closed without the work being completed. That distinction is invisible to the schema and invisible to the engineer. It is obvious to the domain expert.

In every implementation where domain experts participated directly in ontology authoring — rather than reviewing models built by engineers — the resulting model was more accurate, required fewer revisions, and was trusted faster by the teams using it.

Lesson 4

Define ownership before the PoC concludes, not after

The question ‘who owns this after we go live?’ needs to be answered before the PoC concludes. In manufacturing, the model owner is typically a senior reliability or operations engineer who understands both the data and the operational context. In energy, it is often someone from the asset management or planning function. The key characteristic is not technical skill, it is domain authority and organizational credibility. The model owner needs the standing to resolve definitional disputes when different teams have conflicting views of what an entity means. Ownership is not a single person. It is a governance structure: who authors, who reviews, who approves changes. Establishing this during the PoC, rather than after, dramatically accelerates time-to-value in production.

The implementations that moved fastest from PoC to production had executive sponsorship from a business owner, not just IT ownership. When a VP of Operations or a Head of Asset Management has named the production deployment as a business priority, the cross-functional cooperation that ownership requires follows naturally. Without that sponsorship, ownership conversations stall at the team level.

Lesson 5

Narrow scope in the PoC; design for extension from the start

A PoC that attempts to model the entire manufacturing enterprise before delivering value will not finish. Three asset types, two maintenance categories, and one site is a more productive pilot scope than twelve asset types, eight maintenance categories, and five sites. The narrow scope produces faster results and a cleaner model. The design for extension principle means that the initial scope is modelled in a way that makes it straightforward to add the next domain — shared entity definitions, consistent naming conventions, clear relationship typing without requiring the initial work to be rebuilt.

In energy implementations: starting with wind turbine assets and maintenance events, then extending to include weather data and operational schedules, then to grid connection and production forecasts, produces a model that compounds in value with each extension rather than requiring redesign.

Lesson 6

Governance integration determines production longevity

A connected data model that operates outside the organization’s governance perimeter will not survive long in a regulated industry. Access control challenges from the security team, data ownership disputes from the data governance function, and audit questions from compliance teams will all surface in production if the model’s governance is not aligned with the data platform’s governance from the start. When the connected model is built within the Databricks Lakehouse under Unity Catalog governance — inheriting the access controls, lineage, and audit capabilities already in place — these challenges are resolved architecturally rather than managed operationally.

In aerospace and energy: the governance integration requirement is often the deciding factor in build-vs-buy decisions. Teams that have invested in Unity Catalog governance do not want to rebuild those controls in a separate system.

Lesson 7

Genie scales better than expected when the context is right

Several implementations began with Genie as the target interface for business users — particularly in energy and upstream oil and gas, where operations teams need natural language access to asset and maintenance data without requiring SQL skills. The consistent finding: Genie’s performance scales significantly when Databricks Genie spaces are connected to a shared semantic model rather than configured independently per use case. As Genie deployments scale across teams and domains, maintaining consistent business context becomes the primary challenge and a shared connected model is what makes that consistency possible. Teams that set up Genie directly on raw tables hit definitional drift within weeks. Teams that connected Genie to a shared model of assets, maintenance events, and production data sustained accuracy as the user base grew.

The Genie integration path is simpler than most teams expect: establishing the shared context through the Kobai SDK creates a fully contextualised Genie space that draws from governed, connected enterprise data.

Lesson 8

The first production question should be easier than the PoC question

There is a temptation, once a PoC has demonstrated value, to expand the ambition of the first production deployment. The PoC answered three questions; the production deployment should answer thirty. This is how production deployments accumulate scope creep and delay. The better pattern is to make the first production question simpler than the PoC question or the same question applied to a larger dataset or a broader user group. The goal of the first production release is not to demonstrate the full capability of the platform. It is to establish that the platform operates reliably in the production environment, under operational load, with real users. Capability expansion comes in subsequent releases, once operational stability is confirmed.

In manufacturing: the first production release of an OEE and downtime intelligence deployment typically covers one line or one site at full operational load, rather than the entire plant. The multi-site expansion follows once the single-site model is stable.

Lesson 9

The AI adoption curve follows trust, not capability

Business users in manufacturing and energy do not adopt AI tools because they are capable. They adopt them because they trust them. Trust is built through accuracy on questions the user already knows the answer to. An operations manager who asks the system about a downtime event they investigated last week and receives an accurate, traceable answer will return to the system for the next investigation. One inaccurate answer — particularly one that traces back to a definitional error in the semantic model — takes a long time to overcome. The model quality that matters most is not average accuracy across all questions. It is accuracy on the questions the most influential users ask first.

Early adopter selection matters significantly. Identify the operational or engineering leader who is most data-curious and whose endorsement will carry weight with their peers. Design the initial model to answer their questions well. Their advocacy will accelerate adoption faster than any training programme.

Lesson 10

Executive sponsorship is not a nice-to-have. It is the difference.

Across every implementation that reached production on schedule, there was a business owner at the executive level who had named the initiative as an operational priority. Not an IT owner. Not a data team initiative. A VP of Operations, a Head of Asset Management, a Chief Operating Officer who could say: ‘this is one of our three operational priorities for the year, and I need it in production.’ When that sponsorship exists, resourcing decisions are faster, cross-functional cooperation is easier, and the ownership conversations that otherwise stall at the team level get resolved quickly. When it does not exist, technically successful PoCs accumulate in the backlog of ‘approved but not yet prioritized’ initiatives.

The practical implication for data teams: if you cannot identify a business executive who will publicly name the production deployment as a business priority before the PoC begins, address that gap before you start the PoC. A PoC without a business sponsor is likely to succeed technically and stall organizationally.

Phase

What it looks like when it works

PoC scope

One operational question. One or two data domains. Real data, including at least one messy source. Domain expert involvement from day one. Two to four weeks.

PoC success criteria

Can the system answer the target question more reliably and more quickly than the current process? If yes, the PoC has succeeded. Capability demonstration is a secondary criterion.

Production planning

Ownership structure defined. Governance integration confirmed. Production data domains mapped. Extension roadmap drafted. First production question scoped before the PoC concludes.

First production release

Same or simpler scope than the PoC. One site or one line before the enterprise. Operational load tested. Real users from the target team, not just the implementation team.

Extension cadence

One new domain every four to eight weeks, each driven by a specific operational question. Each extension adds value to existing queries through network effects. Model governance reviewed at each extension milestone.

The energy implementation reference

A global wind and solar energy operator used this pattern to build a connected operational model on the Databricks Lakehouse: starting with asset and maintenance data, extending to production forecasting and weather correlation, then to workforce scheduling and parts inventory. The integration time for each new data domain was materially shorter than conventional integration approaches, because the semantic mapping tooling accelerated the brownfield connection process significantly. The deployment is now used daily by operations, maintenance planning, and commercial teams with AI-assisted answers grounded in the shared connected model.

If you are at or approaching the PoC stage for a connected data or enterprise AI initiative on Databricks, speak with us. Contact us at contact@kobai.io or visit kobai.io to explore the Semantic Graph Pilot.