Ontological Engine for Engineering

Many Erre Quadro clients have asked us for a deeper analysis of the key points highlighted by Satya Nadella during the World Economic Forum 2026.
The central concept expressed by Microsoft’s CEO concerns corporate technological sovereignty in an era in which artificial intelligence models are becoming a commodity.

One of the key terms identified is Context Engineering. Although the term may sound new, Nadella uses it to describe the evolution of concepts we have previously known as:

• Knowledge Graphs
• Ontologies (a term now heavily reused by Palantir to promote its Foundry platform).

But what are ontologies or knowledge graphs, and how can data control and context engineering become the new pillars of competitiveness?

Turning Complexity into Knowledge

Product and process engineering still face a critical challenge today: the complexity of information and its interconnections. Technical specifications, test reports, CAD drawings, and simulations contain valuable data, but they often remain isolated or difficult to interpret as a whole. This issue becomes even more evident when working with technologically complex systems such as industrial machinery, electronic devices, or digital products that interact with both physical and software components. Understanding the relationships among requirements, design parameters, and physical constraints is therefore essential to avoid errors, optimize design, and ensure safety and reliability.

In this context, the role of engineering ontologies emerges, enabling technical knowledge to be structured in an explicit and verifiable way. Designers no longer have to simply collect data; they must be able to query it as a coherent system: which components contribute to a given function? Which constraints could generate a failure? How are materials, geometry, and expected performance connected?

Why LLMs Do Not Work in Engineering

Large Language Models have made language easier to query and summarize, but they show significant limitations when applied to technical domains. They do not truly understand what they produce; they work through statistical correlations, much like a student who has memorized material without understanding it. This leads to hallucinations—convincing answers that lack solid foundations—an unacceptable risk in engineering contexts.

Engineering does not rely on broad statistical bases but on functions, constraints, domain rules, and causal relationships—elements these models are unable to interpret. Responses can vary without any reconstructable logic, and weaker signals, often strategically important, are easily lost. Added to this is the issue of cost: developing and maintaining advanced LLM-based systems is expensive, and the economic benefits are not always clear, making many projects difficult to sustain over time… and indeed, they often fail.

Deterministic AI for Engineering

The solution lies in teaching artificial intelligence the logics that govern engineering. To address this challenge, Erre Quadro has developed an ontological engine trained to populate a multi-domain ontology capable of transforming technical specifications, test reports, and CAD drawings (as well as MES or CMMS tables) into an actionable knowledge graph.

This engine does not rely solely on statistical reasoning; instead, it identifies deep semantic entities typical of engineering, such as functional requirements, physical effects, properties, failure mechanisms, and state parameters. These entities are then connected through logical, axiomatic (based on Nam Suh’s Axiomatic Design), and topological relationships (where components are located in space and how they interface with each other), creating an engineering knowledge graph that allows us to understand not only what a document is about, but how the extracted entities interact and what implications they have for overall system behavior.

What an Engineering Ontology Looks Like

The ontology is built to cover the entire design lifecycle, extending to production, service, and eventual end-of-life. Examples of its entities include:

• Intent entities, encompassing design goals and requirements
• Behavior entities, describing functions and physical effects
• Realization entities, representing components, structures, and material properties
• Risk management entities, identifying failure causes, regulatory constraints, and design criticalities

In terms of relationships, the engine goes far beyond simple linguistic hierarchies (hypernymy/hyponymy). Among the most relevant examples are:

1. Axiomatic Relationships: the direct link between Functional Requirements (FR) and Design Parameters (DP), enabling verification of whether a design is coupled or redundant according to the equation [FR] = [A][DP], where [A] is Nam Suh’s axiomatic matrix.
2. Meronymic Relationships: hierarchical “part-of” decompositions (e.g., [screw] ⊂ [fastening assembly] ⊂ [housing]) or material meronymy (such as the [glass] of a window, the [bronze] of a bushing, etc.).
3. Causal Relationships: chains linking a Physical Effect to a Behavior and ultimately to a possible Failure Mode.

Entities and relationships work together to make design dependencies explicit and to structurally assess completeness, consistency, coupling, and potential risks throughout the entire product lifecycle and across all business functions.

Turning Technical Data into Design Knowledge

A core feature of our engine is its ability to operate directly on technical documents, regardless of whether they are MES tables, maintenance interventions described in a CMMS, customer purchasing data recorded in a CRM, PDFs of technical standards, or CAD drawings. The system can identify geometric entities (axes of symmetry, centers of mass, tangency points, and reference planes), reconstruct topological relationships and constraints such as coaxiality or contact interfaces, and recognize quantitative and qualitative properties like surface roughness and flatness.

If the information is available in CAD, the engine can link it to manufacturing cycles, tests, and measurements to be performed on the component, as well as to FMECA data stored in quality department repositories.

By connecting geometry, function, and performance, it becomes possible to identify design criticalities and prevent issues before they translate into costly production or maintenance errors. This is the case when field evidence is captured during production and automatically fed back into R&D or design departments. Let’s consider an example.

Take the design of a hydraulic pump. A traditional system might simply detect the word “shaft” without distinguishing its technical context. The ontological engine, instead, identifies the specific entity “drive shaft” [structure], links it to the torque transmission function, detects constraints such as clearance with the bushing, and flags a potential overheating [failure] if surface roughness does not meet specifications. This approach makes it possible to anticipate critical issues, transforming technical data into a truly effective decision-support tool.

The Advantages of an Ontological Engine

Erre Quadro’s ontological engine is designed to be lean, fast, and deterministic. Unlike generative models, it does not require large computational resources and produces reliable, consistent results at scale. It uses technical context to disambiguate terms, can be deployed directly on the client’s premises, and can quickly adapt to new projects or different industries.

In this way, it delivers precise, actionable information in short timeframes, integrates seamlessly with corporate workflows without adding complexity, and transforms scattered, fragmented data into actionable knowledge.

Equally important is its ability to rapidly adapt to the company’s own technical knowledge—absorbing into its operating logic the very Context Engineering that represents the true core of corporate technological sovereignty described by Satya Nadella at the World Economic Forum 2026.