Software & Tools
The modern PLM tech stack, layer by layer, and where Koddex fits
An industrial company does not run on one engineering tool. It runs on a stack: from the engineer's CAD model to the work order on the shop floor, each layer has its own job, its own vendors and its own data.
The layer model below was popularised by Anup Karumanchi of PLM Coach. We redrew it, and added the layer Koddex occupies.
KoddexDesigning the product: CAD, simulation, PDM
Authoring (CAD) is where engineers create 3D models and drawings: SOLIDWORKS, CATIA, Siemens NX, Creo, Inventor, Onshape. It owns the geometry, and nothing else.
Simulation (CAE) tests designs virtually before anything is built: Ansys, Abaqus, Simcenter, COMSOL. It is optional for some products and essential for others, from structures to thermal and electromagnetics.
Data management (PDM) vaults the CAD files, handles check-in and check-out, and keeps versions: Autodesk Vault, SOLIDWORKS PDM, Windchill PDMLink. Often it lives inside the PLM.
Managing the product: the PLM platform
PLM manages the product definition over its lifecycle: BOMs, change control, workflows. The large platforms are Teamcenter, Windchill and 3DEXPERIENCE; Aras Innovator is the open-architecture option; Arena and Propel are cloud PLMs, popular with younger hardware companies.
PLM is the system of record for the manufacturable definition: what the part is, which revision is released, which ECO changed it.
Moving data and building the product: integration, ERP, MES
The integration layer moves items, BOMs and changes between systems: MuleSoft, Boomi, Apache Kafka, or direct REST and OSLC APIs.
ERP runs planning, inventory, purchasing and cost: SAP S/4HANA, Oracle ERP, Dynamics 365, Infor, Epicor.
MES executes work orders on the shop floor and records the as-built: Siemens Opcenter, DELMIA Apriso, Plex, AVEVA MES.
Infrastructure is where it all runs: AWS, Microsoft Azure, Google Cloud, or on premises.
What the stack still leaves open
Each layer is built around its own object: the geometry, the file, the part, the order. Each does its job well. But the questions engineering teams ask every week cross layers.
Which requirement does this part satisfy, and which test proves it? What does this change touch across the CAD, the BOM, the tests and the units already delivered? Is the product compliant today, and where is the evidence? Which robots or doors carry the faulty lot a supplier just flagged?
No layer answers them alone. Requirements often sit in documents and spreadsheets outside the stack; test results in another tool; compliance evidence in shared folders. The links between them are rebuilt by hand, in meetings and in spreadsheets, usually by the one person who knows where everything is.
That manual work has a measurable cost. In a work-sampling study of 78 design engineers, information behaviours, searching for, receiving and passing on information, took about 56% of working time.
And the later a broken link is found, the more it costs. NASA's study of error cost escalation puts the cost of fixing a requirements error at 21 to 78 times its initial cost once it reaches integration and test.
Relative cost of fixing a requirements error
The integration layer moves data between systems. It does not hold the reasoning: why a value is what it is, what depends on it, and what a change will break.
Where Koddex fits
Koddex adds the missing layer: an engineering knowledge layer that runs alongside every layer from CAD to integration, and feeds the ERP and the MES below.
It holds requirements, BOM, tests, decisions and documents as linked data in a model you define with your own vocabulary, and it computes on it: mass and cost roll-ups, requirement and test coverage, the impact of a change before it is approved.
It does not replace the layers around it. CAD stays in CAD, the released part in the PLM, purchasing in the ERP, the as-built in the MES. Koddex reads what each one knows about the product, and adds what none of them holds: the links.
Take one change. A supplier moves a bracket to a new alloy. The CAD model gets a new revision, the PLM an ECO, the ERP a new supplier reference. In Koddex, the same change shows at once the mass requirement the bracket serves, the fatigue test that no longer proves it, the two product variants that use it and the units already delivered. The engineer sees the impact before approving, instead of discovering it at integration.
| Layer | Koddex reads | Koddex adds |
|---|---|---|
| CAD and PDM | Parts, drawings and models attached to the items they define | Requirements and impacts on each part |
| PLM | Items, revisions, ECOs | Requirement and test coverage, impact before approval |
| ERP | Shared item IDs, suppliers, costs, serial numbers | The engineering definition each unit is built to |
| MES | As-built records per serial number | Which units a change or a faulty lot reaches |
| Git, Jira, docs | Firmware releases, tickets, specifications | Links to the hardware and requirements they concern |
Koddex connects through its REST and GraphQL API, and exposes an MCP server so AI agents, Koddex's own or yours, can read and write in the graph within the rights they are given. They work on branches; an engineer approves every result before it enters the baseline.
At the infrastructure layer, Koddex is hosted in the European Union, in the AWS Europe (Ireland) region.
Across the pyramid, not just across tools
The stack is horizontal: tools side by side, each covering a stage of the product's life. A company is also vertical. The ISA-95 standard already separates business planning (ERP, level 4) from manufacturing operations (MES, level 3) because each level asks different questions. Engineering data has to reach all of them.
Leadership wants to know where the programme stands and whether the product is compliant. Engineering managers want every team on the same process, with owners and deliverables. Engineers want the impact of a change before they approve it. Production and quality need the right revision for each build, and the evidence for each audit. Suppliers and partners need a view limited to what they work on.
In most companies, each level gets its own extract: a slide deck for leadership, a spreadsheet for the manager, a CSV export for the supplier. The extracts drift apart the day they are made.
Koddex is one set of data read at every level, with access rights set on each item. Nobody rebuilds a report, and nobody works from a stale copy.
Koddex- Leadership & programmesProgramme status and compliance computed, not reported
- Engineering managersTemplates, a process from A to Z, owners and dashboards
- EngineersRequirements, BOM, tests and the impact of each change
- Production & qualityAs-built per serial number, FAI and audit evidence
- Partners & suppliersScoped access to the items they work on
Why AI agents need this layer
AI is arriving in every layer of the stack: copilots in CAD, assistants in PLM, bots in the ERP. Each sees only its own layer. Ask one what a change will break, and it can only answer if the links between requirement, part, test and unit exist somewhere it can read.
The Model Context Protocol is the open standard that gives agents structured context. Koddex exposes its graph through an MCP server, with service accounts and access tags, so Claude, ChatGPT or your own agents read the same linked context as your engineers, and nothing outside their scope.
The agents work the way developers already work with code. A trigger, a CAD revision, a software release, a supplier document, or a task you assign, starts the job. The agent reads what it needs, runs roll-ups in sandboxed Python, and drafts the change on a branch. An engineer reviews it like a pull request. Only an approved change enters the baseline, and every action stays in the item's activity.
- 1TriggerA CAD revision, a software release, a supplier PDF, or a task you assign
- 2ContextThe agent reads the linked items it needs through MCP, within its access scope
- 3Work on a branchIt runs roll-ups in sandboxed Python, updates items and drafts the change
- 4Engineer reviewAn engineer reviews the result like a pull request, and approves or asks for changes
- 5Baseline & logThe approved change enters the baseline; every action stays in the item's activity
The point is not to let AI change the product on its own. It is to let it prepare the work, extract requirements from a specification, draft an impact analysis, compile evidence for an audit, so engineers spend their time on decisions.
What it is worth
At our reference customer, Exotec, which runs Koddex with more than 1,000 licences and 20 partner organisations, a change impact analysis went from two weeks of meetings and spreadsheets to one day, and finding the right information from 45 minutes to 10 seconds, after a year in use.
On guided deployments, teams have cut time to market by up to 30% and time spent on repetitive engineering tasks by up to 50%, and gathered audit evidence in under an hour instead of three weeks. These are ranges observed on deployments, not an audited average.
Regulation points the same way. The US Department of Defense's Digital Engineering Strategy calls for an authoritative source of truth across a system's lifecycle. In Europe, the Machinery Regulation 2023/1230 applies from 20 January 2027 and asks manufacturers for a technical file that shows how each safety requirement is met. Both assume links that most stacks still keep in spreadsheets.
Two typical setups
A company moving from projects to products. It has CAD and maybe a PDM, a light ERP, and a lot of spreadsheets. A heavy PLM is on the horizon but not yet justified. Here Koddex is the backbone: one model for requirements, BOM, tests and changes, connected to the CAD and the ERP, in weeks rather than months. If a PLM comes later, Koddex connects to it.
An enterprise with Teamcenter, Windchill or 3DEXPERIENCE. The PLM stays the system of record. Koddex sits beside it and links the PLM items to the requirements, tests and compliance evidence that live elsewhere, so impact analysis and audits stop depending on spreadsheets. Nothing is ripped out.
Choosing your stack
Three questions help place each tool. Which object does it own? Where does that object's truth live? And which cross-layer questions does your team still answer by hand?
The last one is where the hours go. It is also where AI agents need structured, linked context to help rather than guess.
The stack described here is not going away. What changes is the layer that ties it together.
