Documentation Index
Fetch the complete documentation index at: https://docs.seal.run/llms.txt
Use this file to discover all available pages before exploring further.
Why Seal is different
Traditional GxP systems are frozen after validation. Any change risks triggering months of re-validation work. Teams are forced to choose between compliance and improvement—a fundamental conflict between the goals of quality and the operational needs of the business. Seal resolves this. Unlike systems that must be locked down after validation, Seal is built so that every configuration change goes through Change Sets with formal review and approval, and automated tests verify the system after every change. You evolve your configuration without compromising your validated state. Pharmaceutical, biotech, and medical device companies run their GxP-regulated operations on Seal — GMP manufacturing, GLP laboratories, GCP clinical trials. Customers run their entire QMS on Seal: document control, deviations, CAPAs, change control.The FDA has inspected companies using Seal as their QMS and MES.
What is platform vs. what is built for you?
A common question from quality teams is where platform ends and customer-specific work begins. There are three distinct layers:Core platform
The software every customer runs — audit trails, e-signatures, access controls, version history, change sets, search, and the document editor.
Blueprints
Standard modules (ELN, QMS, Inventory, Samples, etc.) version-controlled and tested within the core platform codebase. Every customer runs the same blueprints.
Your configuration
The templates, fields, workflows, review requirements, permissions, and automations you set up through the UI.
| Layer | Who develops it | Who validates it | How it changes |
|---|---|---|---|
| Core platform | Seal engineering | Seal (development lifecycle + automated testing) | Release process with customer notification |
| Blueprints (modules) | Seal engineering | Seal (development lifecycle + automated testing) | Release process with customer notification |
| Your configuration | Customer and/or Seal during implementation | Customer (with Seal guidance) | Change sets with formal review |
| Customer-specific scripts | Seal engineering (with customer) | Seal and customer jointly | Change sets with code review and individual test cases |
Validating your configuration
Software validation is the process of ensuring and documenting that a system is fit for its intended use. The level of formality scales with risk. Most customers fall into one of two pathways:GxP systems
GMP, GLP, GCP environments. Formal validation with risk assessment, Validation Master Plan, and compliance documentation.
Non-GxP / R&D
Simpler User Acceptance Testing focused on fitness for purpose. Faster, lighter documentation.
In practice: You don’t need to validate that electronic signatures work, that audit trails are immutable, that access controls enforce permissions, or that the ELN, QMS, or Inventory modules function correctly — Seal validates all of that through its development lifecycle and provides the evidence. Your effort is concentrated on confirming your specific workflows, templates, and business rules are configured correctly.
Non-GxP: User Acceptance Testing
For non-GxP systems (early-stage R&D, non-regulated workflows), the goal is to ensure and document that Seal is fit for your intended purpose. This is achieved through a lightweight UAT process. Your responsibilities:- Define requirements — outline the specific configurations and workflows you need
- Perform UAT — test against your real-world use cases to confirm Seal is configured correctly
- Document acceptance — sign off on a summary report confirming fitness for purpose
If your system doesn’t have a direct GxP impact, you don’t need the formal methodology below. The UAT process above is sufficient.
GxP validation
For GxP systems (GMP, GLP, GCP), a formal validation process is required. We handle the heavy lifting—you review and approve. Seal’s validation methodology is built on GAMP 5 2nd Edition and the FDA’s Computer Software Assurance guidance (finalized September 2025), informed by consultation with an author of GAMP 5 2nd Edition. Seal follows CSA (Computerized System Assurance) — the modern, risk-focused alternative to traditional CSV, endorsed by the FDA.Validation lifecycle
Requirements are defined at increasing levels of detail, then verified through corresponding tests. Risk assessment drives which tests are required and how rigorous they need to be.| Phase | What happens | Deliverable | Responsibility |
|---|---|---|---|
| Validation Master Plan | Agree strategy, scope, resources, and acceptance criteria | Approved VMP | Seal drafts, you approve |
| User Requirements | Document your workflows, business rules, and regulatory requirements | Approved URS | You provide, Seal documents |
| Functional Spec + Risk Assessment | Define how the platform meets each requirement; risk assessment determines test scope | Approved FS, risk assessment | Seal drafts, you review |
| Configuration | Build and configure your Seal instance to specification; iterative review | Configured system ready for testing | Seal builds, you review |
| Test Execution | Automated and manual tests against functional spec | Executed test evidence with pass/fail | Seal executes, results documented |
| User Acceptance Testing | You test against your user requirements with real workflows | Signed UAT evidence | You execute, Seal supports |
| Validation Report + Go Live | Summary of all evidence, deviations, and formal sign-off | Signed validation summary report | Seal drafts, you approve |
What you get
Every Seal customer receives our validation template pack:| Template | Purpose |
|---|---|
| Validation Master Plan | Overall strategy, scope, resources, deliverables |
| Risk Assessment | Identify and mitigate risks to patient safety and product quality |
| User Requirement Specification | Document your specific requirements |
| Functional Specification | Define how the platform works |
| Traceability Matrix | Map requirements to functions |
| Change Control | Manage and document configuration changes |
| Automated validation guide | Set up automated configuration tests |
Platform development lifecycle
Seal maintains a formalized software development lifecycle for the core platform and blueprints, aligned with GAMP 5 2nd Edition agile lifecycle principles and independently verified through SOC 2 Type II controls.How platform software is developed
Every code change goes through a mandatory process before it reaches production:- Development — engineer builds the change in a version-controlled feature branch with associated automated tests
- Automated test suite — CI/CD pipeline runs unit, integration, and end-to-end tests; changes that fail any test cannot proceed
- Peer code review — mandatory pull request review assessing correctness, security, and test coverage
- Quality review — changes affecting GxP-relevant functionality (audit trails, signatures, access controls, data integrity) receive additional review against compliance requirements
- Staging validation — deployed to a staging environment mirroring production; automated end-to-end tests run again
- Release preview — functional changes are made available as a release preview with advance notice before becoming generally available
- Production release — zero-downtime deployment with automated health checks (see Deployment process)
Testing strategy
| Test layer | What it covers | When it runs |
|---|---|---|
| Unit tests | Individual functions and components in isolation | Every code change |
| Integration tests | Service interactions, database operations, API contracts | Every code change |
| End-to-end tests | Full user workflows through the browser | Every code change and daily against production |
| Security testing | Vulnerability scanning, dependency auditing, penetration testing | Continuous; annual third-party penetration test |
| Performance testing | Load testing, response time monitoring | Continuous in production |
- Visual — a living record of every page Seal continuously monitors for visual regressions. Each row shows a preview thumbnail of the committed baseline, when it last changed, who signed off, and the reason given — along with the full history of earlier changes. Pages that haven’t moved in months carry a “No prior changes” marker; the absence of change is itself the compliance story.
- Integration — every backend integration test in the current release, with pass/fail status, last-run time, and duration. Failures surface a “N failing” tag; opening a row reveals the per-assertion detail.
- Unit — the same shape as Integration, for unit-level tests.
Quality management system
Seal operates under its own quality management system: document control, training (including secure coding and GxP awareness), internal audits, CAPAs, and quarterly management review. SOC 2 Type II certification provides independent third-party assurance that these controls are operating effectively — see trust.seal.run. Internal SOPs are available for review during vendor audits.Change management
All platform changes follow a documented change management process: tracked issues with defined scope, risk assessment and categorization (risk levels), mandatory code review, automated testing, and staged deployment. Customer notification is governed by the Release process.Staying validated
Once validated, how do you stay validated as your system evolves? Two mechanisms work together:Change control
All modifications—configuration, data, workflows—go through Change Sets with formal review and approval. Before any change goes live:- Impact assessment — the system shows exactly what will change
- Review and approval — designated reviewers approve with an electronic signature requiring re-authentication, meeting 21 CFR Part 11 requirements
- Audit trail — every change is logged with who, what, when, and why
- Automated tests — configuration tests run to verify nothing broke
Learn more about Change Sets.
Continuous testing
Seal can generate and execute User Acceptance Tests for your configured workflows. Tests are written in natural language (e.g., “Create a Batch Record from the Production template and verify all required fields appear”), reviewed and approved by your team. Seal executes them automatically, recording video and system events as audit evidence. When tests run:- Every platform release — your test suite runs automatically before your team uses a new Seal version
- After configuration changes — verify workflows still work after you modify templates, fields, or approval chains
- On demand — trigger tests manually whenever you need assurance
Frequently asked questions
How are platform updates managed?
How are platform updates managed?
All functionality changes are released behind Release Previews — Organisation Admins control when they take effect, and production is not affected until your team enables the release. A dedicated preview environment is available for running UAT before go-live. See Release process.
What is the format of test protocols and how are they approved?
What is the format of test protocols and how are they approved?
Testing follows the risk-based approach agreed in the Validation Master Plan at the start of the project.
- Infrastructure: Covered by SOC 2 Type II certification — see Infrastructure and Data Storage & Security.
- Test execution: Seal executes test scripts against your configured workflows. Protocols are shared for pre-approval; executed evidence (pass/fail, screenshots, timestamps) is provided for post-approval sign-off.
- User Acceptance Testing: Your team tests against real-world use cases. Seal provides UAT templates and support.
Does Seal provide test evidence for traceability matrices?
Does Seal provide test evidence for traceability matrices?
Yes. Seal provides documentation mapping platform capabilities to your User Requirement Specification — including test IDs, descriptions, and results for requirements met by the core platform and standard blueprints. Executed platform tests are visible in the Validation page within your Seal organisation, across the Visual, Integration, and Unit tabs.
How does visual regression monitoring work?
How does visual regression monitoring work?
Every platform release captures baseline images of the pages your team uses — the sign-in screen, your change-sets list, and a rolling sample of your published entities and the change sets that publish them. On every code change, the candidate build is rendered and compared pixel-for-pixel against those baselines, and a difference fails CI on the engineer’s pull request. Visual changes follow the same model as release previews: an engineer can only land a change to a baseline by tying it to a release preview you control (so the change is gated behind a flag you enable on your schedule) or by classifying it as a bug fix — both are recorded as part of the merge. The Visual tab on the Validation page surfaces that record alongside the rest of your audit trail. Coverage expands as new surfaces become eligible (the system home, inbox, and settings pages will be re-added once the cross-org reader account holds system membership in your organisation).
How long does validation take?
How long does validation take?
Non-GxP validations typically complete in days. GxP validations take 4–7 weeks depending on complexity—still much faster than traditional approaches. Contact us for a specific estimate.
When should I validate?
When should I validate?
Validate when implementation is complete—with everything built and configured. For larger implementations, we support phased validation where individual workflows are validated as they go live.
Can I validate the system myself?
Can I validate the system myself?
Yes. Seal’s validation documentation and templates adapt to fit your QMS. You have full control—and we’re here if you need us.
Does Seal provide validation templates and reports?
Does Seal provide validation templates and reports?
Yes. We provide a comprehensive validation package including templates for URS and Risk Assessment, platform validation documentation, and a Validation Summary Report you can generate on-demand.
Do I need to revalidate if my organisation moves site?
Do I need to revalidate if my organisation moves site?
No. There is no change to server locations, databases, or core system architecture when your organisation moves. Our Customer Success team can support any risk assessments you need.
How does the API tie in with validation?
How does the API tie in with validation?
The API enables data flow but does not change platform behaviour. You are responsible for documenting your API configuration and risk assessment. The API itself is tested as part of Seal’s routine testing.
Does Seal provide User Acceptance Tests?
Does Seal provide User Acceptance Tests?
Yes. We provide baseline UAT scripts that you can use as a starting point for testing your specific configuration.
Are Seal's modules custom-built for each customer?
Are Seal's modules custom-built for each customer?
No. Modules (ELN, QMS, Inventory, Samples, etc.) are standard blueprints developed, tested, and maintained as part of the core platform. Every customer gets the same blueprints. You configure them for your processes.
Do automations make Seal a Category 5 system?
Do automations make Seal a Category 5 system?
No. Every configurable software system has a formula language — Excel has formulas, ERP systems have calculated fields, LIMS platforms have rule builders. Seal’s automations are the same concept, using Python syntax instead of a proprietary expression language. Writing
mass = density * volume is configuration, not custom software development. A single complex formula does not reclassify the entire system as Category 5, just as a complex Excel formula does not make a spreadsheet bespoke software. Automations are sandboxed to the entity they belong to and are Category 4 configuration. Where a specific script involves genuinely bespoke logic, that individual script is validated as a Category 5 element within the Category 4 system.Does Seal maintain a library of reusable software components?
Does Seal maintain a library of reusable software components?
Seal’s blueprints (ELN, QMS, Inventory, etc.) are the library — standard modules available to all customers, maintained through the core platform development lifecycle. There is no separate library of custom code blocks assembled per customer. Configurations can be exported and imported between organisations as standard platform functionality.
Do I have to validate features that are not enabled?
Do I have to validate features that are not enabled?
No. Disabled features have no interaction with your platform and don’t require validation.