Commissioning and qualification.

1Start from intended use and risk.

Commissioning, qualification and validation should create a defensible chain from intended use and process risk to design, installation, operation, performance, release and continued control. In many projects that chain is split across requirements spreadsheets, vendor documents, paper protocols, punch lists and summary reports, and it is rebuilt by hand for every review. Seal keeps requirements, risks, design objects, assets, tests, instruments, people, exceptions, changes and release decisions as one connected set of records, through project delivery and into routine operation.

The validation plan defines scope, regulatory basis, lifecycle strategy, systems and boundaries, the direct-impact rationale, roles and release stages. It begins with what the operation must reliably achieve, not a list of protocol documents. User requirements are atomic: one need, with its rationale, criticality, acceptance intent, source and owner.¹ Derived functional and design requirements keep their parents, so any requirement can be traced forward to verification and any result back to the approved need.

Risk assessment identifies critical functions, failure modes, controls and the assurance each needs, and links directly to the requirements and tests it influences. Reduced testing, supplier leverage or commissioning credit each carries an approved basis; “low risk” is not a substitute for rationale. Under EU GMP Annex 15, changes that could affect the qualified or validated state go through change control.² Seal provides the connected execution model; the manufacturer’s validation policy remains authoritative.

System boundaries close the gaps between packages. An air handler is not qualified independently of its rooms, controls, alarms, sensors and monitoring. Boundary records carry upstream and downstream dependencies, utility tie-ins, data interfaces, shared instruments and handoff criteria, so cross-system tests can verify behaviour that no single package owns.

1.1Why teams choose Seal for commissioning and qualification

A document-led CQV project leaves requirements in spreadsheets, protocols on paper or in a validation tool, and a summary report that is archived at handover while operations starts from scratch. Seal keeps the requirements, risks, tests, exceptions and turnover decisions connected and in use after release, so the qualified baseline is the reference that change control and periodic review work from. A later change or calibration failure shows exactly which requirements and tests it reopens, instead of starting a fresh qualification exercise.

2Treat design review and supplier evidence as evidence.

Specifications, drawings, material selections, control narratives, alarm lists, software configuration and data flows are reviewed against requirements and risk. Each comment has an owner, disposition, evidence and approval, so design review is a record rather than a meeting date. A design change identifies the requirements, risks, tests, purchases and previously accepted evidence it affects before it is implemented.

Supplier evidence is assessed before it is leveraged. Vendor qualification, quality history, test methods and data integrity determine what can be accepted, and FAT results earn commissioning or qualification credit only under an approved strategy. Seal records the source, witness status, configuration, deviations, raw evidence and intended credit. A vendor PDF is not treated as equivalent to verified traceability.

3Commission the asset that was actually installed.

Commissioning checks capture equipment identity, component and instrument tags, materials, wiring, piping, utilities, software and firmware, setpoints, alarms, interlocks and baseline operation. Results attach to the physical asset and its current configuration. Punch items carry severity, owner, due date, blocking status and their effect on turnover or qualification, so an open item cannot drop out of view between phases.

4Generate protocols from reusable test designs.

Approved test templates define the objective, linked requirements and risks, prerequisites, method, expected results, instruments, acceptance logic, roles and exception behaviour. A project protocol instantiates the effective template against the exact asset and configuration, and retains any approved deviation from it. Reuse applies to the design, not to copy-and-paste execution.

Each stage keeps its purpose. Factory acceptance verifies the supplier’s build and function; site acceptance verifies receipt, installation effects and integration; IQ confirms installed state; OQ challenges operating ranges and functions; PQ demonstrates performance in the intended operating context. Stages can be combined or adapted under an approved lifecycle strategy while the intent and evidence of each test remain visible. A stage label does not substitute for coverage.

5Record execution, eligibility and exceptions as they happen.

Executors confirm prerequisites, identify the actual asset and configuration, scan instruments, record actual values and times, attach source evidence and sign their results. Corrections preserve the original entry and the reason.³ Where testing runs offline in the field, synchronisation, conflict handling and time authority are defined in advance.

Instruments and people must be eligible at the time of use. Test equipment carries its calibration range, status, due date and standards traceability; personnel qualification connects training and authorisation to the test role. Because eligibility is recorded against each execution, a later calibration failure identifies the tests recorded as using that instrument and opens an impact assessment.

A failed acceptance becomes an exception attached to the exact requirement, step, expected result, actual observation and evidence. Investigation, correction, retest and approval stay connected, and a retest creates new evidence without overwriting the original failure. Protocol completion distinguishes accepted, accepted with justified open items, failed, aborted and superseded.

6Calculate coverage from the links.

Coverage is computed from the records rather than maintained in a spreadsheet. It shows each requirement and risk against design, test, result, exception, change and final status, and exposes untested requirements, orphan tests, open failures and requirements verified only in an obsolete configuration.

The denominator is explicit. A requirement removed or made not applicable stays in the history with its rationale and approval instead of disappearing from a favourable percentage. The same applies to project measures such as first-pass yield, retest rate, exceptions by system and open critical punch items: each links to its denominator and source records, so a high protocol-completion percentage cannot hide untested critical requirements or open release blockers.

7Release on readiness and keep the baseline in use.

Mechanical completion, commissioning, qualification, calibration, preventive maintenance, procedures, training, drawings, software backup and open items converge into a turnover decision for each system. A room or process area becomes ready only when its dependent systems meet the configured criteria, and Seal shows the specific evidence that is still preventing release.

The qualified-state decision fixes the system boundary, configuration, software and firmware, requirements, risk, completed tests, open conditions and accountable signatures. That baseline becomes the reference for change control, periodic review, maintenance, calibration and deviation impact. A proposed modification is compared with it to identify the requirements, tests, documents and training affected, and the approved impact sets the re-verification scope. Periodic review then evaluates changes, deviations, calibration and performance, so requalification follows risk and evidence rather than a calendar reminder alone.

8Prove one system boundary through handover.

Take one representative direct-impact system from URS and risk through design, supplier evidence, FAT, installation, SAT, IQ, OQ, exceptions, turnover and qualified-state release. Include the difficult cases: a changed requirement, a leveraged vendor test, a missing calibration certificate, a failed interlock and its retest, a late design change and a conditional open item. The model is ready when a reviewer can go from requirement to result, and back, without a spreadsheet.