What makes a live RTM different from an automated or real-time RTM?

A live RTM updates automatically as validation activities occur — when a test is executed, when a requirement is added through change control, when a deviation is linked to a test failure, when a change closes and affected tests are retested. It is not generated on demand from a database query; it reflects the actual current state of the trace chain at any point. The key property is that upstream changes automatically flag downstream items for review, rather than relying on a person to propagate the update.

Automated Requirements Traceability: How Live RTM Replaces Manual Matrix Maintenance in CSV

What is a live RTM and why does it matter more than a completed traceability matrix in pharma CSV?

A completed RTM proves the validation was complete at a moment in time. A live RTM proves it is still complete right now — after every change control event, every deviation closure, every additional requirement added mid-project. The difference is not cosmetic: the most cited traceability deficiency in FDA observations is not a missing matrix but one that no longer reflects the actual tested state of the system because it was never updated after the first release.

The Requirements Traceability Matrix is probably the most frequently misunderstood artefact in a CSV package. Teams spend significant effort building it before release, treat it as complete when validation closes, and then discover during an inspection or periodic review that the system changed six times since then — and the RTM reflects none of those changes. At that point the matrix doesn't prove compliance. It documents a state that no longer exists.

What an RTM Is Actually Proving

An RTM proves two distinct things simultaneously, and most teams only consciously manage one of them:

Origin

User Requirement (URS)

→ Forward Backward ←

Design

Functional Spec / Config

→ Coverage Necessity ←

Test

Test Case + Protocol

→ Proof Justification ←

Evidence

Execution Result

Forward traceability (left to right) proves completeness: every requirement has a test. A gap here means a requirement was specified and never verified — the system may not do what it was required to do, and there is no evidence either way.

Backward traceability (right to left) proves necessity: every test maps back to a requirement. A gap here produces an "orphan test" — a test case executing against functionality that was never formally required. Orphan tests raise an immediate inspection question: what undocumented function are you testing, and why was it in scope?

A test suite with 1,500 passing results provides no coverage proof if those results cannot be individually linked to the specific requirements they verify. Conversely, an RTM showing 100% requirement coverage with linked executed evidence is strong validation proof even if the total test count is modest. What counts is the chain, not the volume.

The Four Failure Modes of a Manual RTM

Post-change coverage gaps

A new requirement enters the system through change control. Tests are written and executed. The RTM is never updated to include the new requirement row. Forward traceability gap created — the requirement is tested but invisible to the matrix. The next inspector to review the RTM sees a function with no evidence.

Orphan tests after descope

A function is removed from validated scope through change control. Its test cases remain in the protocol and in the RTM — never retired. The RTM now contains backward gaps: tests with no valid requirement link. Inspectors may interpret this as undocumented functionality or scope confusion.

Stale version mismatch

The RTM references URS v1.2. Change control updated requirements to URS v1.5. The matrix was never regenerated. It now maps tests to requirement IDs that no longer exist at their documented version — technically the entire trace chain is unverifiable against the current state of the system.

Pre-inspection reconstruction

The RTM was accurate at initial release. Since then, the team has been manually updating it "when they remember." Before an inspection, a week is spent reconciling the matrix to the current system state — a process that is itself undocumented and uncontrolled, and which creates exactly the type of retroactive record assembly that inspectors are trained to identify.

What "Live" Actually Means Technically

The word "live" gets applied loosely to a lot of systems that are still fundamentally static. A live RTM has one defining property that separates it from a database-driven report or an automated export: upstream changes automatically propagate downstream flags.

1.
Requirement modified → linked test cases flagged for review. If URS-042 is amended through change control, every test case mapped to URS-042 is automatically marked as requiring re-review — not because someone checked, but because the link enforces it structurally.
2.
Test executed → coverage status updated in real time. When a tester records a pass result against TC-117, the RTM entry for the linked requirement reflects that evidence immediately — not after someone updates a spreadsheet row.
3.
Deviation opened → affected requirement flagged as having unresolved failure. A failed test that generates a deviation is linked to the requirement it was testing, making the compliance risk visible at the requirement level, not just in the deviation log.
4.
Change control closes → coverage gap check runs automatically. After a change event, the system confirms that all requirements in the changed scope have linked, passing test evidence before the system can be returned to a fully validated state.

Manual vs Live RTM: The Actual Differences

Dimension	Manual RTM (Spreadsheet)	Live RTM
Coverage check	Visual scan of empty cells — done periodically or pre-inspection	Continuous — any requirement without a linked passing test is flagged in real time
Orphan test detection	Manual cross-reference of test list against requirement list	Automatic — any test without a requirement link is immediately visible as an orphan
Change control integration	RTM updated manually after change — or not at all	Requirement change automatically flags linked test cases for re-execution
State at inspection	Reflects the last time someone manually updated the file	Reflects the actual current validated state of the system
Deviation linkage	Separate deviation log; manually reconciled to test records	Deviation linked to the test and requirement at the moment of failure
Audit trail	Excel change history (if tracked) or version control	Timestamped, user-attributed record of every change to every link

Where GoVal Implements This

GoVal's RTM is not a report generated from a database on demand. Every requirement, test case, and execution result exists as a linked record within the platform's validation lifecycle model. When a requirement is added or modified through change control, the system automatically identifies every test case linked to it and marks them for review. When a tester records an execution result, the corresponding RTM entry updates immediately — including status, evidence reference, and the identity and timestamp of the executor. When a periodic review is due, the live RTM shows the current coverage state of the system: which requirements are fully evidenced, which have open deviations, and which were affected by recent changes and require retesting.

The result is that inspection readiness is a system state rather than a preparation activity. An inspector asking to see the traceability of requirement URS-088 receives a live, complete chain — from the requirement text through functional specification to the test case to the executed result — without anyone reconstructing it first.

Frequently Asked Questions

What is a Requirements Traceability Matrix (RTM) in pharma validation? +

A Requirements Traceability Matrix (RTM) in pharma CSV maps every user requirement to the test case that verifies it and the evidence that it passed. It proves two things: completeness (every requirement has a corresponding test — nothing was left unverified) and necessity (every test traces back to a requirement — no test exists without a documented reason). Inspectors use the RTM to verify that the system was tested as specified, not just that testing occurred.

What is the difference between forward and backward traceability? +

Forward traceability links each requirement downstream to the test case that verifies it — proving completeness and coverage. A gap means a requirement was specified but never tested. Backward traceability links each test case upstream to the requirement that justifies it — proving necessity. A gap reveals orphan tests: tests that were executed but cannot be tied to any approved requirement, which raises the question of what undocumented functionality was being tested and why it was in scope.

Why does a manual RTM become inaccurate over time? +

A manual RTM is a snapshot accurate at a point in time. As the system evolves through change control — requirements added, tests modified, deviations resolved — the RTM must be updated manually to stay current. In practice, it isn't. A requirement added through change control that gets tested but never reflected in the RTM creates a coverage gap. A test retired after descope but left in the matrix becomes an orphan. These gaps compound silently until an inspection forces reconciliation.

What do FDA inspectors look for when reviewing an RTM? +

Inspectors check that every GxP-critical requirement has a corresponding test with executed evidence — not just that testing ran, but that the specific requirement it validates is identifiable. They look for forward gaps (requirements with no linked test), backward gaps (tests with no linked requirement), and whether the RTM reflects the current validated state or a historical snapshot. The most common citation is not a missing RTM but one that no longer accurately reflects the tested state of the system.

What makes a live RTM different from an automated export or database report? +

A live RTM updates automatically as validation activities occur — when a test is executed, when a requirement is added through change control, when a deviation links to a test failure. The key property is that upstream changes automatically flag downstream items for review, rather than relying on a person to propagate the update. A database export or generated report reflects stored data at query time; a live RTM reflects the actual current state of the trace chain continuously, without requiring manual regeneration.

RTM that stays current without manual maintenance

Every requirement linked to its test, evidence, and change history — live, in GoVal.

Book a Free Demo →