A URS clause written during project definition is only useful if it can still be found, unambiguously, in the test record that closes out qualification months or years later. When a reader asks how to trace requirements through DQ, FAT, SAT, IQ, and OQ, the real question is how to keep one requirement identifiable across multiple documents, multiple contributors, and multiple points where the requirement itself might change. That question matters because a qualification package that cannot show this link back to its source requirement is difficult to defend in inspection, and difficult to trust internally when something fails.
The Traceability Matrix as the Control Point for Every URS Clause
| Traceability element | Link maintained | Decision visibility |
|---|---|---|
| Stable URS identifier | Requirement through approved revisions | Confirms that later evidence refers to the current requirement set |
| Supplier response | URS clause to the supplier response | Shows how the proposed solution addresses the clause |
| Design document | URS clause to approved design evidence | Supports design qualification before fabrication choices become costly to change |
| Test protocol and acceptance criterion | URS clause to planned verification | Shows what will be checked and the project-specific criterion applied |
| Test result | Planned verification to recorded outcome | Shows whether the assigned verification produced evidence |
| Deviation and approval status | Requirement or result to its unresolved issue and approval state | Keeps unresolved items visible through final handover |
A traceability matrix exists to answer one question repeatedly: for this requirement, what design decision addressed it, what test checked it, what the test found, and what happens if it was not fully met. The matrix is not a summary document produced at the end of a project; it is a control structure that has to be built while the URS is still being written and then maintained as the single reference point every later document points back to.
This only works if each requirement carries a stable identifier from the moment it is approved. Where a requirement is rewritten during design review, split into two clauses, or merged with another, the identifier scheme has to accommodate that change without breaking the link to whatever evidence was already generated against the earlier version. A matrix that allows requirements to be renumbered freely, or that allows a design document to reference “the URS” generically rather than a specific clause number, loses its value as a control point because no later reviewer can confirm which version of which requirement a given test result actually supports.
The practical discipline is to link six things for every applicable clause: the requirement itself, the supplier’s response to it, the design document that shows how the response was implemented, the test protocol and acceptance criterion assigned to verify it, the result recorded against that criterion, and the deviation or approval status if the result was not a clean pass. Missing any one of these breaks the chain. A supplier response with no design document behind it is an unverified promise. A test result with no link back to an acceptance criterion is just a number with no meaning attached. A deviation with no link back to its originating requirement becomes untraceable the moment someone asks which clause it actually affects.
Where a project changes scope midstream, the matrix has to absorb that change visibly rather than silently. If a requirement is dropped because it no longer applies, the matrix should show that it was dropped, when, and by what approval, not simply omit the row. If a requirement is added late, it needs the same six-part linkage as everything defined earlier, even though it missed the design qualification stage that the rest of the requirement set went through together. This is where many matrices weaken: late-added requirements get verified informally because the formal linkage discipline was already considered “done.”
Design Qualification Links Requirements to Approved Design Evidence
Design qualification exists to answer a narrower question than the matrix as a whole: does the proposed design, on paper, actually address each applicable URS clause, before that design becomes a fabricated system that is expensive to change. This is the stage where the traceability discipline pays for itself, because a gap found here costs a document revision, while the same gap found at FAT or later costs rework on physical equipment.
DQ does not verify performance; it verifies coverage. For each URS clause that applies to the design stage, the DQ record should show which drawing, specification, or design document demonstrates that the requirement was translated into a design feature, and whether a reviewer with relevant technical authority confirmed that translation. Where a requirement is broad or subjective, DQ is also where it needs to be made testable — restated, if necessary, in terms specific enough that a later protocol can actually check it. A requirement that cannot be translated into a testable condition at DQ stage will not become more testable later; it will simply be verified inconsistently, if at all.
The condition that changes this judgment is how firm the design is at the point DQ is performed. Where DQ happens against a mature, largely fixed design, the review can compare requirement against final drawing with confidence that nothing will shift before fabrication. Where DQ happens earlier, against a conceptual or preliminary design, the review has to distinguish between requirements the concept clearly satisfies and requirements that remain open pending detailed engineering — and the matrix needs a status value for that “open, pending further design” condition distinct from “approved” and distinct from “not applicable.” Collapsing those three into a single checkbox is a common way traceability quietly fails: a requirement marked complete at DQ because the concept looked reasonable, with no later stage revisiting it once the detailed design diverged from the concept.
Not every URS clause is applicable at DQ. Operating-condition requirements, for instance, may not be demonstrable until equipment exists and can be run. The matrix should mark these as not-yet-verifiable at this stage rather than leave them blank, so a reviewer scanning the matrix later can distinguish “not yet due” from “missed.”
Factory Acceptance Tests Verify Functions Before Shipment
FAT answers a different question than DQ: not whether the design addresses the requirement, but whether the built equipment actually performs the function the requirement describes, under conditions the factory can produce. The traceability task at this stage is assignment — deciding, for each clause reaching this point, whether FAT is the credible place to verify it, or whether the condition genuinely requires site installation or process integration to demonstrate.
This assignment decision is where judgment matters most, because some conditions can be verified equally well at the factory or on site, while others can only be verified in one location. A function that depends only on the equipment’s own control system and mechanical behavior can usually be verified at FAT, since the factory environment can reproduce the relevant inputs. A function that depends on interfaces with site utilities, integration with adjoining rooms or systems, or environmental conditions particular to the installed location cannot be credibly verified until those interfaces exist — no matter how thoroughly the factory test is designed. Assigning such a requirement to FAT produces a documented pass that does not actually demonstrate the condition the requirement describes.
Where a result generated at FAT is intended to stand in for a later SAT test — carried forward rather than repeated on site — the matrix needs to record not just the result but the rationale for reusing it. This rationale should address whether anything between factory and site could plausibly change the outcome: transport, reassembly, a different utility supply, or a different ambient condition. A reused result without this rationale invites the same question at inspection that an unassigned requirement does — namely, whether the condition was actually verified where it needed to be verified, or verified once somewhere convenient and then assumed to hold everywhere else.
The consequence for planning is that FAT scope should be decided requirement-by-requirement against this credibility test, not by defaulting to “verify everything possible at the factory” simply because it is cheaper or faster to test there than after installation.
Site Acceptance and Installation Qualification Confirm the Delivered Configuration
| Stade | Evidence linked to the URS clause | Applicability boundary |
|---|---|---|
| SAT | Site test result | Assign where the condition can be demonstrated credibly on site |
| QI | Installation check result | Use for installation evidence; the exact acceptance criterion remains project-specific |
SAT and IQ both occur after delivery, and both concern the equipment as installed rather than as designed or as built at the factory, but they answer different questions and the matrix needs to keep that distinction sharp. SAT re-confirms functional behavior under site conditions — the same category of check as FAT, but now exercised against real site utilities, real integration points, and whatever local conditions the factory could not reproduce. IQ, by contrast, confirms that what was actually installed matches what was specified and approved — correct components, correct configuration, correct documentation — independent of whether the equipment yet functions correctly.
The condition that determines whether a given URS clause belongs at SAT or at IQ is what kind of evidence the clause actually requires. A requirement about a physical or configuration attribute — a material, a fitting, a documented drawing revision installed on site — is an installation fact, and IQ is the stage that can close it. A requirement about behavior under operating conditions — a function responding correctly when exercised — needs the equipment to be running, which places it at SAT rather than IQ. Requirements that describe both an installed attribute and a functional response need to be split across the two stages rather than force-fit into one, with the matrix showing both halves against the same parent requirement.
The delivered configuration itself is also where the matrix earns its keep operationally, because this is the point at which project-specific decisions taken earlier — a supplier’s configuration choices, options selected during quotation, interface details agreed during design review — either match what shows up on site or do not. Where discrepancies appear between the approved design record and what was actually delivered, the matrix is what allows the reviewer to trace the discrepancy back to the point it was introduced, rather than treating it as an isolated site-level finding disconnected from its design history.
Operational Qualification Challenges Functions Across Approved Operating Conditions
OQ answers the question DQ and FAT could not fully answer on their own: does the equipment perform correctly not just once, under a single demonstration condition, but across the range of operating conditions the approved requirements actually describe. Where FAT and SAT largely confirm that a function executes, OQ is structured to challenge that function — to test behavior at the edges of its intended operating range, under varying conditions, and in combination with other functions operating at the same time, rather than in isolation.
This distinction changes what the matrix needs to record at this stage. A single pass/fail result against one operating condition does not close a requirement that was written to cover a range of conditions. If the URS clause specifies that a function must perform correctly across varying load, varying environmental condition, or varying combination of simultaneous operations, the matrix entry for that clause needs to show which specific conditions were challenged and confirm that the range tested actually covers what the requirement describes — not merely that some instance of the function was exercised once successfully.
Where a requirement was left loosely worded at the URS stage — a common consequence of requirements drafted before the design existed — OQ is where that vagueness becomes a practical problem, because a loosely worded requirement cannot be translated into a specific, defensible challenge condition without someone deciding, after the fact, what the requirement was actually meant to cover. This is why the earlier discipline of making requirements testable at DQ stage matters: a requirement rewritten for testability during DQ gives OQ planners a specific condition to challenge, while a requirement left in its original broad form forces that interpretation to happen late, informally, and without the same level of review the original requirement received.
The matrix should also distinguish OQ results that confirm a function under normal approved conditions from any that probe boundary or combined conditions, since these represent different depths of challenge against the same underlying requirement, and a reviewer checking coverage needs to see which depth was actually achieved.
Change, Deviation, and Approval Status Through Final Handover
| Control event | Matrix treatment | Handover visibility |
|---|---|---|
| Approved URS revision | Keep the requirement linked through the approved revision | Prevents later qualification from relying on an obsolete requirement set |
| Unresolved requirement | Retain the requirement with its deviation record and approval status | Shows what remains unresolved at handover |
| Reused FAT result | Link the factory result and documented reuse rationale to the applicable URS clause | Makes reliance on factory evidence explicit |
By the time a project reaches handover, the traceability matrix has usually absorbed multiple rounds of change — requirements revised after initial approval, results that did not meet their acceptance criterion on first attempt, and decisions to reuse earlier evidence rather than repeat a test. The task at this final stage is not generating new evidence but confirming that nothing in this accumulated history has become invisible.
An approved URS revision needs to remain linked to the requirement it replaced, not simply overwrite it, so that a reviewer examining evidence generated before the revision can see which version of the requirement that evidence actually supports. Where this link is broken — where a revised requirement quietly replaces an earlier one with no visible connection between them — later qualification stages risk verifying against a requirement set that no longer matches what was formally approved, which is difficult to detect internally and difficult to defend if raised during inspection.
Unresolved requirements need the same visibility, not suppression. A requirement that could not be fully verified, or that generated a deviation still under evaluation at the point of handover, should remain present in the matrix with its deviation record and current approval status attached, rather than being dropped from the active list because the project is closing. This is consistent with EudraLex Volume 4 Annexe 15‘s treatment of the validation life cycle, in which URS functions as a persistent reference point running through design qualification and into acceptance testing, with FAT and SAT roles and the distinction between IQ and OQ evidence kept separate rather than treated as interchangeable — a structure that only holds if the requirement and its current status remain traceable at the point evidence is finally reviewed.
Reused FAT results deserve the same closing scrutiny. If a factory result was carried forward to stand in for a site-stage verification, the documented rationale for that reuse needs to still be present and still be defensible at handover, not have been dropped somewhere between FAT and final review. Annex 15 supports FAT et SAT having justified, distinct roles, which means a reused result without its rationale attached does not meet that standard on its own — the rationale is part of the evidence, not a formality separate from it.
Where the project information supplied by the customer — the original URS, subsequent revisions, and site-specific conditions — has been captured accurately during configuration and quotation review, this final matrix reconciliation is largely a matter of confirming that nothing was lost along the way rather than reconstructing missing links after the fact.
Questions fréquemment posées
Q : How should a buyer prepare URS clauses for traceability before supplier review?
A : Give each clause a stable identifier and keep that identifier through approved revisions. Structure the matrix to link the supplier response, relevant design document, planned test protocol, project-specific acceptance criterion, result, deviation, and approval status to that identifier, so gaps remain visible across the qualification stages.
Q : What should the buyer check before accepting design qualification?
A : Confirm that every applicable URS clause points to both the supplier response and approved design evidence showing how the proposed design addresses the requirement. Any clause without a clear link should remain visible with its deviation and approval status before fabrication choices become costly to change.
Q : How should a requirement be assigned to FAT, SAT, IQ, or OQ?
A : Assign it to the stage where its condition can be demonstrated credibly: factory results for suitable pre-shipment checks, site results for conditions demonstrated on site, installation checks for the delivered configuration, and operational challenges for approved operating conditions. Record the stage choice and project-specific acceptance criterion beside the clause so later evidence can be judged against the intended check.
Q : When can a FAT result be reused instead of repeating verification later?
A : Reuse it only when the matrix identifies the applicable URS clause, links the recorded factory result, and documents the rationale for relying on it. Check whether delivery, installation, site conditions, or an approved revision changed the condition being verified; if so, assign additional verification at the credible later stage.
Q : What should be reviewed in the matrix before final handover?
A : Check that evidence points to the current approved URS revision and that each planned verification has a result or a visible deviation and approval status. Give special attention to unresolved requirements and reused FAT evidence so their current status and documented rationale remain explicit at handover.
