A broken chain does not mean the engineering was wrong. It means the evidence that the engineering was right does not exist.
Two chains, both complete and linked
- Design traceability: user need, system requirement, software requirement, architecture decision, software item, verification.
- Risk traceability: hazard, risk control, software requirement, architecture decision, verification, risk acceptance.
The architecture decision is the pivot point in both. Network segmentation traces back to a cybersecurity risk control and forward to pentest evidence. A failover pattern traces to an availability requirement and a degraded-mode test. Safety classification traces to hazard severity and class-appropriate V&V evidence.
Where chains break
- A decision is never documented. The rationale exists only in someone's memory.
- A risk control lives in code, not in the RMF. The architecture is correct and the DHF has no evidence.
- The system changed and the chain wasn't re-evaluated. The DFMEA analyses components that no longer exist.
What holds
- Clean software item boundaries. No boundary means no impact analysis, and you can't isolate which risk controls a change affects.
- Decisions documented at the moment they're made. The rationale has to exist when the auditor asks, not be reconstructed eighteen months later.
Traceability is not something you add to a system. It is something you build into one.
Seen this differently?
Questions, corrections and counterexamples are welcome.
