Glossary · Traceability

    Engineering Traceability Software for Certification

    Engineering traceability software is the substrate that keeps the chain from requirement to verification consistent across a 7-20 year product lifecycle, through hundreds of revisions and dozens of certification touchpoints. This page is the clause-level reference, what each industry standard demands, where teams predictably break down, and the technical primitives that make this tractable.

    Every certification rests on the same five primitives

    ISO 13485, AS9100D, DO-178C, RCC-M, ISO 10218, ISO 19650, different industries, different inspectors, same demand: structured evidence linking what was specified, what was built, what was verified, under which baseline, and who approved each step. Traceability software is the substrate that keeps those five primitives consistent over a 7-20 year product lifecycle, across thousands of artifacts, through hundreds of revisions.

    What traceability has to deliver, per industry

    Clauses, evidence types, and where teams predictably break down.

    MedTech

    ISO 13485:2016 · EU MDR 2017/745 · FDA QMSR (21 CFR 820) · IEC 62304 · ISO 14971

    ISO 13485 §7.3.10
    Design changes, identification, review, verification & validation as appropriate, approval before implementation, records.
    ISO 13485 §4.2.5
    Control of records, retention period covers device lifetime, retrieval at any past state for audit.
    FDA 21 CFR 820.30(j)
    Design History File, cumulative record of design history, including reviews, V&V results, design transfer, changes.
    IEC 62304 §5.5-7.4
    Software safety class A/B/C, unit, integration, system test records linked to risk control measures.
    EU MDR Annex II §3
    Technical Documentation: traceability between essential safety requirements, risk analysis, V&V evidence.

    Evidence the graph must carry

    Bi-directional matrix URS → SRS → SDD → V&V → DHR. Risk file (ISO 14971) cross-linked to each safety requirement and verification record. IEC 62304 software class justification tied to architecture decisions.

    Where teams typically fail

    Manual spreadsheet traceability matrix hits 1500+ rows and silently drifts. Software class B requirements lose link to their unit tests after the V&V plan is revised. EU MDR Annex II reconstruction takes 4-6 weeks before each notified body audit.

    Aerospace & Defense

    AS9100D / IA9100 · DO-178C · DO-254 · ARP4754A · ARP4761

    AS9100D §8.1.2
    Configuration management, items under CM include hardware, software, documentation; baselined and audited.
    AS9100D §8.5.6
    Control of changes, change request review including impact on certification basis.
    DO-178C Tables A-1…A-10
    Objectives per Development Assurance Level (DAL A-E). DAL A: 71 objectives with independence; DAL C: 62 objectives, less independence.
    DO-178C §11
    12 lifecycle data items: PSAC, SDP, SCMP, SQAP, SCI, SAS, etc., formal artifacts linked to each requirement and test.
    DO-254 §4.5
    Hardware DAL A: elemental analysis, advanced verification methods, independence requirements.
    ARP4754A §5
    Item, function, requirement allocation, system architecture traced down to component implementation.

    Evidence the graph must carry

    Lifecycle data items per DAL, each linked to specific requirements and verification records. FAA/EASA Stage of Involvement (SOI) reviews 1-4 trigger live extraction. Independence proof for DAL A objectives.

    Where teams typically fail

    Requirements in the RM tool; SDP/SCMP/SQAP in a document repository; verification records in a third tool. SOI #3 finds gaps because the artifacts can't be cross-referenced live. DO-178C DAL A independence claims become impossible to prove without an integrated graph.

    Nuclear & Energy

    RCC-M · IEC 61513 · 10 CFR 50 Appendix B · ASME NQA-1 · IEEE 603

    10 CFR 50 App. B Criterion III
    Design Control, designs translated into specifications, verified or checked by qualified individuals other than the originator.
    10 CFR 50 App. B Criterion VI
    Document Control, documents controlled at issue, change, revision; obsolete versions removed from use.
    ASME NQA-1 Req. 3
    Design Control, formal design verification, configuration baseline retained for plant lifetime (60+ years).
    IEC 61513 §5
    I&C systems important to safety, Category A/B/C with corresponding requirements for V&V rigor and independence.
    RCC-M Class 1/2/3
    Component classification by safety significance, drives material qualification, NDT extent, examination records.
    IEEE 603 §5
    Safety system criteria, 1E vs non-1E classification justified and retained throughout design lifecycle.

    Evidence the graph must carry

    Independent V&V records per Criterion III, configuration baseline retained for plant lifetime, 1E classification justification cross-linked to safety analysis, supplier qualification per Criterion VII.

    Where teams typically fail

    EDM holds documents; requirements live in another system. When a Class 1E component spec changes, the safety analysis sometimes doesn't get re-run because nobody knows the link exists. NRC inspections find broken classification trails years after the change.

    Robotics

    ISO 10218-1/-2 · ISO 13482 · ISO/TS 15066 · IEC 62061 · ISO 13849-1 · EN ISO 12100

    ISO 10218-1 §5.10
    Safety-related control system performance, PLr determination per ISO 13849-1 (PLa-PLe) or SIL per IEC 62061.
    ISO 10218-2 §5.3
    Integration of safety functions, hazard analysis, risk reduction, verification per ISO 13849-2.
    ISO/TS 15066 §5
    Collaborative robot modes: safety-rated monitored stop, hand-guiding, speed & separation monitoring, power & force limiting.
    ISO/TS 15066 Annex A
    Biomechanical limits, force and pressure thresholds per body region, validated by measurement.
    ISO 13482 §5.10
    Personal care robots, mobile servant / physical assistant / person carrier classifications drive different normative trees.
    EN ISO 12100 §6
    Risk assessment & risk reduction, iterative risk reduction documented through three-step method.

    Evidence the graph must carry

    PLr/SIL determination for each safety function, traced to the requirements it implements. Risk assessment table (ISO 12100) linking each hazard to its mitigation. ISO/TS 15066 biomechanical limit validation records per contact mode.

    Where teams typically fail

    Safety function PLr is set in the supplier integrator report; the PCB change for diagnostic coverage breaks the PLr assumption silently. Reclassifying a robot from industrial (ISO 10218) to collaborative (ISO/TS 15066) mid-development means re-doing every safety function, usually discovered too late.

    Complex Infrastructure

    ISO 19650-1/-2 · Eurocodes EN 1990-EN 1999 · EN 13670 · IFC (ISO 16739)

    ISO 19650-2 §5.1
    Information Delivery Plan (IDP) per project; Master Information Delivery Plan (MIDP) aggregates across appointed parties.
    ISO 19650-1 §5.1
    Common Data Environment (CDE) with explicit information states: Work-in-Progress, Shared, Published, Archived.
    ISO 19650-2 §5.5
    Information Container management, each model deliverable identified, classified, baselined.
    EN 1990 Annex A1
    Reliability differentiation, Consequence Class CC1/CC2/CC3 drives partial factor selection and execution class.
    EN 13670 §6
    Execution classes EXC1-EXC3 for concrete structures, inspection records by class.
    IFC §4.4
    Schema for property sets, classifications, relationships, interoperability between BIM authoring tools at each milestone.

    Evidence the graph must carry

    As-designed model versions in the CDE per ISO 19650-2 state transitions, party responsibility matrix per appointment, IFC model deltas at each milestone, EN 13670 inspection records linked to execution class.

    Where teams typically fail

    CAD-side change doesn't propagate to as-built records in the CDE. Asset operator inherits a Federated BIM Model (FBM) that diverges from physical asset within months. EN 13670 inspection records are scanned PDFs not linked to the elements they certify.

    Advanced Manufacturing

    ISO 9001 · IATF 16949 · ISO/IEC 27001 · EN 9100 · CE Machinery Regulation 2023/1230

    ISO 9001 §8.5.2
    Identification & traceability, output identification, traceability where required, status of monitoring & measurement.
    ISO 9001 §8.5.6
    Control of changes for production, review and control of unintended changes.
    IATF 16949 §8.3.5.2
    Manufacturing process design output, production line, capacity studies, PFMEA, control plan, FMEA traceability.
    EU 2023/1230 Annex III §1.7.4
    Information & warnings, instructions for use, declaration of conformity retained for 10 years after last unit.
    EU 2023/1230 Art. 10(7)
    Digital documentation accepted, with retrieval guaranteed across product lifetime (often 20+ years).

    Evidence the graph must carry

    PFMEA → control plan → measurement system → first-article inspection chain, linked back to design FMEA. Production change requests traced to design baseline. Declaration of Conformity tied to the technical file version it was issued against.

    Where teams typically fail

    PFMEA in a spreadsheet, control plan in MES, design FMEA in PLM, no live link between them. A design change that should trigger a control plan revision silently doesn't. Machinery Regulation 2027 enforcement begins January 20, 2027, teams without integrated traceability face audit gaps.

    The evidence taxonomy auditors actually look for

    Per artifact type, what the standard expects in writing, and where scattered toolchains create predictable gaps.

    Artifact
    Evidence under standard
    Failure when scattered
    Requirement
    Source (stakeholder, standard clause, hazard), acceptance criteria, verification method, link to verification record, change history with approver.
    Free-text rationale in a ticket. Acceptance criteria implicit. Verification method missing for ~15% of low-priority requirements. No link to the test that verified them.
    Test / verification
    Procedure, environment, executed-by, date, result, deviation log, link to all requirements verified.
    Test report PDF dropped in a document repository. Procedure in a separate Word doc. Link to requirements maintained manually in a coverage matrix.
    Baseline
    Cryptographic snapshot of the typed graph: requirements, components, tests, documents, all at a specific revision. Signed by approver(s).
    ‘Baseline’ is a folder name with a date. Three different ‘baseline’ snapshots disagree because they were taken from three tools at three moments.
    Risk item (ISO 14971 / EN ISO 12100)
    Hazard, hazardous situation, harm, probability, severity, risk control, residual risk, link to verification of control effectiveness.
    Risk file in standalone tool. Linkage to the requirement implementing the control is a row number reference. Control verification result lives elsewhere.
    Change / deviation
    What changed, why, impact analysis, approver(s), baseline before/after, propagation to all affected artifacts.
    Email approval. Impact analysis is ‘we checked the obvious places’. Propagation is manual and partial. Six months later, the audit finds the missed updates.
    Supplier deliverable
    Spec the supplier worked from, qualification record, incoming inspection result, linked to the system requirements they fulfill.
    Supplier qualification in procurement folder. Incoming inspection in MES. System requirements in PLM. Reconciliation runs nightly, sometimes.

    The technical primitives that make this tractable

    01

    Typed bi-directional links

    Requirement.verifiedBy is a typed reference, not a free-text field. The graph rejects an orphan test the way a compiler rejects an unresolved symbol.

    02

    Cryptographic baselines (Merkle-tree snapshots)

    A baseline is a content-addressed hash of every entity in scope at freeze time. Replay any past state, prove no tampering, fork branches Git-style.

    03

    Computable impact analysis across the graph

    Mutate a requirement; immediately get the set of tests, baselines, suppliers, and downstream documents that just became stale. Not a search, a graph traversal.

    04

    Audit trail in the data model

    Author, timestamp, approver, rationale, signed checksum on every mutation. Exportable as PDF, JSON, or directly into the standard's expected format (DHF, lifecycle data set, CDE delivery).

    How traceability fits in the Koddex platform

    Data model, typed traceability entitiesAudit trail, every change, every reviewerCompliance readiness, live dashboardsIntegrations, CAD, PLM, ALM, MES

    Traceability tailored by industry

    Get access Book a demo