"Discipline isn't a constraint, it's the infrastructure of performance." That's the line Stéphane Dicostanzo, CEO, and Valentin, Koddex's co-founders, opened their Tech For Industry Show session with, dedicated to a still little-known concept already practiced by the best engineering teams: the Engineering Operating System. A topic at the crossroads of PLM, data quality and agentic AI — and a direct competitiveness issue for the industry of tomorrow.

The world of hardware engineering doesn't look like the rest of digital technology: an industrial product involves tens of thousands of components, thousands of specifications and hundreds of regulatory requirements, all linked together in an endless web of dependencies. Changing a single element requires an impact analysis across the entire chain — and an error discovered after production can be critical.

To manage this complexity, companies rely on large systems of record — PLM, ERP, QMS — between which an unstructured web of Excel files and collaboration tools has grown up. The result: duplicated, scattered data, considerable reconciliation effort, and a striking finding shared during the session: half the cost of a project is absorbed by its own structure — checking data, tracking validations and handling self-generated non-conformities.

The Engineering OS rests on three layers that are too often disconnected: processes (who does what, why, how — with formalized inputs, outputs and responsibilities); the data model (every business action needs a digital equivalent designed to serve the process, not inherited by default from a tool); and operational data, the data actually captured in the field.

The speakers' observation, shaped by their own experience (notably at Google for Valentin): the best-performing teams have — without always theorizing it — anchored these three layers together. It becomes impossible to change a process without evolving its data model; above all, impossible to distort operational data downstream without seeing its overall impact. The benefits: lower alignment costs (fewer sync meetings, fewer manual checks), reduced non-quality, better onboarding, and restored traceability.

Implementation follows four steps: defining business processes, modeling the data related to them, connecting them together — the step most often neglected — and forcing data instantiation based on the defined models.

A concrete case shared during the session, from a robotics client: defining what "a component" means for the company. R&D, industrialization, deployment and maintenance each have their own attributes — sometimes the same attribute with two different meanings. The Engineering OS lays all of this out, then creates semantic links: a component implements a requirement, a requirement is verified by a test case. Step by step, this builds a knowledge graph of all the company's objects: a technician working at a customer site can access the product's full history — manufacturing, software revision, specifications — and an engineer replacing a screw instantly sees the impact analysis across the entire product.

Two approaches dominate today: templates as structure (Word/Excel document catalogs, gates and review meetings — clear formalism but enormous effort) and after-the-fact supervision (BI and control towers — but the error is caught too late to be fixed at the source). The Engineering OS combines both, in the manner of a software compiler: data is structured at the point of entry and its consistency continuously checked across the entire chain. And as in software, the model is versioned: when a new regulation requires, for example, reporting a product's carbon footprint, it's enough to create a new version of the data model and semantic links — with a "cascading compilation" that guarantees nothing breaks elsewhere.

Tomorrow, it won't just be humans entering data, but AI agents. Yet connecting an agent to unstructured documents requires sifting through enormous volumes of data to extract information that may well be wrong: the wider the context, the greater the risk of statistical hallucination — and the more tokens and energy are wasted.

Conversely, data already structured as a knowledge graph gives the agent a map of the links: it targets a narrow context, hallucinates less and consumes less. "Extract + questions" agent POCs demonstrate value but don't scale, either across the enterprise or over time. The Engineering Operating System, by design, naturally forces teams to build, populate and evolve this graph — benefiting today's operations teams as much as tomorrow's agentic AI.

The speakers didn't just theorize the concept — they also built Koddex, a dedicated platform: it knows the map of expected data, validates the impact of changes in real time, connects to enterprise systems of record (PLM, ERP), and natively tracks links, history and revisions to maintain consistency over time.

Watch the full session, along with the other Tech For Industry Show replays, on our dedicated page.