Establish the system definition, GAMP 5 categorisation (Category 5 — custom), and intended use before any requirement is written. Without this, validation scope is undefendable at inspection.
Author the Validation Master Plan (VMP) and a system-specific Validation Plan (VP) that fix scope, deliverables, roles, risk approach (CSA), acceptance criteria, and the definition of "validated".
Stand up the Quality Management System wrappers: SOPs for SDLC, CSV/CSA, change control, deviation/CAPA, document control, supplier management, periodic review, BCP/DR.
Key activities (detailed)
System inventory entry + GxP determination: does the system create/modify/approve/retain/transmit GxP records? Classify GxP-critical vs GxP-supporting vs non-GxP.
GAMP 5 software category assignment (Cat 5 custom for Verixa core; Cat 3/4 for any COTS/configured components). Drives validation rigour.
Intended Use Statement per module — specific, not "manages quality". Defines records, decisions supported, user population, and AI role (advisory vs deterministic).
Regulatory applicability matrix — confirm which of Part 11, Annex 11, Annex 22, EU AI Act, FDA CSA, ICH E6(R3), 21 CFR 211 apply per module and market.
CSA strategy — declare the risk-based assurance approach (scripted vs unscripted vs automated vs leveraged supplier evidence) so test effort tracks risk, per FDA CSA.
Roles & training matrix, document control numbering, and the traceability strategy (RTM owner, tooling) established now and maintained through every later phase.
RACI
Activity
R
A
C
I
VMP / Validation Plan
RValidation Lead
AHead of QA
CSV/CSA Lead, Reg Affairs
Eng Lead, Product
GAMP 5 / GxP classification
RCSV/CSA Lead
AHead of QA
Product Owner
Engineering
Intended Use Statements
RProduct Owner
AHead of QA
AI Governance, SME
Eng, Test
QMS / SOP framework
RQA
AHead of QA
All function leads
All staff
Evidence / deliverables produced
Validation Master Plan (VMP)Approved, version-controlled
System-specific Validation Plan (VP)Scope, CSA approach, acceptance
Exit gate: VMP + VP approved and signed by Head of QA; GxP classification locked; intended use baselined. No requirements work proceeds until the VP defines how it will be validated.
Capture user requirements as atomic, uniquely-numbered, testable statements covering functional, workflow-state, data/record, audit trail, e-signature, role/permission, AI governance, reporting/export, integration, performance, and security/privacy needs.
Every URS line becomes a traceability anchor — it must flow to design → test → evidence with no orphans.
Key activities (detailed)
Process mapping with business SMEs for each eQMS workflow (e.g. Deviation → RCA → CAPA, Change Control, Complaint, Audit/Finding, Batch/OOS where GMP).
Requirement authoring — atomic ("the system shall…"), testable, no vague verbs. Each tagged with GxP domain (GCP/GVP/GMP/GDP/GLP/GDocP) and criticality.
Records & audit trail requirements — for every regulated record define create/modify/delete/approve/retrieve events, before/after capture, reason-for-change, retention.
E-signature requirements — signature meaning, authority, manifestation in UI and export, record-signature binding.
AI requirements — intended use, advisory-vs-deterministic label, human-in-the-loop points, model/prompt versioning, citation/explainability, confidence handling, audit logging of inputs/outputs/overrides.
Acceptance criteria per requirement so the Test Architect can design pass/fail tests.
CSV/CSA URS review — independent quality check for atomicity, testability, coverage gaps, and traceability readiness; defects logged and resolved.
RACI
Activity
R
A
C
I
Author URS
RProduct Owner / BA
AHead of QA
Business SME, Eng Lead, AI Gov
Test, DevOps
URS quality review
RCSV/CSA Lead
AHead of QA
Data Integrity SME
Product
Approve / baseline URS
RQA
AHead of QA
Reg Affairs
All
Evidence / deliverables
Approved URSAtomic, numbered, testable
URS review / defect logIssues resolved before baseline
Run function-level risk assessment (severity × probability × detectability) per ICH Q9(R1) to set assurance rigour. This is the engine of Computer Software Assurance — high-risk functions get strong scripted evidence; low-risk get justified lighter assurance.
Confirm GxP impact and the EU AI Act / Annex 22 risk classification for every AI function (high-risk vs limited-risk).
Key activities (detailed)
Function decomposition from URS; for each, identify failure modes and GxP/patient-safety/data-integrity impact.
Risk scoring → High / Medium / Low with documented rationale and the control that mitigates it.
CSA test-strategy mapping — assign assurance method per function (scripted / unscripted / automated / supplier-evidence / review-only) with rationale.
AI risk classification — batch/OOS/deviation/CAPA prediction → High-Risk (EU AI Act Annex III); copilot/analytics → Limited-Risk transparency. Confirm prohibition: no generative/probabilistic AI in critical GMP decisions (Annex 22).
Data integrity risk — ALCOA+ exposure per record class; identify where audit trail / e-sig / retention controls are mandatory.
AI Risk ClassificationEU AI Act / Annex 22 tiering
Exit gate: every URS function has a risk level + assurance method; AI functions classified; no high-risk function left without a planned control and test approach.
Translate URS into Functional Requirements Spec (FRS), Software/System Design Spec (SDS), data model, API contracts, audit-event model, and configuration spec — each mapped back to URS IDs.
Design the secure multi-tenant architecture: tenant isolation (RLS), RBAC, audit-trail substrate, e-signature service, encryption, and AI module boundaries.
Key activities (detailed)
FRS — functional behaviour, workflow state machines, business rules, field validation, notifications, error handling.
SDS / architecture — services, schema, tenant-isolation model (Row-Level Security + TDAL), API design, observability, audit-event catalogue (create/modify/delete/approve/export with before/after + reason).
Part 11 / Annex 11 design controls — audit trail as append-only & non-modifiable; e-signature manifestation + record binding; time source (server UTC, TIMESTAMPTZ); retention/archival design.
AI design — advisory output segregation (AI never writes to GxP-critical fields without human e-sign); model registry; prompt template version control; ai_requests/llm_audit_log design; HITL gates & confidence-threshold escalation.
Security/privacy by design — authn/MFA, authorization, encryption at rest/in transit, key management, PII/PHI handling, data-residency, subprocessor map.
Architecture Decision Records (ADRs) + design review; RTM updated URS→FRS→SDS.
AI design + model registry specAnnex 22 / EU AI Act hooks
Security/privacy designThreat model, data flow
RTM (URS→FRS→SDS)No orphan requirements
Exit gate: design reviewed & approved; every URS traced to FRS/SDS; Part 11, DI, AI-governance, and security controls explicitly designed (not deferred). Design baseline frozen for build.
Implement the design under a controlled, version-managed, secure SDLC where every line is audit-inspectable and every regulated mutation carries audit trail, attribution, and tenant isolation.
Key activities (detailed)
Source control & branching — protected main, PR-based, every change traceable to a requirement/ticket; commit standards.
Coding standards (GxP) — audit trail on every INSERT/UPDATE/DELETE; created_by/updated_by attribution; server-generated UTC timestamps; RLS + tenant-scoped data access on every query; zero any types; no dead code; parameterised SQL.
AI implementation guardrails — AI output flagged advisory; never written to GxP-critical fields without human e-sign; model/prompt versions + inputs/outputs/overrides logged to audit tables; no LLM in critical GMP modules.
Unit tests written alongside code (happy path, validation failure, permission denied, not-found, tenant isolation, audit-trail verification) — same commit, not a follow-up.
RACI
Activity
R
A
C
I
Implementation
REngineers
AEng Lead
Architect, DI SME
QA
Code review
RSenior Eng (peer)
AEng Lead
Security
QA
AI guardrail implementation
REngineers
AAI Governance Lead
CSV/CSA
Head of QA
Pipeline security gates
RDevSecOps
ASecurity Lead
Eng Lead
QA
Evidence / deliverables
Source code + commit historyTraceable to requirements
Prove the system meets the URS through a risk-proportionate test campaign. The CSA Test Strategy from Phase 2 dictates depth: scripted pre-approved protocols for high-risk; exploratory/automated for lower-risk.
Key activities (detailed)
Test design by Test Architect — each test case linked to URS + risk, with preconditions, data, steps, defined expected result, and evidence to capture.
Test layers — unit (done in build) → integration/API → system/functional → regression → performance/load → UAT with business SMEs.
E-signature tests — success, failed auth, unauthorized signer, record-changed-after-sign, manifestation in UI & export, signature meaning & binding.
AI assurance tests — HITL enforced, advisory labelling, model/prompt version logging, citation/explainability present, low-confidence escalation, override audit, prohibition of autonomous critical decisions.
Security testing — authz/tenant-isolation tests, OWASP, and an independent penetration test; vulnerabilities triaged.
Defect & deviation management — root cause, impact, retest; no critical defect left open without QA risk decision; results captured as ALCOA+ evidence.
RACI
Activity
R
A
C
I
Test design & protocols
RTest Architect
AHead of QA
CSV/CSA, DI SME, AI Gov
Eng
Test execution & evidence
RQA Testers
ATest Architect
Eng (fixes)
Product
Penetration test
RSecurity / 3rd-party
ASecurity Lead
DevSecOps
Head of QA
Defect/deviation disposition
RQA
AHead of QA
Eng Lead
Product
Evidence / deliverables
Approved test protocolsScripted for high-risk
Executed test evidencePass/fail, screenshots, logs
Defect & deviation logResolved or risk-accepted
Pen-test & security reportFindings triaged
Performance/load resultsAgainst criteria
RTM (→ test cases & results)High-risk URS directly tested
Exit gate: all planned tests executed; high-risk functions directly evidenced; DI/audit/e-sig/AI/security tests passed; deviations resolved or formally risk-accepted; RTM shows no orphan high-risk requirement or test.
Promote the validated build to the qualified production cloud environment under formal change control, with rollback, monitoring, and a complete release evidence index — without bypassing QA disposition.
Key activities (detailed)
Cloud / infrastructure qualification — qualify the IaaS/PaaS (regions, network, IAM, encryption, backup) and leverage supplier evidence (SOC 2 Type II, ISO 27001, pen-test summary) under a supplier qualification + quality agreement.
Change record for the release — scope, classification, impact assessment, validation impact, regression scope, rollback, customer-notification decision (Release & Change Control Manager).
Deployment controls — blue/green or canary; database migration plan with idempotent, reversible, audited migrations; feature-flag state confirmed and change-controlled.
Rollback plan — trigger conditions, owner, technical steps, data/audit/e-sig impact, AI model/prompt rollback, communication; tested where material.
Production monitoring & observability — error rate, audit-event failures, e-sig failures, AI output errors, integration failures, security events, with defined thresholds & owners.
Release notes drafted; deployment evidence captured (version, time, who, result).
Demonstrate, with approved evidence, that the system is installed correctly, operates per spec, and performs in the production environment for its intended use — then obtain the formal QA release disposition. This is where "validated" is earned.
Key activities (detailed)
Installation Qualification (IQ) — verify the production deployment, configuration baseline, environment, integrations, and access controls are installed as designed.
Operational Qualification (OQ) — verify functions operate per FRS across the risk-based test set in the qualified environment (workflows, audit trail, e-sig, RBAC, AI HITL, reports/exports, negative/boundary).
Performance Qualification (PQ) — verify the system performs for intended use under representative conditions/data, often with business SMEs; confirm DI controls hold end-to-end.
RTM closure — every URS → risk → design → test → evidence; no orphans; every deviation traced to resolution; every high-risk & AI & Part 11 function traced to verification evidence.
Validation Summary Report (VSR) — system/version, intended use, scope, risk summary, test summary, deviations, open defects with risk, traceability status, supplier evidence used, Part 11/Annex 11/AI status, residual risk, limitations, QA conclusion.
QA release disposition — Head of QA reviews the VSR + release-control pack and issues the disposition. Only authorised humans approve; AI does not.
RACI
Activity
R
A
C
I
IQ / OQ / PQ execution
RValidation Lead / Test
AHead of QA
Eng, DevOps, SME
Product
RTM closure
RCSV/CSA Lead
AHead of QA
Test Architect
Eng
VSR authoring
RValidation Lead
AHead of QA
CSV/CSA, Reg Affairs
Product
Release disposition
RHead of QA
AHead of QA
Reg Affairs
All
Evidence / deliverables
IQ / OQ / PQ protocols + executed evidenceSigned
Closed RTMFull bidirectional traceability
Validation Summary Report (VSR)QA conclusion on fitness
Deviation closure recordsResolved / risk-accepted
QA Release DispositionSigned release decision
Validation package indexInspection-ready
Exit gate: IQ/OQ/PQ passed; RTM closed; VSR concludes fit for intended use (or with conditions); Head of QA signs the release disposition. System is now validated for the stated scope & version.
Stand up the customer's tenant and configuration, define the shared responsibility split, and equip the customer's QA to validate their intended use. Verixa provides evidence that may support customer validation — it never certifies customer compliance.
Key activities (detailed)
Implementation plan + customer intended use — modules in scope, GxP processes, version, go-live target, validation owner, customer QA owner.
Shared Responsibility Matrix — who owns intended use, SOP alignment, configuration approval, role assignment, training, validation execution, UAT, migration approval, AI oversight, periodic review.
Data migration (if in scope) — source→target mapping, transformation rules, test migration, reconciliation, exception handling, customer approval. DI controls owned by DI SME; validation impact by CSV/CSA.
Integration onboarding — API auth, mapping, error/retry, test environment, customer-side validation responsibility, security review.
Customer Validation Support Pack — system overview, shared-responsibility matrix, supplier qualification pack, VSR/release notes, URS/RA/RTM templates, Part 11/Annex 11 control matrix, audit-trail & e-sig descriptions, AI governance evidence, DI matrix, security/privacy summary, known limitations.
Training — admin, end-user, QA approver, e-signature, audit-trail review, AI feature; training records owned by customer.
RACI
Activity
R
A
C
I
Implementation plan & tenant setup
RImplementation Lead
ACustomer Success Lead
Customer QA, DevOps
Head of QA
Shared responsibility matrix
RImplementation Lead
AHead of QA
Customer QA, Legal
Customer admin
Validation support pack
RCSV/CSA Lead
AHead of QA
DI SME, AI Gov, Security
Customer QA
Migration & integration
RImplementation / Eng
ACustomer QA (approval)
DI SME, Security
Head of QA
Evidence / deliverables
Implementation planScope, owners, timeline
Shared Responsibility MatrixVerixa vs customer
Approved tenant configurationCustomer-signed
Customer Validation Support PackEvidence index
Migration reconciliationIf applicable
Training recordsCustomer-owned
Exit gate: tenant configured & customer-approved; shared responsibility agreed; validation support pack delivered; migration reconciled; training ready. Implementation readiness handed to customer QA — no customer-compliance claim made by Verixa.
The customer validates the configured system against their intended use, SOPs, and risk assessment — leveraging Verixa's evidence — and their QA approves go-live. Verixa supports and coordinates; the customer's QA owns the validation approval.
Key activities (detailed)
Customer validation plan — customer authors/approves their VP, URS, risk assessment, and RTM using Verixa templates; defines what they leverage vs test themselves (CSA leveraging).
Customer UAT / PQ — business users execute scripts against their configured workflows & data; defects and (if validation) deviations managed; ALCOA+ evidence captured.
Configuration & SOP verification — confirm tenant config matches approved design; SOPs aligned to system behaviour; roles correctly assigned.
Go-Live Readiness Gate — intended use defined; config approved; training complete; UAT/validation status known; open defects reviewed; migration reconciled; integrations tested; AI governance reviewed; DI & security evidence in place; Verixa release version QA-approved.
Customer VSR + go-live approval — customer QA signs. Verixa Head of QA confirms Verixa's quality position only.
Hypercare — defined support channel, escalation path, GxP/AI/security escalation, duration, and lessons-learned review before steady-state support handoff.
RACI
Activity
R
A
C
I
Customer validation execution
RCustomer validation team
ACustomer QA
Verixa Implementation, CSV/CSA
Verixa Head of QA
Go-live readiness assessment
RImplementation Lead
ACustomer QA
Verixa Head of QA
Customer Success
Customer go-live approval
RCustomer QA
ACustomer QA
Customer Reg Affairs
Verixa
Hypercare
RVerixa Support / Impl
ACustomer Success Lead
Eng, QA
Customer admin
Evidence / deliverables
Customer VP / URS / RA / RTMCustomer-owned
Customer UAT/PQ evidenceExecuted, signed
Go-Live Readiness checklistAll gates passed
Customer VSR + go-live approvalCustomer QA signed
Hypercare planChannels, escalation, duration
Exit gate (Go-Live): customer QA approves go-live against their intended use; hypercare active. System in regulated production use at the customer. Verixa asserts only that its evidence may support the customer's validation.
Keep the system in a validated state for its operating life. Every change — feature, fix, config, AI model/prompt, supplier/cloud, security — is controlled, impact-assessed, re-validated to the extent of its risk, and QA-disposed. Uncontrolled SaaS change is the failure mode this phase exists to stop.
Key activities (detailed)
Change intake & classification — administrative / cosmetic / standard / normal GxP-supporting / major GxP-impacting / critical / emergency / AI change / supplier-cloud change. Classification sets minimum control.
Routing to specialist owners — validation impact → CSV/CSA; record/audit/e-sig → Data Integrity; AI → AI Governance; security/privacy → Security; supplier/cloud → Supplier Quality. "Unknown impact ≠ no impact."
Regression scope — targeted, risk-based; full regression when shared high-risk components change; detailed cases by Test Architect.
AI change control — model swap, version, system/prompt template, retrieval corpus, threshold, automation authority — each requires AI governance review + validation impact + regression before release; prohibition on autonomous critical GMP decisions re-confirmed.
Re-validation & re-release — affected IQ/OQ/PQ re-executed; VSR addendum; Head of QA re-disposes; customer notification decision; deploy with rollback & monitoring (loops back through Phases 5–7, and 9 if customer-impacting).
Periodic review — confirm intended use current, access appropriate, config controlled, audit trails complete, backup/restore effective, incidents/deviations/CAPA reviewed, AI monitoring & drift current, validation state maintained.
Continued operation controls — incident/deviation/CAPA, BCP/DR & backup-restore testing (RTO/RPO), AI drift & performance monitoring, supplier re-qualification, and eventual decommissioning with data retention/migration/archival per Part 11 retention.
RACI
Activity
R
A
C
I
Change intake / classification / impact
RRelease & Change Control Mgr
AHead of QA
CSV/CSA, DI, AI Gov, Security
Product, CS
Re-validation
RValidation Lead
AHead of QA
Test Architect
Eng
Periodic review
RCSV/CSA Lead
AHead of QA
DI, AI Gov, Security
Product
BCP/DR & monitoring
RSRE / Security
AHead of QA
DevOps
Customer Success
Change QA disposition
RHead of QA
AHead of QA
Reg Affairs
All
Evidence / deliverables
Change records (classified)Impact-assessed, routed
Operating rule: no production change reaches users without classification + impact assessment + specialist routing + risk-based re-validation + Head of QA disposition. Periodic review confirms the validated state is maintained between changes.
Deep-Dive Sub-Flow — GxP Data Migration & Integration Validation
The strict, evidence-first procedure for any time regulated records, audit trails, e-signatures, attachments, linked records, AI-source documents, customer tenant data, reports/exports, or integration payloads move between systems. Was a sub-bullet in Phases 6 & 8 — here it is in full.
Ownership rule for this sub-flow: the Migration & Integration Validation function recommends readiness and assembles evidence — it does not approve. Final migration execution approval = Head of QA (QA risk acceptance) + Release & Change Control Manager (cutover/release). Data-integrity adequacy → DI Expert; security/privacy → Security Expert; supplier/ETL tooling → Supplier Quality; detailed test scripts → Test Architect. Missing evidence is marked Unknown — evidence required and blocks readiness.
Preserve or controlled-archive the things that carry regulatory meaning
Data Integrity SME
▼
Key activities (detailed)
Audit trail — preserve who/what/when, previous & new value, reason, record context, original-source reference, plus migration-execution metadata (operator, timestamp, rule applied, exception history). If history isn't migrated → controlled archive strategy + retrieval procedure + target-record link + retention justification + QA (and customer) approval.
E-signature — preserve signer identity, date/time, meaning, reason, version signed, sequence, record linkage, source reference. If not migrated as active signatures → controlled archive + meaning preservation + retrieval method + legal/counsel handoff if admissibility is in question.
Metadata — created/modified by & date, owner, lifecycle state, version, effective/expiry dates, approval & training status, tenant ID, source/legacy/target IDs, migration batch ID & status. Defaulted/regenerated metadata = Unknown — evidence required until rule evidence exists.
Attachments — inventory with name/type/size/checksum-hash, source & target & version linkage, access restriction, retention, malware-scan evidence, failed/corrupted/duplicate handling, reconciliation. No attachment migration accepted without content/hash verification where feasible.
Handoff: final ALCOA+ / Part 11 / Annex 11 data-integrity adequacy is owned by the Data Integrity Expert — this sub-flow defines the requirements, not the adequacy verdict.
L4 — Functional: search works, record opens, workflow state displays correctly, reports/exports match expected source data, permissions apply, active-workflow records remain actionable, historical records retrievable.
L5 — Integrity: attachment hash/checksum (where feasible), audit-trail sequence intact or archived, signature meaning preserved or archived, metadata preserved/controlled, tenant boundary intact.
Rule: any unreconciled high-risk item is a readiness blocker unless explicitly accepted by Head of QA. Row counts alone are never accepted as reconciliation.
Hard stop: open critical defects, or open major defects without QA-reviewed disposition, block readiness. Repeated integration failures may trigger a deviation/CAPA.
📋 Governing SOPs:VRX-SOP-406VRX-SOP-901
21 CFR 11.10(e) audit of correctionsALCOA+ (attributable, original)ICH Q10 — CAPA on failuresEU Annex 11 §16 incident mgmt
M8
Cutover & Rollback
Controlled production switchover with a real, tested recovery path
Discipline — rollback is never just "restore backup": restore scope, timing, data-loss risk, and verification evidence must be defined and rehearsed.
RACI
Activity
R
A (approval)
C
I
Cutover plan & go/no-go
RMigration Lead
ARelease & Change Control Mgr + Head of QA
DevOps, DI SME, Customer QA
Customer Success
Rollback readiness
RSRE / Eng
ARelease & Change Control Mgr
BCP/DR, Security
Head of QA
Evidence / deliverables
Approved cutover planGo/no-go criteria
Tested rollback planRestore verified
Production execution + monitoring logsPost-cutover
Handoff: cutover/release approval is owned by the Release & Change Control Manager (+ Head of QA QA-risk acceptance); backup/restore feasibility is corroborated by the BCP/DR function. This sub-flow provides the cutover/rollback input.
Final Position — readiness (Ready / Conditionally ready / Not ready / Unknown); evidence sufficiency; and explicit "not owned by this skill" rows pointing DI adequacy → DI Expert, validation strategy → CSV/CSA, detailed protocols → Test Architect, QA risk → Head of QA, security → Security Expert, supplier → Supplier Quality, release/cutover → Release Mgr, audit pack → Audit Readiness, legal → Counsel.
Owner approval — Head of QA accepts residual QA risk; Release & Change Control Manager approves the cutover/release. Only then does production migration execute. Loops back to Phase 9 (customer reconciliation evidence) and Phase 10 (change record closure).
RACI
Activity
R
A (approval)
C
I
Evidence pack & final position
RMigration Validation Lead
AHead of QA
CSV/CSA, Audit Readiness
Release Mgr
Cutover/release approval
RRelease & Change Control Mgr
AHead of QA + Release Mgr
Customer QA (if customer data)
All
Evidence / deliverables
Migration/Integration Evidence PackInspection-ready index
Final Position tableReadiness + handoffs
QA risk acceptance + cutover approvalSigned by owners
Post-cutover monitoring + close-outInto change record
Operating rule: this function never writes "approved", "validated", "migration passed", or "compliant". It recommends readiness; Head of QA + Release & Change Control Manager approve. Customer-data migrations also require the customer's QA acceptance.
GAMP 5 — migration report21 CFR Part 11 — records & retentionEU Annex 11 §4.8·§10·§11ALCOA+ — full evidenceISO 27001 / SOC 2 — supplier & security
Deep-Dive Sub-Flow — AI Validation & Governance
Runs across every phase for Mira copilot, prediction engine, AI scoring/classification, and the model registry. The control set that keeps generative/probabilistic AI out of critical GMP decisions and advisory AI off the system-of-record.
Plugs into: Phase 1 (AI requirements) · Phase 2 (AI risk class) · Phase 3 (AI design) · Phase 4 (AI guardrails) · Phase 5 (AI assurance tests) · Phase 10 (AI change control). Owner: AI Governance Lead; adequacy verdict by AI Validation & Governance Expert; final QA by Head of QA.
Hard regulatory boundary: only static, deterministic AI in critical GMP decisions (batch release, OOS, CAPA disposition). Generative AI/LLMs/probabilistic models are prohibited there (EU/PIC-S Annex 22). Copilot/analytics = advisory, never written to GxP-critical fields without human e-signature.
Declare what each AI function does, its risk tier, and register it before deployment
AI Governance Lead
▼
Key activities
Intended Use Statement per AI function — purpose, user population, performance thresholds (precision/recall/F1), advisory-vs-deterministic label.
EU AI Act classification — batch/OOS/deviation/CAPA prediction → High-Risk (Annex III); copilot/analytics/trend → Limited-Risk transparency. FDA CSA process-risk tiering in parallel.
Model registry entry — model name, version, provider, intended use, risk class, acceptance criteria, training/test data lineage — registered before any use.
Annex 22 criticality — confirm whether the AI touches patient safety / product quality / data integrity in GMP; if critical, only static deterministic models permitted.
RACI
Activity
R
A
C
I
AI intended use & classification
RAI Governance Lead
AHead of QA
Reg Affairs, Legal, CSV/CSA
Eng, Product
Model registry
RAI/ML Eng
AAI Governance Lead
CSV/CSA
Head of QA
Evidence
AI Intended Use StatementsPer function, thresholds
EU AI Act / Annex 22 classificationHigh vs limited risk
Model registry recordVersion, provider, criteria
📋 Governing SOPs:VRX-SOP-501
EU AI Act Art.6 + Annex IIIEU Annex 22 — intended use & criticalityGMLP Principle 1FDA AI Draft Jan 2025
Data lineage, no black boxes in quality-critical paths, human-in-the-loop gates
AI Governance Lead · DI SME
▼
Key activities
Training-data governance — source, quality, representativeness, version control; training and test data kept separate (Annex 22 §5.3); bias testing across site/product-line/submitter role before deployment.
Explainability — every prediction surfaced to a user returns a structured explanation (feature importance / contributing factors / confidence), not a raw score. No black-box models in quality-critical paths.
HITL gates — AI output → human review → e-signature → action; confidence below the configured threshold auto-escalates to quality_lead+. No silent low-confidence passes.
Advisory segregation — AI suggestions visually labelled "AI-generated — requires human review"; never written to complaints.root_cause, deviations.investigation_conclusion, capas.action_description, batch_records.disposition without human confirmation.
EU AI Act Art.10·13·14EU Annex 22 §5·§6·§7GMLP Principles 4·5·721 CFR 11 — e-sig on AI-accepted decision
AI-3
AI Audit Logging, Drift Monitoring & AI Change Control
Full traceability of inputs/outputs/overrides; revalidate on drift; control every model/prompt change
AI Governance Lead · MLOps
▼
Key activities
AI audit log — ai_requests/llm_audit_log capture model name+version, prompt/input hash, output, confidence, timestamp, triggering user, and accept/reject/modify outcome. Human-accepted outputs attributed to the human, not the model.
Drift & performance monitoring — production tracking via prediction_log/ai_scoring_results; accuracy below acceptance threshold raises a dashboard_alert and flags the model for revalidation.
AI change control — model swap, version bump, system/prompt-template change, retrieval-corpus change, threshold/parameter change, automation-authority change each require AI governance review + validation-impact + regression + Head of QA disposition. Prompt templates are version-controlled, never hardcoded inline.
Periodic revalidation — frequency by model risk level; revalidation evidence stored alongside the model version.
RACI
Activity
R
A
C
I
AI audit logging & monitoring
RMLOps
AAI Governance Lead
DI SME, Eng
Head of QA
AI change control disposition
RAI Governance Lead
AHead of QA
CSV/CSA, Release Mgr
Product
Evidence
AI audit log recordsInputs/outputs/overrides
Drift monitoring + alertsAcceptance thresholds
AI change records + revalidationPer model version
📋 Governing SOPs:VRX-SOP-502VRX-SOP-505
EU Annex 22 §5·§8 (monitoring, change)EU AI Act Art.72 post-marketGMLP Principles 6·9·1021 CFR 11.10(e) AI audit trail
AI-4
AI Knowledge-Base / RAG Source Governance
Only approved, current, traceable sources drive Mira RAG — with source-to-answer traceability and tenant-source isolation
AI Governance Lead · RAG Source Steward
▼
Key activities
Source eligibility & approval — only approved, owned, current sources are RAG-eligible; draft / obsolete / superseded sources excluded; public web content is not treated as controlled evidence.
Provenance & freshness — every source carries origin, owner, version, effective/review date. A current source file does not prove a current index — re-index evidence required.
Chunk / index & source-to-answer traceability — every chunk traces to source ID + version + section; every answer traces query → retrieval → source version → chunk → citation. No untraceable regulated answer.
Citation governance — citations link to the exact approved source version; no fabricated, obsolete, or draft citations; source-supported answer distinguished from model synthesis.
Tenant source isolation — customer-specific sources are never retrievable cross-tenant; role/tenant retrieval filters enforced.
For Verixa's multi-agent workflows: every agent registered & qualified; panel deliberations, dissent and decision-record-trails evidenced; HITL escalation governed
AI Governance Lead · Agentic Workflow Owner
▼
Key activities
Agent registry & qualification — every agent (role, version, tool access, intended use) is registered and qualified before use; qualification records link to intended use and validation evidence.
Panel sessions & deliberation evidence — multi-agent panel sessions, deliberations and routing are recorded; agent participation and review touchpoints are traceable.
Dissent / conflict & DRT documents — dissent and conflict records captured; Decision-Record-Trail (DRT) documents link each agentic decision to its evidence, requirement, risk, and change record.
Escalation & HITL — agentic decisions affecting regulated records escalate to human review + e-signature; no autonomous critical GMP decision; HITL linkage governed.
Linkage & audit — agentic workflow evidence links to requirement, risk, change, validation, deviation/CAPA and audit trail; full traceability of agent inputs / outputs / human overrides.
EU AI Act Art.14 (human oversight)EU Annex 22 — AI controlGMLP 721 CFR Part 11 — e-sig & recordsALCOA+ (traceable)
AI-6
AI Provider / LLM Gateway Assurance
Every model call routed, controlled and logged — provider config, fallback, token handling, provider-change control
AI Governance Lead · Platform Eng
▼
Key activities
Gateway & provider configuration — model endpoints, provider/model version pinning, and routing under configuration control; no untracked provider/model in a regulated path.
Rate limits, token handling & logging — request/response logging to the AI audit trail; controls on what data is placed in prompts; rate-limit & quota behavior defined.
Fallback & failover — defined behavior when a provider/model is unavailable or degraded; no silent provider substitution in regulated decisions.
Provider change control — provider swap, model version, endpoint or terms change → AI governance + supplier + validation impact + regression before release.
Supplier & privacy dependency — AI provider qualification and data-processing terms (→ Supplier Quality, Security & Privacy).
EU Annex 22 — AI controlEU AI Act Art.10·15EU Annex 11 §3 · 11.10(e)ISO 27001 / SOC 2 — provider
AI-7
Human-in-the-Loop / E-Signature Decision Workflow
Decision gates where AI / agent output requires human review & e-signature before any regulated action
HITL / E-Signature SME · QA
▼
Key activities
Decision gates — defined points where AI/agent output must be human-reviewed before action; gate configuration is controlled.
Escalation paths & authority — review routing, reviewer authority, and low-confidence/critical escalation recorded as review events.
E-signature linkage — the human decision is e-signed and bound to the AI output and the regulated record (Part 11 meaning, identity, manifestation).
Decision evidence — who / what / when / why captured for every gated decision; AI recommendation, human decision and override reason logged.
Hard rule — no autonomous critical GMP decision; AI never writes to a GxP-critical field without the human e-signature.
RACI
Activity
R
A
C
I
HITL / e-signature decision workflow
RHITL/E-sig SME
AHead of QA
DI SME, AI Gov Lead
Reg Affairs
Evidence
Decision-gate configurationControlled
Signed decision recordsAI→human→e-sig binding
Override / escalation logReason captured
Final QA risk acceptance → Head of QA; data-integrity adequacy of the signed record → Data Integrity Expert; AI governance adequacy → AI Validation & Governance Expert.
EU AI Act Art.14 (human oversight)21 CFR 11.50/11.70/11.100/11.200EU Annex 11 §14 (e-sig)GMLP 7
Deep-Dive Sub-Flow — Data Integrity, 21 CFR Part 11 & EU Annex 11
The ALCOA+ control spine: audit trail, electronic signatures, access control, and retention/archival on every regulated record across the whole lifecycle.
Plugs into: Phases 3–7 (design→validation), 8–9 (customer), 10 (change). Owner: Data Integrity SME; final adequacy verdict by Data Integrity / Part 11 / Annex 11 Expert; QA by Head of QA.
Attributable, contemporaneous, original, accurate — append-only audit trail on every mutation
Data Integrity SME
▼
Key activities
ALCOA+ controls — attribution (created_by/updated_by from authenticated user), server-generated UTC timestamps, original-record preservation (versioning/soft-delete, no hard delete of GxP records), legibility, completeness, consistency, enduring & available storage.
Audit trail — every INSERT/UPDATE/DELETE logged with tenant, user, action, resource, before/after field-level diff, reason; append-only and non-modifiable by any application user incl. platform_admin; captures the meaning of the change, not just raw values.
Audit-trail review — defined review process & cadence; export & inspector retrieval verified.
RACI
Activity
R
A (adequacy)
C
I
ALCOA+ & audit-trail controls
REngineers
AData Integrity SME
Architect, CSV/CSA
Head of QA
Evidence
Audit-trail design + test evidenceAppend-only, before/after
ALCOA+ control matrixPer record class
📋 Governing SOPs:VRX-SOP-401VRX-SOP-402
21 CFR 11.10(a)(c)(e)EU Annex 11 §9 (audit trails)ALCOA+ (all 9); MHRA DI 2018; WHO TRS 996
DI-2
Electronic Signatures & Access Control
Signature meaning, record binding, manifestation; RBAC and least privilege
Data Integrity SME · Security
▼
Key activities
E-signature controls — signature meaning & reason, signer identity + authority, date/time, record-signature binding, manifestation in UI and export; record-changed-after-sign detection; Part 11 §11.100/§11.200 verified.
Access control — authentication (MFA where required), role-based authorization checked on every route before business logic, least privilege, role hierarchy never granted upward, segregation of duties (creator ≠ approver).
Tenant isolation — RLS on every table; tenant-scoped data access enforced; cross-tenant access only via explicitly named, documented platform context.
RACI
Activity
R
A
C
I
E-signature controls
REngineers
AData Integrity SME
Legal (meaning), Security
Head of QA
Access control / RLS
REngineers
ASecurity Lead
DI SME
Head of QA
Evidence
E-signature design + test evidenceMeaning, binding, manifestation
Protects the confidentiality, integrity, and availability of regulated and personal data — secure SDLC, tenant isolation, encryption, vulnerability management, and privacy/DPA.
Penetration testing — independent pen test per release cycle / major change; tenant-isolation & OWASP coverage; findings triaged and retested.
Security incident response — detection, logging/monitoring (SIEM), defined IR plan, breach assessment & notification, and link to deviation/CAPA where GxP-impacting.
User/role certification, privileged & service accounts, break-glass, joiner-mover-leaver, segregation of duties, tenant boundaries
Security Lead · Access Review Owner
▼
Key activities
Periodic access certification — defined scope, reviewer authority, retain / modify / revoke decision per user & account, exceptions logged and closed. A calendar invite or meeting note is not evidence.
Service accounts & API tokens — owner, purpose, scope, expiry, rotation, revocation; no orphaned or never-expiring tokens; tokens revoked when the owner leaves.
Break-glass / emergency access — time-bound, approved, logged, post-use reviewed, with an incident/deviation trigger.
Joiner-Mover-Leaver — provisioning approved; mover's old access removed; leaver revoked with deactivation evidence (terminated user must not remain active).
Segregation of duties & tenant boundaries — no create+approve of the same record, no self-approval of access, no audit-trail-config + audit-trail-review in one role; cross-tenant access is high-risk.
Handoff: security/privacy adequacy → Security & Privacy Expert; data-integrity adequacy of record-altering privilege → Data Integrity Expert; final QA risk acceptance → Head of QA.
Verixa runs on third parties — IaaS/PaaS, AI model providers, subprocessors, ETL/middleware. Their evidence can be leveraged, but only after qualification under a quality agreement.
Qualification & evidence review — SOC 2 Type II, ISO 27001, pen-test summary, SDLC evidence, cloud-architecture evidence, AI-provider evidence; QA assesses adequacy (claims not accepted at face value).
Restore testing — periodic, evidenced restore tests proving data + audit trail + signatures recover intact within RTO/RPO; absence of a tested restore = not a validated continuity control.
The operational quality loop that runs continuously once the system is live — turning any failure (bug, outage, audit finding, customer complaint) into a controlled, evidenced corrective & preventive action.
Root Cause Analysis & CAPA (corrective + preventive)
Fix this, and stop recurrence — with up-front effectiveness criteria
QA · Process Owner
▼
Key activities
Root cause analysis — structured RCA (e.g. 5-Why / Ishikawa); distinguish correction from corrective from preventive action.
CAPA plan — action items with owners + target dates; measurable, time-bound effectiveness criteria defined up front; segregation of duties (creator ≠ assignee ≠ verifier).
ICH Q10 §3.2.221 CFR 211.192 · 820.100ALCOA+ action evidence
QE-3
Effectiveness Check & Closure (e-signed)
Prove the CAPA worked before closing — ineffective never reaches closed
Independent Verifier · Head of QA
▼
Key activities
Effectiveness check — objective verification against the up-front criteria; e-signed determination (not just final close); verifier ≠ creator/assignee.
Outcome routing — Effective → closure gate; Partially effective → residual-action plan (cannot close); Ineffective → mandatory rework or linked new CAPA.
The governance loop that proves the QMS itself works: self-inspection finds gaps, management review steers, and inspection-readiness keeps the evidence binder current for FDA/EMA/customer audits.
Plugs into: all phases (continuous oversight) and Phase 10 (validated-state maintenance). Owners: Internal Audit · Head of QA · Audit & Inspection Readiness.
The cross-cutting platform & infrastructure GxP controls every release must address — identity, configuration, data lifecycle, integration, operations and data capture.
Screen-reader/OCR/email ingestion, regulated-wording translation control, and seed/test-data governance
Platform Eng · QA
▼
Key activities
Data capture — screen-reader capture, OCR jobs, extraction templates, email-ingestion rules, inbound queues, and extracted-data review linkage.
Localization / i18n — locale records, translation keys/values, and version control of regulated wording; user locale preferences.
Seed & test data — seed data, test tenants/users, permission seed, demo records, dataset lineage and reset scripts; test data segregated from production.
Evidence — extraction review, translation version control and seeded-data lineage retained.
Coverage map — where every engineering & regulatory concern lives
The main spine (Phases 0–10) is sequential. The 7 sub-flows are cross-cutting tracks — AI, data integrity, security, supplier, continuity, quality events and governance recur across many phases, so they run as parallel tracks rather than single steps. That is why they sit alongside the spine, not inside one phase. Everything is wired together below — click any row to jump.
Each sub-flow card also lists its own "Plugs into" phases — integration runs both ways.
How to read this flow. Phases 0–7 are Verixa's internal build-and-validate lifecycle (vendor side). Phases 8–9 are the customer rollout (where Verixa enables but the customer's QA owns their validation approval). Phase 10 is the loop that keeps every later change re-entering the lifecycle at the right depth. Decision Gate A and the per-phase exit gates are hard stops — a failed gate routes work backward, never forward.
Main lifecycle (Phases 0–10) plus 10 deep-dive sub-flows so nothing is missed: (1) Data Migration & Integration (M1–M10), (2) AI Validation & Governance incl. RAG source governance + agentic registry/panel/DRT (AI-1–5), (3) Data Integrity / Part 11 / Annex 11 (DI-1–3), (4) Security & Privacy incl. access review (SEC-1–4), (5) Supplier & Cloud Qualification (SUP-1–2), (6) BCP/DR & Backup-Restore (DR-1–2), (7) Quality Events Incident/Deviation/RCA/CAPA/Complaint (QE-1–3) and Governance — Internal Audit / Management Review / Inspection Readiness (GOV-1–3); (9) Platform Engineering & Operations (PE-1–7); (10) Validation Automation & Statistical Quality (VA-1–2).
Verixa skills invoked to build this: CSV/CSA Assurance Expert · Release & Change Control Manager · Customer Implementation & Validation Enablement Expert · GxP Data Migration & Integration Validation Expert. Skill chain: URS Expert → CSV/CSA Expert → Validation Test Architect → Head of QA (terminal release authority). Specialist sub-flows map to: AI Validation & Governance Expert, Data Integrity/Part 11/Annex 11 Expert, Security/Privacy Expert, Supplier Quality Expert, BCP/DR Expert, GxP Incident/Deviation/CAPA/Complaint Expert, Internal Audit/Self-Inspection Expert, QMS Management Review/Quality Risk Expert, Audit & Inspection Readiness Expert. Regulatory baseline per the Verixa repository CLAUDE.md (GAMP 5 Cat 5; 21 CFR Part 11 & 211; EU Annex 11; EU Annex 22 Draft 2025; EU AI Act 2024/1689; FDA CSA Sep 2025; ICH Q9(R1)/Q10/E6(R3); ISO 27001/22301/SOC 2; GDPR; MHRA DI; GMLP; WHO TRS 996 Annex 5).
Scope & limitations. This is a process workflow template, not a validation approval or a compliance certification. Regulatory clause references are pointers to public guidance and must be confirmed per module, jurisdiction, and market. EU Annex 22 is draft/consultation; treat as forward-looking until adopted. "Validated" applies only to a specific scope + version + intended use with approved human evidence — never asserted by this document. Per Verixa governance, only authorised QA/validation humans approve validation; AI produces the assurance pack, humans approve it.