Large language models (LLMs) are impressively flexible. In engineering, however, this flexibility quickly runs up against a simple limitation: AI-generated answers may sound plausible, but a plausible answer is not necessarily a physically or technically correct answer. LLMs can hallucinate, and their outputs are not guaranteed to be correct or repeatable. A language model infers relationships from its training data, but it does not automatically have a clear understanding of how a specific machine or plant is built, which physical relationships apply, or what a particular signal actually means for the plant or its operator. For industrial applications such as engineering analysis, this is precisely the problem. An analysis should not depend on whether a model correctly interprets a physical quantity, guesses a relationship from context, or reaches a slightly different conclusion the next time it is asked. Technical meaning, boundary conditions and calculation procedures must be clearly defined, and the corresponding rules must be followed.
Giving AI technical context
That is why we at eSENSEial have developed a framework that connects world models of technical systems with AI-powered large language models. The world model explicitly describes the technical knowledge base: Which components exist in a plant or machine? Which measured quantities are associated with them? What do they mean? In which units are they expressed? What relationships exist between them? Which definitions, boundary conditions and methods apply to a particular analysis or set of measurements? This means the AI does not have to infer these relationships from documents, variable names or a prompt each time. Instead, it works within an explicitly defined technical context.
Technical meaning independent of implementation
A central principle of the framework is the separation of three layers:
- technical meaning,
- analytical objectives, and
- implementation.
This makes it possible, for example, to define unambiguously in advance which measured quantities will be used, what their physical meaning is, and which analyses should be performed based on them — regardless of whether the actual implementation is subsequently written in Python, Rust, C, C++ or MATLAB. The underlying engineering definition remains the same.
Reproducibility instead of a black box
This separation into distinct layers is also essential for repeatability.
AI can, for example, help set up an analysis, call suitable tools or make existing knowledge accessible. Wherever possible, calculations are implemented as actual, repeatable computational steps based on defined formulas and rules — rather than having the language model reinterpret the same task on every run. The required analysis steps are structured as a hierarchical graph of instructions: dependencies and execution order are formally defined, so there is no need to find a new path to the same goal each time. This builds repeatability and traceability into the technical workflow. Our framework therefore ensures that the underlying technical meaning is no longer left to the language model’s free interpretation, establishing a foundation for unambiguous and reproducible results.
Traceable from result to measurement
In our view, knowing the result alone is not enough, particularly when AI is involved. Our framework therefore also supports traceability and provenance. This means that an analysis result can be traced directly back to its foundations. The origin of measurement data, the project context, technical definitions, methods and parameters are transparently documented within the framework. This makes it possible to understand how a result was obtained — an essential prerequisite when AI is to be used not just experimentally, but as part of engineering processes. This is a key distinction between an AI system that generates a technically plausible answer and a tool that can be integrated into a reproducible engineering workflow.
Preserving engineering knowledge — and making it usable
Another aspect was particularly important to us during development. In engineering organisations, a great deal of valuable knowledge is embedded in existing programs and scripts — and often simply in the experience of individual engineers. Our approach allows this knowledge to be progressively translated into explicit, formal and machine-readable definitions. This creates a body of technical knowledge that is not tied to a single person, software application or programming language. It can be reused, transferred to other applications and systematically extended.
AI as a tool for engineering knowledge
Our aim is not to replace engineering knowledge with AI. Quite the opposite. We are creating a structure that makes existing engineering knowledge unambiguously accessible and usable for modern AI systems. The strength of large language models — their flexibility — is preserved. Technical meaning, physical context and traceability, however, are not simply left to the model. This means AI in engineering does not have to guess how to interpret a system. It can work with a knowledge base that already describes exactly that.