In one technical-file review, I was asked to trace a single use case through its risk controls, design inputs, design outputs and verification evidence.
Every document existed. Each had an identifier, an owner and a controlled version. The problem was that the links between them had not survived the project.
We found the intended-use record in one place, the hazard analysis in another, and the relevant tests somewhere in a test repository. The requirement had been revised after the test protocol was approved, but the relationship did not trigger an impact assessment. The result was a collection of valid artefacts that did not tell a coherent design story.
That is the difference between document control and traceability.
The standard asks for relationships, not folders
ISO 13485:2016 clauses 7.3.2 to 7.3.6 require documented design and development processes, reviews, verification, validation, change control and evidence that design requirements have been met.
For devices entering the US market, 21 CFR 820.30 similarly addresses design inputs, design outputs, verification, validation and design changes.
Under EU MDR, Article 10(9) and Annex II require technical documentation that demonstrates conformity with the General Safety and Performance Requirements. In practice, this means the technical file must connect the claimed intended use and risk controls to the design evidence supporting them.
A controlled repository helps. It does not, by itself, provide traceability.
A spreadsheet cross-reference can show that requirement RE-017 was linked to test VER-042. It does not necessarily tell you whether:
- RE-017 is still the effective revision;
- VER-042 tested the output generated from that revision;
- a subsequent change affected the risk-control chain;
- the link was approved by the right person;
- the evidence remains valid at the time of release.
Those are not formatting problems. They are design-control problems.
The links that matter
For an ordinary device, I would expect the following relationships to be explicit:
- Intended use or use case → foreseeable hazards and risk controls
- Risk control → design input or requirement
- Design input → design output
- Design output → verification or validation activity
- Verification result → released design configuration
- Design change → impact assessment across affected records
For software, these links should also address the software lifecycle evidence, where applicable, including software requirements, architecture, implementation, verification and release configuration.
Each relationship needs more than a document title. I want to see:
- a stable identifier for both records;
- the type of relationship;
- the revision of each record;
- the approval status;
- the rationale for the link;
- the date the relationship was assessed.
The stable identifier matters. If a requirement is called “RE-017” in one document, “Alarm threshold requirement” in another and “Design input 17” in a third, a reviewer is effectively conducting an uncontrolled naming exercise.
Use a controlled identifier consistently, while retaining a human-readable title.
“Real time” should not mean silent rewriting
The value of a connected design technical file is not that two people can edit the same paragraph simultaneously. The value is that a change exposes downstream consequences.
If a design input changes, the system should identify the risk analysis, output, verification activity and other records that may require review. If a revised input invalidates an approved test, that needs a controlled impact assessment and, where appropriate, nonconformity or CAPA evaluation.
It must not automatically rewrite the requirement, alter the test result or close the evidence gap. Controlled assistance is valuable precisely because a qualified reviewer remains accountable for the decision.
In practice, this means:
- The source record changes under change control.
- Linked records are identified for impact assessment.
- Owners review relevance and document their conclusions.
- Affected evidence is revised, rejected or formally justified.
- The new relationship and approval are recorded.
An AI-assisted search can make the relevant records easier to find. It should not be the mechanism that decides whether a link is valid.
Search helps only when the underlying links are sound
Keyword retrieval depends on the searcher already knowing the document title, identifier or exact wording. That is rarely how an audit question arrives.
Someone may ask for evidence that:
The alarm threshold reduces the risk associated with continued use under a foreseeable misuse scenario.
The wording may not appear in the design input, risk analysis or test report. An AI-powered semantic search can locate candidate records almost instantly by matching the concept rather than requiring an exact phrase.
That is genuinely useful for a practitioner trying to reconstruct the design history.
However, semantic similarity is not traceability. The search result must show the source document, revision, approval status and relationship path. It should distinguish between:
- a record directly linked to the use case;
- a record containing related terminology;
- an inactive revision retained for historical reasons.
The strongest control is to make the underlying relationship explicit and let search accelerate retrieval across it. Otherwise, AI is being asked to infer regulatory meaning from prose, which is precisely where it is least trustworthy.
What I would test before calling the file connected
I would select several representative design questions and attempt to answer them without exporting data or rebuilding a spreadsheet. For example:
- Which risks are addressed by this design input?
- Which tests demonstrate that the current output meets it?
- What changed after this risk control was introduced?
- Which released configurations depend on this requirement?
- Can an obsolete test still appear as current evidence?
Then I would test the same questions through AI-powered search. The expected answer is not merely a list of relevant documents. It is a navigable chain with enough context for a human to decide whether the evidence is adequate.
The review should also confirm that permissions, redaction and audit trails remain intact. Fast retrieval is useful only when the user is allowed to see the evidence and the system preserves who accessed, searched or changed it.
Traceability is the real product
A design technical file should function as a living network of controlled evidence. The purpose of linking use cases, risks, inputs, outputs and tests is not to make the documentation look sophisticated. It is to expose design decisions as they happen, including when those decisions become unsafe to leave behind.
The standardised elements remain familiar: controlled records, approved procedures, documented reviews and verifiable evidence. What changes is the connective tissue between them.
A reviewer should be able to select a use case and follow it to the relevant risk controls, requirements, outputs and tests without spreadsheet archaeology. An AI-powered search should help locate those elements immediately, but the traceability must already exist in the underlying system.
How does your team currently expose a use-case-to-test chain to a reviewer: through live links, generated matrices, or a controlled index that somebody still maintains by hand?
Top comments (0)