Carry the change into the work.

A traditional eQMS approves the document. Seal changes the work.

A traditional eQMS is a system of record. Its change control files the request, the assessment and the approval of a revised document, while the workflow, the form, the training and the copy at the line are changed somewhere else.

So a corrective action that ends with “update the procedure” is not finished when the change is approved. Someone still has to carry it into the execution form, the qualification records and the controlled copies, and then work out which revision is in force for the work already running.

In Seal the procedure, the workflow that runs it, the training and the copies are records the change can reach. A change carries the revision, the records it affects, its verification cases and their actual results, the decision on which work uses which revision, and the review of whether it worked. The next batch runs the released version, and earlier work keeps the version it ran against.

Figure 1 follows a corrective action through change control. DEV-⁠018 recorded a 52-minute post-mix hold on batch B-⁠041 against a 45-minute limit. CAPA-⁠012’s action, to show the elapsed hold time on the step, becomes CC-⁠019: MBR-⁠014 v05 calculates the elapsed time, keeps the limit at 45 minutes and routes holds over it for assessment. CC-⁠019 is verified with holds of 44, 45 and 46 minutes before release, and B-⁠042 then runs the released version. The sections below follow CC-⁠019 and a second change, CHG-⁠014, from the impact assessment to the effectiveness review.

You can start with one change, alongside the eQMS you already run: Seal connects to the documents, CAPAs and change controls in systems such as Veeva Vault QMS, MasterControl, Qualio and ETQ Reliance. The advantage grows as quality, manufacturing and laboratory work run on the same connected records: fewer changes carried by hand between systems, and a clearer path from a finding to an improvement that can be verified.

A corrective action becomes a change to the workflow.

When a CAPA’s action changes how the work runs, the change carries it: the reason, the current and proposed behaviour, the verification plan and the release review, linked to the finding that started it. ICH Q10 counts CAPA among the drivers of change that a change management system evaluates, approves and implements.¹

CC-⁠019 records why it exists: DEV-⁠018 found a 52-minute hold against the 45-minute limit. The limit stays at 45 minutes. What changes is the workflow: elapsed time is calculated from the start and transfer timestamps, a hold above the limit routes an exception for assessment, and a missing timestamp reports neither a duration nor a pass. The disposition of B-⁠041 remains a separate review.

The verification plan sits on the same change. Holds of 44 and 45 minutes must stay within the configured limit, 46 minutes must require the exception route, and a missing start time must leave the record incomplete. Figure 2 shows CC-⁠019 before release: the plan is still a draft and its cases are not yet executed. A saved plan is not a passed test. The release review asks for the impact assessment, the updated configuration specification, the executed checks and the training needs before authorised people approve release.

Configuration changes the way a procedure does: in a controlled manner, under a defined procedure, with its specification and evidence.² The relevant URS, FS, DS and configuration specification are kept in Seal and linked to the released version.³ That applies to the quality workflow itself too. A changed classification rule, approval route or closure gate carries its reason, proposed configuration and verification.

Seal keeps the action, its verification and its effectiveness review as distinct records. Showing the elapsed time on the step is the action. Demonstrating that it calculates and routes holds correctly is verification. Assessing whether hold exceptions recur over the agreed period is the effectiveness review.

One instruction changes three jobs.

A revised procedure rarely changes only the document. Adding one step to line clearance can need a new field on the execution form, a qualified person to perform the check and a matching copy at the line.

Proposed v05 of SOP-⁠PKG-⁠014 adds one instruction: “A qualified second person independently verifies clearance. Record the verifier, result and time before starting the line.” CHG-⁠014 links that revision to each record it affects, with a responsible role and the evidence needed to close the action. For the execution form, that is the verifier’s identity, the clearance result and the time, with evidence that missing and failed checks follow the required blocked path. For the qualification, it is an observed independent clearance, the assessor, the demonstrated scope and the procedure revision used. For the line-side copy, it is the reconciliation of the line 2 v04 copy with the authorised v05 cutover. None of those actions is complete, and approval remains open.

Confirm the scope beyond the known links. Inspect dependent procedures, forms, equipment, materials, suppliers and market commitments where relevant. Record why each candidate is included or excluded, what could not be checked and who must resolve it. A missing reference is not evidence of no impact. EU GMP asks for planned changes to be evaluated, using quality risk management, for their impact on documentation, validation, regulatory status, calibration, maintenance and other systems.⁴

Route the assessment to the technical and quality roles defined for the change. In the US, written production and process control procedures, including any changes, are drafted, reviewed and approved by the appropriate organisational units and reviewed and approved by the quality control unit.⁵

Different changes can follow different paths. Configure the assessment, required roles and implementation evidence for each change type: a major change with cross-functional review, a minor change with a proportionate path, a supplier change that starts from an external notification, and an authorised urgent-change path with recorded scope, limits and follow-up, so urgency does not become an unrecorded bypass.

Neil prepares the changeset. Your team decides.

Neil is Seal’s AI agent. Bring it the current procedure, the proposed revision and the reason for the change; it works across the records the requester is permitted to see and prepares the change as work in Seal, not a recommendation to retype.

To trace the impact, ask Neil to compare the current procedure with the proposed independent check and to show the source behind each candidate. It prepares a proposed impact assessment linked to both revisions, with implementation tasks, responsible roles and unresolved references. It distinguishes confirmed dependencies from candidates and shows what it could not inspect. People confirm the scope and the required reviews.

To author the workflow, ask it to configure the verifier, result and time capture, with the permission and qualification checks, the blocked paths and the verification cases, while preserving existing executions. It drafts the templates, capture fields, workflow states and requirement-linked cases, including missing evidence, a failed result and an unauthorised attempt. Where a script is needed, Neil can prepare and lint it for operator-run testing. The authorised team verifies the actual configuration and publishes the change.

To assemble readiness, ask what still prevents v05 becoming effective. Neil prepares a readiness assessment linked to the open implementation, training and copy actions, with the cutover tasks and an effectiveness review based on subsequent line starts. Missing evidence remains outstanding; Neil does not infer that a task is complete, sign an approval or make a revision effective.

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.

Test the behaviour. Keep the actual evidence.

A revised workflow needs evidence that it behaves as intended, including when the check is missing, fails or is attempted by someone without the qualification. Define the cases before release, then keep the actual results against the configuration that was tested.

CS-⁠PKG-⁠014 defines four cases for CHG-⁠014. 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; passing this check is not permission to start the line. CC-⁠019’s plan does the same for the hold, with 44, 45 and 46 minutes and a missing start time.

Record each actual result, the tested configuration and any exception against its case. As captured in Figures 2 and 5, both plans are still unexecuted, and neither a saved plan nor a published record establishes that the workflow works.

An executed case keeps the requirement, the configuration and procedure versions, the test inputs, the expected and observed behaviour, the executor, the date and the supporting evidence. Link exceptions to their assessment and any retest, and keep failed attempts. Confirm independence and qualification rules, permissions, in-progress records and recovery behaviour where the assessed scope requires them. The four cases shown are the example plan, not a complete validation strategy for every deployment.

Applicable automated verification and repeatable UAT checks run when the configuration changes, with actual results and exceptions retained against the proposed version. EU GMP asks for the supporting data to be reviewed to confirm that the impact of a change has been demonstrated before final approval.⁴ An automated check supports that decision; it is not an independent declaration of compliance. The continuous validation detail explains the risk-based assurance approach and responsibilities.

Decide which work uses which revision.

Approval of the change request, completion of implementation and permission to use the revised process are separate decisions. Set the effective point only after the required evidence, qualifications, controlled copies and operational dependencies have been reviewed.

Existing work retains its recorded version. Keep the instruction version, recorded checks and evidence used by existing work, and record any assessed transition or exception separately. Assess work in progress explicitly; do not silently move an execution onto the new instruction.

For v05, bring together the form verification, the supervisor qualification and the copy reconciliation before effective use. The fictional CHG-⁠014 assessment remains open.

Plan temporary limits and recovery. State how in-progress work will be handled, who can authorise an exception and what evidence is needed. Define any temporary restriction, its expiry, the responsible role and the recovery route. If the new configuration cannot be used, assess whether the earlier version remains suitable; reverting is not automatically safe or authorised. Keep the implementation history and the affected execution records.

Some changes also depend on a market. EU GMP expects planned changes to be evaluated and approved before implementation, taking into account regulatory notification and approval where required.⁶ Connect the change to the relevant product and market assessments, and keep pending filings, decisions and correspondence linked to it. An internal approval does not establish market permission.

Check whether the change solved the problem.

Define the effectiveness review before implementation, while the intended outcome is clear. After implementation, it confirms whether the change achieved its objective without an unintended effect on product quality.⁶

For CHG-⁠014, assess whether independent verification is being captured at the right point and whether clearance problems recur. A completed training task or a signed change alone does not answer those questions.

Define the population: the line, operations and instruction revision included, with exclusions and their rationale. Choose the measure: compare missing or late independent checks with the number of eligible line starts, and review clearance exceptions alongside the rate. Agree the review: the observation window, responsible reviewer and acceptance criteria. Link the source executions and create follow-up work for an unmet outcome.

This is a proposed review design. No effectiveness result is recorded for CHG-⁠014. For CC-⁠019, the review counts hold exceptions over the agreed period on the batches that run MBR-⁠014 v05. Both evaluations follow ICH Q10¹ and Annex 15,⁴ which ask for a change to be evaluated after implementation to confirm that it achieved its objective.

A change stays linked to the deviation, investigation and CAPA that started it, so its effectiveness review reads back to the original finding instead of inferring success from completed tasks.

Start with one change.

Bring one change you need to make: the current procedure, the proposed revision and the reason for it.

Neil prepares the impact assessment, the revised workflow and its verification cases 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 missing check, a failed result, an unqualified verifier, work in progress at cutover and the effectiveness review that follows. Verify both the allowed and the disallowed paths for the intended roles, including edits, execution and effective use.

Seal can run beside the eQMS you already use. Agree which system owns the change record, which records Seal reads and how status crosses the boundary. To scope the first change with us, book a demo.