Fitness for use, shown from the work.

A document-based validation tool files the protocol. Seal shows fitness from the work.

A document-based validation tool digitises the protocol. It authors the IQ, OQ and PQ packages, routes them for signature and files them. The question an inspector and an operator both ask is narrower and harder: is this equipment, this configuration and this process fit for its intended use today, and what shows it?

Validation evidence is usually assembled for a release and then filed. When a requirement or configuration changes later, the question is which results still apply, and a folder of signed protocols cannot answer it. Impact then has to be reconstructed by hand, which pushes teams towards broader revalidation than the change needs, or a narrower judgement that is hard to justify, and in practice towards freezing the system.

Seal’s case is not a better way to write the protocol. Fitness for intended use is shown from the work itself: equipment and system status is checked at the point of use, each configuration change is verified in proportion to its risk, and the release record carries its evidence under change control. Each change carries its own requirements, test evidence and approval, and automated checks run when the change is prepared for review, so validation moves with the configuration instead of stopping it.

The guidance points the same way. FDA’s computer software assurance guidance describes a risk-based approach to establishing confidence that software is fit for its intended use, and recommends digital records such as system logs, audit trails and other data the software generates over paper documentation, screenshots or duplicated results.¹ GAMP 5, Second Edition supports iterative and incremental methods, supplier involvement and automation, applied with the critical thinking of experienced subject-matter experts.²

EU GMP Annex 15 still names the qualification stages for equipment, facilities, utilities and systems: the user requirements specification, design, installation, operational and performance qualification.³ Where a site needs those stages, Seal’s evidence maps onto them, and the section on IQ, OQ and PQ below shows how.

Figure 1 follows CHG-⁠031, a fictional change that tightens a water-content limit from 0.50% (v03) to 0.40% (v04). Its checks run before release: 0.40% stays within the limit, 0.45% is now outside it, a missing reading requires a result and a reading in the wrong unit is rejected. The next result runs on v04, with the titrator and the analyst checked when the result is recorded. Evidence recorded under v03 stays attached to v03.

Check fitness at the point of use.

A qualification report says the equipment was fit when it was tested. The work needs to know whether it is fit now, for this use. Configure the requirements in the workflow that selects the equipment, so a missing prerequisite stops the configured path at the moment of use.

HPLC-⁠007 carries its intended uses. Release testing under AM-⁠014 v03 requires a qualified range, calibration, maintenance and analyst qualification; troubleshooting requires an authorised service work order and isolation. After a flow check measured 0.92 mL/min at a 1.00 mL/min set point against a 0.98–1.02 mL/min interval, new analytical use is blocked pending a flow assessment, while service work goes ahead with no reportable sample results.

A current calibration is one prerequisite. A release test may also require a qualified range, a particular configuration, a clean state and an authorised analyst. Record the asset, the intended use, the applicable rules and the supporting evidence with the execution. A failed or missing prerequisite stops that configured path and makes the reason clear. See equipment management for the full asset model.

Return to use is its own decision. RTS-⁠007 records the repair and the parts used, post-service flow readings of 0.998, 1.002 and 1.000 mL/min and a leak check, and still shows no permitted analytical use until the review is complete. The impact of the original 0.92 mL/min finding on earlier sequences has its own assessment. Bring together the qualification, calibration, maintenance and remaining restrictions, and make the authorisation decision separately from saving or completing a record.

Annex 15 asks for equipment, facilities, utilities and systems to be evaluated at an appropriate frequency to confirm that they remain in a state of control,³ and Annex 11 asks for computerised systems to be evaluated periodically to confirm that they remain valid.⁴ A check at the point of use does not replace that evaluation. It makes the state of control part of every execution, and gives the periodic review a record of each use to read. Software verification does not replace physical qualification either: the equipment still needs the qualification and calibration evidence appropriate to its intended use.

Map the evidence onto IQ, OQ and PQ where a site needs them.

Annex 15 describes qualification as stages from the user requirements specification to the end of use.³ Each stage asks for something to be demonstrated. In Seal, that evidence is recorded with the work it concerns, so it can be grouped by stage where a site’s validation plan uses them.

Requirements, specifications and tests are controlled records linked to the configuration. The URS describes what the operation needs, the functional and design specifications describe the required behaviour and how it is implemented, and the configuration specification describes the actual fields, workflows, calculations, permissions, interfaces and approval rules. The depth of each follows the complexity and risk of the intended use. Annex 11 asks for user requirements to be traceable throughout the life cycle.⁴

Installation checks record the equipment identity, components, instrument tags, materials, utilities, software and firmware against the installed configuration. Operational cases test the upper and lower operating limits and worst-case conditions, with the expected and actual results. Performance runs link to the batches and samples they produced. For a new system taken from URS and risk through FAT, SAT, IQ, OQ, PQ and turnover, see commissioning and qualification.

Annex 15 allows qualification documents to be combined where appropriate, such as IQ and OQ, and, where justified, some tests performed at factory acceptance need not be repeated on site if it can be shown that transport and installation did not affect the functionality. Results that fail their pre-defined acceptance criteria are recorded as deviations and investigated, and conditional approval to proceed to the next stage needs a documented assessment that the open items have no significant impact on it.³ Keep each of those assessments with the evidence it concerns.

Verify each change in proportion to its risk.

A change is assessed against the accepted intended use, requirements and risks. The assessment records which evidence still applies and which checks must run again, and the selected checks run against the candidate version before it is released.

The input stays the same; the expected outcome changes. CHG-⁠031 changes a limit, not a recorded result. A 0.45% input needs a different expected outcome under the proposed rule. 0.40% sits on the new boundary, which both limits include. A missing reading remains missing under either version, and invalid input must not become a passing result. Only the 0.45% case needs a revised expectation; the others confirm the boundary and the failure paths still behave.

In Seal, keep the intended use, requirement revision, tested configuration and execution evidence together. When a requirement changes, assess which tests and dependent workflows need another look. Earlier results retain their original scope.

Selected user acceptance tests run in a background simulation when a change is prepared for review, and their results join the release review with the previous approved state preserved. Publication requires current passing results for the required tests. Configure which tests each kind of change selects across the governed scope: a change that matches no rule has no automated coverage. Not every update needs full revalidation; the impact assessment sets the scope, relevant evidence is reused with a documented rationale and affected functions are verified through regression checks, new tests or further assessment.

Annex 11 asks for changes to a computerised system, including its configuration, to be made in a controlled manner under a defined procedure, and for automated testing tools to have documented assessments of their adequacy.⁴ ICH Q9(R1) uses quality risk management to set the scope and extent of verification, qualification and validation.⁵ FDA’s CSA guidance applies risk-based testing: more rigour, such as scripted testing, where a failure would be a high process risk, and unscripted methods such as scenario testing, error guessing and exploratory testing where it would not.¹

Test the paths that should not continue.

A verification plan needs more than an ordinary passing value. Define boundary cases, invalid or missing inputs, incompatible units and restricted actions. Capture the expected behaviour before execution, then retain the actual result and any deviation.

This native Seal example proposes an independent check before line start. Its cases cover an absent verifier, a failed check and missing qualification. With no verifier recorded, or a failed clearance check, line start is blocked. Without the required qualification, the independent-check task is unavailable. With the required checks met, the work continues to the remaining start requirements. The plan is saved; the verification is still unexecuted.

Annex 11 asks for test methods and scenarios to consider system parameter limits, data limits and error handling.⁴ A reviewable result identifies the test version, the application and configuration, the environment, the input data, the expected and actual outcome, the execution time and the responsible person or automated runner. Retain the original failure and link it to the investigation, correction and retest. An unexecuted or inconclusive check is not a pass, and a later passing run does not erase the earlier evidence.

FDA’s CSA guidance describes the record the same way: the intended use, the result of the risk-based analysis, the testing conducted, the issues found and their resolution, a conclusion on acceptability, who performed it and when, and review and approval where appropriate.¹

Neil prepares the verification. Your team decides.

Neil is Seal’s AI agent. Give it the requirement and the configuration; it compares the proposed change with the tested baseline, traces the affected records and prepares the verification as structured cases, capture fields and review steps rather than a prose test specification.

To prepare the change-impact package, ask Neil to compare the requirement revision with the tested baseline and show which expectations, workflows and evidence are affected. It prepares proposed revised cases, a traceable verification scope and an explicit list of coverage gaps. Prior execution evidence remains attached to its original version.

To author the executable workflow, ask it to configure the plan template, the linked result records and the review states from the requirements. It drafts templates, fields and configuration to inspect and test. Where a script is needed, Neil can prepare it and verification cases for operator-run testing.

To prepare the review, ask it to collect the execution evidence, deviations and unresolved prerequisites for the intended-use review. It drafts a review package showing what was tested, against which version and what is still unresolved. People assess the results and authorise intended use.

Your team checks the source criteria and coverage, tests the configuration and reviews the actual evidence. Missing requirements stay explicit; generated expectations are not execution results. A proposed test is a starting point: for a critical function, include adverse and boundary conditions, because a configuration and its test generated from the same mistaken reading of a requirement can agree with each other and both miss it.

In line with the EU’s draft GMP Annex 22 on AI, Neil is not used in GMP execution. It helps set up configuration, which your team verifies and releases under change control. Customer data is not used to train AI models, and the requester’s permissions govern what Neil can read. See how Neil fits Annex 22 and more about Neil.

The release record carries its evidence.

Release is a decision on a defined baseline: the selected requirements, the executed results, the deviations and the remaining limitations. Authorised reviewers decide what the evidence supports, separately from saving or completing a record.

CC-⁠019, from the change control page, shows the shape: the reason, the current and proposed configuration, the verification plan and a release review that asks for the impact assessment, the updated configuration specification, the executed checks and the training needs before authorised people approve release. Its cases are still planned; a saved plan is not a passed test.

Supplier testing of the platform can support your assessment. It does not establish that your particular configuration, integrations, permissions or intended use have been verified. Seal provides the platform controls and its own verification and release evidence for the version in scope; your team owns the intended use, the process requirements, risk acceptance and production approval, including the qualification of integrations and migrated data. The validation guide sets out where each boundary sits.

Seal validates other software the same way. Each release of a supplier system, such as a hosted LIMS, is a change control whose required Check runs the automated test cases against the new version and requires a passing manual run before Quality signs; the computer system assurance blueprint follows one release from a failed step to its retest.

Bring together the selected requirements, executed results, deviations and unresolved limitations. Authorised reviewers decide what the evidence supports. Reuse a plan’s structure across sites without treating one execution as proof for every installation. Annex 15 asks for the supporting data to be reviewed to confirm that the impact of a change has been demonstrated before final approval, and for the effectiveness of the change to be evaluated after implementation where appropriate.³ Annex 11 asks for validation documentation to include change control records and reports on deviations observed during validation.⁴

Start with one change.

Bring one configuration change you need to make, with its requirement and current test evidence.

Neil prepares the impact assessment, the verification cases and the review package from that material, and your team inspects them against how the work should run. Start with sample material or arrange an NDA before sharing confidential records.

Test the complete cycle before you rely on it: a boundary value, a missing reading, an invalid unit, a failed case and its retest, an equipment prerequisite that has lapsed, and the release decision that follows.

Use existing protocols as source material for the configured plan. Preserve imported evidence with its original version and context; importing it does not establish that it covers the current use. To scope the first change with us, book a demo.