Your Traceability Must Survive the Next Baseline

The trace matrix is green. The design has changed twice. The test report covers an earlier software build. Nobody has checked whether the safety argument still holds.

That is not a missing-link problem. It is a lifecycle configuration problem.

Links need meaning and context

A requirement linked to a test is not necessarily verified. The test may cover only one operating mode, use an outdated acceptance criterion or belong to a different product variant.

Useful traceability records the relationship, not just the connection. Does this requirement derive from a stakeholder need? Does it constrain an interface? Does this result provide verification evidence for the released configuration?

Keep those distinctions explicit. A generic “related to” link tells a reviewer very little and makes change impact harder to assess.

Treat change as an engineering question

Consider a revised actuator response-time requirement. Updating its value is easy. Understanding the consequences is the work.

Trace the change through:

• Allocated subsystem requirements and interface timing budgets.
• Control-law assumptions and failure-response behaviour.
• Verification procedures, test conditions and acceptance criteria.
• Safety-case claims that rely on the original response time.

These paths identify candidates for review, not automatic conclusions. Engineers must decide which artefacts need revision, which evidence remains valid and where additional V&V is necessary.

Record that disposition. Otherwise, the next review repeats the same investigation with less context.

Baseline the evidence, not just the requirements

At each release, preserve the requirements, their relationships, the relevant design configuration and the evidence used to justify acceptance. Include unresolved anomalies and the rationale for accepting them.

A passed test is useful only when you can establish what was tested, against which requirement revision, under which conditions. Validation evidence must also remain tied to the intended use and operating environment.

Carry that discipline into service. A field modification, supplier substitution or software update can invalidate assumptions long after certification or initial acceptance.

The practical check is simple: select one changed requirement and reconstruct its path from source to implementation, V&V evidence and affected assurance claims. If that takes days of email archaeology, the traceability is not doing its job.

Engineer-approved AI can flag suspect links and propose change-impact paths for review.