# Verixa — User Requirements Specification # Module 17: Root Cause Analysis | Field | Value | |---|---| | Document ID | VRX-URS-17 | | Version | 1.0 | | Status | Final — ready for QA, Validation, Regulatory Affairs, Information Security, Manufacturing Head, Clinical / PV Head, Site Quality Lead, and Founder approval. URS approval is separate from validation execution. This document becomes "Approved Controlled URS — released for engineering implementation and validation planning" only after signature capture in the Document Approval block. It becomes "Released for validation execution" only after the module migration evidence gate (URS-17-VAL-008) and validation evidence pack are satisfied. | | Document Type | User Requirements Specification (URS) | | GAMP 5 Category | Category 5 — Custom Application | | Code Modules | Target implementation binding: expected primary code module `rca`, expected API mount `/api/v1/rcas/*`, expected methodology sub-route ownership for 5-Why, Fishbone, and Fault Tree methodologies. Implementation evidence remains subject to repository verification and validation evidence. | | Architecture Bindings | This module is subject to **ARCH-AI-001 AI Optionality and Manual Continuity**. Verixa internally classifies this AI surface as **high-risk under internal AI governance**, aligned with the high-risk classification approach in **EU AI Act (Regulation 2024/1689) Annex III**, unless a jurisdiction-specific legal assessment determines otherwise. AI-assisted root-cause analysis surfaces (AI root-cause suggestion, AI fishbone-node suggestion, AI 5-Why generation, MIRA RCA copilot, AI contributing-factor extraction, AI precedent-linking) are advisory only under internal AI governance aligned with EU AI Act Article 13 transparency principles. Every AI surface shall provide a fully functional manual RCA path; RCA creation, technique selection, analysis, conclusion-drafting, and approval shall be executable when AI services are disabled, degraded, or overridden by the investigator. **No AI service shall be the sole path to finalize a root cause; a qualified human investigator shall sign the RCA conclusion.** This module binds ARCH-AI-001 AC-2, AC-3, AC-4, and AC-7. Verixa treats **EU GMP Annex 22 Draft 2025** as an internal forward-looking architectural control (not an enacted predicate rule); under that internal control, generative / probabilistic AI is **PROHIBITED** in RCA conclusion finalisation, RCA approval, and RCA closure decision paths. Static deterministic AI may surface similar prior RCAs and historical contributing-factor patterns; the human investigator's signed conclusion is the system of record. Jurisdiction-specific legal enforceability of Annex 22 and the EU AI Act remains subject to a future jurisdiction-specific legal assessment. | | Regulatory Classification | Critical infrastructure substrate — operates the canonical Root Cause Analysis register, the RCA lifecycle state machine (`draft → in_progress → root_cause_identified → completed → approved → closed`; reopen is a governed transition event from `closed → in_progress` that appends a new investigation iteration and does not mutate or erase the prior closed evidence — DEC-17-22 + SoD-17-06), the source-linkage controls (deviation, finding, OOS investigation, complaint) with app-level existence validation, the multi-dimensional context capture (study, site, product, supplier, batch), the contributing-factor lifecycle with evidence reference arrays and tombstone-preserved deletion, the methodology catalogue and methodology-instance application (5-Why, Fishbone, Fault Tree), the action management within RCA, the conclusion capture with reviewer independence and e-signature approval, the post-approval / post-closure record immutability across the RCA header, contributing factors, actions, methodology instances, and methodology steps, the controlled reopen workflow, the downstream CAPA recommendation handoff via `rca_conclusion_created` event, and the per-jurisdictional regulatory expectations under FDA 21 CFR §211.192 (Production record review for unexplained discrepancies), 21 CFR §312.62 (Investigator records — clinical), EU GMP Chapter 1 §1.4 (Pharmaceutical Quality System), ICH Q9 (Quality Risk Management), ICH Q10 (Pharmaceutical Quality System §3.2.4), MHRA Data Integrity. | | Date of Issue | 2026-05-06 | | Module Owner (Engineering) | Investigation / Quality Squad | | Module Owner (Quality Validation) | CSV / CSA Lead — RCA | | Module Owner (Compliance) | Quality Assurance, Manufacturing, Clinical / Pharmacovigilance, Regulatory Affairs | | Approving Authority | Founder / Chairman & MD; QA Head; Manufacturing Head; Clinical / PV Head; Validation Head; RA Head; Information Security Head; Site Quality Lead | --- ## 0. Document Framing ### 0.1 Purpose of this document This URS defines the target expected state for Verixa's Root Cause Analysis module (Module 17). It is the binding contract between product, engineering, quality validation, regulatory affairs, manufacturing, clinical / pharmacovigilance, distribution, laboratory operations, information security, and the executive authority for the design, implementation, validation, release, and on-going periodic review of the regulated root-cause-analysis substrate: the canonical RCA register; the lifecycle state machine (`draft → in_progress → root_cause_identified → completed → approved → closed` with reopen as a governed transition event from `closed → in_progress` per executive authority co-sign + reason — DEC-17-22 + SoD-17-06 — that appends a new investigation iteration without mutating or erasing the prior closed evidence); the source-linkage controls (deviation per URS-16, finding per URS-21, OOS investigation per URS-15, complaint per URS-14) with app-level existence validation; the multi-dimensional context model (`study_id`, `site_id`, `product_id`, `supplier_id`, `batch_id` with at least one scope anchor required and `not_applicable` rationale stored where a dimension is genuinely out of scope); the contributing-factor lifecycle with evidence reference arrays, tombstone-preserved deletion, and per-factor evidence basis; the methodology catalogue (5-Why, Fishbone / Ishikawa, Fault Tree Analysis); the methodology application controls with methodology accessibility verification before instance creation; the methodology-step capture (5-Why ladder, Fishbone causes per category, Fault Tree nodes with probability calculation); the RCA action management with controlled action add / update / list and interim-control planning; the conclusion capture with reviewer independence (SoD-17-01: creator ≠ approver), reason-for-change discipline, and e-signature approval gate; the post-approval / post-closure immutability across the RCA header, contributing factors, actions, methodology instances, and methodology steps; the controlled reopen workflow with executive authority co-sign and rationale; the downstream CAPA recommendation handoff via the `rca_conclusion_created` event; the audit trail coverage with reason-for-change, reviewer disposition, and closure-signoff evidence; the configurable methodology catalogue at tenant level; the AI architecture binding under ARCH-AI-001 AC-2 / AC-3 / AC-4 / AC-7 with the internal Annex 22 / EU AI Act Annex III high-risk control prohibiting generative AI in RCA conclusion finalisation, approval, and closure decision paths; and the per-jurisdictional regulatory expectations. Compliance with this URS is mandatory. ### 0.2 Audience Engineering, QA, RA, Manufacturing, Clinical / Pharmacovigilance, Distribution, Laboratory Operations, Validation, Information Security, executive authority, the platform's Implementation team, internal and external auditors, and inspectors from regulatory bodies (FDA, EMA, MHRA, Health Canada, CDSCO, PIC/S, PMDA). The plain-language primer (§0.4) and worked examples (§3.5) make Module 17 accessible to non-domain engineers, product owners, validation engineers, and quality investigators. ### 0.3 Cross-references - **URS-01** Authentication, Session & Access Control — identity envelope for every RCA mutation - **URS-02** RBAC & Permissions — the `rcas:*` permission set - **URS-03** Context Gate & Approval Scope — context-gate enforcement for RCA scope dimensions - **URS-04** Workflow / HITL / E-Signature / Approval Authority — Controlled Approval Modal contract for RCA approval and reopen - **URS-05** Authority Profile / Delegation / SoD — Authority Profiles consumed (`investigation_lead_authority`, `final_quality_approver`, `executive_authority`) - **URS-06** Audit Trail / Hash Chain / Tamper-Evident — append-only audit substrate - **URS-07** Study Management — study-scope dimension consumed - **URS-08** Tenant Management Lifecycle — tenant context for RCA records - **URS-09** Site / Facility Management — site-scope dimension consumed - **URS-10** Product / SKU / Drug Master Data — product-scope dimension consumed - **URS-11** Supplier Management — supplier-scope dimension consumed - **URS-12** Document Control / SOP — affected-document linkage; methodology references - **URS-13** Change Control — RCA-precipitated change linkage - **URS-14** Complaints — complaint-source RCA linkage - **URS-15** OOS / OOT — OOS-source RCA linkage - **URS-16** Deviations — deviation-source RCA linkage - **URS-18** CAPA — downstream CAPA recommendation and handoff - **URS-21** Findings — finding-source RCA linkage - **URS-23** Batch Records — batch-scope dimension consumed - **URS-30** Notifications — notification delivery for RCA lifecycle events - **URS-32** MIRA AI — read-only MIRA copilot context for closed RCAs (no write path) - **URS-35** Infrastructure / Backup-Restore — operational continuity ### 0.4 Plain-language primer In a regulated pharmaceutical operation, **the question "why did this happen?" is a regulated question**. When a deviation, an out-of-specification result, a complaint, or a finding is opened, the investigator is required by **21 CFR Part 211.192 (Production record review for unexplained discrepancies), EU GMP Chapter 1 §1.4 (Pharmaceutical Quality System), ICH Q9 (Quality Risk Management), ICH Q10 (Pharmaceutical Quality System §3.2.4), and MHRA Data Integrity Guidance (2018)** to conduct a structured root-cause analysis: identify the contributing factors, evaluate their evidence basis, apply a recognised analytical methodology (5-Why, Fishbone / Ishikawa, Fault Tree, or equivalent), document the conclusion, and obtain reviewer-independent approval. Module 17 is the target specification for this regulated workflow. The most common mistake in regulated RCA is **insufficient depth**: the investigator stops at the first plausible cause without applying a methodology and without testing alternative hypotheses, leaving the true root cause unaddressed. The regulator's tell-tale at inspection is an RCA conclusion that describes a symptom ("operator made an error") rather than the root cause ("training material did not cover the rare excursion handling — root cause is procedural"). Module 17 enforces the structured pathway: every RCA MUST capture contributing factors with evidence; every RCA MUST apply at least one methodology (5-Why, Fishbone, or Fault Tree); every conclusion MUST be reviewer-approved by an independent investigator (SoD-17-01: creator cannot approve their own RCA); every RCA reaching `approved` or `closed` becomes immutable; reopen is a governed transition that appends a new investigation iteration without erasing the prior closed evidence. The **AI-assistance** dimension is critical. Static deterministic AI may surface "similar prior RCAs in the last 12 months" or "common contributing-factor patterns for this deviation type" as advisory help. Generative AI (LLMs / MIRA copilot) is **prohibited** from writing to the RCA conclusion, the approval decision, or the closure decision under the internal Annex 22 Draft 2025 forward-looking AI governance control. MIRA copilot may read closed RCAs for read-only context (per URS-32 mapping) but no AI service writes to `rcas`, `rca_contributing_factors`, `rca_conclusions`, or `rca_methodology_*` tables. The signed conclusion is the system of record, attributable to the human investigator. The **two-step release path** mirrors every other Module: this URS becomes "Approved Controlled URS — released for engineering implementation and validation planning" upon signature capture in the Document Approval block; it becomes "Released for validation execution" only after URS-17-VAL-008 (Migration Evidence Gate) and the §17 validation evidence pack are satisfied. ### 0.5 Conventions Each requirement has a unique identifier. "MUST" denotes a mandatory requirement; "SHOULD" denotes a strong recommendation; "MAY" denotes an option. The document is self-contained: front end (§5), back end (§6), data model (§6.2), application programming interface (§6.3), workflow (§6.4), business rules (§6.5), audit (§6.6), security (§12), regulatory mapping (§14), test cases (§16), and validation evidence (§17) are all in this single file. Every requirement is mandatory unless explicitly marked SHOULD or MAY. ### 0.6 Glossary | Term | Definition | |---|---| | RCA | Root Cause Analysis — the structured investigation of why a deviation, OOS, complaint, or finding occurred. | | Contributing factor | A condition, action, or omission that contributed to the event under investigation; documented with evidence basis. | | Root cause | The underlying causal factor that, if eliminated, would have prevented the event. May be procedural, technical, organisational, or training-related. | | Methodology | A structured analytical technique used to systematically derive root cause: 5-Why, Fishbone (Ishikawa), Fault Tree Analysis. | | 5-Why | An iterative interrogative technique used to explore the cause-and-effect relationships underlying a problem; "why" is asked five (or more) times to drill from symptom to root. | | Fishbone | Ishikawa diagram organising contributing factors by category (Method, Machine, Material, Measurement, Mother Nature, Manpower) leading to the effect. | | Fault Tree | A top-down deductive failure analysis using Boolean logic to combine lower-level events into a top-level event with computed probability. | | Conclusion | The signed root-cause statement, evidence basis, and recommended downstream action (typically CAPA per URS-18). | | Reviewer independence | The Segregation-of-Duties enforcement that the RCA approver MUST NOT be the RCA creator (SoD-17-01). | | Source linkage | The mandatory FK to the precipitating record (deviation per URS-16, finding per URS-21, OOS investigation per URS-15, complaint per URS-14). | | Scope anchor | At least one of `study_id`, `site_id`, `product_id`, `supplier_id`, `batch_id` MUST be captured on every RCA record; non-applicable dimensions MAY be marked `not_applicable` with controlled rationale. | | Reopen | A governed transition event from `closed → in_progress` requiring executive authority co-sign and documented reason; appends a new investigation iteration without mutating prior closed evidence. | | ARCH-AI-001 | Platform architecture binding requiring manual continuity for every AI surface (AC-1..AC-7). | | Annex 22 | EU GMP Annex 22 (Draft 2025). Verixa treats Annex 22 and EU AI Act high-risk / transparency concepts as internal forward-looking AI governance controls unless a jurisdiction-specific legal assessment determines otherwise. Under the internal control, generative / probabilistic AI is prohibited in RCA conclusion finalisation, approval, and closure. Binding predicate-rule obligations remain those listed in §14. | | MIRA | The platform's read-only AI copilot service; for Module 17 MIRA is read-only over closed RCAs and never writes to RCA tables. | | CAPA | Corrective and Preventive Action (URS-18); the downstream remediation vehicle that consumes the `rca_conclusion_created` event. | ### 0.7 Module-17 architectural picture ```mermaid flowchart TD U[Investigator / Reviewer] --> RCA[/RCA register/] RCA --> CF[Contributing factors] RCA --> METH[Methodology instances] METH --> WHY[5-Why ladder] METH --> FISH[Fishbone causes] METH --> FT[Fault Tree nodes] RCA --> ACT[Actions] RCA --> CONC[Conclusion] CONC --> APPROVE[Approval e-sign + SoD-17-01] APPROVE --> CLOSE[Closure] CLOSE -. governed reopen + executive co-sign .-> RCA M16[URS-16 Deviations] --> RCA M15[URS-15 OOS / OOT] --> RCA M14[URS-14 Complaints] --> RCA M21[URS-21 Findings] --> RCA CONC --> M18[URS-18 CAPA] CONC -. precipitating change .-> M13[URS-13 Change Control] M22[URS-22 Inspection Mgmt] <-- RCA M26[URS-26 APQR] <-- RCA M30[URS-30 Notifications] <-- RCA ARCHAI[ARCH-AI-001] -.governs advisory AI.-> RCA ANNEX22[Internal Annex 22 control — forward-looking; not enacted predicate rule] -.governs.-> CONC ANNEX22 -.governs.-> APPROVE ANNEX22 -.governs.-> CLOSE AIAct[Internal EU AI Act Annex III high-risk classification — forward-looking] -.classifies.-> RCA ``` Diagram 0.7-A — Module 17 architectural picture. The target `rca` code module is the expected owner of the RCA register, lifecycle, source linkage, contributing-factor lifecycle, methodology catalogue and instances, action management, conclusion capture, approval gate, and closure; ownership is target binding and remains subject to repository verification and validation evidence. Verixa treats EU GMP Annex 22 Draft 2025 and EU AI Act high-risk / transparency concepts as internal forward-looking AI governance controls unless a jurisdiction-specific legal assessment determines otherwise; under the internal control, generative AI is prohibited in conclusion finalisation, approval, and closure decision paths and the module is internally classified high-risk AI. ARCH-AI-001 governs advisory deterministic AI in similarity / signal surfacing. Binding predicate-rule obligations remain those listed in §14. ### 0.8 Entity-relationship overview ```mermaid flowchart LR RCA[(rcas)] --> CF[(rca_contributing_factors)] RCA --> ACT[(rca_actions)] RCA --> CONC[(rca_conclusions)] RCA --> MI[(rca_methodology_instances)] MI --> MS[(rca_methodology_steps)] RCA --> LCE[(rca_lifecycle_events)] RCA --> APPR[(rca_approvals)] CAT[(rca_methodologies)] --> MI ``` Diagram 0.8-A — Module 17 entity-relationship overview. The target `rca` code module is the expected owner of 8 tables (RCA header, contributing factors, actions, conclusions, methodology catalogue, methodology instances, methodology steps, lifecycle events, approvals); ownership is target binding and remains subject to repository verification and validation evidence. URS-06 substrate is consumed for audit and authority snapshots. --- ## 1. Document Control This document is the User Requirements Specification (URS) for Verixa Module 17 — Root Cause Analysis. The document is controlled per URS-12; all revisions follow URS-12 versioning and approval. Approval and signature evidence is captured in the Document Approval block at the end of this document. Distribution is governed by URS-12 entitlement; the document is read-accessible to all Verixa internal staff and to authorised external auditors / inspectors at the platform administrator's discretion under the existing inspection-readiness export pattern of URS-22. Version 1.0 is the launch version. Future revisions follow URS-13 Change Control with the `module_17_specification` change-class tag. --- ## 2. Scope ### 2.1 In scope #### RCA Registry - The RCA master registry per DEC-17-01: per-tenant registry with `id`, `tenant_id`, `rca_number` (server-authoritative `RCA-{YYYY}-{nnnnnn}` per DEC-17-03), `discovery_date`, `creator_user_id`, `investigation_lead_user_id` (nullable until assigned), `study_id` (FK URS-07 nullable), `site_id` (FK URS-09 nullable), `product_id` (FK URS-10 nullable), `supplier_id` (FK URS-11 nullable), `batch_id` (FK URS-23 nullable), `deviation_id` (FK URS-16 nullable), `finding_id` (FK URS-21 nullable), `oos_investigation_id` (FK URS-15 nullable), `complaint_id` (FK URS-14 nullable), `practice` (`gmp` / `gcp` / `glp` / `gdp` / `gvp` / `multi`), `priority` (`standard` / `expedited` / `critical`), `lifecycle_state` (`draft` / `in_progress` / `root_cause_identified` / `completed` / `approved` / `closed`), `study_scope` (per scope-dimension applicability), `site_scope`, `product_scope`, `supplier_scope`, `batch_scope`, `created_at`, `updated_at`, `approved_at` (nullable), `approved_e_sig_id` (nullable), `closed_at` (nullable), `closed_e_sig_id` (nullable), `deleted_at` (nullable for soft-delete), `voided_at` (nullable), `voided_reason`, `voided_signature_id`. **At least one source linkage** (`deviation_id`, `finding_id`, `oos_investigation_id`, or `complaint_id`) is required. **At least one scope anchor** (`study_id`, `site_id`, `product_id`, `supplier_id`, or `batch_id`) is required. Non-applicable scope dimensions MAY be marked `not_applicable` with controlled rationale. - Server-authoritative race-safe RCA number per DEC-17-03 via DB sequence. #### Source Linkage - Source-linkage validation per DEC-17-04: every RCA MUST be linked to at least one of: a deviation (URS-16), a finding (URS-21), an OOS investigation (URS-15), or a complaint (URS-14). The linked record's existence MUST be validated at the application layer before persistence; orphan RCAs are forbidden. - Cross-tenant source linkage is forbidden: the linked source record MUST be in the same tenant as the RCA being created. #### RCA Lifecycle - Lifecycle state machine per DEC-17-02: `draft → in_progress → root_cause_identified → completed → approved → closed`; reopen is a governed transition event from `closed → in_progress` per DEC-17-22 + SoD-17-06 that appends a new investigation iteration and a new lifecycle event without mutating or erasing the prior closed evidence. **Reopen MUST NOT erase the prior closed RCA evidence.** - Each transition is electronically signed; all transitions log dual-write to `rca_lifecycle_events` + URS-06 substrate. - The lifecycle states `draft`, `in_progress`, `root_cause_identified`, `completed`, `approved`, `closed` are the canonical set; shared types, shared schemas, and the service layer MUST all align to this single canonical set. #### Contributing Factor Lifecycle - Per-RCA contributing-factor entity per DEC-17-05: `id`, `tenant_id`, `rca_id`, `factor_category` (configurable per tenant; defaults to Manpower / Method / Machine / Material / Measurement / Mother-Nature / Management), `factor_description`, `evidence_references_jsonb` (array of `{evidence_type, evidence_document_id (FK URS-12), evidence_url, evidence_observation}`), `created_by`, `created_at`, `removed_at` (nullable; tombstone for SoD-preserved deletion), `removed_by` (nullable), `removed_reason` (nullable). Removal MUST preserve a logical tombstone (not physical delete) so investigation evidence integrity is preserved. - Evidence references on factors MUST be persisted at factor level and link to URS-12 controlled documents. #### Methodology Catalogue and Application - Tenant-scoped methodology catalogue per DEC-17-06: `rca_methodologies` table with `id`, `tenant_id`, `methodology_type` (`five_why` / `fishbone` / `fault_tree`), `methodology_label`, `methodology_description`, `default_categories_jsonb` (Fishbone categories), `effective_from`, `effective_to` (nullable). Tenant administrators MAY configure tenant-specific methodology templates; platform provides defaults at launch. - Methodology application to RCA per DEC-17-07: an RCA MAY have one or more methodology instances (`rca_methodology_instances`); applying a methodology creates an instance linked to the RCA + methodology row; the application service MUST verify methodology accessibility before instance creation. #### 5-Why Workflow - 5-Why instance per DEC-17-08: linked to a methodology instance with `methodology_type = five_why`; child rows in `rca_methodology_steps` capture the 5-Why ladder with `step_index`, `why_question`, `answer`, `evidence_observation`. Investigator MAY add, edit, and delete steps while RCA is mutable; once RCA reaches `approved` or `closed`, methodology steps become immutable (DEC-17-15). #### Fishbone Workflow - Fishbone instance per DEC-17-09: linked to a methodology instance with `methodology_type = fishbone`; child rows capture causes per category (`category` from methodology default categories, `cause_text`, `evidence_observation`). Investigator MAY add and read fishbone causes while RCA is mutable. #### Fault Tree Workflow - Fault Tree instance per DEC-17-10: linked to a methodology instance with `methodology_type = fault_tree`; child rows capture nodes with `parent_node_id` (nullable for top event), `gate_type` (`AND` / `OR` / `NONE` for leaf), `node_label`, `node_probability` (decimal), `evidence_observation`. The service computes top-event probability via `calculateFaultTreeProbability(...)` over the AND / OR Boolean tree. Computation is deterministic; AI is not used in probability calculation. #### Action Management - RCA action entity per DEC-17-11: `id`, `tenant_id`, `rca_id`, `action_description`, `action_type` (`interim_control` / `containment` / `corrective_proposal` / `preventive_proposal`), `assigned_user_id`, `due_date`, `status` (`open` / `in_progress` / `completed` / `cancelled`), `closure_notes`, `closure_evidence_document_id` (FK URS-12 nullable), `created_by`, `created_at`, `closed_at` (nullable). Actions are formalised within the RCA scope as interim-control planning; permanent corrective / preventive actions flow downstream to URS-18 CAPA. #### Conclusion Capture and Approval - RCA conclusion entity per DEC-17-12: `id`, `tenant_id`, `rca_id`, `root_cause_statement`, `contributing_factor_summary`, `evidence_basis_jsonb`, `recommended_capa_summary`, `created_by`, `created_at`. Conclusion creation transitions the RCA to `completed`. - RCA approval gate per DEC-17-13: approval requires `rcas:approve` permission, `withAuthority(...)` Authority Profile resolution, and Controlled Approval Modal e-signature. SoD-17-01 enforced: the RCA approver MUST NOT be the RCA creator. Approval transitions the RCA to `approved`. - Approval emits `RCA_APPROVED` to URS-06 with the e-signature attribution and reason-for-change captured. #### Downstream CAPA Handoff - CAPA recommendation handoff per DEC-17-14: conclusion creation emits `rca_conclusion_created` event consumed by URS-18 CAPA service; the event payload includes RCA id, root-cause statement, contributing factors, recommended-CAPA summary. URS-18 governs the downstream non-bypassable CAPA review decision. #### Final-State Immutability - Post-approval / post-closure immutability per DEC-17-15: once an RCA reaches `approved` or `closed` (the IMMUTABLE_STATUSES set), the RCA header, contributing factors, actions, methodology instances, and methodology steps become immutable. Any mutation attempt MUST return `RCA_IMMUTABLE_FINAL_STATE` with the 21 CFR Part 11 §11.10(e) message. This guard applies via `assertRCAMutable(...)` on every mutation route across the RCA module and the methodology sub-routes (header, contributing-factor, action, and methodology mutators). #### Closure - RCA closure per DEC-17-16: closure requires the RCA to be `approved`, all RCA actions in terminal status (`completed` or `cancelled`), the conclusion present, and a closure-rationale captured. Closure is e-signed by the closure authority (`final_quality_approver`); SoD-17-04 enforced (closure authority ≠ creator). #### Reopen - Reopen per DEC-17-22: reopen is a governed transition event from `closed → in_progress`; requires `executive_authority` co-sign + documented reason; appends a new lifecycle event and a new investigation iteration; **does NOT mutate or erase the prior closed evidence**. SoD-17-06 enforced: the executive-authority reopen co-signer cannot be the original closure authority. #### Multi-Dimensional Context - Context model per DEC-17-17: `MODULE_CONTEXT_CONFIG['rca']` declares `study`, `site`, `product`, `supplier`, `batch` filtering as applicable per scope dimensions captured on the RCA registry record. The persistence layer MUST persist `study_id`, `site_id`, `product_id`, `supplier_id`, `batch_id` per the registry schema. #### AI Architecture Binding - AI architecture binding per DEC-17-18: NO direct LLM / generative AI write to `rcas`, `rca_contributing_factors`, `rca_conclusions`, `rca_methodology_instances`, or `rca_methodology_steps`. Static deterministic AI MAY surface "similar prior RCAs" or "common contributing-factor patterns" as advisory; advisory output is visibly labelled per ARCH-AI-001 AC-3 and never autonomously writes per AC-4. MIRA copilot read-only context for closed RCAs is permitted (read-only mapping `rca → rcas`); MIRA write paths are prohibited. #### Audit Trail - Audit trail per DEC-17-19: every RCA mutation (create, update, contributing-factor add / remove, methodology apply, methodology step add / edit / delete, action add / update / close, conclusion create, approve, close, reopen, void) emits `auditTrailService.log(...)` to the URS-06 hash-chained audit substrate with `tenantId`, `userId`, `action`, `resourceType`, `resourceId`, `details` (before-state and after-state for UPDATEs), `ipAddress`, `timestamp`. Reason-for-change captured for every UPDATE to a regulated field. Reviewer disposition and closure-signoff evidence captured at the appropriate lifecycle transition. #### Configurable Methodology Catalogue - Configurable methodology catalogue per DEC-17-20: tenant administrators MAY add tenant-specific methodologies through the `rca_methodologies` table; platform provides launch defaults (5-Why, Fishbone, Fault Tree). Custom methodologies are tracked but at launch only the three platform-default methodology types are supported in the methodology-step computation logic. ### 2.2 Out of scope - Permanent corrective / preventive action management (forward URS-18 CAPA — Module 17 emits the CAPA recommendation event but does not own CAPA workflow). - Effectiveness-check workflow on closed RCAs (effectiveness checks live with downstream CAPA per URS-18). - Domain-specific record semantics for the precipitating record (every domain module — URS-14 / URS-15 / URS-16 / URS-21 — owns its own state model; Module 17 only references via FK). - AI-driven decision-making on RCA conclusion finalisation (explicitly prohibited per DEC-17-18; AI suggestion paths are advisory only). ### 2.3 Closed launch decisions | ID | Decision | |---|---| | DEC-17-01 | RCA master registry shape and per-tenant scoping. | | DEC-17-02 | Lifecycle state machine: `draft → in_progress → root_cause_identified → completed → approved → closed`. Reopen is a governed transition event from `closed → in_progress` per DEC-17-22 + SoD-17-06; appends a new lifecycle event + new investigation iteration without mutating or erasing prior closed evidence. | | DEC-17-03 | Server-authoritative race-safe `RCA-{YYYY}-{nnnnnn}` numbering via DB sequence. | | DEC-17-04 | Source linkage: at least one of deviation / finding / OOS investigation / complaint required; existence validated at application layer before persistence; cross-tenant source linkage forbidden. | | DEC-17-05 | Contributing-factor entity model with evidence-reference arrays and tombstone-preserved deletion. | | DEC-17-06 | Methodology catalogue (5-Why, Fishbone, Fault Tree) at launch; tenant-configurable. | | DEC-17-07 | Methodology application to RCA with methodology-accessibility verification before instance creation. | | DEC-17-08 | 5-Why workflow with step ladder; methodology steps immutable post-approval / post-closure per DEC-17-15. | | DEC-17-09 | Fishbone workflow with causes per category. | | DEC-17-10 | Fault Tree workflow with parent-node + gate-type Boolean tree; deterministic probability calculation. | | DEC-17-11 | RCA action management (interim-control / containment / corrective-proposal / preventive-proposal); permanent CAPA flows downstream to URS-18. | | DEC-17-12 | Conclusion capture entity with root-cause statement, contributing-factor summary, evidence basis, recommended-CAPA summary. | | DEC-17-13 | RCA approval requires `rcas:approve` permission + `withAuthority(...)` + Controlled Approval Modal e-signature; SoD-17-01 enforced. | | DEC-17-14 | Downstream CAPA handoff via `rca_conclusion_created` event payload. | | DEC-17-15 | Post-approval / post-closure immutability across RCA header, contributing factors, actions, methodology instances, and methodology steps; IMMUTABLE_STATUSES = {`approved`, `closed`}; `assertRCAMutable(...)` guard on every mutation route. | | DEC-17-16 | RCA closure requires `approved` state, all RCA actions in terminal status, conclusion present, closure-rationale captured, e-signature by `final_quality_approver`; SoD-17-04 enforced. | | DEC-17-17 | Multi-dimensional context: persistence layer MUST persist `study_id`, `site_id`, `product_id`, `supplier_id`, `batch_id` per the registry schema. | | DEC-17-18 | AI architecture binding: NO direct LLM / generative AI write to RCA tables; static deterministic AI advisory only; MIRA read-only context for closed RCAs. | | DEC-17-19 | Audit trail: every mutation emits to URS-06 substrate with reason-for-change discipline; reviewer disposition + closure-signoff evidence captured. | | DEC-17-20 | Configurable methodology catalogue at tenant level; platform default methodologies (5-Why, Fishbone, Fault Tree). | | DEC-17-21 | Critical-RCA approval (where the RCA is linked to a critical deviation per URS-16, a class-I recall complaint per URS-14, an inconclusive OOS per URS-15, or a critical finding per URS-21) requires `final_quality_approver` + executive authority co-sign per SoD-17-07. | | DEC-17-22 | Reopen of closed RCA is a governed transition event from `closed → in_progress`; requires `executive_authority` co-sign + reason; appends a new lifecycle event + new investigation iteration; does NOT mutate or erase prior closed evidence. SoD-17-06: executive reopen co-signer ≠ original closure authority. | --- ## 3. Roles, Authority Profiles, Segregation of Duties ### 3.1 Roles consumed (URS-02 catalogue) | Role key | Description | |---|---| | `viewer` | Read-only access within Module 17. | | `investigator` | Can create RCAs, add contributing factors, apply methodology, capture conclusion. | | `investigation_lead` | Senior investigator who leads the RCA; can assign other investigators; can sign investigation conclusion. | | `qa_reviewer` | QA reviewer who reviews the RCA conclusion and signs approval (subject to SoD-17-01). | | `quality_lead` | Module 17 administrative oversight within tenant; reviews open RCAs; manages tenant methodology catalogue. | | `practice_lead_gmp` | GMP practice lead; co-signs approvals for GMP-practice critical RCAs per DEC-17-21. | | `practice_lead_gcp` | GCP practice lead; co-signs approvals for GCP-practice critical RCAs. | | `practice_lead_gdp` | GDP practice lead. | | `practice_lead_glp` | GLP practice lead. | | `practice_lead_gvp` | GVP practice lead. | | `closure_authority` | Authority who signs RCA closure (subject to SoD-17-04). | | `auditor` | Read access to RCAs and RCA audit trail. | | `admin` | Module 17 tenant-administrative actions (taxonomy configuration, methodology catalogue management). | | `platform_admin` | Verixa platform — tenant-scoped Module 17 actions are support / break-glass only with reason, support-ticket reference, electronic signature, `PLATFORM_TENANT_ACCESS_USED` audit emit, and SOC alert; routine tenant RCA administration belongs to tenant `admin` users. | | `super_admin` | Verixa super-admin — tenant-scoped Module 17 actions are support / break-glass only under the same controls as `platform_admin`. | | `executive_authority` | Founder / Chairman & MD — co-signs critical-RCA approvals per DEC-17-21 and reopen events per DEC-17-22. | ### 3.2 Authority Profiles (URS-05) | Authority Profile | Purpose | |---|---| | `investigation_lead_authority` | Investigation conclusion sign by the investigation lead. | | `qa_review_authority` | RCA approval sign by QA reviewer (subject to SoD-17-01). | | `final_quality_approver` | RCA approval and closure sign by final quality approver. | | `practice_lead_*` | Practice-lead co-sign for critical-RCA approval per DEC-17-21. | | `executive_authority` | Founder co-sign for critical-RCA approval per DEC-17-21 and reopen per DEC-17-22. | | `closure_authority` | RCA closure sign per DEC-17-16. | | `rca_reopen_executive_authority` | Executive authority for reopen (DEC-17-22). | ### 3.3 Permissions (Module 17 owns) - `rcas:read` - `rcas:create` - `rcas:investigate` (with authority + SoD-17-02) - `rcas:add_contributing_factor` - `rcas:remove_contributing_factor` (tombstone-preserved) - `rcas:apply_methodology` - `rcas:add_methodology_step` - `rcas:edit_methodology_step` - `rcas:delete_methodology_step` - `rcas:add_action` - `rcas:update_action` - `rcas:create_conclusion` (with authority) - `rcas:approve` (with authority + SoD-17-01) - `rcas:close` (with authority + SoD-17-04) - `rcas:reopen_executive` (executive authority + SoD-17-06) - `rcas:read_audit` ### 3.4 Segregation-of-Duties constraints | ID | Constraint | |---|---| | SoD-17-01 | The RCA approver MUST NOT be the RCA creator. | | SoD-17-02 | The investigation lead assigned to the RCA MUST be different from the discoverer (creator) of the RCA. | | SoD-17-03 | The conclusion sign-off (`investigation_lead_authority`) MUST NOT be the contributing-factor sole author for that RCA where the investigator authored the entire factor set without independent review. | | SoD-17-04 | The closure authority MUST NOT be the RCA creator. | | SoD-17-05 | The methodology step deleter MUST NOT be the methodology step creator (for steps deleted within the same iteration; tombstone preserved either way). | | SoD-17-06 | The executive authority reopen co-signer MUST NOT be the original closure authority. | | SoD-17-07 | Critical-RCA approval matrix: no single user can satisfy two required slots (`final_quality_approver` + executive authority + practice lead). | ### 3.5 Worked SoD examples **Example 1: Standard minor-deviation RCA — direct approval.** A QC analyst opens deviation `DEV-2026-001234` (minor, GMP). The QC supervisor (different from the analyst per SoD-16-01) creates RCA `RCA-2026-000456` linked to the deviation. The investigation lead (different from the QC supervisor per SoD-17-02) is assigned. The investigation lead applies the 5-Why methodology, captures three contributing factors with evidence references, drafts the conclusion. The QA reviewer (different from the QC supervisor per SoD-17-01) reviews the conclusion and signs approval with Controlled Approval Modal e-signature. RCA transitions to `approved`. The closure authority (different from the QC supervisor per SoD-17-04) signs closure after all RCA actions are completed. RCA `closed`. **Example 2: Critical-RCA approval requires executive authority co-sign (DEC-17-21).** A sterile-filtration deviation on Batch B-9876 produces an RCA linked to a critical GMP deviation (`practice = gmp`, severity = `critical`). RCA conclusion identifies a procedural root cause requiring SOP revalidation. Approval requires `final_quality_approver` + `practice_lead_gmp` + executive authority co-sign per DEC-17-21. SoD-17-07 enforced (no user can satisfy two slots). **Example 3: SoD-17-01 enforcement — creator attempts to approve own RCA.** The investigator who created `RCA-2026-000457` is also a qualified QA reviewer and attempts to approve it. Service rejects with HTTP 403 + `RCA_SOD_VIOLATION_CREATOR_CANNOT_APPROVE` and the URS-04 BR-04-21 reason "the approver cannot be the author of the version under review". URS-06 audit substrate records the attempt. **Example 4: SoD-17-02 enforcement — discoverer attempts to be investigation lead.** The QC analyst who created `RCA-2026-000458` (linked to a deviation they discovered) attempts to assign themselves as investigation lead. Service rejects with HTTP 403 + `RCA_SOD_VIOLATION_DISCOVERER_CANNOT_BE_INVESTIGATION_LEAD`. URS-06 records the attempt. **Example 5: Post-approval mutation attempt blocked (DEC-17-15).** An approved RCA is found to have a typo in the root-cause statement. The investigator attempts a direct edit. Service rejects with HTTP 403 + `RCA_IMMUTABLE_FINAL_STATE` and the 21 CFR Part 11 §11.10(e) message. The proper path: reopen via executive authority co-sign per DEC-17-22, edit, re-approve. **Example 6: Reopen requires executive authority co-sign (DEC-17-22).** A closed RCA is found post-closure to have additional contributing factors not previously identified. QA proposes reopen. Executive authority e-signs reopen via `rca_reopen_executive_authority` with documented reason "Additional Batch B-9877 implicated; new investigation iteration required". SoD-17-06 enforced. RCA transitions back to `in_progress`. The prior closed evidence is preserved; a new investigation iteration appends to the RCA. **Example 7: AI prohibition runtime block (DEC-17-18).** A user attempts to invoke "AI-suggest root cause" via an experimental UI surface that would write to `rca_conclusions`. Runtime block returns HTTP 403 + `RCA_GENAI_PROHIBITED`. URS-06 audit substrate records the attempt. Static deterministic AI may suggest "similar prior RCAs in the last 12 months" — that is permitted as advisory, visibly labelled per ARCH-AI-001 AC-3, and the suggestion does not autonomously write per AC-4. ### 3.6 Role-permission matrix (Module 17 administrative surface only) | Permission | viewer | investigator | investigation_lead | qa_reviewer | quality_lead | practice_lead_* | closure_authority | auditor | admin | platform_admin | super_admin | |---|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:| | `rcas:read` | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | support / break-glass only | support / break-glass only | | `rcas:create` | ✗ | ✓ | ✓ | ✗ | ✓ | ✗ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only | | `rcas:investigate` (with authority + SoD-17-02) | ✗ | ✗ | ✓ | ✗ | ✓ | ✗ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only | | `rcas:add_contributing_factor` | ✗ | ✓ | ✓ | ✗ | ✓ | ✗ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only | | `rcas:remove_contributing_factor` (tombstone-preserved) | ✗ | ✓ | ✓ | ✗ | ✓ | ✗ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only | | `rcas:apply_methodology` | ✗ | ✓ | ✓ | ✗ | ✓ | ✗ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only | | `rcas:add_methodology_step` | ✗ | ✓ | ✓ | ✗ | ✓ | ✗ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only | | `rcas:edit_methodology_step` | ✗ | ✓ | ✓ | ✗ | ✓ | ✗ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only | | `rcas:delete_methodology_step` (with SoD-17-05) | ✗ | ✓ | ✓ | ✗ | ✓ | ✗ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only | | `rcas:add_action` | ✗ | ✓ | ✓ | ✗ | ✓ | ✗ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only | | `rcas:update_action` | ✗ | ✓ | ✓ | ✗ | ✓ | ✗ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only | | `rcas:create_conclusion` (with authority) | ✗ | ✗ | ✓ | ✗ | ✓ | ✗ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only | | `rcas:approve` (with authority + SoD-17-01) | ✗ | ✗ | ✗ | ✓ | ✓ | ✓ (critical-RCA) | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only | | `rcas:close` (with authority + SoD-17-04) | ✗ | ✗ | ✗ | ✗ | ✓ | ✗ | ✓ | ✗ | ✓ | support / break-glass only | support / break-glass only | | `rcas:reopen_executive` (executive authority + SoD-17-06) | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ (executive authority only) | | `rcas:read_audit` | ✗ | ✗ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | support / break-glass only | support / break-glass only | External identities (URS-01 §3.2.3) MAY be added as `viewer` for read-only access to RCAs within their study-grant scope; cannot hold investigator / approval / closure roles. --- ## 4. End-to-End User Journeys The 28 launch user journeys cover the full RCA lifecycle: create from each source type, investigation lead assignment, contributing-factor capture, methodology application (5-Why, Fishbone, Fault Tree), action management, conclusion capture, approval (standard and critical), closure, reopen, void, AI advisory surface, AI prohibition negative paths, platform identity break-glass, India CDSCO scope, multi-dimensional context, and immutability negative paths. ### J-01 — Create RCA from a deviation (URS-16 source) A QC supervisor opens deviation `DEV-2026-001234` (minor, GMP). She clicks "Open RCA" from the deviation surface. Module 17 service `createRCA(...)` validates the `deviation_id` exists in the same tenant (DEC-17-04), captures `study_id`, `site_id`, `product_id`, `batch_id` from the deviation context (DEC-17-17), assigns server-authoritative `RCA-2026-000456` (DEC-17-03), state `draft`. URS-06 records create. ### J-02 — Create RCA from a finding (URS-21 source) A QA auditor opens a critical finding `FND-2026-000123`. From the finding surface they click "Open RCA". Module 17 validates the `finding_id` exists same-tenant; captures applicable scope dimensions from the finding context; assigns `RCA-2026-000457`. State `draft`. ### J-03 — Create RCA from an OOS investigation (URS-15 source) A QC analyst escalates an inconclusive OOS investigation `OOS-2026-001235` to RCA. Module 17 validates the `oos_investigation_id` exists same-tenant; captures product / site / batch scope from the OOS context; assigns `RCA-2026-000458`. State `draft`. ### J-04 — Create RCA from a complaint (URS-14 source) A complaint investigator escalates complaint `CMP-2026-000789` to RCA. Module 17 validates the `complaint_id` exists same-tenant; captures product / batch / supplier scope from the complaint context; assigns `RCA-2026-000459`. State `draft`. ### J-05 — Source-linkage validation negative path Investigator submits an RCA with `deviation_id = "DEV-2099-999999"` (does not exist). Service rejects with HTTP 400 + `SOURCE_RECORD_NOT_FOUND`. URS-06 records the rejected attempt. ### J-06 — Cross-tenant source linkage negative path Investigator submits an RCA in tenant A linked to a deviation in tenant B. Service rejects with HTTP 400 + `CROSS_TENANT_SOURCE_LINKAGE_FORBIDDEN`. URS-06 records the rejected attempt. ### J-07 — Investigation lead assignment with SoD-17-02 QC supervisor assigns an investigation lead. Service verifies the proposed lead is not the discoverer (creator) per SoD-17-02. If they are the same user, service rejects with HTTP 403 + `RCA_SOD_VIOLATION_DISCOVERER_CANNOT_BE_INVESTIGATION_LEAD`. On valid assignment, RCA transitions `draft → in_progress`. ### J-08 — Add contributing factors with evidence references Investigation lead adds three contributing factors via `POST /rcas/:rcaId/contributing-factors` with `evidence_references_jsonb` linking to URS-12 controlled documents (`DOC-MFG-014-v3.0`, `DOC-DEV-2026-001234`). Each factor row carries `factor_category`, `factor_description`, evidence references. URS-06 records each add. ### J-09 — Remove a contributing factor (tombstone-preserved) Investigator decides one contributing factor is not material. They remove it via `DELETE /rcas/:rcaId/contributing-factors/:factorId`. Service does NOT physically delete; sets `removed_at`, `removed_by`, `removed_reason`. The factor row remains visible to auditors. URS-06 records the removal. ### J-10 — Apply 5-Why methodology Investigator applies the 5-Why methodology via `POST /rcas/:rcaId/methodology` with `methodology_id` referencing the 5-Why catalogue row. Service verifies methodology accessibility (DEC-17-07: methodology is active for tenant). On success, methodology instance is created. Investigator adds 5 why-steps via `POST /rcas/:rcaId/methodology/:instanceId/why-steps`. Each step captures `why_question`, `answer`, `evidence_observation`. URS-06 records each step. ### J-11 — Apply Fishbone methodology Investigator applies the Fishbone methodology with default categories (Manpower / Method / Machine / Material / Measurement / Mother-Nature / Management). Investigator adds causes per category via `POST /rcas/:rcaId/methodology/:instanceId/fishbone-causes`. Each cause carries `category`, `cause_text`, `evidence_observation`. ### J-12 — Apply Fault Tree methodology Investigator applies Fault Tree methodology. Investigator adds nodes via `POST /rcas/:rcaId/methodology/:instanceId/fault-tree-nodes` with `parent_node_id` (nullable for top event), `gate_type` (`AND` / `OR` / `NONE`), `node_label`, `node_probability`. Service computes top-event probability via `calculateFaultTreeProbability(...)` deterministically. AI is not used. ### J-13 — Add an interim-control RCA action Investigation lead adds an RCA action via `POST /rcas/:rcaId/actions` with `action_type = interim_control`, `action_description = "Pre-filter integrity test before each batch"`, assigned user, due date. Status `open`. URS-06 records create. ### J-14 — Update / close an RCA action Action assignee completes the interim-control action, updates status to `completed`, captures `closure_notes`, links closure evidence document. URS-06 records the update. ### J-15 — Capture RCA conclusion Investigation lead captures the conclusion via `POST /rcas/:rcaId/conclusions` with `root_cause_statement`, `contributing_factor_summary`, `evidence_basis_jsonb`, `recommended_capa_summary`. Service transitions RCA to `completed`. URS-06 records create. The `rca_conclusion_created` event is emitted (per DEC-17-14) and consumed by URS-18 CAPA service. ### J-16 — Approve RCA (standard) with SoD-17-01 QA reviewer (different from RCA creator per SoD-17-01) opens the RCA approval surface, reviews the conclusion, opens Controlled Approval Modal (URS-04), enters password / meaningOfSignature / reasonForChange, submits. Service validates `withAuthority(...)` Authority Profile resolution, validates SoD-17-01, persists `approved_e_sig_id`, transitions RCA to `approved`. URS-06 emits `RCA_APPROVED` with the e-signature attribution. ### J-17 — Approve RCA (critical) requires executive authority co-sign (DEC-17-21) A critical-deviation-linked RCA reaches conclusion. Approval requires `final_quality_approver` + practice lead (per practice — e.g., `practice_lead_gmp`) + executive authority co-sign per DEC-17-21. SoD-17-07 enforced (no user can satisfy two slots). On all three signatures present, RCA transitions to `approved`. URS-06 emits `RCA_APPROVED` with all three signature attributions. ### J-18 — SoD-17-01 enforcement — creator attempts to approve own RCA Investigator who created `RCA-2026-000459` attempts to approve it. Service rejects with HTTP 403 + `RCA_SOD_VIOLATION_CREATOR_CANNOT_APPROVE` and the URS-04 BR-04-21 message. URS-06 records the attempt. ### J-19 — Methodology step delete with SoD-17-05 Investigator A added a 5-Why step. Investigator A attempts to delete the same step. Service rejects with HTTP 403 + `RCA_SOD_VIOLATION_STEP_DELETER_CANNOT_BE_STEP_CREATOR` (within the same iteration). Tombstone preservation applies either way; but the deleter must be different. ### J-20 — RCA closure with SoD-17-04 Closure authority (different from creator per SoD-17-04) signs closure via `POST /rcas/:rcaId/close`. Service validates RCA is `approved`, all RCA actions in terminal status, conclusion present, closure-rationale captured, closure authority Authority Profile resolved. Persists `closed_e_sig_id`, `closed_at`. RCA transitions to `closed`. URS-06 emits `RCA_CLOSED`. ### J-21 — Post-closure immutability negative path (DEC-17-15) User attempts to add a contributing factor to a closed RCA. Service rejects with HTTP 403 + `RCA_IMMUTABLE_FINAL_STATE` and the 21 CFR Part 11 §11.10(e) message. URS-06 records the attempt. The proper path is reopen via DEC-17-22. ### J-22 — Governed reopen by executive authority (DEC-17-22) QA proposes reopen of `RCA-2026-000459` (closed) on the basis of newly discovered evidence implicating Batch B-9877. Executive authority opens the reopen surface, reviews the QA rationale, e-signs reopen via `rca_reopen_executive_authority` with documented reason. SoD-17-06 enforced (executive authority ≠ original closure authority). RCA transitions `closed → in_progress`. The prior closed evidence is preserved as a closed lifecycle event; a new investigation iteration appends to the RCA. URS-06 emits `RCA_REOPENED`. ### J-23 — Static deterministic AI advisory surface (DEC-17-18) Investigator opens a new RCA. The advisory panel surfaces "Similar prior RCAs in the last 12 months on this product / deviation type" via static deterministic similarity over closed RCAs (no LLM). Surfacing is visibly labelled "AI-suggested — requires human review" per ARCH-AI-001 AC-3. Investigator MAY use suggestions as inspiration but the final RCA is human-authored. The advisory output does NOT autonomously write to the RCA per AC-4. ### J-24 — AI prohibition runtime block (DEC-17-18) User attempts to invoke "AI-suggest root cause" via an experimental UI surface that would write to `rca_conclusions`. Runtime block returns HTTP 403 + `RCA_GENAI_PROHIBITED`. URS-06 records the attempt. Per the internal Annex 22 control, generative AI is prohibited in RCA conclusion finalisation. ### J-25 — MIRA copilot read-only context (URS-32) A reviewer opens MIRA copilot from a closed RCA. MIRA reads the RCA context (`rca → rcas` mapping per URS-32 §718-719) and answers questions about prior RCAs in natural language. MIRA MUST NOT write to any RCA table. URS-32 governs the MIRA service. ### J-26 — Multi-dimensional context capture (DEC-17-17) Investigator opens an RCA linked to a deviation that affects multiple sites. They capture `site_id` for the primary site and add the related sites via the `affected_sites_jsonb` (forward roadmap). At launch, RCA captures one primary `site_id`; multi-site RCAs MAY use linked deviation context per URS-16. The persistence layer MUST persist `study_id`, `site_id`, `product_id`, `supplier_id`, `batch_id` per the registry schema. ### J-27 — India CDSCO worked example A pharma manufacturer in India (CDSCO Form 25 / Form 28 manufacturing licence holder) operates Module 17 for GMP manufacturing deviations. Module 17 carries `practice = gmp`; the linked deviation per URS-16 carries the India regulatory framework defaults from URS-08 tenant context. The §14 regulatory mapping row applicable to India (D&C Act 1940 + Drugs Rules 1945 + Revised Schedule M + NDCT 2019 where clinical scope + Medical Devices Rules 2017 where device scope) applies to RCA records originating from India tenant operation, subject to per-tenant jurisdictional regulatory assessment. ### J-28 — Platform-identity break-glass A platform support engineer needs to inspect a tenant's RCA for an inspection-readiness query. They open the platform support / break-glass surface, capture support-ticket reference, electronic signature, reason. Service emits `PLATFORM_TENANT_ACCESS_USED` to URS-06; SOC alert routed; tenant-scoped read access granted under the controlled support / break-glass envelope per the URS-08 platform-identity policy. Routine tenant RCA administration remains the tenant `admin` user's responsibility. --- ## 5. Front-end Module 17 ### 5.1 Routes | Route | Purpose | |---|---| | `/rcas` | Module 17 landing — RCA register filtered by tenant + scope dimensions | | `/rcas/:rcaId` | RCA detail with tabbed view (overview, contributing factors, methodology instances, actions, conclusion, lifecycle history, audit) | | `/rcas/new` | RCA creation surface (with source linkage selection) | | `/rcas/:rcaId/methodology` | Methodology application surface | | `/rcas/:rcaId/methodology/5-why` | 5-Why ladder editor | | `/rcas/:rcaId/methodology/fishbone` | Fishbone diagram editor | | `/rcas/:rcaId/methodology/fault-tree` | Fault Tree node editor with probability calculation | | `/rcas/:rcaId/conclusion` | Conclusion capture surface | | `/rcas/:rcaId/approve` | Approval surface (Controlled Approval Modal) | | `/rcas/:rcaId/close` | Closure surface | | `/rcas/:rcaId/reopen` | Reopen surface (executive authority only) | | `/rcas/admin/methodology-catalogue` | Tenant methodology catalogue admin | ### 5.2 Components - **RCARegisterTable** — paginated, filterable table of RCAs. - **RCADetailTabs** — tabbed view of an RCA. - **CreateRCAWizard** — multi-step: source selection (deviation / finding / OOS / complaint) → scope-dimension capture → priority / practice → submit. - **ContributingFactorEditor** — add / view / remove (tombstone-preserved) contributing factors with evidence reference picker. - **MethodologyApplyDialog** — methodology selector with accessibility verification. - **FiveWhyLadder** — interactive 5-Why ladder editor. - **FishboneDiagram** — interactive Fishbone diagram with cause add / categorise. - **FaultTreeEditor** — interactive Fault Tree editor with node add / gate-type selection / probability calculation surface. - **RCAActionPlanner** — RCA action add / update / list. - **ConclusionCapturePanel** — root-cause statement + contributing-factor summary + evidence basis + recommended-CAPA summary. - **ApprovalModal** — Controlled Approval Modal (URS-04) with SoD-17-01 enforcement. - **CriticalRCAApprovalMatrix** — multi-sign matrix for critical-RCA approval (DEC-17-21). - **ClosureModal** — closure surface with prerequisite check. - **ExecutiveAuthorityReopenModal** — executive-authority-only reopen. - **RCAAuditTrailView** — full RCA audit trail consumed from URS-06. ### 5.3 Accessibility WCAG 2.1 Level AA. Keyboard-navigable. Screen-reader labels for all interactive elements, including the FiveWhyLadder, FishboneDiagram, and FaultTreeEditor (with non-visual fallback for structural diagrams per URS-29 if applicable). --- ## 6. Back-end Module 17 ### 6.1 Architecture overview ```mermaid flowchart LR ROUTES[rca.routes.ts + rca-methodology.routes.ts] --> SVC[rca.service.ts + rca-methodology.service.ts] SVC --> DB[(rca tables)] SVC --> AUDIT[(URS-06 audit substrate)] SVC --> EVT[eventBus.emit rca_conclusion_created] EVT --> CAPA[URS-18 CAPA service consumer] ``` Diagram 6.1-A — Module 17 architecture overview. The target `rca` code module is the expected owner of routes, services, and DB persistence; ownership is target binding and remains subject to repository verification and validation evidence. URS-06 substrate is consumed for audit; URS-18 CAPA consumes the `rca_conclusion_created` event downstream. ### 6.1.1 RCA lifecycle state machine (full) ```mermaid stateDiagram-v2 [*] --> draft : create draft --> in_progress : investigation_lead_assigned (SoD-17-02) in_progress --> root_cause_identified : root_cause_added (DEC-17-08 / DEC-17-09 / DEC-17-10) root_cause_identified --> completed : conclusion_created (DEC-17-12) in_progress --> completed : conclusion_created (skip when methodology not required for trivial RCAs; SHOULD apply methodology) completed --> approved : approval_signed (DEC-17-13 + SoD-17-01) approved --> closed : closure_signed (DEC-17-16 + SoD-17-04) closed --> in_progress : reopen — governed transition (DEC-17-22 + SoD-17-06; appends new lifecycle event + new investigation iteration; does NOT mutate or erase prior closed evidence) closed --> [*] : immutable parent + children DEC-17-15 note right of in_progress SoD-17-01: approver ≠ creator SoD-17-02: investigation lead ≠ discoverer SoD-17-03: conclusion sign ≠ contributing-factor sole author SoD-17-04: closure authority ≠ creator SoD-17-05: step deleter ≠ step creator (within iteration) SoD-17-06: reopen co-signer ≠ original closure authority SoD-17-07: critical-RCA matrix — no user can hold two slots end note ``` Diagram 6.1-B — RCA lifecycle state machine including methodology-driven advancement, executive-authority-cosigned reopen path (DEC-17-22), and post-approval / post-closure parent + child immutability (DEC-17-15). ### 6.2 Data model requirements | Entity | Purpose | Key fields | Required | Unique | Tenant isolation | Versioning | Retention | Soft-delete | Audit | E-sig link | |---|---|---|---|---|---|---|---|---|---|---| | `rcas` | Canonical RCA record per DEC-17-01 | `id`, `tenant_id`, `rca_number`, `discovery_date`, `creator_user_id`, `investigation_lead_user_id` (nullable), `study_id` (FK URS-07 nullable), `site_id` (FK URS-09 nullable), `product_id` (FK URS-10 nullable), `supplier_id` (FK URS-11 nullable), `batch_id` (FK URS-23 nullable), `deviation_id` (FK URS-16 nullable), `finding_id` (FK URS-21 nullable), `oos_investigation_id` (FK URS-15 nullable), `complaint_id` (FK URS-14 nullable), `practice`, `priority`, `lifecycle_state`, `study_scope`, `site_scope`, `product_scope`, `supplier_scope`, `batch_scope`, `created_at`, `updated_at`, `approved_at` (nullable), `approved_e_sig_id` (nullable), `closed_at` (nullable), `closed_e_sig_id` (nullable), `deleted_at` (nullable), `voided_at` (nullable), `voided_reason`, `voided_signature_id` | per-state | unique(`tenant_id`, `rca_number`) | RLS on `tenant_id` | stateful + append-only audit | retain (long-term) | yes (voided / closed preserved) | yes | yes | | `rca_contributing_factors` | Per-RCA contributing-factor record per DEC-17-05 | `id`, `tenant_id`, `rca_id`, `factor_category`, `factor_description`, `evidence_references_jsonb`, `created_by`, `created_at`, `removed_at` (nullable; tombstone), `removed_by` (nullable), `removed_reason` (nullable) | core required | unique(`rca_id`, `id`) | RLS via RCA tenant | append-only with tombstone | retain (long-term) | yes (tombstone-preserved) | yes | not applicable | | `rca_methodologies` | Tenant methodology catalogue per DEC-17-06 | `id`, `tenant_id`, `methodology_type` (`five_why` / `fishbone` / `fault_tree`), `methodology_label`, `methodology_description`, `default_categories_jsonb`, `effective_from`, `effective_to` (nullable) | core required | unique(`tenant_id`, `methodology_type`, `effective_from`) | RLS on `tenant_id` | versioned | retain (long-term) | not applicable | yes | not applicable | | `rca_methodology_instances` | Per-RCA × methodology application per DEC-17-07 | `id`, `tenant_id`, `rca_id`, `methodology_id` (FK), `applied_by`, `applied_at`, `removed_at` (nullable; tombstone) | core required | unique active(`rca_id`, `methodology_id`) | RLS via RCA tenant | append-only | retain (long-term) | yes (tombstone-preserved) | yes | not applicable | | `rca_methodology_steps` | Per-instance methodology steps (5-Why ladder, Fishbone causes, Fault Tree nodes) | `id`, `tenant_id`, `instance_id`, `step_type` (`why_step` / `fishbone_cause` / `fault_tree_node`), `step_index`, `parent_step_id` (nullable; for fault tree), `step_label`, `step_value` (text / number), `gate_type` (nullable; for fault tree), `node_probability` (nullable; for fault tree), `evidence_observation`, `created_by`, `created_at`, `removed_at` (nullable; tombstone), `removed_by` (nullable), `removed_reason` (nullable) | core required | unique(`instance_id`, `id`) | RLS via RCA tenant | append-only with tombstone | retain (long-term) | yes (tombstone-preserved) | yes | not applicable | | `rca_actions` | Per-RCA action record per DEC-17-11 | `id`, `tenant_id`, `rca_id`, `action_description`, `action_type` (`interim_control` / `containment` / `corrective_proposal` / `preventive_proposal`), `assigned_user_id`, `due_date`, `status` (`open` / `in_progress` / `completed` / `cancelled`), `closure_notes`, `closure_evidence_document_id` (FK URS-12 nullable), `created_by`, `created_at`, `closed_at` (nullable) | core required | unique(`rca_id`, `id`) | RLS via RCA tenant | stateful | retain (long-term) | not applicable | yes | yes (per stage) | | `rca_conclusions` | RCA conclusion entity per DEC-17-12 | `id`, `tenant_id`, `rca_id`, `root_cause_statement`, `contributing_factor_summary`, `evidence_basis_jsonb`, `recommended_capa_summary`, `created_by`, `created_at` | core required | unique(`rca_id`) | RLS via RCA tenant | append-only | retain (long-term) | not applicable | yes | yes (links to approved_e_sig_id on parent RCA) | | `rca_lifecycle_events` | Append-only lifecycle transition log | `id`, `tenant_id`, `rca_id`, `from_state`, `to_state`, `event_code`, `signature_set_jsonb` (derived read snapshot only; authoritative multi-signature evidence is stored in the module signature-slot table), `reason_jsonb`, `audit_log_id` (FK URS-06), `triggered_at`, `previous_hash`, `record_hash` | all | unique(`rca_id`, `id`); unique(`record_hash`) | RLS via RCA tenant | append-only | retain (long-term) | not applicable | yes | yes | | `rca_approvals` | Per-approval signature-slot table per DEC-17-13 / DEC-17-21 | `id`, `tenant_id`, `rca_id`, `slot_role` (`final_quality_approver` / `practice_lead_*` / `executive_authority`), `slot_user_id`, `slot_e_sig_id`, `slot_signed_at`, `slot_reason_for_change` | per-slot | unique(`rca_id`, `slot_role`, `slot_user_id`) | RLS via RCA tenant | append-only | retain (long-term) | not applicable | yes | yes | ### 6.3 API requirements | Method | Endpoint | Actor | Request | Response | Permission | Audit | Error codes | |---|---|---|---|---|---|---|---| | GET | `/rcas` | tenant-scoped | filters | `RCA[]` | tenant base role + `audit:read` | `RCA_REGISTER_VIEW_OPENED` once per session | none | | GET | `/rcas/:rcaId` | tenant-scoped | none | full RCA detail with contributing factors + methodology instances + actions + conclusion | `rcas:read` | none | `NOT_FOUND` | | POST | `/rcas` | investigator | source linkage + scope-dimension fields (electronic-signed) | `201` (state `draft`) | `rcas:create` | `RCA_CREATED` | `SOURCE_RECORD_NOT_FOUND`, `CROSS_TENANT_SOURCE_LINKAGE_FORBIDDEN`, `SCOPE_ANCHOR_REQUIRED`, `SOURCE_LINKAGE_REQUIRED`, validation | | PATCH | `/rcas/:rcaId` | investigator | partial fields (electronic-signed; reason-for-change required) | `200` | `rcas:investigate` | `RCA_UPDATED` | `RCA_IMMUTABLE_FINAL_STATE`, `REASON_FOR_CHANGE_REQUIRED`, validation | | POST | `/rcas/:rcaId/assign-investigation-lead` | investigation lead | reason (electronic-signed) | `200` | `rcas:investigate` | `INVESTIGATION_LEAD_ASSIGNED` | `RCA_SOD_VIOLATION_DISCOVERER_CANNOT_BE_INVESTIGATION_LEAD` | | POST | `/rcas/:rcaId/contributing-factors` | investigator | factor fields (electronic-signed) | `201` | `rcas:add_contributing_factor` | `CONTRIBUTING_FACTOR_ADDED` | `RCA_IMMUTABLE_FINAL_STATE`, validation | | DELETE | `/rcas/:rcaId/contributing-factors/:factorId` | investigator | reason (electronic-signed) | `200` (tombstone) | `rcas:remove_contributing_factor` | `CONTRIBUTING_FACTOR_REMOVED` | `RCA_IMMUTABLE_FINAL_STATE`, `REMOVAL_REASON_REQUIRED` | | POST | `/rcas/:rcaId/methodology` | investigator | `methodology_id` (electronic-signed) | `201` | `rcas:apply_methodology` | `METHODOLOGY_APPLIED` | `METHODOLOGY_NOT_ACCESSIBLE`, `RCA_IMMUTABLE_FINAL_STATE` | | POST | `/rcas/:rcaId/methodology/:instanceId/why-steps` | investigator | step fields (electronic-signed) | `201` | `rcas:add_methodology_step` | `METHODOLOGY_STEP_ADDED` | `RCA_IMMUTABLE_FINAL_STATE` | | PATCH | `/rcas/:rcaId/methodology/:instanceId/why-steps/:stepId` | investigator | step fields (electronic-signed; reason-for-change required) | `200` | `rcas:edit_methodology_step` | `METHODOLOGY_STEP_UPDATED` | `RCA_IMMUTABLE_FINAL_STATE`, `REASON_FOR_CHANGE_REQUIRED` | | DELETE | `/rcas/:rcaId/methodology/:instanceId/why-steps/:stepId` | investigator | reason (electronic-signed) | `200` (tombstone) | `rcas:delete_methodology_step` | `METHODOLOGY_STEP_REMOVED` | `RCA_IMMUTABLE_FINAL_STATE`, `RCA_SOD_VIOLATION_STEP_DELETER_CANNOT_BE_STEP_CREATOR` | | POST | `/rcas/:rcaId/methodology/:instanceId/fishbone-causes` | investigator | cause fields (electronic-signed) | `201` | `rcas:add_methodology_step` | `METHODOLOGY_STEP_ADDED` | `RCA_IMMUTABLE_FINAL_STATE` | | POST | `/rcas/:rcaId/methodology/:instanceId/fault-tree-nodes` | investigator | node fields (electronic-signed) | `201` | `rcas:add_methodology_step` | `METHODOLOGY_STEP_ADDED` | `RCA_IMMUTABLE_FINAL_STATE` | | GET | `/rcas/:rcaId/methodology/:instanceId/fault-tree/probability` | viewer | none | `{topEventProbability}` | `rcas:read` | none | `NOT_FOUND`, `INSUFFICIENT_NODES` | | POST | `/rcas/:rcaId/actions` | investigator | action fields (electronic-signed) | `201` | `rcas:add_action` | `RCA_ACTION_CREATED` | `RCA_IMMUTABLE_FINAL_STATE`, validation | | PATCH | `/rcas/:rcaId/actions/:actionId` | action assignee or investigator | action fields (electronic-signed) | `200` | `rcas:update_action` | `RCA_ACTION_UPDATED` | `RCA_IMMUTABLE_FINAL_STATE`, validation | | GET | `/rcas/:rcaId/actions` | tenant-scoped | filters | `RCAAction[]` | `rcas:read` | none | none | | POST | `/rcas/:rcaId/conclusions` | investigation lead | conclusion fields (electronic-signed) | `201` | `rcas:create_conclusion` | `RCA_CONCLUSION_CREATED` (and emits `rca_conclusion_created` to URS-18) | `RCA_IMMUTABLE_FINAL_STATE`, `CONTRIBUTING_FACTORS_REQUIRED`, `METHODOLOGY_REQUIRED` (where applicable per practice / criticality) | | POST | `/rcas/:rcaId/approve` | qa_reviewer | reason (electronic-signed + MFA + Controlled Approval Modal) | `200` | `rcas:approve` | `RCA_APPROVED` | `RCA_SOD_VIOLATION_CREATOR_CANNOT_APPROVE`, `STATE_NOT_COMPLETED`, `MISSING_FOUNDER_COSIGN` (for critical), `MISSING_PRACTICE_LEAD_COSIGN` (for critical) | | POST | `/rcas/:rcaId/close` | closure authority | reason (electronic-signed + MFA) | `200` | `rcas:close` | `RCA_CLOSED` | `STATE_NOT_APPROVED`, `RCA_ACTIONS_NOT_TERMINAL`, `RCA_CONCLUSION_MISSING`, `CLOSURE_RATIONALE_REQUIRED`, `RCA_SOD_VIOLATION_CLOSER_CANNOT_BE_CREATOR` | | POST | `/executive/rcas/:rcaId/reopen` | executive authority | reason (electronic-signed + MFA + co-sign) | `200` | `rcas:reopen_executive` | `RCA_REOPENED` | `STATE_NOT_CLOSED`, `RCA_SOD_VIOLATION_REOPEN_COSIGNER_CANNOT_BE_CLOSURE_AUTHORITY` | ### 6.4 Workflow requirements (inline above and in §4 journeys) ### 6.5 Business rules - **BR-17-01** — Every RCA MUST have at least one source linkage (deviation_id / finding_id / oos_investigation_id / complaint_id) per DEC-17-04. - **BR-17-02** — Source-record existence MUST be validated at the application layer before persistence; cross-tenant source linkage forbidden. - **BR-17-03** — Every RCA MUST have at least one scope anchor (`study_id`, `site_id`, `product_id`, `supplier_id`, or `batch_id`); non-applicable dimensions MAY be `not_applicable` with controlled rationale. - **BR-17-04** — Lifecycle state machine per DEC-17-02: `draft → in_progress → root_cause_identified → completed → approved → closed`; reopen is governed transition `closed → in_progress` per DEC-17-22 (does NOT mutate or erase prior closed evidence). - **BR-17-05** — Investigation lead assignment enforces SoD-17-02 (lead ≠ discoverer). - **BR-17-06** — Contributing-factor removal preserves logical tombstone (no physical delete); evidence integrity preserved. - **BR-17-07** — Methodology accessibility verified before instance creation (DEC-17-07). - **BR-17-08** — RCA approval enforces SoD-17-01 (approver ≠ creator) + Controlled Approval Modal e-signature. - **BR-17-09** — Critical-RCA approval requires `final_quality_approver` + practice lead + executive authority co-sign per DEC-17-21; SoD-17-07 enforced. - **BR-17-10** — RCA closure enforces SoD-17-04 (closure authority ≠ creator) + 4-prerequisite check (state `approved`, all actions terminal, conclusion present, closure-rationale captured). - **BR-17-11** — Post-approval / post-closure immutability enforced via `assertRCAMutable(...)` on every mutation route across `rca` and `rca-methodology` services (DEC-17-15). - **BR-17-12** — Reopen is a governed transition event from `closed → in_progress` per DEC-17-22 + SoD-17-06; appends new lifecycle event + new investigation iteration; does NOT mutate or erase prior closed evidence. - **BR-17-13** — Every regulated mutation emits to URS-06 substrate with reason-for-change discipline (DEC-17-19). - **BR-17-14** — `rca_conclusion_created` event emitted on conclusion creation (DEC-17-14); URS-18 CAPA service consumes downstream. - **BR-17-15** — Static deterministic AI may surface advisory similarity / signal output; generative AI prohibited in conclusion finalisation, approval, and closure decision paths (DEC-17-18). - **BR-17-16** — MIRA copilot read-only mapping `rca → rcas` for closed RCAs; no MIRA write paths. - **BR-17-17** — Methodology step deletion enforces SoD-17-05 (deleter ≠ creator within iteration); tombstone-preserved. - **BR-17-18** — Audit-log writes atomic with originating action per URS-04 BR-04-15. - **BR-17-19** — Audit-trail row for every Module 17 mutation per QS-1. ### 6.6 Audit substrate Module 17 governance event vocabulary (canonical launch list; every code MUST have at least one writer and one regression test; adding a code is a Class 3 change): `RCA_CREATED`, `RCA_UPDATED`, `INVESTIGATION_LEAD_ASSIGNED`, `CONTRIBUTING_FACTOR_ADDED`, `CONTRIBUTING_FACTOR_REMOVED`, `METHODOLOGY_APPLIED`, `METHODOLOGY_INSTANCE_REMOVED`, `METHODOLOGY_STEP_ADDED`, `METHODOLOGY_STEP_UPDATED`, `METHODOLOGY_STEP_REMOVED`, `RCA_ACTION_CREATED`, `RCA_ACTION_UPDATED`, `RCA_ACTION_CLOSED`, `RCA_CONCLUSION_CREATED`, `RCA_APPROVED`, `RCA_CLOSED`, `RCA_REOPENED`, `RCA_VOIDED`, `RCA_SOD_VIOLATION_CREATOR_CANNOT_APPROVE`, `RCA_SOD_VIOLATION_DISCOVERER_CANNOT_BE_INVESTIGATION_LEAD`, `RCA_SOD_VIOLATION_STEP_DELETER_CANNOT_BE_STEP_CREATOR`, `RCA_SOD_VIOLATION_CLOSER_CANNOT_BE_CREATOR`, `RCA_SOD_VIOLATION_REOPEN_COSIGNER_CANNOT_BE_CLOSURE_AUTHORITY`, `RCA_GENAI_PROHIBITED`, `RCA_IMMUTABLE_FINAL_STATE`, `PLATFORM_TENANT_ACCESS_USED`, `PLATFORM_TENANT_ACCESS_DENIED`, `RCA_REGISTER_VIEW_OPENED`, `RCA_INSPECTION_PREP_EXPORTED`. The following events are emitted by upstream / downstream modules and consumed (read-only) by Module 17 dashboards: `DEVIATION_INVESTIGATING`, `OOS_PHASE_2_OPEN`, `COMPLAINT_INVESTIGATION_OPENED`, `FINDING_OPENED` (all read-only into Module 17 to populate the new-RCA selection lists). ### 6.7 Architecture binding — Internal Annex 22 GenAI prohibition control + ARCH-AI-001 (AC-2, AC-3, AC-4, AC-7) + internal EU AI Act Annex III high-risk classification (forward-looking; not enacted predicate rule; binding predicate-rule obligations remain those listed in §14) | Surface | AI use permitted | Governance | |---|---|---| | RCA conclusion authoring | NONE — internal Annex 22 prohibition | Manual decision; investigator-signed system of record | | RCA approval decision | NONE — internal Annex 22 prohibition | Manual decision; QA-reviewer-signed system of record | | RCA closure decision | NONE — internal Annex 22 prohibition | Manual closure; deterministic 4-prerequisite check | | AI similar-RCA suggestion (advisory) | YES — static deterministic over closed RCAs | ARCH-AI-001 AC-2/3/4/7 | | AI contributing-factor pattern (advisory) | YES — static deterministic; never autonomous | ARCH-AI-001 AC-2/3/4/7 | | MIRA copilot read-only retrieval over closed RCAs | YES — read-only | URS-32 RAG; mapping `rca → rcas` | Internal AI-governance obligations aligned with EU AI Act Annex III high-risk classification (treated as internal forward-looking control, not enacted predicate rule) include AI-specific QMS, conformity assessment, technical documentation, ongoing monitoring, human oversight; supported by ARCH-AI-001 architectural reference + URS-06 audit substrate + Authority-gated workflow. Jurisdiction-specific legal enforceability remains subject to a future jurisdiction-specific legal assessment. Binding predicate-rule obligations remain those listed in §14. --- ## 7. Cross-Module Wiring and Change-Impact ### 7.1 Cross-module wiring ```mermaid flowchart LR M14[URS-14 Complaints] --> M17 M15[URS-15 OOS / OOT] --> M17 M16[URS-16 Deviations] --> M17 M21[URS-21 Findings] --> M17 M17 --> M18[URS-18 CAPA] M17 -. precipitating change .-> M13[URS-13 Change Control] M17 --> M06[URS-06 Audit substrate] M17 --> M30[URS-30 Notifications] M22[URS-22 Inspection Mgmt] <-- M17 M26[URS-26 APQR] <-- M17 M32[URS-32 MIRA AI] <-- M17 (read-only) ANNEX22[Internal Annex 22 control — forward-looking] -.governs.-> M17 ARCHAI[ARCH-AI-001] -.governs advisory AI.-> M17 AIAct[Internal EU AI Act Annex III high-risk classification — forward-looking] -.classifies.-> M17 ``` Diagram 7.1-A — Module 17 cross-module wiring. ### 7.2 Change-Impact Matrix (CIM) | Asset | Cross-module consumers | Direction | Class | |---|---|---|---| | RCA conclusion event vocabulary | URS-18 CAPA | Outbound | Class 3 (add) | | Methodology catalogue | tenant admin | Inbound (configurable per tenant) | Class 2 | | RCA register | URS-21, URS-22, URS-26 | Outbound | Class 2 | | Source linkage FKs | URS-14, URS-15, URS-16, URS-21 | Inbound | Class 1 (rename) / Class 3 (add) | --- ## 8. AI / HITL controls - ARCH-AI-001 architectural reference applies. AC-2: advisory AI is secondary; manual primary path. AC-3: visible labelling. AC-4: no autonomous write. AC-7: graceful degradation. - Internal Annex 22 Draft 2025 forward-looking AI governance control prohibits generative / probabilistic AI in RCA conclusion finalisation, approval, and closure decision paths. Static deterministic AI may surface similar prior RCAs and contributing-factor patterns as advisory. - Verixa internally classifies AI-assisted RCA decision-making as high-risk AI under internal AI governance, aligned with the high-risk classification approach in EU AI Act Annex III, unless a jurisdiction-specific legal assessment determines otherwise. - MIRA copilot read-only mapping `rca → rcas` for closed RCAs (per URS-32). MIRA MUST NOT write to any RCA table. - AI service errors degrade gracefully: similarity panel hides if the AI service is unavailable; the RCA core workflow proceeds. --- ## 9. Performance / scalability - RCA register listing supports filters by `lifecycle_state`, `practice`, `priority`, scope dimensions; 95th-percentile response time MUST be ≤ 500 ms for tenants up to 100,000 RCAs. - Methodology step listing for an RCA returns within ≤ 200 ms for instances up to 1,000 steps. - Fault-Tree probability calculation for trees up to 1,000 nodes returns within ≤ 1 second. - Concurrent RCA mutation by independent investigators MUST not deadlock; row-level locking on the RCA header. --- ## 10. Localisation / i18n UI strings, lifecycle state labels, methodology category names, and error messages localised per tenant locale (English, French, German, Spanish, Hindi, Japanese, Mandarin at launch). --- ## 11. Errors ### 11.1 Error envelope Standard envelope (human message, machine code in upper-snake-case, optional structured details, correlation identifier). ### 11.2 Error-code catalogue | Code | HTTP | Path | UI behaviour | |---|---|---|---| | SOURCE_RECORD_NOT_FOUND | 400 | RCA create | inline error | | CROSS_TENANT_SOURCE_LINKAGE_FORBIDDEN | 400 | RCA create | inline error | | SCOPE_ANCHOR_REQUIRED | 400 | RCA create | inline error | | SOURCE_LINKAGE_REQUIRED | 400 | RCA create | inline error | | RCA_SOD_VIOLATION_DISCOVERER_CANNOT_BE_INVESTIGATION_LEAD | 403 | investigation lead assign | inline error | | RCA_SOD_VIOLATION_CREATOR_CANNOT_APPROVE | 403 | RCA approve | inline error | | RCA_SOD_VIOLATION_STEP_DELETER_CANNOT_BE_STEP_CREATOR | 403 | methodology step delete | inline error | | RCA_SOD_VIOLATION_CLOSER_CANNOT_BE_CREATOR | 403 | RCA close | inline error | | RCA_SOD_VIOLATION_REOPEN_COSIGNER_CANNOT_BE_CLOSURE_AUTHORITY | 403 | RCA reopen | inline error | | METHODOLOGY_NOT_ACCESSIBLE | 400 | methodology apply | inline error | | RCA_IMMUTABLE_FINAL_STATE | 403 | any mutation post-approval / post-closure | inline error citing 21 CFR Part 11 §11.10(e) | | REASON_FOR_CHANGE_REQUIRED | 400 | RCA update / methodology step update | inline error | | REMOVAL_REASON_REQUIRED | 400 | contributing-factor remove | inline error | | CONTRIBUTING_FACTORS_REQUIRED | 400 | conclusion create | inline error | | METHODOLOGY_REQUIRED | 400 | conclusion create (where applicable) | inline error | | STATE_NOT_DRAFT | 409 | lifecycle endpoints | inline error | | STATE_NOT_IN_PROGRESS | 409 | lifecycle endpoints | inline error | | STATE_NOT_ROOT_CAUSE_IDENTIFIED | 409 | lifecycle endpoints | inline error | | STATE_NOT_COMPLETED | 409 | RCA approve | inline error | | STATE_NOT_APPROVED | 409 | RCA close | inline error | | STATE_NOT_CLOSED | 409 | RCA reopen | inline error | | RCA_ACTIONS_NOT_TERMINAL | 409 | RCA close | inline error listing open actions | | RCA_CONCLUSION_MISSING | 409 | RCA close | inline error | | CLOSURE_RATIONALE_REQUIRED | 400 | RCA close | inline error | | MISSING_FOUNDER_COSIGN | 401 | RCA approve (critical) | open executive authority co-sign request | | MISSING_PRACTICE_LEAD_COSIGN | 401 | RCA approve (critical) | open practice-lead co-sign request | | INSUFFICIENT_NODES | 400 | fault-tree probability calc | inline error | | RCA_GENAI_PROHIBITED | 403 | any AI surface that would write to RCA tables | inline error citing internal Annex 22 control | | AUDIT_TRAIL_WRITE_FAILED | 500 | any state-changing action | toast; the originating action did NOT commit | | PLATFORM_TENANT_ACCESS_DENIED | 403 | platform identity outside support envelope | inline error; SOC alert | ### 11.3 Negative-path catalogue | Scenario | Detection | Response | UI behaviour | |---|---|---|---| | Create RCA with non-existent deviation | back end | `400 SOURCE_RECORD_NOT_FOUND` | inline error | | Create RCA without scope anchor | back end | `400 SCOPE_ANCHOR_REQUIRED` | inline error | | Discoverer attempts to be investigation lead | back end | `403 RCA_SOD_VIOLATION_DISCOVERER_CANNOT_BE_INVESTIGATION_LEAD` | inline error | | Creator attempts to approve own RCA | back end | `403 RCA_SOD_VIOLATION_CREATOR_CANNOT_APPROVE` | inline error | | Edit on closed RCA | back end | `403 RCA_IMMUTABLE_FINAL_STATE` | inline error | | Approve RCA before conclusion exists | back end | `409 STATE_NOT_COMPLETED` | inline error | | Close RCA with open actions | back end | `409 RCA_ACTIONS_NOT_TERMINAL` | inline error listing actions | | Reopen by original closure authority | back end | `403 RCA_SOD_VIOLATION_REOPEN_COSIGNER_CANNOT_BE_CLOSURE_AUTHORITY` | inline error | | Apply inactive methodology | back end | `400 METHODOLOGY_NOT_ACCESSIBLE` | inline error | | GenAI invocation in conclusion / approval / closure path | back end runtime block | `403 RCA_GENAI_PROHIBITED` | inline error | --- ## 12. Security and Observability ### 12.1 Security envelope Tenant isolation via TDAL.withTenant per QS-5; RLS on every RCA-scoped table per QS-6; permission checks per QS-7; structured error handling per QS-9; e-signature via URS-04 Controlled Approval Modal; MFA step-up for executive authority co-sign and reopen. ### 12.2 Observability | Signal | Threshold | Action | |---|---|---| | RCA approval rate per investigator (high outliers) | > 95th percentile | Quality review | | RCA reopen rate per RCA | > 1 reopen per RCA | Quality oversight surface | | Time from RCA creation to conclusion (SLA) | > 30 days | Notification to QA Lead | | `RCA_SOD_VIOLATION_*` events | any single event | high; SOC chat | | `RCA_GENAI_PROHIBITED` events | any single event | high; SOC chat (potential misconfiguration) | | `PLATFORM_TENANT_ACCESS_USED` events | any single event | medium; SOC e-mail | ### 12.3 Reports | Report | Purpose | Owner | |---|---|---| | Open RCA register | Active RCAs by lifecycle state and priority | QA | | RCA-action open list | Open RCA actions across RCAs | QA | | Approved RCAs awaiting closure | Approved RCAs with open actions | QA | | Reopen audit register | Reopened RCAs with executive authority attribution | QA, executive authority | | Cross-tenant indices (platform-admin support / break-glass only) | Aggregate Module 17 events | `platform_admin` (support / break-glass only with reason, support-ticket reference, electronic signature, `PLATFORM_TENANT_ACCESS_USED` audit emit, SOC alert) | Exports: - RCA evidence pack (zipped: full RCA + contributing factors + methodology instances + actions + conclusion + lifecycle events + URS-06 audit excerpt with hash-chain). --- ## 13. Data integrity (ALCOA+) | Principle | How met | |---|---| | Attributable | Every RCA mutation carries `created_by` / `updated_by` / `signed_by` per QS-2 | | Legible | UI surfaces the RCA detail with lifecycle history and audit trail | | Contemporaneous | Server-generated timestamps per QS-3 | | Original | Tombstone-preserved deletion for contributing factors / methodology steps; post-approval / post-closure immutability for RCA header / actions / methodology instances per DEC-17-15 | | Accurate | App-level source-record validation; SoD enforcement at every approval / closure / reopen; Controlled Approval Modal e-signature | | Complete | All RCA mutations audited; conclusion event fans out to URS-18 CAPA | | Consistent | URS-06 chain integrity; cross-tenant cascade preserved | | Enduring | Long-term retention; chain sealing at tenant offboarding per URS-08 | | Available | RCA register surface; auditor read access per URS-22 | --- ## 14. Regulatory Mapping ### 14.1 Predicate-rule applicability matrix | Regulatory authority | Predicate | Module 17 obligation | |---|---|---| | FDA | 21 CFR Part 11 §11.10(a) — System validation | Module 17 must be validated per QS-15, QS-16; URS-17-VAL-* gates | | FDA | 21 CFR Part 11 §11.10(d) — Limit access to authorised individuals | Three-guard RBAC + Authority Profile | | FDA | 21 CFR Part 11 §11.10(e) — Audit trail | URS-06 hash-chained audit substrate, append-only | | FDA | 21 CFR Part 11 §11.50/§11.70/§11.100/§11.200/§11.300 | Controlled Approval Modal contract | | FDA | 21 CFR Part 211 §211.192 (Production record review for unexplained discrepancies) | RCA workflow | | FDA | 21 CFR §312.62 (Investigator records — clinical) | Clinical RCA taxonomy | | EMA | EU GMP Annex 11 §4 / §9 / §12 / §16 | Module 17 validation, audit, security, incident handling | | EMA / PIC/S | EU GMP Chapter 1 §1.4 (Pharmaceutical Quality System) | RCA element of PQS | | MHRA | MHRA Data Integrity Guidance (2018) — ALCOA+ | §13 mapping | | Health Canada | C.02.020 — GMP records | RCA register and retention | | ICH | ICH Q9 — Quality Risk Management | Risk-based investigation | | ICH | ICH Q10 — Pharmaceutical QMS §3.2.4 | RCA element | | ICH | ICH E6(R3) — GCP | Clinical RCA taxonomy | | OECD | OECD GLP | GLP RCA taxonomy | | GAMP | GAMP 5 Cat 5 — Custom application | Validation per §17 | | FDA | FDA CSA Final Guidance (Sep 2025) | Risk-based testing | | WHO | TRS 996 Annex 5 — Good data management | ALCOA+ implementation | | Internal architectural control (forward-looking; not enacted predicate rule) | EU GMP Annex 22 (Draft 2025) | Internal forward-looking AI governance evidence (Annex 22 platform reference) | | Internal architectural control (forward-looking; not enacted predicate rule) | EU AI Act Regulation 2024/1689 Annex III (high-risk classification approach) | Internal high-risk AI governance aligned with the Annex III approach (jurisdiction-specific legal enforceability subject to future legal assessment) | | Internal architectural control (forward-looking; not enacted predicate rule) | EU AI Act Art. 13 — Transparency principles | Visible advisory labelling (jurisdiction-specific legal enforceability subject to future legal assessment) | | India CDSCO (per applicable scope) | India Drugs and Cosmetics Act 1940 + Drugs Rules 1945 + Revised Schedule M (RCA / investigation handling within GMP) + Schedule M-III (where distribution-investigation scope) + New Drugs and Clinical Trials Rules 2019 (where clinical-protocol RCA is in scope) + CDSCO GCP guidance (where clinical / study RCA scope) + Medical Devices Rules 2017 (where device / combination-product RCA scope) — Applicable per India tenant operation and jurisdictional regulatory assessment | RCA register, methodology application, conclusion with reviewer-independent approval, closure with executive authority co-sign for critical, reopen audit chain; external jurisdictional legal / RA confirmation required for clause / form applicability per India RCA scope | --- ## 15. URS Requirements Register ### 15.1 Front-end (FE) | ID | Requirement | Priority | |---|---|---| | URS-17-FE-001 | Module 17 landing route at `/rcas` | MUST | | URS-17-FE-002 | RCA register table with filters by `lifecycle_state`, `practice`, `priority`, scope dimensions | MUST | | URS-17-FE-003 | RCA detail tabbed view (overview, contributing factors, methodology instances, actions, conclusion, lifecycle history, audit) | MUST | | URS-17-FE-004 | Create-RCA wizard with source linkage selection | MUST | | URS-17-FE-005 | Contributing-factor editor with evidence reference picker | MUST | | URS-17-FE-006 | Methodology apply dialog with accessibility verification surface | MUST | | URS-17-FE-007 | 5-Why ladder editor | MUST | | URS-17-FE-008 | Fishbone diagram editor (with non-visual fallback per URS-29 if applicable) | MUST | | URS-17-FE-009 | Fault Tree editor with probability calculation surface | MUST | | URS-17-FE-010 | RCA action planner | MUST | | URS-17-FE-011 | Conclusion capture panel | MUST | | URS-17-FE-012 | Approval modal (Controlled Approval Modal — URS-04) with SoD-17-01 enforcement surface | MUST | | URS-17-FE-013 | Critical-RCA approval matrix | MUST | | URS-17-FE-014 | Closure modal with prerequisite check | MUST | | URS-17-FE-015 | Executive authority reopen modal (executive only) | MUST | | URS-17-FE-016 | RCA audit trail view consumed from URS-06 | MUST | | URS-17-FE-017 | AI advisory similarity panel (visibly labelled per ARCH-AI-001 AC-3) | MUST | | URS-17-FE-018 | Annex 22 GenAI prohibition surface (no AI offered in conclusion / approval / closure UI) | MUST (negative requirement) | | URS-17-FE-019 | All Module 17 surfaces meet WCAG 2.1 Level AA | MUST | ### 15.2 Back-end (BE) | ID | Requirement | Priority | |---|---|---| | URS-17-BE-001 | RCA service `createRCA(...)` validates source linkage and scope anchor | MUST | | URS-17-BE-002 | Cross-tenant source linkage forbidden | MUST | | URS-17-BE-003 | Investigation lead assignment enforces SoD-17-02 | MUST | | URS-17-BE-004 | Contributing-factor add / tombstone-preserved removal | MUST | | URS-17-BE-005 | Methodology accessibility verification before instance creation | MUST | | URS-17-BE-006 | 5-Why / Fishbone / Fault Tree step add / edit / delete (with SoD-17-05) | MUST | | URS-17-BE-007 | Fault Tree probability calculation deterministic (no AI) | MUST | | URS-17-BE-008 | RCA action add / update / list | MUST | | URS-17-BE-009 | Conclusion creation transitions RCA to `completed`; emits `rca_conclusion_created` event | MUST | | URS-17-BE-010 | Approval enforces SoD-17-01 + Controlled Approval Modal e-signature | MUST | | URS-17-BE-011 | Critical-RCA approval matrix per DEC-17-21 with SoD-17-07 | MUST | | URS-17-BE-012 | Closure enforces SoD-17-04 + 4-prerequisite check | MUST | | URS-17-BE-013 | Post-approval / post-closure immutability via `assertRCAMutable(...)` on every mutation route across `rca` and `rca-methodology` services | MUST | | URS-17-BE-014 | Reopen as governed transition `closed → in_progress` per DEC-17-22 + SoD-17-06; appends new lifecycle event + new investigation iteration | MUST | | URS-17-BE-015 | Audit-log writes atomic with originating action per URS-04 BR-04-15 | MUST | | URS-17-BE-016 | Reason-for-change captured for every RCA UPDATE | MUST | | URS-17-BE-017 | Multi-dimensional context persistence: `study_id`, `site_id`, `product_id`, `supplier_id`, `batch_id` per registry schema | MUST | ### 15.3 Data (DATA) | ID | Requirement | Priority | |---|---|---| | URS-17-DATA-001 | `rcas` per DEC-17-01 with required source linkage and scope anchor enforcement | MUST | | URS-17-DATA-002 | `rca_contributing_factors` with evidence reference array and tombstone-preserved deletion | MUST | | URS-17-DATA-003 | `rca_methodologies` tenant catalogue with default categories | MUST | | URS-17-DATA-004 | `rca_methodology_instances` with methodology-accessibility verification | MUST | | URS-17-DATA-005 | `rca_methodology_steps` with `step_type` (`why_step` / `fishbone_cause` / `fault_tree_node`) | MUST | | URS-17-DATA-006 | `rca_actions` with status lifecycle (`open` / `in_progress` / `completed` / `cancelled`) | MUST | | URS-17-DATA-007 | `rca_conclusions` with root-cause statement, contributing-factor summary, evidence basis, recommended-CAPA summary | MUST | | URS-17-DATA-008 | `rca_lifecycle_events` append-only with hash chain | MUST | | URS-17-DATA-009 | `rca_approvals` per-slot signature table for critical-RCA approval matrix | MUST | | URS-17-DATA-010 | RLS on every RCA-scoped table per QS-6 | MUST | ### 15.4 AI / HITL (AI) | ID | Requirement | Priority | |---|---|---| | URS-17-AI-001 | NO LLM / GenAI in RCA conclusion / approval / closure decision paths per the internal Annex 22 control | MUST (negative) | | URS-17-AI-002 | Static deterministic AI MAY surface similar prior RCAs (advisory only) per ARCH-AI-001 AC-2 | MUST | | URS-17-AI-003 | Advisory output visibly labelled per ARCH-AI-001 AC-3 | MUST | | URS-17-AI-004 | Advisory output never autonomously writes to RCA tables per ARCH-AI-001 AC-4 | MUST | | URS-17-AI-005 | AI service errors degrade gracefully per ARCH-AI-001 AC-7 | MUST | | URS-17-AI-006 | MIRA copilot read-only mapping `rca → rcas` for closed RCAs (per URS-32); no MIRA write path | MUST | | URS-17-AI-007 | Internal forward-looking AI governance evidence (EU AI Act Art. 13 transparency principles) | MUST | | URS-17-AI-008 | Internal forward-looking AI governance evidence (EU AI Act Annex III high-risk classification approach) | MUST | ### 15.5 Audit (AUD) | ID | Requirement | Priority | |---|---|---| | URS-17-AUD-001 | Every Module 17 mutation produces an audit row through URS-06 | MUST | | URS-17-AUD-002 | Audit-write failure rolls back originating action | MUST | | URS-17-AUD-003 | Source linkage / contributing factor / methodology / action / conclusion / approval / closure / reopen / void all audited | MUST | ### 15.6 Validation (VAL) | ID | Requirement | Status | |---|---|---| | URS-17-VAL-001 | Installation Qualification | Pending | | URS-17-VAL-002 | Operational Qualification | Pending | | URS-17-VAL-003 | Performance Qualification | Pending | | URS-17-VAL-004 | RLS enforcement evidence | Pending | | URS-17-VAL-005 | URS-06 chain integrity evidence | Pending | | URS-17-VAL-006 | SoD enforcement evidence (SoD-17-01..07) | Pending | | URS-17-VAL-007 | Post-approval / post-closure immutability evidence (DEC-17-15) | Pending | | URS-17-VAL-008 | Migration evidence: `assertRCAMutable(...)` extension to methodology mutators (5-Why, Fishbone, Fault Tree) verified with regression test pack | Pending | | URS-17-VAL-009 | Internal forward-looking AI governance evidence (EU GMP Annex 22 Draft 2025 GenAI prohibition control) | Pending | | URS-17-VAL-010 | ARCH-AI-001 AC-2/3/4/7 advisory AI evidence pack | Pending | | URS-17-VAL-011 | Internal forward-looking AI governance evidence (EU AI Act Annex III high-risk classification approach) | Pending | | URS-17-VAL-012 | Internal forward-looking AI governance evidence (EU AI Act Art. 13 transparency principles) | Pending | | URS-17-VAL-013 | Critical-RCA executive authority co-sign procedural evidence per DEC-17-21 | Pending | | URS-17-VAL-014 | Reopen executive authority co-sign procedural evidence per DEC-17-22 + SoD-17-06 | Pending | | URS-17-VAL-015 | Methodology accessibility verification evidence (DEC-17-07) | Pending | | URS-17-VAL-016 | Fault Tree probability calculation determinism evidence | Pending | | URS-17-VAL-017 | Source-record validation evidence (DEC-17-04) | Pending | | URS-17-VAL-018 | Multi-dimensional context persistence evidence (DEC-17-17) | Pending | | URS-17-VAL-019 | Tombstone-preserved deletion evidence (contributing factors + methodology steps) | Pending | ### 15.7 Integration (INT) | ID | Requirement | Priority | |---|---|---| | URS-17-INT-001 | URS-14 Complaints inbound source linkage | MUST | | URS-17-INT-002 | URS-15 OOS / OOT inbound source linkage | MUST | | URS-17-INT-003 | URS-16 Deviations inbound source linkage | MUST | | URS-17-INT-004 | URS-21 Findings inbound source linkage | MUST | | URS-17-INT-005 | URS-13 Change Control linkage where RCA precipitates a regulated change | MUST | | URS-17-INT-006 | URS-18 CAPA outbound `rca_conclusion_created` event consumer | MUST | | URS-17-INT-007 | URS-22 Inspection Mgmt outbound (RCA register accessible to inspection-readiness export) | MUST | | URS-17-INT-008 | URS-26 APQR outbound | MUST | | URS-17-INT-009 | URS-30 Notifications outbound | MUST | | URS-17-INT-010 | URS-32 MIRA AI inbound (read-only mapping `rca → rcas` for closed RCAs) | MUST | | URS-17-INT-011 | URS-06 audit substrate inbound | MUST | | URS-17-INT-012 | URS-04 Controlled Approval Modal contract | MUST | | URS-17-INT-013 | URS-05 Authority Profile registry consumer | MUST | | URS-17-INT-014 | Internal forward-looking AI governance evidence (EU GMP Annex 22 Draft 2025) | MUST | | URS-17-INT-015 | Internal forward-looking AI governance evidence (EU AI Act Annex III high-risk classification approach) | MUST | ### 15.8 Reports (REP) | ID | Requirement | Priority | |---|---|---| | URS-17-REP-001 | Open RCA register | MUST | | URS-17-REP-002 | RCA-action open list | MUST | | URS-17-REP-003 | Approved RCAs awaiting closure | MUST | | URS-17-REP-004 | Reopen audit register with executive authority attribution | MUST | | URS-17-REP-005 | RCA evidence pack export | MUST | ### 15.9 Workflow (WF) | ID | Requirement | Priority | |---|---|---| | URS-17-WF-001 | RCA lifecycle state machine per DEC-17-02 | MUST | | URS-17-WF-002 | Investigation lead assignment per SoD-17-02 | MUST | | URS-17-WF-003 | Methodology application with accessibility verification per DEC-17-07 | MUST | | URS-17-WF-004 | Conclusion creation transitions RCA to `completed`; emits `rca_conclusion_created` | MUST | | URS-17-WF-005 | Approval per DEC-17-13 + SoD-17-01 | MUST | | URS-17-WF-006 | Critical-RCA approval matrix per DEC-17-21 + SoD-17-07 | MUST | | URS-17-WF-007 | Closure per DEC-17-16 + SoD-17-04 | MUST | | URS-17-WF-008 | Reopen as governed transition per DEC-17-22 + SoD-17-06 | MUST | ### 15.10 Functional acceptance (FUN) | ID | Requirement | Priority | |---|---|---| | URS-17-FUN-001 | RCA create with source linkage validation | MUST | | URS-17-FUN-002 | RCA approve with SoD-17-01 enforcement | MUST | | URS-17-FUN-003 | RCA close with 4-prerequisite check | MUST | | URS-17-FUN-004 | RCA reopen by executive authority with SoD-17-06 | MUST | | URS-17-FUN-005 | Post-closure mutation blocked per DEC-17-15 | MUST | --- ## 16. Test cases and Acceptance criteria ### 16.1 Test cases (TC) | ID | Test | |---|---| | TC-17-01 | RCA happy path from deviation source → investigation lead assign → contributing factors → 5-Why → conclusion → QA approval → closure | | TC-17-02 | RCA from finding source happy path | | TC-17-03 | RCA from OOS investigation source happy path | | TC-17-04 | RCA from complaint source happy path | | TC-17-05 | RCA create with non-existent source returns `400 SOURCE_RECORD_NOT_FOUND` | | TC-17-06 | RCA create cross-tenant source returns `400 CROSS_TENANT_SOURCE_LINKAGE_FORBIDDEN` | | TC-17-07 | RCA create without scope anchor returns `400 SCOPE_ANCHOR_REQUIRED` | | TC-17-08 | Discoverer attempts to be investigation lead returns `403 RCA_SOD_VIOLATION_DISCOVERER_CANNOT_BE_INVESTIGATION_LEAD` | | TC-17-09 | Creator attempts to approve own RCA returns `403 RCA_SOD_VIOLATION_CREATOR_CANNOT_APPROVE` | | TC-17-10 | Critical-RCA approval requires `final_quality_approver` + practice lead + executive authority co-sign per DEC-17-21 | | TC-17-11 | Mutation on closed RCA returns `403 RCA_IMMUTABLE_FINAL_STATE` | | TC-17-12 | Reopen by original closure authority returns `403 RCA_SOD_VIOLATION_REOPEN_COSIGNER_CANNOT_BE_CLOSURE_AUTHORITY` | | TC-17-13 | Reopen by executive authority transitions `closed → in_progress`; appends new lifecycle event; preserves prior closed evidence | | TC-17-14 | 5-Why ladder add / edit / delete with tombstone preservation; SoD-17-05 enforced on delete | | TC-17-15 | Fishbone causes add per category | | TC-17-16 | Fault Tree node add with probability calculation determinism | | TC-17-17 | Methodology apply with inactive methodology returns `400 METHODOLOGY_NOT_ACCESSIBLE` | | TC-17-18 | Contributing factor remove preserves tombstone | | TC-17-19 | Conclusion create transitions RCA to `completed` and emits `rca_conclusion_created` event | | TC-17-20 | Closure with open RCA actions returns `409 RCA_ACTIONS_NOT_TERMINAL` | | TC-17-21 | Closure without conclusion returns `409 RCA_CONCLUSION_MISSING` | | TC-17-22 | Internal Annex 22 negative test: any GenAI invocation in conclusion / approval / closure path blocked at runtime + lint | | TC-17-23 | Static deterministic AI similarity surface advisory only; no autonomous write; visibly labelled | | TC-17-24 | MIRA copilot read-only context mapping `rca → rcas` for closed RCAs; MIRA write paths blocked | | TC-17-25 | Multi-dimensional context: `study_id`, `site_id`, `product_id`, `supplier_id`, `batch_id` persisted per registry schema | | TC-17-26 | Race-condition test on `rca_number` generation under concurrent creates per DEC-17-03 | | TC-17-27 | Audit-write failure rolls back originating action | | TC-17-28 | Platform identity outside support envelope returns `403 PLATFORM_TENANT_ACCESS_DENIED`; SOC alert fires | ### 16.2 Acceptance criteria (AC) | ID | Acceptance criterion | |---|---| | AC-17-01 | Every RCA carries at least one source linkage and at least one scope anchor. | | AC-17-02 | SoD-17-01 enforced: RCA approver ≠ creator. | | AC-17-03 | SoD-17-02 enforced: investigation lead ≠ discoverer. | | AC-17-04 | SoD-17-04 enforced: closure authority ≠ creator. | | AC-17-05 | SoD-17-06 enforced: executive reopen co-signer ≠ original closure authority. | | AC-17-06 | Critical-RCA approval matrix per DEC-17-21 enforced; SoD-17-07 enforced. | | AC-17-07 | Post-approval / post-closure immutability per DEC-17-15 enforced via `assertRCAMutable(...)` on every mutation route across `rca` and `rca-methodology` services. | | AC-17-08 | Reopen is governed transition per DEC-17-22; appends new investigation iteration without mutating prior closed evidence. | | AC-17-09 | Methodology accessibility verified before instance creation. | | AC-17-10 | Fault Tree probability calculation deterministic (no AI). | | AC-17-11 | Internal Annex 22 GenAI prohibition enforced runtime + lint per DEC-17-18. | | AC-17-12 | Internal forward-looking AI governance evidence (EU AI Act Annex III high-risk classification approach) maintained. | | AC-17-13 | Internal forward-looking AI governance evidence (EU AI Act Art. 13 transparency principles) maintained for all AI surfaces. | | AC-17-14 | URS-06 hash-chain integrity preserved on every RCA mutation. | | AC-17-15 | RCA evidence pack export includes full RCA + contributing factors + methodology instances + actions + conclusion + lifecycle events + URS-06 audit excerpt with hash-chain. | --- ## 17. Validation evidence pack ### 17.1 Validation gate URS-17-VAL-008 (Migration Evidence Gate) MUST be satisfied before "Released for validation execution": - Schema migration applied with `IF NOT EXISTS` / `IF EXISTS` guards per QS-13. - Cross-layer status alignment applied (shared types, shared schemas, service all aligned to DEC-17-02 canonical state set). - `assertRCAMutable(...)` extended to methodology mutators (5-Why steps, Fishbone causes, Fault Tree nodes). - Source-record validation applied at service layer for `deviation_id`, `finding_id`, `oos_investigation_id`, `complaint_id` per DEC-17-04. - Multi-dimensional context persistence aligned: `study_id`, `site_id`, `product_id`, `supplier_id`, `batch_id` persisted per registry schema. - Approval gate `withAuthority(...)` + Controlled Approval Modal e-signature wired per DEC-17-13. - Closure gate 4-prerequisite check wired per DEC-17-16. - Reopen route mounted with executive authority + SoD-17-06 + reason per DEC-17-22. ### 17.2 Validation evidence index - IQ pack (installation qualification). - OQ pack (operational qualification per RCA happy path + negative paths). - PQ pack (performance qualification per §9 thresholds). - RLS evidence per QS-6. - URS-06 chain integrity evidence per DEC-17-19. - SoD enforcement evidence (SoD-17-01..07). - Post-approval / post-closure immutability evidence. - Critical-RCA executive authority co-sign procedural evidence. - Reopen executive authority co-sign procedural evidence. - Methodology accessibility verification evidence. - Fault Tree probability calculation determinism evidence. - Source-record validation evidence. - Multi-dimensional context persistence evidence. - Tombstone-preserved deletion evidence. - Internal forward-looking AI governance evidence (EU GMP Annex 22 Draft 2025 GenAI prohibition control). - Internal forward-looking AI governance evidence (EU AI Act Annex III high-risk classification approach). - Internal forward-looking AI governance evidence (EU AI Act Art. 13 transparency principles). - ARCH-AI-001 AC-2/3/4/7 advisory AI evidence pack. --- ## 18. Cross-module dependencies and integration points ### 18.1 Closed Decision Register (Module 17 inputs) | ID | Decision | |---|---| | DEC-17-01..22 | All Module 17 closed launch decisions per §2.3. | ### 18.2 Cross-module dependencies | Linked module | Direction | Source | |---|---|---| | URS-01 Authentication | Inbound | URS-01 module URS | | URS-02 RBAC | Inbound | URS-02 module URS | | URS-03 Context Gate | Inbound | URS-03 module URS | | URS-04 Workflow / HITL / E-Sign | Inbound | URS-04 module URS | | URS-05 Authority Profile | Inbound | URS-05 module URS | | URS-06 Audit Trail | Inbound | URS-06 module URS | | URS-07 Study Management | Inbound (study scope) | URS-07 module URS | | URS-08 Tenant Management | Inbound (tenant context) | URS-08 module URS | | URS-09 Site / Facility | Inbound (site scope) | URS-09 module URS | | URS-10 Product / SKU | Inbound (product scope) | URS-10 module URS | | URS-11 Supplier Management | Inbound (supplier scope) | URS-11 module URS | | URS-12 Document Control | Inbound (evidence references) | URS-12 module URS | | URS-13 Change Control | Bidirectional (precipitating change) | URS-13 module URS | | URS-14 Complaints | Inbound (source linkage) | URS-14 module URS | | URS-15 OOS / OOT | Inbound (source linkage) | URS-15 module URS | | URS-16 Deviations | Inbound (source linkage) | URS-16 module URS | | URS-18 CAPA | Outbound (`rca_conclusion_created` event) | URS-18 module URS | | URS-21 Findings | Inbound (source linkage) | URS-21 module URS | | URS-22 Inspection Mgmt | Outbound | URS-22 module URS | | URS-23 Batch Records | Inbound (batch scope) | URS-23 module URS | | URS-26 APQR | Outbound | URS-26 module URS | | URS-30 Notifications | Outbound | URS-30 module URS | | URS-32 MIRA AI | Outbound (read-only mapping `rca → rcas`) | URS-32 module URS | | EU GMP Annex 22 (Draft 2025) | Internal forward-looking architectural reference (not enacted predicate rule) | Internal forward-looking AI governance evidence (Annex 22 platform reference) | | ARCH-AI-001 AI Optionality and Manual Continuity | Architectural binding | ARCH-AI-001 platform binding | | EU AI Act Annex III (high-risk classification approach) | Internal forward-looking architectural reference (not enacted predicate rule) | EU AI Act | --- ## 19. Completeness Checklist | Item | Met | |---|---| | Header + mapping + Code Modules Mapped + Architecture Bindings (ARCH-AI-001 + Annex 22 + Annex III high-risk) | ✓ | | Glossary, primer, worked examples, regulatory anchors | ✓ | | Audience and stakeholders | ✓ | | Roles + Authority Profile catalogue + SoD constraints | ✓ | | Role-permission matrix (Module 17 administrative surface only) | ✓ | | End-to-end user journeys (28) | ✓ | | Front-end UI per §5 | ✓ | | Back-end per §6 (architecture, data model, APIs, workflow, business rules, audit, AI architecture binding) | ✓ | | Annex 22 + ARCH-AI-001 + Annex III high-risk architecture reference section | ✓ | | Cross-module wiring + Change-Impact Matrix per §7 | ✓ | | AI / Automation / HITL controls (with internal Annex 22 prohibition) | ✓ | | Performance / scalability per §9 | ✓ | | Localisation / i18n per §10 | ✓ | | Errors + negative-path catalogue per §11 | ✓ | | Security + Observability per §12 | ✓ | | Data integrity (ALCOA+) per §13 | ✓ | | Regulatory mapping per §14 | ✓ | | URS requirements register per §15 (FE / BE / DATA / AI / AUD / VAL / INT / REP / WF / FUN) | ✓ | | Test cases + acceptance criteria per §16 | ✓ | | Validation evidence pack per §17 | ✓ | | Cross-module dependencies per §18 | ✓ | | Decisions and dependencies registered (no internal decisions outstanding)? | Yes | §18.1, §18.2 | --- ## 20. Final Module Output Quality Gate **URS approval is separate from validation execution.** This document becomes "Approved Controlled URS — released for engineering implementation and validation planning" upon signature capture in the Document Approval block; it becomes "Released for validation execution" only after URS-17-VAL-008 (Migration Evidence Gate) and the §17 validation evidence pack are satisfied. **No Module 17 internal decisions outstanding.** - **Specification ready for engineering review?** Yes — every requirement is fully specified within this URS. - **Specification ready for quality validation review?** Yes — IQ/OQ/PQ + RLS + audit chain + Annex 22 GenAI-prohibition evidence + ARCH-AI-001 AC-2/3/4/7 advisory AI evidence + EU AI Act Art. 13 transparency + SoD enforcement + post-approval / post-closure immutability + critical-RCA executive co-sign + reopen executive co-sign + methodology accessibility verification + Fault Tree probability determinism + source-record validation + multi-dimensional context persistence + tombstone-preserved deletion evidence are itemised in §17. - **Specification ready for compliance review?** Yes — ALCOA+, 21 CFR Part 11, 21 CFR §211.192, 21 CFR §312.62, EU GMP Annex 11 §4/9/12/16, EU GMP Chapter 1 §1.4, MHRA ALCOA+, ICH Q9 / Q10 / E6(R3), OECD GLP, GAMP 5 Cat 5, FDA CSA, WHO TRS 996 Annex 5 — all mapped in §14. EU GMP Annex 22 (Draft 2025) and EU AI Act Regulation 2024/1689 (Annex III high-risk classification approach + Art. 13 transparency principles) are treated as internal forward-looking architectural controls; jurisdiction-specific legal enforceability remains subject to a future jurisdiction-specific legal assessment. - **Specification ready for inspector / client review?** Yes — 28 journeys (§4), full requirements register (§15), evidence pack index (§17.2). - **Specification ready for Founder approval?** Yes. - **Blocking gaps?** None internal. - **Two-step release path:** 1. **Approved Controlled URS — released for engineering implementation and validation planning.** 2. **Released for validation execution.** After URS-17-VAL-008 + §17 evidence complete. --- ## Appendix A — Module 17 End-to-End Composite (Discover → Investigate → Methodology → Conclude → Approve → Close → Immutable / Reopen) ```mermaid flowchart TD A[Source: Deviation/Finding/OOS/Complaint] --> B[Create RCA - draft] B --> C[Assign Investigation Lead - SoD-17-02 - in_progress] C --> D[Add Contributing Factors with Evidence] D --> E[Apply Methodology - 5-Why, Fishbone, Fault Tree] E --> F[Add Methodology Steps] F --> G[Add Interim-Control Actions] G --> H[Capture Conclusion - completed - emits rca_conclusion_created] H --> I[QA Reviewer Approval - SoD-17-01 - approved] I --> J{Critical RCA?} J -- yes --> K[Practice Lead Co-Sign + Executive Authority Co-Sign per DEC-17-21 + SoD-17-07] J -- no --> L[Standard Approval Path] K --> M[All Actions Terminal? Conclusion Present? Closure Rationale Captured?] L --> M M -- yes --> N[Closure Authority Sign - SoD-17-04 - closed] M -- no --> O[Closure Blocked] N --> P[Immutable Parent + Children per DEC-17-15] P -. Reopen Path .-> Q[Executive Authority Reopen - DEC-17-22 + SoD-17-06] Q --> R[closed -> in_progress; new investigation iteration appended; prior closed evidence preserved] R --> C E -. Internal Annex 22 control .-> S[NO GenAI in conclusion / approval / closure paths per DEC-17-18] ``` Diagram Appendix A — Module 17 End-to-End Composite. Discover → submit → investigation with cross-module linkage → methodology application → conclusion → approval matrix per DEC-17-13 (standard / critical with executive authority co-sign per DEC-17-21 + SoD-17-07) → closure per DEC-17-16 + SoD-17-04 → immutable parent + children per DEC-17-15 → executive-authority-cosigned reopen path per DEC-17-22 + SoD-17-06; conclusion creation emits `rca_conclusion_created` to URS-18 CAPA. Verixa treats EU GMP Annex 22 Draft 2025 and EU AI Act high-risk / transparency concepts as internal forward-looking AI governance controls unless a jurisdiction-specific legal assessment determines otherwise; under the internal control, generative AI is prohibited in conclusion / approval / closure decision paths and the module is internally classified high-risk AI. ARCH-AI-001 governs advisory deterministic AI in similarity / signal surfacing. Binding predicate-rule obligations remain those listed in §14. — End of Module 17 User Requirements Specification —