Software & Tools
Koddex does not replace your PLM or your requirements tool. It connects what they leave apart.
The gap between the requirement and the BOM
A systems engineer tightens a mass requirement. A hardware engineer moves a bracket to a new supplier. The two decisions collide, and no tool in the company knows it.
The requirements tool sees the requirement. The PLM sees the part. The link between them lives in a spreadsheet, maintained by hand, often by a single person who knows where everything is.
That gap is expensive. NASA's study of error cost escalation puts the cost of fixing a requirements error at 1 unit in the requirements phase, 3 to 8 units in design, 7 to 16 in manufacturing and 21 to 78 at integration and test. Every week a broken link stays invisible pushes the fix further right on that curve.
Relative cost of fixing a requirements error
The gap is also slow. A work-sampling study of 78 design engineers found that information behaviours, searching for, receiving and passing on information, took up about 56% of their working time. Much of it is spent rebuilding links that no tool holds.
Koddex was built for this gap. Not to replace the tools around it.
What your tools do well, and where they stop
PLM is the system of record for the manufacturable definition: CAD geometry, part lifecycle, formal ECOs, effectivity, supplier data. Windchill, Teamcenter and 3DEXPERIENCE have done this for twenty years. Nobody should rip them out.
Requirements management tools such as DOORS, Jama Connect or Polarion structure the specification, manage baselines and track test coverage. They are often the contractual reference with the customer or the certification authority.
ALM extends that logic to software: code, continuous integration, defects, test runs. MBSE tools such as Capella or Cameo model the architecture and its behaviour.
Their shared limit is structural. Each one is built around its own central object: the requirement, the ticket, the model element, the part. None of them computes across all of them.
A mass requirement does not know what the assembly weighs. A BOM does not know which tests it invalidates when a component changes. An architecture model does not know the cost of the parts allocated to it.
Bridges exist, mostly as point-to-point connectors or OSLC links. They move data from one tool to another. They do not put it into a model that can reason about it, so the reasoning still happens in spreadsheets and meetings.
| Requirements tool | ALM | MBSE | PLM | Koddex | |
|---|---|---|---|---|---|
| Structured requirements and baselines | Core | Core | Partial | Partial | Core |
| Code, builds and defects | No | Core | No | No | Linked |
| Architecture models | No | No | Core | No | Linked |
| CAD geometry and released parts | No | No | No | Core | Linked |
| Formal ECO and effectivity | No | No | No | Core | Linked |
| Mass and cost roll-up against requirements | No | No | Partial | Partial | Core |
| Impact analysis across requirement, part and test | Partial | Partial | Partial | Partial | Core |
Koddex: the layer that links and computes
Koddex holds the product definition as a graph. Requirements, BOM, tests, variants, decisions and documents are linked objects, in a data model you define with your own vocabulary. When your process changes, you update the model and your existing data follows.
On that graph, Koddex computes: mass and cost roll-ups, requirement coverage, and the impact of a change on everything that depends on it. A requirement knows which parts satisfy it. A part knows which requirements and tests it touches.
The US Department of Defense made an "enduring, authoritative source of truth" one of the five goals of its Digital Engineering Strategy. In practice, that truth is spread across several systems. Koddex does not ask you to move it all into one. It makes the links between them authoritative, versioned and auditable.
AI agents work on this graph. They structure an incoming specification, update a mass budget, flag the tests to rerun and draft a change request. Every result waits for an engineer's approval before it enters the baseline, and every action is logged with who made it, person or agent.
Each user, partner and agent sees only what its access rights allow. Customer data is hosted in the European Union.
For systems engineers: from specification to milestone review
Systems engineers work where PLM is not yet useful: when the product exists only as requirements, architecture and allocations. Koddex comes in at four moments.
When the customer specification arrives. It is imported in minutes, broken down into linked requirements and allocated to subsystems. Agents propose the structure; your engineers review and correct it. No more copy-paste between a PDF and a spreadsheet.
When the design takes shape. Each requirement is linked to the parts that satisfy it and the tests that verify it. Coverage gaps are visible as they appear, not at the next review.
When a requirement changes. Koddex shows at once which subsystems, components, variants and tests are affected. At our reference customer, an impact analysis takes one day instead of two weeks of meetings and spreadsheets. That is the difference between catching an error in design and catching it at integration, where NASA's figures put the cost of a fix at 21 to 78 units instead of 3 to 8.
At the milestone review. The baseline is frozen and can be compared with any previous version. The requirement, design and test traceability matrix is exported, not rebuilt by hand.
Your requirements tool does not have to go. If it holds the contractual reference, it stays there. Koddex synchronises with it and adds the link to the design that it cannot carry.
For hardware engineers: between CAD and release
Hardware engineers live in CAD and PLM. Koddex does not touch their geometry. It comes in at the moments where CAD cannot answer the right questions.
During concept and preliminary design. Choices are not frozen, and the BOM changes every week. At our reference customer, building a complex product structure takes about 15 minutes in Koddex, against two to three days in Excel. Mass and cost are computed continuously, subassembly by subassembly, against the budgets set by the requirements.
When a component changes. A bracket moves to supplier B and gains 180 g. Koddex recomputes the assembly mass, flags the mass budget requirement now at risk and the tests to rerun, then drafts the change request on a branch. The engineer decides. The formal ECO stays in PLM, where it belongs.
When variants multiply. A change to a shared module shows its effect on every variant that uses it, before anyone approves it.
Over the life of the programme. The reason behind a design choice stays attached to the part it concerns. It does not live in an email thread or in the head of a colleague who has since left. Finding the right information takes seconds, instead of the 45 minutes our reference customer used to spend across several tools.
How Koddex fits into your stack
Each system keeps what it does best. Koddex connects through its API (integrations), usually via your IT team's existing middleware, and every integration is logged with its own audit trail.
| Data | Stays master in | What Koddex adds |
|---|---|---|
| CAD geometry and drawings | CAD / PLM | Links each part to its requirements, tests and decisions |
| Released parts, formal ECOs, effectivity | PLM | Impact analysis before the ECO is raised, draft change request |
| Contractual requirements | Requirements tool, if you have one | Allocation to design, coverage, change impact |
| Architecture models | MBSE tool | Mass, cost and coverage computed on the allocated parts |
| Code, builds, defects | ALM / Git | A pull request can trigger impact analysis on hardware requirements |
| Costs, suppliers, stock | ERP | Cost roll-up and supplier changes in the design context |
The first use case runs in your own Koddex within a month, on your perimeter, without migrating anything out of the tools in place.
Complement, not replace
Replacing a PLM or a requirements tool is a multi-year project, with migration risks nobody wants to take in the middle of a programme. Koddex starts from the opposite end: keep your systems of record, and make the links between them computable.
The timing matters. The EU Machinery Regulation 2023/1230 applies from 20 January 2027 and replaces the Machinery Directive. Manufacturers will need to show how each safety requirement is met in the design, and keep that evidence current through every change. That is precisely the link between requirement, part and test that no single tool in today's stack holds.
- 14 June 2023Regulation adopted
- 19 July 2023Entry into force
- 20 January 2024Notified body rules apply
- 20 January 2027Full application, Directive 2006/42/EC repealed
Our customers use Koddex to cut the time spent on repetitive engineering tasks and to produce audit evidence in minutes rather than weeks. In a 20-minute demo, we show Koddex on a product close to yours, in your vocabulary. Book a demo
Sources
- Stecklein, Dabney et al., Error Cost Escalation Through the Project Life Cycle, NASA Johnson Space Center, NTRS 20100036670
- Robinson, An empirical analysis of engineers' information behaviors, Journal of the American Society for Information Science and Technology, 2010
- US Department of Defense, Digital Engineering Strategy, June 2018
- EU-OSHA, Regulation 2023/1230/EU on machinery
- Koddex figures (impact analysis, product structure, search time) are measured at our reference customer after a year in use, and walked through on your perimeter during the demo.
