Traceability without spreadsheets

Almost every audit finding we are asked to remediate has the same root cause: the traceability matrix was assembled after the work, by a person who was not present for the decisions. It is accurate on the day it is signed and wrong a week later.

Where the record actually lives

Requirements live in the issue tracker. Design decisions live in reviewed architecture records. Verification lives in the test suite and its results. Releases live in the pipeline. Each of these already carries an identifier and a timestamp; the matrix is a projection of them, not a separate artefact.

• —Give every requirement a stable identifier at creation, never at review.
• —Reference that identifier in the branch, the test name and the risk control.
• —Generate the matrix in the pipeline so it is versioned with the build it describes.
• —Fail the build when a requirement has no verifying test rather than reporting it later.

What auditors ask next

Once the matrix is generated, the question shifts from 'is this current?' to 'how do you know the generator is correct?'. That is a much better question to be asked, and it is answered once, by validating the generator itself and placing it under change control.

The effect on the team is larger than the effect on the audit. Engineers stop treating documentation as a separate tax and start treating identifiers as part of the work.