Designed for GxP.
Controlled by you.

Requirements and risk

Maintain URS, FS, DS and configuration specification (CS) records in the platform, linked to the process, its risks and its tests. Keep the specification current as the configuration evolves.

Change impact

Keep changes linked to affected requirements, configuration and evidence. Record what needs verification and why existing evidence can be reused.

Automated checks

Run configured automated UAT and regression checks on each configuration change. Keep results linked to the configuration and specification versions under review, including failures and retests.

Connected evidence

Bring supplier evidence, automated results and human testing into the same assurance record. Trace a requirement through its checks, anomalies and review.

Release and ongoing review

Approve a defined baseline with its evidence and residual risks. Keep subsequent changes, incidents and periodic reviews connected to that accepted state.

Seal maintains specification records alongside the configuration and its verification evidence. The user requirements specification (URS) describes what the operation needs. The functional specification (FS) describes the required behavior; the design specification (DS) describes how it is implemented.

For a configured process, the configuration specification (CS) describes the actual fields, workflows, calculations, permissions, interfaces and approval rules. It is kept up to date in Seal as the configuration changes, with version history preserving the previously approved state.

Requirements link to the checks that verify them, so a revision and its evidence can be reviewed together. The depth of specification follows the complexity and risk of the intended use. These records can live in the platform without becoming four separate document-writing exercises.

Seal provides the platform controls and integrated assurance capabilities. Review the supplier verification and release evidence for the version in scope, then identify the process, configuration and integration checks needed for your use.

Your team owns the intended use, process requirements, risk acceptance and production approval. That includes qualification of integrations and migrated data, user procedures, training and operational readiness.

GAMP 5 Second Edition supports risk-based lifecycle assurance, critical thinking, iterative development and the use of software tools and automation. The focus remains intended use, patient safety, product quality and data integrity.

FDA’s February 2026 CSA guidance addresses medical-device production and quality-management software. It supports proportionate assurance activities and objective evidence, including automated and unscripted testing where appropriate to the risk.

Continuous validation describes how we bring that lifecycle into the work: assess changes, verify affected functions and retain the evidence supporting each release. Neither guidance makes every update automatically validated or removes the need for an intended-use assessment.

No. Customer data is not used to train AI models. Records retained in Seal provide working context for neil; that is different from training the underlying model.

neil follows the requester’s access permissions. It cannot grant itself access or cross organisations. Required people and signatures still govern changes: a recommendation is not a released change.

Seal supports choices of region, AI provider and keys. The platform’s storage location and the model’s processing location are separate parts of the deployment review.

Ask us to confirm the hosting provider and region, model endpoint, subprocessors and any cross-border processing for your proposed deployment. Include backups, logs and support access in that review—not only the primary database.

The model and endpoint are selected for the deployment. We’ll confirm the supported options for your use case, including whether your organisation’s own provider account can be used.

Review the terms for that endpoint, its model-change policy and any additional services receiving data. Processing and retention terms can differ between services from the same provider.

Review the data flow for the intended job: the request, retrieved record content, attachments, tool results and generated response. Agree which data classes may be processed before connecting production records.

No training does not mean zero retention. Confirm retention and deletion separately for Seal records, AI-provider requests and responses, operational logs and backups. Do not assume a single retention period covers them all.

Scope the deployment around the data you intend to use. Before sharing sensitive records, agree the permitted data classes, processing purposes, access, locations and retention with your privacy and security teams. Confirm the applicable contractual arrangements for Seal and the selected AI provider.

An initial evaluation can use sample or appropriately redacted records. Include attachments, free-text fields and retrieved context in the assessment: removing a name from the prompt does not remove identifying information elsewhere in a record.

Review the finding against its source records before relying on it. A citation helps you inspect the evidence; it does not prove the interpretation. An investigation may identify a hypothesis without establishing a cause.

For a GxP use case, define acceptable outputs, reviewer responsibilities and the actions neil is allowed to propose. Include incomplete, conflicting and misleading source material in the evaluation. Release decisions stay with the authorised team.

Agree the evidence needed for the job: the request and requester, source records and versions, generated output, proposed or executed actions, and the reviewer’s decision. Confirm which model and configuration details are available in the deployment and how they are retained.

Preserve what supported the decision at the time. Sources can change, and a new response may differ from the original. Retain the original output and action evidence rather than relying on a later rerun or a generated explanation.

Yes. AI can be disabled for an individual system or the whole organisation. Scope its use to the tasks and records your team has assessed, with the required approval gates in place.

Review tenant isolation, identity and access management, encryption and key ownership, connector permissions, support access, incident response, backup recovery and data export.

See the published controls for data protection, access protection, recovery and security testing.

Retrieved documents can contain instructions that try to redirect an agent. Examine how the deployment handles this prompt-injection risk, restricts tool permissions and checks access when retrieving records or taking actions. Test attempts to expose restricted information or bypass an approval gate; a model instruction alone is not an access control.

The OWASP prompt-injection guidance can inform that review. Assess the actual deployment and its remaining risks; prompt-injection defenses are not an absolute guarantee.

Scope an initial investigation around reading the records it needs. Confirm that the selected connector and credentials can enforce that scope. Treat permission to write back as a separate decision, with defined actions, review gates and audit evidence.

Review service-account access as well as user access. A connector with broad source permissions needs an explicit assessment of how those permissions are narrowed for each requester. Test revoked access and permission changes, not just successful retrieval.

Define source identifiers, field mappings, units, time zones and acceptable data freshness. Test missing or delayed records, duplicates, changed schemas and partial failures. Reconcile the transferred records against the source rather than treating a successful connection as proof of complete data.

For write-back, test retries and conflicting updates. A repeated request should not create an unintended duplicate action. Agree who resolves exceptions and how incomplete work is identified before a downstream decision relies on it.

Automation executes the defined acceptance scenarios repeatedly: calculations, required fields, permissions, approval gates and interface behavior. Each configuration change gets fresh evidence from those checks. The risk assessment determines whether the change also needs new scenarios or additional human testing.

Your team still reviews the acceptance criteria, assesses the results and approves the intended use. A passing automated suite is evidence for that decision, not an automatic production approval. Failed checks, unresolved issues and retests remain part of the release review.

A reviewable result identifies the test version, application and configuration, environment, input data, expected and actual outcome, execution time and responsible person or automated runner. Supporting logs or records should make the outcome inspectable.

Use representative jobs with expert-reviewed acceptance criteria. For an investigation, assess source selection, factual support, missing evidence and the distinction between a hypothesis and a conclusion. For process configuration, inspect the proposed fields, calculations and gates against the approved procedure.

Include obsolete procedures, conflicting records, missing units, insufficient evidence and restricted access. Define when neil should stop or ask for clarification. Evaluate the same cases after a relevant model or configuration change, retaining failures as well as successful examples. A general model benchmark does not establish suitability for your process.

Retain the original failure and link it to the investigation, correction and retest. Distinguish a product defect from a test-data or environment problem. An unexecuted or inconclusive check is not a pass.

The release review considers unresolved anomalies, their impact and any accepted limitation or compensating control. A later passing run should not erase the earlier evidence.

No. A proposed test is a starting point. Review its expected behavior against the requirement, execute it in the relevant environment and retain the actual result.

For a critical function, include adverse and boundary conditions. Generating the configuration and its test from the same mistaken interpretation can make both agree while missing the requirement.

Confirm model-version availability and retirement notices for the selected provider. Do not assume a model name guarantees an unchanged version or that a provider will keep an older model available indefinitely.

Agree notification, evaluation and approval arrangements before adopting a replacement. Include changes to instructions, tools and retrieved context in the assessment, even when the model name has not changed.

Separate work that depends on the unavailable service from work that can continue under the approved procedure. Define what pauses, how people are notified and who authorises any manual alternative. An outage should not become permission to bypass a required control.

Test recovery with interrupted requests and partially completed actions. Confirm timeout, retry and reconciliation behavior for the deployment. If an alternative model or endpoint is proposed, assess its data-processing terms and intended-use evidence before authorising the switch.

No. The impact assessment sets the scope. Reuse relevant evidence with a documented rationale and verify affected functions through regression checks, new tests or further assessment as needed.

Agree change notification, test-environment access, deployment approval and recovery arrangements for your service. Periodic review should consider changes, incidents, access, recovery evidence and whether the intended use is still current.

Inspect who created or changed a record, when it happened and the relevant version. Test required signatures, authority checks and the effect of changing an approved record. Include restricted users and attempts to act on an obsolete version.

Agree record retention, readable export, audit-trail review, backup and restoration requirements. Demonstrate that retained records and their associated context can be retrieved for the required period.

Agree an exit plan before production use: the records to export, available formats, attachments, version history, signatures and audit evidence. Test that the receiving system can preserve the meaning and relationships your team needs to review the records.

Confirm retrieval access, migration support and deletion timing, including backups and provider-held data. Distinguish closing an account from ending a record-retention obligation. These details belong in the service and data-processing arrangements, not in an assumption that an export contains everything.

No software alone makes an operation compliant. Applicability depends on the intended use, jurisdiction and records involved. Your quality system, configuration, procedures, training and ongoing controls remain part of the assessment.

Review 21 CFR Part 11 for electronic records and signatures within its scope, and EU GMP Annex 11 for computerised systems. For medical devices, QMSR incorporates ISO 13485:2016 by reference. These are assessment references, not software certifications.