Quality Manager

Lock what's certified. Trace every change. Govern who touches what.

Koddex gives quality managers structural guarantees, not naming conventions. Baselines that hold, revisions that are explicit, and audit trails that are always ready.

Quality engineer inspecting a production machine on the line

EU MDR · ISO 13485 · AS9100 · DO-178C / DO-254 · ISO 10218 · IEC 61508 · 10 CFR 50 App. B

Across every regulated industry, certification has shifted from "deliver a binder of documents" to "prove your engineering data was under structural control at every stage." MedTech (EU MDR, FDA QMSR, ISO 13485), aerospace and defense (AS9100, EASA Part 21, DO-178C, DO-254), robotics (ISO 10218, EN ISO 13482, IEC 61508), nuclear and energy (RCC-M, 10 CFR 50 App. B, IAEA SSG-39) and advanced manufacturing (ISO 9001, IATF 16949) all converge on the same requirement: traceable design history, locked baselines, explicit revision lineage, and audit-ready records.

For quality managers, the structural problem is identical regardless of regime: prove the configuration that was certified, prove every change since, and prove who had the right to touch what, without spending weeks reconstructing it.

Most teams' tooling (Word, Excel, shared drives) was never designed for that level of structural proof. Auditors expose the gap.

Koddex closes it upstream, before the QMS layer.

WHAT QUALITY MANAGERS ACTUALLY TOLD US

Three of these came from one 26-year career in regulated design control.

“Show me the room-14 prototype, on the day of the test”

Fifteen prototypes, none at the same revision level. Three years later the auditor asks which one passed which test. The answer is in a spreadsheet and in the memory of three people, two of whom have left.

15prototypes

never at the same revision level

Requirement

Verification plan

« this link exists nowhere »

Hardware revision

Audit evidence

Requirement

Verification plan

« this link exists nowhere »

Hardware revision

Audit evidence

« Proving that the room-14 prototype was at that document level on the day of the test is computerised nowhere. »

When it gets paid forFDA audit, three years later

How do you answer that today?

A test run is a dated fact, attached to one revision.

A twenty-page checklist, completeness judged by eye

The impact analysis for a change is done in a meeting, by hand, against a paper checklist. Nobody can say whether it is complete. Nothing reminds anyone of what was skipped.

20pages

of paper checklist, ticked by hand

« We estimate whether the analysis is complete. Finger in the air. »

When it gets paid forRegulatory submission

Impact is computed from the graph, not remembered in a meeting.

Five people out of thirty do the paperwork

Design control needs the equivalent of five full-time people to document the work of a team of thirty. They are engineers. None of them is designing anything.

5 / 30engineers

on documentation, in a typical design team

« The administrative load of design control took five people for a team of twenty to thirty. »

When it gets paid forEvery release

Evidence is a by-product of the work, not a second job.

01
Auditors demand structured proof, not documents. Whether the regime is EU MDR, AS9100, DO-178C / DO-254, ISO 10218 or 10 CFR 50 App. B, your file must demonstrate continuous traceability from inputs to verified outputs, with explicit version control at every stage. A folder of PDFs doesn't satisfy any of them. The auditor will ask: "Show me the baseline that was in effect when this product was certified." You need to answer without reconstructing it.
02
Every post-certification change triggers a re-evaluation cycle. MDR Article 83, AS9100 § 8.5.6, DO-178C § 7 and 10 CFR 50.59 all require documented impact analysis on every design change. Each change must be traced back to affected requirements, risk assessments and verification activities. Without a structured graph, this is weeks of manual work per change.
03
"Locked" doesn't mean anything in a shared drive. Your design freeze lives in a folder called _FINAL_v3. Someone edits a file without telling anyone. The configuration drifts. You find out during a Notified Body, FAA or AIB audit, or after a field safety corrective action.

Audit-readiness as a property of the data, not a project.

01
Structural proof, generated as you work.
Requirements, design outputs, tests and revisions are linked in one graph. When the auditor asks for the baseline in effect at certification, you query it. You don't spend days reconstructing it.
02
Every change carries its own impact trail.
Each revision records its author, date, reason and predecessor. The documented impact analysis MDR Article 83, AS9100 § 8.5.6 and 10 CFR 50.59 demand is already attached to the change.
03
A lock that's a guarantee, not a folder name.
Locking a baseline seals every item, attribute and linked child. A frozen configuration can't drift, so the file you present to the Notified Body is the file that was certified.

🔒BOM

🔒REQ

🔒COMP-A

🔒COMP-B

🔒TEST

Baseline locked · Rev A

LOCKING

A locked baseline is a structural guarantee, not a folder name.

Click lock. Every item, every attribute, every linked child is sealed. Provable. Permanent. Auditable.

Rev A / 2025-11-14 / J. Martin

Rev B / 2026-01-09 / S. Lecomte

Rev C / 2026-03-22 / A. Nguyen

▮

REVISION LINEAGE

Every revision knows where it came from.

Full history of who created which revision, when, and from which state. No reconstruction. No guesswork.

TEAMvieweditlockmanage

SUPPLIERvieweditlockmanage

AUDITORvieweditlockmanage

PERMISSIONS

The right access. For the right actor. At the right scope.

Assign view, edit, lock, and manage rights by group, by item, by model. Contractors get exactly what they need.

›item_locked / BOM_Senova_RevA / 09:14:02

›revision_created / COMP-117 / 09:15:44

›attribute_edited / mass_kg / 09:17:11

›item_locked / BOM_Senova_RevA / 09:14:02

›revision_created / COMP-117 / 09:15:44

›attribute_edited / mass_kg / 09:17:11

ACTIVITY LOG

Every action. Every actor. Every timestamp.

Full activity log per item, ready for EU MDR, ISO 13485, AS9100, DO-178C / DO-254, ISO 10218, IEC 61508 and 10 CFR 50 audits, without reconstruction.

Certifications changed the standard. Your tooling hasn't.

Whether you certify under EU MDR, AS9100, DO-178C / DO-254, ISO 10218, IEC 61508 or 10 CFR 50 App. B, the underlying audit question is the same: prove that, at the moment of certification, every requirement was linked to a verified output, every component was at a known revision, every baseline was locked, and every change was traceable to an authorized actor.

The gap most teams discover too late: their design control layer (requirements, components, verification, design outputs) lives in disconnected tools with no structural link between them. When the auditor asks "prove that this design output was linked to a validated input at the time of certification," the answer requires days of manual reconstruction.

Koddex structures that layer upstream. Requirements, components, design outputs and test results are explicitly linked in a single graph. Baselines are locked at the item level, not the folder level. Every change is a traceable revision with author, date and reason. When the audit comes, under any regime, the technical file isn't assembled. It's already there.

Related use cases

Impact analysis

See the full cascade of any change before you commit.

Single source of truth

One always-current source of truth, so teams ship on time.

Quality management across our industries

MedTech

Class II–III device makers under EU MDR, FDA QMSR, ISO 13485.

Robotics

Industrial, mobile and humanoid platforms under ISO 10218, EN ISO 13482, IEC 61508.

Aerospace & Defense

AS9100, DO-178C, DO-254 and EASA Part 21 programs with locked baselines.

Nuclear & Energy

RCC-M, 10 CFR 50 App. B, IAEA SSG-39 design control for reactor and SMR systems.

Advanced Manufacturing

ISO 9001 / IATF 16949 plants with structured BOMs and revision control.

Renewable Energy

IEC 61400, IEC 61215 and DNV-GL wind, solar and storage assets with locked baselines.