Turn procedures into the way work runs.

1A document system controls the file. Seal makes the procedure govern the work.

A traditional document management system is a system of record for files. It controls a procedure’s approval, effective date and read-and-understood training, and it sits beside the work the procedure governs. It can show who approved a revision. It cannot put the new check in front of the next operator.

So a revision is approved and the work is not finished. Someone must still change the form, train the right people, verify the behaviour and make sure the next run uses the right version. When those live in separate systems, every improvement becomes a coordination project.

Seal links the instruction to the forms, qualifications and execution rules it governs. Documents, training, manufacturing, laboratory and quality share one platform, so a revision carries its reason, impact assessment, configuration and verification through change control to a controlled release. Once it is effective, the next run follows the new version, and the records already created keep the one they used.

You can start with one procedure, alongside the document system you already have. The advantage grows as forms, training and execution move onto the same foundation: fewer lists to reconcile after each revision, and a clearer path from an approved change to the work that follows it.

2Neil prepares the revision. Your team decides.

Neil is Seal’s AI agent. It works across the same records your team does, within the permissions of the person asking, and prepares a revision as work in the system: the revised instruction, the records it affects and the configuration change that implements it.

Everything in the middle column is preparation. Reviewers check Neil’s proposals against the source and confirm the scope. Neil does not sign for an approver or make a procedure effective by itself; required people and signatures still control approval.

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, how AI works with your data and more about Neil.

3Assess what a revision touches before approving it.

A wording correction and a new process step do not need the same implementation plan. Record the reason for the change, then assess the roles, forms, references and work it affects.

In this example, adding an independent line-clearance check to SOP-PKG-014 affects the operator’s instruction, a supervisor’s qualification, the form used to record the result and the printed copy at packaging line 2. Those are linked changes to one operation, not separate documents to reconcile later.

The assessment records a decision for each area: the training for each role, the execution behaviour to verify, the effective date and copy reconciliation, and how work already started on v04 is handled. Approval stays open until that evidence has been reviewed.

4Turn an instruction into an execution rule.

“Get a second person to check” becomes something specific: who can perform the check, which result is acceptable and what evidence must be recorded.

The proposed configuration makes those conditions explicit. A missing verifier, a failed check or a missing qualification keeps the line start blocked. Meeting this check allows the process to continue to its remaining requirements; it does not release the batch.

An SOP explains what to do. A linked form or workflow captures what happened: required fields, measurements and units, calculations, observations, attachments and signatures where needed. Define the form once as a controlled template, and the same kind of rule can govern manufacturing execution or laboratory workflows.

5Approval and effectiveness are different decisions.

Approval records agreement to a version. Effectiveness determines when it can be used, and the outgoing version stays effective until the replacement is ready.

Plan the cutover around the applicable training, verification, implementation tasks and outstanding copies, not only a date on a PDF. Keep a clear distinction between an approved version awaiting implementation and the instruction currently in use. Historical versions remain available to authorised reviewers without being presented as current instructions.

Each execution retains its version, values and history. Revising the template prepares future work; it does not silently rewrite a completed record.¹ An investigation can therefore follow the recorded result back to the exact instruction and configuration used.

6Train for the change, not only the document.

The impact assessment determines who needs training and what they need to demonstrate. Opening a document is not proof of competence.

A clarification may need acknowledgement; a changed operation may need instruction, an assessment or observed practice. Connect assignments to the relevant procedure version, role and activity, and configure qualification checks where the work runs, so a completed training record supports the task it was intended for.

A proposed revision should not automatically invalidate every person’s existing qualification before the cutover has been assessed. Assignments, assessments and qualification evidence are covered in training and qualification.

7Continuous validation makes improvement part of the operation.

A validated system should be able to improve. When a procedure revision changes an executable workflow, its requirements, configuration, test evidence and approval belong to the same controlled change.²

Keep the user requirements specification (URS), functional specification (FS), design specification (DS) and configuration specification (CS) linked to the implementation in Seal.³ Run automated verification and repeatable UAT checks for the changed behaviour, retain results and exceptions against the proposed version, and review the evidence before release. Neil prepares the specifications and verification cases with the change, so the evidence is drafted with it rather than after it.

The assurance effort follows intended use and risk; an editorial correction does not need to be treated as a new manufacturing process. Requirements, implementation and verification stay connected as the process evolves, so going live starts that lifecycle rather than freezing it. The continuous validation detail explains the risk-based assurance approach and responsibilities.

8Keep the full document lifecycle in view.

The same records support the rest of document control. Review content and implementation impact together, with the required people and signature meanings defined by your process.⁴

A new edition of an external standard is assessed before the local process changes. A digital status cannot retrieve a physical printout, so local confirmation remains part of copy control. A periodic review considers source changes, deviations, audit findings and feedback, and records whether to retain, revise or retire the instruction. Archived versions stay intelligible after the process changes, for the required retention period.

9Start with one procedure, beside the system you have.

Bring an effective SOP, a proposed revision and the form or training requirement it affects to a demo. We work through the current process, model the relationships and agree what needs to be demonstrated before use.

A captured version is referenced with @ in documents, comments and Neil, and stays linked to its original. You do not need to replace these systems to start. Each connection is scoped before it goes live: what Seal may read, whether anything is written back and which system stays the source of truth. See all integrations.

The 48-hour evaluation turns that one procedure into a working workflow with a validation pack to inspect, so you judge Seal on your own procedure rather than a demonstration. Production timing then depends on scope, interfaces, migration and your release requirements.

For migration, inventory the source population, map document types and owners, preserve available versions and approval evidence, and reconcile imported records. Do not invent missing history or treat a file upload as an approved baseline. Agree the migration scope and acceptance checks before expanding to the next document family.