Validation V-Model Explained

What Is the Validation V-Model?

The validation V-Model is a structured diagram used in computer system validation (CSV) to organise the relationship between specifications and evidence. The left side descends from user intent into design; the right side ascends from installation through operational testing to intended-use confirmation. Traceability — the documented links between each layer — is the horizontal spine connecting both sides.

The V-Model originates from software development lifecycle (SDLC) thinking, where verification confirms you built the product right and validation confirms you built the right product. CSV adapted the model for regulated environments: instead of generic unit and integration tests, the right side uses IQ, OQ, and PQ qualification layers tied to GMP intended use.

In practice, the V-Model is not a regulatory form — it is the map most validation teams use to show that controlled system behaviour was specified, configured, tested, and supported by objective evidence. GXPLearn Module 10 frames it as tracing the validation spine from requirement to evidence.

Why the V-Model Matters

Structured validation reduces the risk of releasing systems with untested critical functions. Without a V-Model discipline, teams accumulate documents that do not connect — an OQ protocol that never references the URS, or a design spec with no corresponding test.

Traceability is the primary value. A requirements traceability matrix proves each approved requirement has an implementation and a test, connecting intent, design, risk, and evidence. Regulators and internal QA reviewers ask the same question: how do you know this function works as intended?

The V-Model also supports risk reduction by exposing gaps early. A requirement with no test mapped in the matrix is visible before batch release — not during an inspection. FDA GPSV emphasises that validation cannot succeed without defined user requirements; the V-Model is how teams operationalise that principle.

Left Side of the V

The left side captures intent and design — what the system must do and how it will be built or configured. Each layer should be testable and traceable to the layer below.

User Requirements Specification

The URS documents intended use from the process and quality perspective — what the system must achieve in production or quality operations. Requirements must be testable: BR-201 shall maintain Growth Hold at 37.0 °C ± 1.0 °C is verifiable; "system shall be user-friendly" is not.

In GXPLearn Module 09, URS-14 requires automatic XV-101 closure when LI-101 exceeds 90%; URS-15 requires manual open commands to be rejected during high-level conditions. These drive the entire OQ-INT-001 protocol chain.

Functional Requirements

Functional requirements (or functional specifications) translate URS into system behaviour — interlock logic, alarm handling, batch step sequencing, access roles. They answer how the system implements user intent without yet specifying every configuration parameter.

Module 09 maps URS-14 to FRS-INT-014 and URS-15 to FRS-INT-015 — the functional layer auditors expect between user intent and detailed design.

Design Specification

Design or configuration specifications describe the implemented solution — module downloads, phase logic, setpoints, alarm priorities, interface mappings. For configured products (GAMP Category 4), this is often a configuration specification rather than custom source code.

Design review at this stage evaluates whether outputs meet requirements before build commitment — a GPSV and GAMP supporting process that prevents expensive downstream defects.

Configuration Strategy

Configuration strategy defines how the system will be built or configured under control — revision management, download procedures, environment separation, and configuration audit trails. It bridges design intent to the implemented baseline verified at the bottom of the V.

Bottom of the V: Build, Configuration and Implementation

The bottom of the V is where specifications become reality — build, configuration, coding, and implementation. In automation CSV, this is typically controlled configuration: DeltaV module downloads, recipe parameterisation, HMI graphics, historian tags, and interface mappings executed under change control.

Configuration management is intrinsic to defensible validation. The installed baseline must match the approved design before IQ and OQ begin. Running functional tests against an unverified configuration undermines the entire right side of the V.

Development activities for custom code (GAMP Category 5) also sit here — but with additional design review, coding standards, and unit testing expectations before qualification on the right side.

Right Side of the V

The right side produces verification and validation evidence — proving the configured system meets specifications and intended use. Each layer traces back to requirements on the left.

Installation Qualification (IQ)

IQ confirms the system is installed according to approved specifications — hardware, software versions, configuration downloads, network environment, and baseline records. In Module 10, IQ maps to installation and download checks before functional testing begins.

See IQ, OQ & PQ explained for detailed IQ scope and common mistakes such as running OQ before confirming the installation baseline.

Operational Qualification (OQ)

OQ demonstrates functional behaviour across defined operating ranges under controlled test conditions. Module 09 executes OQ-INT-001 against the BR-201 interlock scenario with predefined steps, acceptance criteria, and deviation handling when Step 2 fails.

Each OQ step should trace to a functional requirement and URS — not exist as an isolated checklist. The requirements traceability matrix links URS-14 through FRS-INT-014, risk RA-014, OQ Step 1, and evidence EV-OQ-001.

Performance Qualification (PQ)

PQ confirms performance in intended-use or production-like conditions — representative batch runs, trend review, alarm and event evidence. In Module 10, PQ maps to intended-use confirmation such as Growth Hold maintaining controlled temperature during a batch with batch records and historian trends as evidence.

PQ answers whether the system performs reliably in real use — beyond what controlled OQ alone can demonstrate.

Traceability Throughout the V

Traceability is the documented linkage from URS through functional and design specifications to test cases and objective evidence. A traceability matrix is the tool most teams use to make the V-Model auditable.

Requirement mapping: every GMP-critical URS should have at least one test and one evidence record. Test coverage: tests should address real intended-use risks, not only happy-path scenarios. Defect management: when OQ fails — as in DEV-OQ-INT-001 — the V-Model requires documented investigation, correction under change control, retest, and closure before the requirement can be considered verified.

Module 10's Traceability Matrix Builder (TB-1: Bioreactor Temperature Loop) practises mapping three URS through functional spec, design spec, test, and evidence — with distractors that look plausible but do not prove the requirement.

A requirement with no corresponding test is a direct audit finding. The V-Model is a traceability tool, not paperwork theatre.

V-Model and CSV

Computer System Validation (CSV) uses the V-Model as its structural backbone. CSV is not a single test event — it spans URS, specifications, IQ/OQ/PQ, traceability matrices, validation summary reports, and change control. The V-Model shows how those artefacts connect.

The What is CSV? guide explains the regulatory baseline for fitness for intended use. The V-Model explains how CSV teams organise evidence so reviewers can follow the chain from requirement to test result without guessing.

Data integrity controls — audit trails, access control, electronic signatures — should be specified on the left and verified on the right. See What is data integrity in GxP? for ALCOA+ expectations that apply across every traceability layer.

V-Model and CSA

Computer Software Assurance (CSA) does not replace the V-Model — it proportions effort within it. The V-Model defines what must be traced; CSA critical thinking defines how rigorously each function is tested based on process risk and intended use.

Module 10 includes a CSA lens on each V-Model node: depth of evidence depends on process risk. A high-risk interlock warrants scripted OQ with full traceability; a non-GxP tooltip change may warrant lighter assurance under CSA thinking.

The What is CSA? guide explains FDA's risk-based assurance framework. Many organisations keep V-Model structure for GxP-critical functions while applying CSA to right-size testing methods and documentation depth.

V-Model and GAMP 5

ISPE GAMP 5 describes lifecycle approaches consistent with V-Model thinking — specification on the left, verification on the right, with risk management and traceability as supporting processes throughout.

GAMP software categorisation influences how many specification layers and test stages the V-Model requires. Category 3 non-configured products may use an abbreviated V with URS and installation verification; Category 4 configured systems need full left-side specifications and business process testing on the right; Category 5 custom code adds design review and structural testing at the bottom and right.

See GAMP 5 categories explained for how categorisation scales validation effort within the V-Model structure.

V-Model Across the Validation Lifecycle

The V-Model is the diagram inside the broader validation lifecycle — not the lifecycle itself. Concept and project planning establish scope; the V-Model organises specification and evidence during project execution; operation maintains traceability through change control and periodic review.

The Validation lifecycle explained guide walks through GPSV principles from requirements through change control and maintained validated state. IQ/OQ/PQ detail on the right side lives in IQ, OQ & PQ explained.

When a change occurs — configuration update, software patch, recipe modification — the V-Model discipline requires impact assessment: which left-side specifications changed, which right-side tests must be repeated, and how traceability matrices are updated before returning to validated state.

How GXPLearn Teaches V-Model Thinking

GXPLearn practises the V-Model through interactive modules — not slide-deck theory.

Module 10 (V-Model) — explore the interactive V-Model map linking URS, FS, design, build, IQ, OQ, and PQ for BR-201 Growth Hold; build requirement-to-evidence chains; judge objective evidence quality; walk deviation-to-retest flows; and complete the Traceability Matrix Builder.

Module 09 (CSV Validation) — execute OQ-INT-001 with live simulation, document DEV-OQ-INT-001, and close with retest evidence EV-OQ-002R — the right-side execution that Module 10 traces back to URS.

Modules 11–12 add CSA assurance sizing and CSV vs CSA comparison on the same V-Model spine. Module 24's Validation Digital Twin capstone integrates change impact, regression testing, and package review across the full V.

Start at /app?mod=vmodel or follow CSV & CSA training for the guided validation path.