Both directions, and why the second one matters
Forward traceability answers which tests verify a given requirement. This is what auditors ask for, and what most traceability matrices are built to provide.
Backward traceability answers which requirement justifies a given test. It is supported far less often, and it is the direction that finds orphans — cases that outlived the requirement motivating them and now consume review effort verifying behaviour nobody asked for.
Why the matrix goes stale
Because it is a second source of truth about a relationship recorded nowhere else. Nothing enforces it and nothing detects drift. A requirement is revised and its identifier changes; a suite is reorganised and cases are renumbered; an engineer writes three cases and records one.
None of these produces an error at the time. Each surfaces months later as an audit finding, which is why the pre-audit reconstruction ritual exists and why teams budget weeks for it.
The structural fix
Stop treating traceability as documentation and treat it as provenance. When a test is generated from a requirement, write the requirement identifier onto the case as it is created. The matrix then stops being a document to maintain and becomes a query to run — nothing can drift, because there is no second copy to drift from.
Traceability is not coverage
A complete traceability matrix proves every written requirement is verified. It says nothing about behaviour that entered the system without a requirement — an interlock added during integration, a timeout adjusted after a field issue, a fallback introduced to work around a supplier component.
That behaviour is real, it ships, and it is invisible to a requirements-driven report. Answering "is every implemented behaviour verified?" requires an index of what exists, derived by parsing the implementation rather than maintained by hand.