# Verixa — User Requirements Specification

# Module 18: CAPA (Corrective and Preventive Action)

| Field | Value |
|---|---|
| Document ID | VRX-URS-18 |
| 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-18-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 `capas`, expected API mount `/api/v1/capas/*`, expected CAPA-specific HITL decision orchestration through the `hitl` subsystem, expected CAPA-bound e-signature persistence through the `authority` and `audit-log` subsystems, expected dashboard metric publication through the `dashboard` subsystem. 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 CAPA surfaces (AI priority suggestion, AI action recommendation, AI effectiveness-check prediction, MIRA copilot, root-cause-to-action mapping assistant) 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 prioritisation, action-planning, and effectiveness-verification path; CAPA creation, action assignment, execution, verification, and closure shall be executable when AI services are disabled, degraded, or overridden by the CAPA owner or quality lead. **No AI service shall be the sole path to prioritise, dispose, or close a CAPA.** 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 CAPA prioritisation disposition, effectiveness-check outcome decisions, closure-disposition decisions, and reopen decisions. Static deterministic AI may surface similar prior CAPAs and historical effectiveness patterns; the human approver's signed disposition 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 CAPA register, the CAPA lifecycle state machine (`draft → open → assigned → in_progress → completed → effectiveness_check → verified → closed`; reopen is a governed transition event from `closed → in_progress` per DEC-18-22 + SoD-18-06 that appends a new CAPA iteration and does not mutate or erase the prior closed evidence), the source-linkage controls (deviation per URS-16, RCA conclusion per URS-17, complaint per URS-14, OOS investigation per URS-15, finding per URS-21, audit observation per URS-22, change-control precipitating per URS-13, supplier non-conformance per URS-11) with app-level existence validation, the multi-dimensional context capture (`study_id`, `site_id`, `product_id`, `supplier_id`, `batch_id`), the CAPA action-item lifecycle with controlled execution + closure evidence, the CAPA effectiveness-check lifecycle with scheduled checks, completion outcome capture, and effectiveness adjudication, the CAPA cascade-item lifecycle with downstream change-control / training / document-control linkage, the CAPA-specific HITL decision orchestration for non-bypassable approval, the CAPA-bound e-signature persistence on closure, the post-approval / post-closure record immutability across the CAPA header, action items, effectiveness checks, and cascade items, the controlled reopen workflow with executive authority co-sign, the dashboard metrics publication, and the per-jurisdictional regulatory expectations under FDA 21 CFR Part 11, 21 CFR §211.192 (Production record review for unexplained discrepancies), 21 CFR §820.100 (Corrective and Preventive Action — medical devices), 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) | Quality / Investigation Squad |
| Module Owner (Quality Validation) | CSV / CSA Lead — CAPA |
| 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 CAPA module (Module 18). 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 CAPA substrate: the canonical CAPA register; the lifecycle state machine (`draft → open → assigned → in_progress → completed → effectiveness_check → verified → closed` with reopen as a governed transition event from `closed → in_progress` per executive authority co-sign + reason — DEC-18-22 + SoD-18-06 — that appends a new CAPA iteration without mutating or erasing the prior closed evidence); the source-linkage controls (deviation per URS-16, RCA conclusion per URS-17, complaint per URS-14, OOS investigation per URS-15, finding per URS-21, audit observation per URS-22, change-control precipitating per URS-13, supplier non-conformance per URS-11) with app-level existence validation extended across all declared source types; the multi-dimensional context model (`study_id`, `site_id`, `product_id`, `supplier_id`, `batch_id`) with at least one scope anchor required and aligned with the platform context filter; the CAPA action-item lifecycle (`open` / `in_progress` / `completed` / `cancelled`) with assignment, due-date tracking, closure-evidence capture, and reviewer-signed completion; the CAPA effectiveness-check lifecycle (scheduled, executed, outcome captured, adjudicated as `effective` / `partial` / `ineffective`) with completion and outcome update routes; the CAPA cascade-item lifecycle with downstream change-control / training / document-control / supplier linkage; the CAPA-specific HITL decision orchestration through the platform `hitl` subsystem with non-bypassable approval; the CAPA-bound e-signature persistence on final approval and closure; the post-approval / post-closure record immutability across the CAPA header, action items, effectiveness checks, and cascade items; the controlled reopen workflow with executive authority co-sign; the canonical status-model alignment across backend workflow, shared domain types, and frontend hooks; 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 CAPA prioritisation disposition, effectiveness-check outcome decisions, closure-disposition decisions, and reopen decisions; the dashboard metrics publication with closure-time formula computed as `closed_at - assigned_at`; 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 18 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 CAPA mutation
- **URS-02** RBAC & Permissions — the `capas:*` permission set
- **URS-03** Context Gate & Approval Scope — context-gate enforcement for CAPA scope dimensions
- **URS-04** Workflow / HITL / E-Signature / Approval Authority — Controlled Approval Modal contract for CAPA approval, closure, and reopen; CAPA-specific HITL decision orchestration
- **URS-05** Authority Profile / Delegation / SoD — Authority Profiles consumed (`capa_owner_authority`, `final_quality_approver`, `effectiveness_check_authority`, `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 CAPA 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; supplier non-conformance source linkage
- **URS-12** Document Control / SOP — affected-document linkage; closure-evidence document references
- **URS-13** Change Control — precipitating-change source linkage; cascade-item change-control linkage
- **URS-14** Complaints — complaint-source CAPA linkage
- **URS-15** OOS / OOT — OOS-source CAPA linkage
- **URS-16** Deviations — deviation-source CAPA linkage (primary upstream)
- **URS-17** RCA — RCA-conclusion-source CAPA linkage (`rca_conclusion_created` event consumer)
- **URS-21** Findings — finding-source CAPA linkage
- **URS-22** Inspection Mgmt — audit-observation-source CAPA linkage
- **URS-23** Batch Records — batch-scope dimension consumed
- **URS-28** Training — training-cascade-item linkage
- **URS-30** Notifications — notification delivery for CAPA lifecycle events
- **URS-32** MIRA AI — read-only MIRA copilot context for closed CAPAs (no write path)
- **URS-35** Infrastructure / Backup-Restore — operational continuity

### 0.4 Plain-language primer

In a regulated pharmaceutical operation, **CAPA is the regulator's most-inspected workflow after the audit trail and the change-control register**. When a deviation, OOS, complaint, finding, or RCA conclusion identifies that something has gone wrong (the "corrective" leg) or that something will go wrong without intervention (the "preventive" leg), the marketing authorisation holder is obligated by **21 CFR Part 211, 21 CFR §820.100 (medical devices), EU GMP Chapter 1 §1.4, ICH Q9, ICH Q10 §3.2.4, MHRA Data Integrity Guidance (2018), and PIC/S PE 009** to (1) open a controlled CAPA record, (2) plan the corrective and preventive actions with named owners and due dates, (3) execute the actions with documented evidence, (4) verify effectiveness through scheduled effectiveness checks, (5) capture the effectiveness-check outcome with reviewer-independent adjudication, (6) close the CAPA with bound e-signature only after effectiveness is verified, and (7) cascade the lessons learned to downstream change-control, training, and document-control records. Module 18 is the target specification for this regulated workflow.

The most common mistake in regulated CAPA is **closure without effectiveness verification**: the CAPA owner declares the action "completed" and closes the CAPA before any effectiveness check is run. The regulator's tell-tale at inspection is a CAPA closed within days of opening with no scheduled effectiveness check or with an effectiveness check that was never executed. Module 18 enforces the pathway: closure requires `verified` state (DEC-18-16); `verified` state requires an effectiveness check with outcome `effective` or `partial` (with `partial` requiring documented re-CAPA decision); the closure transition is bound to a captured e-signature on the CAPA record (DEC-18-13 + DEC-18-16). Reopen is a governed transition that appends a new CAPA iteration without erasing the prior closed evidence.

The **AI-assistance** dimension is critical. Static deterministic AI may surface "similar prior CAPAs in the last 12 months" or "historical effectiveness patterns by source type" as advisory help during planning. Generative AI (LLMs / MIRA copilot) is **prohibited** from writing to the CAPA prioritisation disposition, the effectiveness-check outcome, the closure decision, or the reopen decision under the internal Annex 22 Draft 2025 forward-looking AI governance control. MIRA copilot may read closed CAPAs for read-only context but no AI service writes to `capas`, `capa_action_items`, `capa_effectiveness_checks`, or `capa_cascade_items` tables. The signed disposition is the system of record, attributable to the human approver.

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-18-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 |
|---|---|
| CAPA | Corrective and Preventive Action — the controlled record of corrective remediation and preventive intervention triggered by a regulated quality event. |
| Corrective leg | Action targeted at the immediate problem and at preventing recurrence of the same root cause. |
| Preventive leg | Action targeted at preventing occurrence of similar problems where root-cause analysis indicates systemic risk. |
| Action item | A discrete owner-assigned task within the CAPA scope with due date, status, and closure evidence. |
| Effectiveness check | A scheduled verification that the corrective and preventive actions have achieved their intended effect; outcome adjudicated as `effective`, `partial`, or `ineffective`. |
| Effectiveness adjudication | The reviewer-independent decision on the effectiveness-check outcome (SoD-18-03: effectiveness reviewer ≠ CAPA owner). |
| Cascade item | A downstream record (URS-13 change request, URS-28 training assignment, URS-12 document revision, URS-11 supplier requalification) that the CAPA precipitates. |
| Source linkage | The mandatory FK to the precipitating record (deviation per URS-16, RCA per URS-17, complaint per URS-14, OOS per URS-15, finding per URS-21, audit observation per URS-22, change-control per URS-13, supplier non-conformance per URS-11). |
| Scope anchor | At least one of `study_id`, `site_id`, `product_id`, `supplier_id`, `batch_id` MUST be captured on every CAPA record. |
| HITL decision orchestration | The platform Human-in-the-Loop subsystem (URS-04) that creates non-bypassable decision records for CAPA approval and closure with assignment, escalation, and decision capture. |
| Bound e-signature | The e-signature payload captured at closure that is persisted on the CAPA record (`closed_e_sig_id`) and traceable to the URS-04 Controlled Approval Modal contract. |
| Reopen | A governed transition event from `closed → in_progress` requiring executive authority co-sign and documented reason; appends a new CAPA iteration without mutating prior closed evidence. |
| Reviewer independence | The Segregation-of-Duties enforcement that the CAPA approver MUST NOT be the CAPA owner (SoD-18-01) and the effectiveness reviewer MUST NOT be the CAPA owner (SoD-18-03). |
| 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 CAPA prioritisation disposition, effectiveness-check outcome decisions, closure-disposition decisions, and reopen decisions. Binding predicate-rule obligations remain those listed in §14. |
| MIRA | The platform's read-only AI copilot service; for Module 18 MIRA is read-only over closed CAPAs and never writes to CAPA tables. |

### 0.7 Module-18 architectural picture

```mermaid
flowchart TD
 U[CAPA Owner / Quality Lead / Approver] --> CAPA[/CAPA register/]
 CAPA --> AI[Action items]
 CAPA --> EC[Effectiveness checks]
 CAPA --> CI[Cascade items]
 CAPA --> APPROVE[Approval HITL + e-sign + SoD-18-01]
 APPROVE --> CLOSE[Closure HITL + bound e-sign + SoD-18-04]
 CLOSE -. governed reopen + executive co-sign .-> CAPA
 M16[URS-16 Deviations] --> CAPA
 M17[URS-17 RCA] --> CAPA
 M14[URS-14 Complaints] --> CAPA
 M15[URS-15 OOS / OOT] --> CAPA
 M21[URS-21 Findings] --> CAPA
 M22[URS-22 Inspection Obs.] --> CAPA
 M13[URS-13 Change Control] <--> CAPA
 M11[URS-11 Supplier NCR] --> CAPA
 CI --> M13
 CI --> M28[URS-28 Training]
 CI --> M12[URS-12 Document Control]
 CI --> M11sup[URS-11 Supplier Requalification]
 M30[URS-30 Notifications] <-- CAPA
 M32[URS-32 MIRA AI] <-- CAPA (read-only)
 ARCHAI[ARCH-AI-001] -.governs advisory AI.-> CAPA
 ANNEX22[Internal Annex 22 control — forward-looking; not enacted predicate rule] -.governs.-> APPROVE
 ANNEX22 -.governs.-> CLOSE
 ANNEX22 -.governs.-> EC
 AIAct[Internal EU AI Act Annex III high-risk classification — forward-looking] -.classifies.-> CAPA
```

Diagram 0.7-A — Module 18 architectural picture. The target `capas` code module is the expected owner of the CAPA register, lifecycle, source linkage, action-item lifecycle, effectiveness-check lifecycle, cascade-item lifecycle, HITL decision orchestration, e-signature persistence, approval gate, closure, and reopen; 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 CAPA prioritisation disposition, effectiveness-check outcome decisions, closure-disposition decisions, and reopen decisions, 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
 CAPA[(capas)] --> AI[(capa_action_items)]
 CAPA --> EC[(capa_effectiveness_checks)]
 CAPA --> CI[(capa_cascade_items)]
 CAPA --> LCE[(capa_lifecycle_events)]
 CAPA --> APPR[(capa_approvals)]
 CAPA --> HITL[(hitl_decisions — entity_type=capa)]
 APPR --> ESIG[(esignatures)]
```

Diagram 0.8-A — Module 18 entity-relationship overview. The target `capas` code module is the expected owner of 7 tables (CAPA header, action items, effectiveness checks, cascade items, lifecycle events, approvals, HITL-decision linkage); ownership is target binding and remains subject to repository verification and validation evidence. URS-06 substrate is consumed for audit; URS-04 HITL + e-signature subsystem is consumed for non-bypassable approval and bound signature persistence.

---

## 1. Document Control

This document is the User Requirements Specification (URS) for Verixa Module 18 — CAPA. 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_18_specification` change-class tag.

---

## 2. Scope

### 2.1 In scope

#### CAPA Registry

- The CAPA master registry per DEC-18-01: per-tenant registry with `id`, `tenant_id`, `display_id` (server-authoritative `CAPA-{YYYY}-{nnnnnn}` per DEC-18-03), `title`, `description`, `capa_type` (`corrective` / `preventive` / `corrective_and_preventive`), `priority` (`low` / `medium` / `high` / `critical`), `source_type` (`deviation` / `rca` / `complaint` / `oos` / `finding` / `audit_observation` / `change_control` / `supplier_ncr`), `source_id`, `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), `capa_owner_user_id` (nullable until assigned), `due_date`, `status` (`draft` / `open` / `assigned` / `in_progress` / `completed` / `effectiveness_check` / `verified` / `closed`), `study_scope`, `site_scope`, `product_scope`, `supplier_scope`, `batch_scope`, `created_by`, `created_at`, `updated_at`, `assigned_at` (nullable), `started_at` (nullable), `completed_at` (nullable), `effectiveness_check_scheduled_at` (nullable), `verified_at` (nullable), `verified_by_user_id` (nullable), `verified_e_sig_id` (nullable), `closed_at` (nullable), `closed_by_user_id` (nullable), `closed_e_sig_id` (nullable), `closure_rationale` (nullable), `deleted_at` (nullable; for soft-delete). **At least one source linkage** (`source_type` + `source_id`) is required. **At least one scope anchor** (`study_id`, `site_id`, `product_id`, `supplier_id`, or `batch_id`) is required.
- Server-authoritative race-safe CAPA number per DEC-18-03 via DB sequence.

#### Source Linkage and Validation

- Source-linkage validation per DEC-18-04: every CAPA MUST be linked to at least one of the eight declared source types (deviation / RCA / complaint / OOS / finding / audit observation / change control / supplier NCR). The linked record's existence MUST be validated at the application layer before persistence for ALL declared source types (`deviation`, `rca`, `complaint`, `oos`, `finding`, `audit_observation`, `change_control`, `supplier_ncr`).
- Cross-tenant source linkage is forbidden: the linked source record MUST be in the same tenant as the CAPA being created.
- Relink endpoint (`PATCH /capas/:id/relink`) preserves the original linkage history; relink requires `capas:relink` permission + reason-for-change.

#### CAPA Lifecycle

- Lifecycle state machine per DEC-18-02: `draft → open → assigned → in_progress → completed → effectiveness_check → verified → closed`; reopen is a governed transition event from `closed → in_progress` per DEC-18-22 + SoD-18-06 that appends a new CAPA iteration and a new lifecycle event without mutating or erasing the prior closed evidence. **Reopen MUST NOT erase the prior closed CAPA evidence.**
- Each transition is electronically signed (status-transition route requires e-signature per URS-04 Controlled Approval Modal); all transitions log dual-write to `capa_lifecycle_events` + URS-06 substrate.
- Canonical-status alignment per DEC-18-23: the canonical state set (`draft`, `open`, `assigned`, `in_progress`, `completed`, `effectiveness_check`, `verified`, `closed`) MUST be aligned across the backend workflow module, shared DB types, shared domain types, and frontend hooks. Any legacy state names (`pending_verification`, `verified_effective`, `verified_ineffective`) are not part of the canonical set and MUST NOT be used.

#### CAPA Action Items

- Action-item entity per DEC-18-05: `id`, `tenant_id`, `capa_id`, `action_description`, `action_type` (`corrective` / `preventive`), `assigned_user_id`, `due_date`, `status` (`open` / `in_progress` / `completed` / `cancelled`), `completion_notes`, `closure_evidence_document_id` (FK URS-12 nullable), `created_by`, `created_at`, `closed_at` (nullable), `closed_by_user_id` (nullable). Action items support add, update, list within the parent CAPA. Action-item completion requires reviewer-signed completion notes (SoD-18-02: completion reviewer ≠ assignee).
- Action items are mutable while the CAPA lifecycle state is `open`, `assigned`, `in_progress`, or `completed`; action items become immutable once the CAPA reaches `verified` or `closed` per DEC-18-15.

#### CAPA Effectiveness Checks

- Effectiveness-check entity per DEC-18-06: `id`, `tenant_id`, `capa_id`, `check_description`, `scheduled_at`, `executed_at` (nullable), `executed_by_user_id` (nullable), `outcome` (`effective` / `partial` / `ineffective`; nullable until executed), `outcome_evidence_document_id` (FK URS-12 nullable), `outcome_signed_at` (nullable), `outcome_signed_by_user_id` (nullable), `outcome_signed_e_sig_id` (nullable), `re_capa_required` (boolean; defaults true if outcome is `partial` or `ineffective`), `re_capa_id` (FK URS-18 nullable; populated when a follow-on CAPA is opened), `created_at`, `created_by`. The CAPA service MUST expose the completion / outcome update routes specified below.
- Effectiveness-check completion routes: `POST /capas/:id/effectiveness-checks/:checkId/execute` (records `executed_at` and `executed_by_user_id`), `POST /capas/:id/effectiveness-checks/:checkId/outcome` (records outcome + signed by reviewer with bound e-signature; SoD-18-03 enforced: outcome reviewer ≠ CAPA owner).
- Effectiveness adjudication per DEC-18-07: outcome `effective` allows the CAPA to advance `effectiveness_check → verified`; outcome `partial` requires documented decision to either advance to `verified` (with explicit acceptance rationale) or open a new CAPA via the `re_capa_id` reference; outcome `ineffective` requires opening a new CAPA via `re_capa_id` and the parent CAPA does NOT advance to `verified`.

#### CAPA Cascade Items

- Cascade-item entity per DEC-18-08: `id`, `tenant_id`, `capa_id`, `cascade_type` (`change_control` / `training` / `document_revision` / `supplier_requalification` / `procedure_update`), `cascade_description`, `downstream_record_id` (FK to URS-13 / URS-28 / URS-12 / URS-11 per cascade type), `status` (`pending` / `in_progress` / `completed` / `cancelled`), `assigned_user_id`, `due_date`, `closure_evidence_document_id` (FK URS-12 nullable), `created_by`, `created_at`, `closed_at` (nullable). Cascade items are mutable while the CAPA lifecycle state is `open`, `assigned`, `in_progress`, `completed`, or `effectiveness_check`; cascade items become immutable once the CAPA reaches `verified` or `closed` per DEC-18-15.
- Closure dependency: if a cascade item is in `pending` or `in_progress` status when CAPA closure is attempted, closure is blocked with `CAPA_CLOSURE_BLOCKED_BY_OPEN_CASCADE_ITEMS`.

#### CAPA-Specific HITL Orchestration

- CAPA-specific HITL decision orchestration per DEC-18-09: every CAPA approval transition (`completed → effectiveness_check`), every effectiveness-check outcome adjudication, every closure transition, and every reopen transition MUST create a HITL decision record in the URS-04 platform `hitl` subsystem with `entity_type = 'capa'`, `entity_id = capa_id`, decision-type appropriate to the transition, assignment, escalation rules, and decision capture. Route-level authority gates alone are not sufficient; the HITL decision record MUST be created.

#### Bound E-Signature on Closure

- Bound e-signature persistence per DEC-18-13 + DEC-18-16: the closure transition (`verified → closed`) MUST capture an e-signature payload via the URS-04 Controlled Approval Modal and persist `closed_e_sig_id` on the CAPA header. Route-level metadata such as `requiresEsign: true` is not sufficient; the CAPA-bound signature payload MUST be captured and persisted on closure. The verification transition (`effectiveness_check → verified`) MUST capture `verified_e_sig_id` similarly.

#### Final-State Immutability

- Post-verification / post-closure immutability per DEC-18-15: once a CAPA reaches `verified` or `closed`, the CAPA header, action items, effectiveness checks, and cascade items become immutable. Any mutation attempt MUST return `CAPA_IMMUTABLE_FINAL_STATE` with the 21 CFR Part 11 §11.10(e) message. This guard applies via `assertCapaMutable(...)` on every mutation route across the CAPA, action-item, effectiveness-check, and cascade-item services.

#### Closure

- CAPA closure per DEC-18-16: closure requires the CAPA to be in `verified` state, all action items in terminal status (`completed` or `cancelled`), all cascade items in terminal status, the effectiveness check outcome captured (`effective` or accepted-partial), and a closure-rationale captured. Closure is e-signed by the closure authority (`final_quality_approver`); SoD-18-04 enforced (closure authority ≠ CAPA owner).

#### Reopen

- Reopen per DEC-18-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 CAPA iteration; **does NOT mutate or erase the prior closed evidence**. SoD-18-06 enforced: the executive-authority reopen co-signer cannot be the original closure authority.

#### Multi-Dimensional Context

- Context model per DEC-18-17: `MODULE_CONTEXT_CONFIG['capa']` declares `study`, `site`, `product`, `supplier`, `batch` filtering as applicable per scope dimensions captured on the CAPA registry record. The persistence layer MUST persist `study_id`, `site_id`, `product_id`, `supplier_id`, `batch_id` per the registry schema; the typed DB layer and the platform context filter MUST agree on this set.

#### AI Architecture Binding

- AI architecture binding per DEC-18-18: NO direct LLM / generative AI write to `capas`, `capa_action_items`, `capa_effectiveness_checks`, or `capa_cascade_items`. Static deterministic AI MAY surface "similar prior CAPAs", "historical effectiveness patterns by source type", "common cascade-item categories for this source type" 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 CAPAs is permitted; MIRA write paths are prohibited.

#### Audit Trail

- Audit trail per DEC-18-19: every CAPA mutation (create, update, relink, action-item add / update / close, effectiveness-check schedule / execute / outcome, cascade-item add / update / close, status transition, approval, verification, closure, reopen) 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 after `draft`. Reviewer disposition, HITL decision linkage, and closure-signoff evidence captured at the appropriate lifecycle transition.

#### Dashboard Metrics

- Dashboard metrics per DEC-18-20: the closure-time metric is computed as `closed_at - assigned_at` (the regulated CAPA-active interval), not `updated_at - created_at`. Open-CAPA count by source type, by priority, by overdue-status; effectiveness-check outcome distribution; cascade-item completion rate; reopen rate.

### 2.2 Out of scope

- Root-cause analysis methodology (forward URS-17 RCA — Module 18 consumes the `rca_conclusion_created` event but does not own RCA workflow).
- Effectiveness-check methodology library (effectiveness checks are scheduled and outcome-captured within Module 18; the methodology of testing the check is out of scope).
- AI-driven decision-making on CAPA prioritisation, effectiveness outcome, closure, or reopen (explicitly prohibited per DEC-18-18; AI suggestion paths are advisory only).

### 2.3 Closed launch decisions

| ID | Decision |
|---|---|
| DEC-18-01 | CAPA master registry shape and per-tenant scoping. |
| DEC-18-02 | Lifecycle state machine: `draft → open → assigned → in_progress → completed → effectiveness_check → verified → closed`. Reopen is a governed transition event from `closed → in_progress` per DEC-18-22 + SoD-18-06; appends a new lifecycle event + new CAPA iteration without mutating or erasing prior closed evidence. |
| DEC-18-03 | Server-authoritative race-safe `CAPA-{YYYY}-{nnnnnn}` numbering via DB sequence. |
| DEC-18-04 | Source linkage: at least one of deviation / RCA / complaint / OOS / finding / audit observation / change control / supplier NCR required; existence validated at application layer before persistence for ALL declared source types; cross-tenant source linkage forbidden. |
| DEC-18-05 | Action-item entity model with assignment, due-date tracking, closure-evidence capture; SoD-18-02 enforced (completion reviewer ≠ assignee). |
| DEC-18-06 | Effectiveness-check entity model with completion / outcome update routes; outcome captured by reviewer with bound e-signature; SoD-18-03 enforced. |
| DEC-18-07 | Effectiveness adjudication: `effective` advances to `verified`; `partial` requires documented decision (advance or open re-CAPA); `ineffective` requires opening re-CAPA and parent does NOT advance to `verified`. |
| DEC-18-08 | Cascade-item entity model with downstream URS-13 / URS-28 / URS-12 / URS-11 linkage; closure blocked while cascade items are pending or in_progress. |
| DEC-18-09 | CAPA-specific HITL decision orchestration through URS-04 `hitl` subsystem with `entity_type = 'capa'` for every approval / verification / closure / reopen transition. |
| DEC-18-10 | Reviewer / verifier / approver gating through RBAC + Authority Profile + HITL non-bypassable workflow. |
| DEC-18-11 | E-signature binding for closure: `closed_e_sig_id` persisted on CAPA header; verification: `verified_e_sig_id` persisted. |
| DEC-18-12 | Segregation-of-duties enforcement: SoD-18-01..07 across creator, owner, approver, completion reviewer, effectiveness reviewer, closure authority, reopen co-signer. |
| DEC-18-13 | E-signature binding payload capture per Controlled Approval Modal contract (URS-04). |
| DEC-18-14 | Audit trail with reason-for-change discipline; HITL decision linkage and closure-signoff evidence captured at appropriate lifecycle transitions. |
| DEC-18-15 | Post-verification / post-closure immutability across CAPA header, action items, effectiveness checks, and cascade items; IMMUTABLE_STATUSES = {`verified`, `closed`}; `assertCapaMutable(...)` guard on every mutation route. |
| DEC-18-16 | CAPA closure requires `verified` state, all action items + cascade items in terminal status, effectiveness-check outcome captured (`effective` or accepted-partial), closure-rationale captured, e-signature by `final_quality_approver`; SoD-18-04 enforced. |
| DEC-18-17 | Multi-dimensional context: persistence layer MUST persist `study_id`, `site_id`, `product_id`, `supplier_id`, `batch_id` per the registry schema; the typed DB layer and the platform context filter MUST agree on this set. |
| DEC-18-18 | AI architecture binding: NO direct LLM / generative AI write to CAPA tables; static deterministic AI advisory only; MIRA read-only context for closed CAPAs. |
| DEC-18-19 | Audit trail: every mutation emits to URS-06 substrate with reason-for-change discipline; reviewer disposition + HITL linkage + closure-signoff evidence captured. |
| DEC-18-20 | Dashboard metrics: closure-time metric = `closed_at - assigned_at` (regulated CAPA-active interval); not `updated_at - created_at`. |
| DEC-18-21 | Critical-CAPA approval (where the CAPA is linked to a critical deviation per URS-16, a class-I recall complaint per URS-14, an inconclusive OOS per URS-15, a critical finding per URS-21, or an audit-observation 483 finding per URS-22) requires `final_quality_approver` + executive authority co-sign per SoD-18-07. |
| DEC-18-22 | Reopen of closed CAPA is a governed transition event from `closed → in_progress`; requires `executive_authority` co-sign + reason; appends a new lifecycle event + new CAPA iteration; does NOT mutate or erase prior closed evidence. SoD-18-06: executive reopen co-signer ≠ original closure authority. |
| DEC-18-23 | Canonical status-model alignment across backend workflow, shared DB type, shared domain type, and frontend hook to the canonical state set defined in DEC-18-02. |

---

## 3. Roles, Authority Profiles, Segregation of Duties

### 3.1 Roles consumed (URS-02 catalogue)

| Role key | Description |
|---|---|
| `viewer` | Read-only access within Module 18. |
| `capa_owner` | CAPA owner; manages action items + cascade items; drives the CAPA toward completion. |
| `capa_action_assignee` | Assignee of a specific CAPA action item; updates action-item progress and completion. |
| `qa_reviewer` | QA reviewer who reviews CAPA approval (subject to SoD-18-01) and effectiveness-check outcome (subject to SoD-18-03). |
| `effectiveness_reviewer` | Reviewer who adjudicates effectiveness-check outcome (subject to SoD-18-03). |
| `quality_lead` | Module 18 administrative oversight within tenant. |
| `closure_authority` | Authority who signs CAPA closure (subject to SoD-18-04). |
| `auditor` | Read access to CAPAs and CAPA audit trail. |
| `admin` | Module 18 tenant-administrative actions (taxonomy configuration, dashboard configuration). |
| `platform_admin` | Verixa platform — tenant-scoped Module 18 actions are support / break-glass only with reason, support-ticket reference, electronic signature, `PLATFORM_TENANT_ACCESS_USED` audit emit, and SOC alert; routine tenant CAPA administration belongs to tenant `admin` users. |
| `super_admin` | Verixa super-admin — tenant-scoped Module 18 actions are support / break-glass only under the same controls as `platform_admin`. |
| `executive_authority` | Founder / Chairman & MD — co-signs critical-CAPA approvals per DEC-18-21 and reopen events per DEC-18-22. |

### 3.2 Authority Profiles (URS-05)

| Authority Profile | Purpose |
|---|---|
| `capa_owner_authority` | CAPA ownership and action-item assignment. |
| `qa_review_authority` | CAPA approval sign by QA reviewer (subject to SoD-18-01). |
| `effectiveness_check_authority` | Effectiveness-check outcome adjudication (subject to SoD-18-03). |
| `final_quality_approver` | CAPA verification sign and closure sign by final quality approver. |
| `closure_authority` | CAPA closure sign per DEC-18-16. |
| `executive_authority` | Founder co-sign for critical-CAPA approval per DEC-18-21 and reopen per DEC-18-22. |
| `capa_reopen_executive_authority` | Executive authority for reopen (DEC-18-22). |

### 3.3 Permissions (Module 18 owns)

- `capas:read`
- `capas:create`
- `capas:update` (with reason-for-change)
- `capas:relink` (with reason-for-change)
- `capas:assign_owner` (with authority + SoD-18-02)
- `capas:add_action_item`
- `capas:update_action_item`
- `capas:close_action_item` (with SoD-18-02)
- `capas:add_cascade_item`
- `capas:update_cascade_item`
- `capas:close_cascade_item`
- `capas:schedule_effectiveness_check`
- `capas:execute_effectiveness_check`
- `capas:adjudicate_effectiveness_outcome` (with authority + SoD-18-03)
- `capas:transition_status` (with authority + Controlled Approval Modal e-sign)
- `capas:approve` (with authority + SoD-18-01)
- `capas:verify` (with authority + bound e-sign)
- `capas:close` (with authority + bound e-sign + SoD-18-04)
- `capas:reopen_executive` (executive authority + SoD-18-06)
- `capas:read_audit`

### 3.4 Segregation-of-Duties constraints

| ID | Constraint |
|---|---|
| SoD-18-01 | The CAPA approver MUST NOT be the CAPA creator or the CAPA owner. |
| SoD-18-02 | The action-item completion reviewer MUST NOT be the action-item assignee. |
| SoD-18-03 | The effectiveness-check outcome adjudicator MUST NOT be the CAPA owner or any action-item assignee for that CAPA. |
| SoD-18-04 | The closure authority MUST NOT be the CAPA creator or the CAPA owner. |
| SoD-18-05 | The CAPA owner MUST NOT be the discoverer of the precipitating source record (where source is deviation / OOS / complaint and the discoverer identity is captured). |
| SoD-18-06 | The executive-authority reopen co-signer MUST NOT be the original closure authority. |
| SoD-18-07 | Critical-CAPA approval matrix: no single user can satisfy two required slots (`final_quality_approver` + executive authority). |

### 3.5 Worked SoD examples

**Example 1: Standard CAPA — direct closure path.** A QC supervisor opens deviation `DEV-2026-001234` (minor, GMP). The QA reviewer (different from the QC supervisor per SoD-18-05) opens CAPA `CAPA-2026-000456` linked to the deviation. The CAPA owner (different from the QA reviewer per SoD-18-01 establishment) is assigned. Action items are created with assignees; action-item completion reviewers (different from assignees per SoD-18-02) sign each completion. Effectiveness check is scheduled, executed, and the outcome is adjudicated by an effectiveness reviewer (different from the CAPA owner per SoD-18-03) as `effective`. CAPA advances to `verified`. The closure authority (different from the QA reviewer / CAPA owner per SoD-18-04) signs closure with bound e-signature. CAPA `closed`.

**Example 2: Critical-CAPA approval requires executive authority co-sign (DEC-18-21).** A sterile-filtration deviation on Batch B-9876 produces a CAPA linked to a critical GMP deviation. CAPA approval requires `final_quality_approver` + executive authority co-sign per DEC-18-21. SoD-18-07 enforced (no user can satisfy two slots).

**Example 3: SoD-18-01 enforcement — creator attempts to approve own CAPA.** The CAPA owner who created `CAPA-2026-000457` attempts to approve it. Service rejects with HTTP 403 + `CAPA_SOD_VIOLATION_CREATOR_CANNOT_APPROVE`. URS-06 records the attempt.

**Example 4: SoD-18-03 enforcement — CAPA owner attempts to adjudicate own effectiveness check.** The CAPA owner attempts to sign the effectiveness-check outcome. Service rejects with HTTP 403 + `CAPA_SOD_VIOLATION_OWNER_CANNOT_ADJUDICATE_EFFECTIVENESS`. URS-06 records the attempt.

**Example 5: Effectiveness outcome `ineffective` requires re-CAPA (DEC-18-07).** The effectiveness check outcome is `ineffective`. Adjudicator captures the outcome with bound e-signature. Service blocks the CAPA from advancing to `verified` and creates a `re_capa_id` reference; a new CAPA must be opened to remediate the ineffective outcome. URS-30 notifies the CAPA owner.

**Example 6: Closure blocked by open cascade items (DEC-18-08).** Closure authority attempts to close `CAPA-2026-000458` while a `change_control` cascade item (URS-13 record `CR-2026-000789`) is still in `in_progress` status. Service rejects with HTTP 409 + `CAPA_CLOSURE_BLOCKED_BY_OPEN_CASCADE_ITEMS` listing the open cascade item.

**Example 7: Post-closure mutation attempt blocked (DEC-18-15).** A user attempts to add an action item to a closed CAPA. Service rejects with HTTP 403 + `CAPA_IMMUTABLE_FINAL_STATE` and the 21 CFR Part 11 §11.10(e) message. The proper path: reopen via executive authority co-sign per DEC-18-22.

**Example 8: Governed reopen by executive authority (DEC-18-22).** QA proposes reopen of `CAPA-2026-000459` (closed) on the basis of recurrence within 90 days of closure. Executive authority e-signs reopen via `capa_reopen_executive_authority` with documented reason. SoD-18-06 enforced. CAPA transitions `closed → in_progress`. Prior closed evidence preserved; a new CAPA iteration appends.

**Example 9: AI prohibition runtime block (DEC-18-18).** A user attempts to invoke "AI-suggest closure decision" via an experimental UI surface. Runtime block returns HTTP 403 + `CAPA_GENAI_PROHIBITED`. URS-06 audit substrate records the attempt.

### 3.6 Role-permission matrix (Module 18 administrative surface only)

| Permission | viewer | capa_owner | capa_action_assignee | qa_reviewer | effectiveness_reviewer | quality_lead | closure_authority | auditor | admin | platform_admin | super_admin |
|---|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|
| `capas:read` | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | support / break-glass only | support / break-glass only |
| `capas:create` | ✗ | ✓ | ✗ | ✓ | ✗ | ✓ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only |
| `capas:update` (with reason-for-change) | ✗ | ✓ | ✗ | ✓ | ✗ | ✓ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only |
| `capas:relink` (with reason-for-change) | ✗ | ✓ | ✗ | ✓ | ✗ | ✓ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only |
| `capas:assign_owner` (with SoD-18-02) | ✗ | ✗ | ✗ | ✓ | ✗ | ✓ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only |
| `capas:add_action_item` | ✗ | ✓ | ✗ | ✓ | ✗ | ✓ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only |
| `capas:update_action_item` | ✗ | ✓ | ✓ | ✓ | ✗ | ✓ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only |
| `capas:close_action_item` (with SoD-18-02) | ✗ | ✓ | ✗ | ✓ | ✗ | ✓ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only |
| `capas:add_cascade_item` | ✗ | ✓ | ✗ | ✓ | ✗ | ✓ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only |
| `capas:update_cascade_item` | ✗ | ✓ | ✗ | ✓ | ✗ | ✓ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only |
| `capas:schedule_effectiveness_check` | ✗ | ✓ | ✗ | ✓ | ✗ | ✓ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only |
| `capas:execute_effectiveness_check` | ✗ | ✗ | ✗ | ✗ | ✓ | ✓ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only |
| `capas:adjudicate_effectiveness_outcome` (with SoD-18-03) | ✗ | ✗ | ✗ | ✓ | ✓ | ✓ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only |
| `capas:approve` (with SoD-18-01) | ✗ | ✗ | ✗ | ✓ | ✗ | ✓ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only |
| `capas:verify` (with bound e-sign) | ✗ | ✗ | ✗ | ✓ | ✗ | ✓ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only |
| `capas:close` (with bound e-sign + SoD-18-04) | ✗ | ✗ | ✗ | ✗ | ✗ | ✓ | ✓ | ✗ | ✓ | support / break-glass only | support / break-glass only |
| `capas:reopen_executive` (executive authority + SoD-18-06) | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ (executive authority only) |
| `capas: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 CAPAs within their study-grant scope; cannot hold ownership / approval / closure roles.

---

## 4. End-to-End User Journeys

The 28 launch user journeys cover the full CAPA lifecycle: create from each source type, owner assignment, action-item lifecycle, effectiveness-check lifecycle (schedule / execute / adjudicate), cascade-item lifecycle, approval (standard and critical), verification, closure, reopen, AI advisory surface, AI prohibition negative paths, platform identity break-glass, India CDSCO scope, multi-dimensional context, and immutability negative paths.

### J-01 — Create CAPA from a deviation (URS-16 source)

A QA reviewer opens a major deviation `DEV-2026-001234`. From the deviation surface they click "Open CAPA". Module 18 service `create(...)` validates the `source_id` exists same-tenant for `source_type = 'deviation'` (DEC-18-04), captures applicable scope dimensions from the deviation context (DEC-18-17), assigns server-authoritative `CAPA-2026-000456` (DEC-18-03), state `draft`. URS-06 records create.

### J-02 — Create CAPA from an RCA conclusion (URS-17 source)

The `rca_conclusion_created` event from URS-17 is consumed by URS-18; the CAPA workflow surface presents a "Create CAPA from this RCA" action. CAPA owner clicks; Module 18 validates the `source_id` (RCA id) exists same-tenant; captures scope dimensions from the RCA context; assigns `CAPA-2026-000457`. State `draft`.

### J-03 — Create CAPA from a complaint (URS-14 source)

Complaint investigator escalates a complaint to CAPA. Module 18 validates the `complaint_id` exists same-tenant; captures product / batch / supplier scope from the complaint context; assigns `CAPA-2026-000458`. State `draft`.

### J-04 — Create CAPA from an OOS investigation (URS-15 source)

QC analyst escalates an inconclusive OOS investigation to CAPA. Module 18 validates the `oos_investigation_id` exists same-tenant; captures product / site / batch scope; assigns `CAPA-2026-000459`. State `draft`.

### J-05 — Create CAPA from a finding (URS-21 source)

Quality auditor escalates a critical finding to CAPA. Module 18 validates the `finding_id` exists same-tenant; captures applicable scope; assigns `CAPA-2026-000460`. State `draft`.

### J-06 — Create CAPA from an audit observation (URS-22 source)

Inspection coordinator escalates an inspection observation (e.g., FDA 483) to CAPA. Module 18 validates the audit-observation `source_id` exists same-tenant; captures applicable scope; assigns `CAPA-2026-000461`. State `draft`.

### J-07 — Create CAPA from a change-control precipitating record (URS-13 source)

Change Control identifies that a recently approved change has resulted in an unintended consequence requiring corrective action. CAPA is opened with `source_type = 'change_control'`. Module 18 validates the `change_request_id` exists same-tenant.

### J-08 — Create CAPA from a supplier non-conformance (URS-11 source)

Supplier quality lead opens a CAPA for a recurring supplier non-conformance. Module 18 validates the supplier NCR `source_id` exists same-tenant; captures supplier + product scope.

### J-09 — Source-linkage validation negative path

Investigator submits a CAPA with `source_id = "DEV-2099-999999"` (does not exist). Service rejects with HTTP 400 + `SOURCE_RECORD_NOT_FOUND`. URS-06 records the rejected attempt.

### J-10 — Cross-tenant source linkage negative path

Investigator submits a CAPA 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-11 — Owner assignment with SoD-18-05

QA reviewer assigns a CAPA owner. Service verifies the proposed owner is not the discoverer of the precipitating source record per SoD-18-05. If they are the same user, service rejects with HTTP 403 + `CAPA_SOD_VIOLATION_OWNER_CANNOT_BE_DISCOVERER`. On valid assignment, CAPA transitions `draft → assigned`.

### J-12 — Add action items

CAPA owner adds three action items (two corrective, one preventive) via `POST /capas/:id/action-items` with `assigned_user_id`, `due_date`, `action_type`. Each action item is in status `open`. URS-06 records each add.

### J-13 — Action-item completion with SoD-18-02

Action assignee A completes an action item, captures `completion_notes`, links closure-evidence document. The completion reviewer (different from the assignee per SoD-18-02) signs completion. Action item transitions `in_progress → completed`. URS-06 records the close.

### J-14 — Schedule effectiveness check

CAPA owner schedules an effectiveness check via `POST /capas/:id/effectiveness-checks` with `check_description`, `scheduled_at`. URS-06 records the schedule.

### J-15 — Execute effectiveness check

Effectiveness reviewer executes the scheduled check via `POST /capas/:id/effectiveness-checks/:checkId/execute`. Service captures `executed_at`, `executed_by_user_id`. Outcome is captured in J-16.

### J-16 — Adjudicate effectiveness outcome with SoD-18-03

Effectiveness reviewer (different from CAPA owner per SoD-18-03) records the outcome via `POST /capas/:id/effectiveness-checks/:checkId/outcome` with `outcome = effective` and bound e-signature. Service captures `outcome_signed_at`, `outcome_signed_by_user_id`, `outcome_signed_e_sig_id`. CAPA-specific HITL decision record is created (DEC-18-09). CAPA transitions `effectiveness_check → verified`. URS-06 records the outcome.

### J-17 — Effectiveness outcome `partial` requires documented decision (DEC-18-07)

Effectiveness outcome is `partial`. Adjudicator captures the outcome with bound e-signature. The CAPA workflow presents two options: (a) advance to `verified` with explicit acceptance rationale (signed by `final_quality_approver`); or (b) open a re-CAPA via the `re_capa_id` reference. The chosen path is captured in the audit trail.

### J-18 — Effectiveness outcome `ineffective` requires re-CAPA (DEC-18-07)

Effectiveness outcome is `ineffective`. Service blocks the CAPA from advancing to `verified` and requires opening a new CAPA via `re_capa_id`. URS-30 notifies the CAPA owner.

### J-19 — Add cascade items

CAPA owner adds cascade items via `POST /capas/:id/cascade-items`: a change-control cascade (URS-13 record), a training-cascade (URS-28 assignment), and a document-revision cascade (URS-12 minor revision). Each cascade item carries `cascade_type`, `downstream_record_id`, `assigned_user_id`, `due_date`, status `pending`. URS-06 records each add.

### J-20 — Cascade-item closure

Each cascade item is closed by the assignee with closure evidence linked to URS-12. CAPA cannot close while any cascade item is in `pending` or `in_progress` status (DEC-18-08).

### J-21 — CAPA approval (standard) with SoD-18-01

QA reviewer (different from CAPA creator and CAPA owner per SoD-18-01) opens the CAPA approval surface, reviews the action items + effectiveness check + cascade items, opens Controlled Approval Modal (URS-04), enters password / meaningOfSignature / reasonForChange, submits. CAPA-specific HITL decision record is created (DEC-18-09). Service validates SoD-18-01, persists approval record, advances CAPA workflow. URS-06 emits `CAPA_APPROVED`.

### J-22 — CAPA verification with bound e-signature (DEC-18-11)

QA reviewer signs verification (`effectiveness_check → verified`) via `POST /capas/:id/verify` with bound e-signature. Service captures `verified_at`, `verified_by_user_id`, `verified_e_sig_id` on the CAPA header. URS-06 emits `CAPA_VERIFIED`.

### J-23 — Critical-CAPA approval requires executive authority co-sign (DEC-18-21)

A CAPA linked to a critical deviation (`practice = gmp`, severity = `critical`) reaches verification. Approval requires `final_quality_approver` + executive authority co-sign per DEC-18-21. SoD-18-07 enforced (no user can satisfy two slots). On both signatures present, CAPA advances to `verified`. URS-06 emits `CAPA_VERIFIED` with both signature attributions.

### J-24 — CAPA closure with bound e-signature and SoD-18-04 (DEC-18-16)

Closure authority (different from creator / owner per SoD-18-04) signs closure via `POST /capas/:id/close` with bound e-signature. Service validates CAPA is `verified`, all action items + cascade items in terminal status, effectiveness-check outcome captured, closure-rationale captured. Persists `closed_e_sig_id`, `closed_at`, `closed_by_user_id`, `closure_rationale`. CAPA transitions to `closed`. URS-06 emits `CAPA_CLOSED`.

### J-25 — Closure blocked by open action items

Closure authority attempts to close a CAPA while action items are still in `open` or `in_progress`. Service rejects with HTTP 409 + `CAPA_CLOSURE_BLOCKED_BY_OPEN_ACTION_ITEMS` listing the open items.

### J-26 — Post-closure immutability negative path (DEC-18-15)

User attempts to add an action item to a closed CAPA. Service rejects with HTTP 403 + `CAPA_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-18-22.

### J-27 — Governed reopen by executive authority (DEC-18-22)

QA proposes reopen of `CAPA-2026-000459` (closed). Executive authority opens the reopen surface, reviews the QA rationale, e-signs reopen via `capa_reopen_executive_authority` with documented reason. SoD-18-06 enforced. CAPA transitions `closed → in_progress`. The prior closed evidence is preserved as a closed lifecycle event; a new CAPA iteration appends. URS-06 emits `CAPA_REOPENED`.

### J-28 — India CDSCO worked example

A pharma manufacturer in India (CDSCO Form 25 / Form 28 manufacturing licence holder) operates Module 18 for GMP manufacturing CAPAs. Module 18 carries source linkage to URS-16 deviations; the linked deviation 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 CAPA records originating from India tenant operation, subject to per-tenant jurisdictional regulatory assessment.

---

## 5. Front-end Module 18

### 5.1 Routes

| Route | Purpose |
|---|---|
| `/capas` | Module 18 landing — CAPA register filtered by tenant + scope dimensions |
| `/capas/:capaId` | CAPA detail with tabbed view (overview, action items, effectiveness checks, cascade items, lifecycle history, audit) |
| `/capas/new` | CAPA creation surface (with source-type picker) |
| `/capas/:capaId/action-items` | Action-item editor |
| `/capas/:capaId/effectiveness-checks` | Effectiveness-check scheduler / executor / adjudicator |
| `/capas/:capaId/cascade-items` | Cascade-item editor |
| `/capas/:capaId/approve` | Approval surface (Controlled Approval Modal) |
| `/capas/:capaId/verify` | Verification surface |
| `/capas/:capaId/close` | Closure surface (Controlled Approval Modal with bound e-sign) |
| `/capas/:capaId/reopen` | Reopen surface (executive authority only) |
| `/capas/dashboard` | CAPA dashboard with metrics |

### 5.2 Components

- **CAPARegisterTable** — paginated, filterable table of CAPAs.
- **CAPADetailTabs** — tabbed view of a CAPA.
- **CreateCAPAWizard** — multi-step: source-type picker → source-record selection → scope-dimension capture → priority / type → submit.
- **ActionItemEditor** — add / view / update / close action items with closure-evidence picker.
- **EffectivenessCheckPanel** — schedule / execute / adjudicate effectiveness checks.
- **CascadeItemEditor** — add / view / update / close cascade items with downstream-record linkage.
- **ApprovalModal** — Controlled Approval Modal (URS-04) with SoD-18-01 enforcement.
- **CriticalCAPAApprovalMatrix** — multi-sign matrix for critical-CAPA approval (DEC-18-21).
- **VerificationModal** — verification surface with bound e-signature.
- **ClosureModal** — closure surface with prerequisite check and bound e-signature.
- **ExecutiveAuthorityReopenModal** — executive-authority-only reopen.
- **CAPAAuditTrailView** — full CAPA audit trail consumed from URS-06.
- **CAPADashboard** — open-CAPA count, overdue CAPAs, effectiveness-outcome distribution, cascade completion rate, reopen rate.

### 5.3 Accessibility

WCAG 2.1 Level AA. Keyboard-navigable. Screen-reader labels for all interactive elements.

---

## 6. Back-end Module 18

### 6.1 Architecture overview

```mermaid
flowchart LR
 ROUTES[capas.routes.ts] --> SVC[capas.service.ts + workflow.ts]
 SVC --> DB[(capas tables)]
 SVC --> AUDIT[(URS-06 audit substrate)]
 SVC --> HITL[(URS-04 HITL subsystem entity_type=capa)]
 SVC --> ESIG[(URS-04 e-signature subsystem)]
 EVT[rca_conclusion_created event from URS-17] --> SVC
 SVC --> EVT2[capa_created event for downstream consumers]
```

Diagram 6.1-A — Module 18 architecture overview. The target `capas` code module is the expected owner of routes, services, workflow validation, and DB persistence; ownership is target binding and remains subject to repository verification and validation evidence. URS-06 substrate is consumed for audit; URS-04 HITL + e-signature subsystem is consumed for non-bypassable approval and bound signature persistence.

### 6.1.1 CAPA lifecycle state machine (full)

```mermaid
stateDiagram-v2
 [*] --> draft : create
 draft --> open : submitted_for_assignment
 open --> assigned : owner_assigned (SoD-18-05)
 assigned --> in_progress : work_started
 in_progress --> completed : action_items_completed
 completed --> effectiveness_check : effectiveness_check_scheduled (DEC-18-06)
 effectiveness_check --> verified : effective_outcome_adjudicated (DEC-18-07 + SoD-18-03 + bound e-sign)
 effectiveness_check --> in_progress : ineffective_outcome — re-CAPA opened (DEC-18-07)
 verified --> closed : closure_signed (DEC-18-16 + SoD-18-04 + bound e-sign)
 closed --> in_progress : reopen — governed transition (DEC-18-22 + SoD-18-06; appends new lifecycle event + new CAPA iteration; does NOT mutate or erase prior closed evidence)
 closed --> [*] : immutable parent + children DEC-18-15
 note right of in_progress
 SoD-18-01: approver ≠ creator/owner
 SoD-18-02: action-item completion reviewer ≠ assignee
 SoD-18-03: effectiveness reviewer ≠ owner/action-assignee
 SoD-18-04: closure authority ≠ creator/owner
 SoD-18-05: owner ≠ discoverer of source record
 SoD-18-06: reopen co-signer ≠ original closure authority
 SoD-18-07: critical-CAPA matrix — no user can hold two slots
 end note
```

Diagram 6.1-B — CAPA lifecycle state machine including effectiveness-driven advancement, executive-authority-cosigned reopen path (DEC-18-22), and post-verification / post-closure parent + child immutability (DEC-18-15).

### 6.2 Data model requirements

| Entity | Purpose | Key fields | Required | Unique | Tenant isolation | Versioning | Retention | Soft-delete | Audit | E-sig link |
|---|---|---|---|---|---|---|---|---|---|---|
| `capas` | Canonical CAPA record per DEC-18-01 | `id`, `tenant_id`, `display_id`, `title`, `description`, `capa_type`, `priority`, `source_type`, `source_id`, `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), `capa_owner_user_id` (nullable), `due_date`, `status`, `study_scope`, `site_scope`, `product_scope`, `supplier_scope`, `batch_scope`, `created_by`, `created_at`, `updated_at`, `assigned_at` (nullable), `started_at` (nullable), `completed_at` (nullable), `effectiveness_check_scheduled_at` (nullable), `verified_at` (nullable), `verified_by_user_id` (nullable), `verified_e_sig_id` (nullable), `closed_at` (nullable), `closed_by_user_id` (nullable), `closed_e_sig_id` (nullable), `closure_rationale` (nullable), `deleted_at` (nullable) | per-state | unique(`tenant_id`, `display_id`) | RLS on `tenant_id` | stateful + append-only audit | retain (long-term) | yes (soft-delete only) | yes | yes |
| `capa_action_items` | Per-CAPA action item per DEC-18-05 | `id`, `tenant_id`, `capa_id`, `action_description`, `action_type` (`corrective` / `preventive`), `assigned_user_id`, `due_date`, `status`, `completion_notes`, `closure_evidence_document_id` (FK URS-12 nullable), `created_by`, `created_at`, `closed_at` (nullable), `closed_by_user_id` (nullable), `completion_review_signed_e_sig_id` (nullable) | core required | unique(`capa_id`, `id`) | RLS via CAPA tenant | stateful | retain (long-term) | not applicable | yes | yes |
| `capa_effectiveness_checks` | Per-CAPA effectiveness check per DEC-18-06 | `id`, `tenant_id`, `capa_id`, `check_description`, `scheduled_at`, `executed_at` (nullable), `executed_by_user_id` (nullable), `outcome` (nullable), `outcome_evidence_document_id` (FK URS-12 nullable), `outcome_signed_at` (nullable), `outcome_signed_by_user_id` (nullable), `outcome_signed_e_sig_id` (nullable), `re_capa_required` (boolean), `re_capa_id` (FK URS-18 nullable), `created_at`, `created_by` | core required | unique(`capa_id`, `id`) | RLS via CAPA tenant | append-only outcome | retain (long-term) | not applicable | yes | yes |
| `capa_cascade_items` | Per-CAPA cascade item per DEC-18-08 | `id`, `tenant_id`, `capa_id`, `cascade_type`, `cascade_description`, `downstream_record_id`, `status`, `assigned_user_id`, `due_date`, `closure_evidence_document_id` (FK URS-12 nullable), `created_by`, `created_at`, `closed_at` (nullable) | core required | unique(`capa_id`, `id`) | RLS via CAPA tenant | stateful | retain (long-term) | not applicable | yes | yes |
| `capa_lifecycle_events` | Append-only lifecycle transition log | `id`, `tenant_id`, `capa_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(`capa_id`, `id`); unique(`record_hash`) | RLS via CAPA tenant | append-only | retain (long-term) | not applicable | yes | yes |
| `capa_approvals` | Per-approval signature-slot table per DEC-18-13 / DEC-18-21 | `id`, `tenant_id`, `capa_id`, `slot_role` (`final_quality_approver` / `executive_authority`), `slot_user_id`, `slot_e_sig_id`, `slot_signed_at`, `slot_reason_for_change` | per-slot | unique(`capa_id`, `slot_role`, `slot_user_id`) | RLS via CAPA tenant | append-only | retain (long-term) | not applicable | yes | yes |

### 6.3 API requirements

| Method | Endpoint | Actor | Request | Response | Permission | Audit | Error codes |
|---|---|---|---|---|---|---|---|
| GET | `/capas` | tenant-scoped | filters | `CAPA[]` | tenant base role + `audit:read` | `CAPA_REGISTER_VIEW_OPENED` once per session | none |
| GET | `/capas/:id` | tenant-scoped | none | full CAPA detail with action items + effectiveness checks + cascade items | `capas:read` | none | `NOT_FOUND` |
| GET | `/capas/:id/full` | tenant-scoped | none | enhanced full-detail aggregation | `capas:read` | none | `NOT_FOUND` |
| GET | `/capas/stats` | tenant-scoped | filters | aggregated stats (open count, overdue count, effectiveness outcome distribution, cascade completion rate, reopen rate, mean closure-time per DEC-18-20) | `capas:read` | none | none |
| POST | `/capas` | CAPA owner | source linkage + scope-dimension fields (electronic-signed) | `201` (state `draft`) | `capas:create` | `CAPA_CREATED` | `SOURCE_RECORD_NOT_FOUND`, `CROSS_TENANT_SOURCE_LINKAGE_FORBIDDEN`, `SCOPE_ANCHOR_REQUIRED`, `SOURCE_LINKAGE_REQUIRED`, validation |
| PATCH | `/capas/:id` | CAPA owner | partial fields (electronic-signed; reason-for-change required after `draft`) | `200` | `capas:update` | `CAPA_UPDATED` | `CAPA_IMMUTABLE_FINAL_STATE`, `REASON_FOR_CHANGE_REQUIRED`, validation |
| PATCH | `/capas/:id/relink` | CAPA owner | new source linkage + reason-for-change (electronic-signed) | `200` | `capas:relink` | `CAPA_RELINKED` | `SOURCE_RECORD_NOT_FOUND`, `REASON_FOR_CHANGE_REQUIRED` |
| POST | `/capas/:id/assign-owner` | QA reviewer | reason (electronic-signed) | `200` | `capas:assign_owner` | `CAPA_OWNER_ASSIGNED` | `CAPA_SOD_VIOLATION_OWNER_CANNOT_BE_DISCOVERER` |
| POST | `/capas/:id/action-items` | CAPA owner | action-item fields (electronic-signed) | `201` | `capas:add_action_item` | `CAPA_ACTION_ITEM_CREATED` | `CAPA_IMMUTABLE_FINAL_STATE`, validation |
| PATCH | `/capas/:id/action-items/:itemId` | assignee or CAPA owner | action-item fields (electronic-signed) | `200` | `capas:update_action_item` | `CAPA_ACTION_ITEM_UPDATED` | `CAPA_IMMUTABLE_FINAL_STATE`, validation |
| POST | `/capas/:id/action-items/:itemId/close` | CAPA owner | completion notes + reviewer-signed (electronic-signed) | `200` | `capas:close_action_item` | `CAPA_ACTION_ITEM_CLOSED` | `CAPA_SOD_VIOLATION_COMPLETION_REVIEWER_CANNOT_BE_ASSIGNEE` |
| POST | `/capas/:id/effectiveness-checks` | CAPA owner | check fields + scheduled-at (electronic-signed) | `201` | `capas:schedule_effectiveness_check` | `CAPA_EFFECTIVENESS_CHECK_SCHEDULED` | `CAPA_IMMUTABLE_FINAL_STATE`, validation |
| POST | `/capas/:id/effectiveness-checks/:checkId/execute` | effectiveness reviewer | reason (electronic-signed) | `200` | `capas:execute_effectiveness_check` | `CAPA_EFFECTIVENESS_CHECK_EXECUTED` | `STATE_NOT_EFFECTIVENESS_CHECK`, validation |
| POST | `/capas/:id/effectiveness-checks/:checkId/outcome` | effectiveness reviewer | outcome + bound e-sign | `200` | `capas:adjudicate_effectiveness_outcome` | `CAPA_EFFECTIVENESS_OUTCOME_CAPTURED` | `CAPA_SOD_VIOLATION_OWNER_CANNOT_ADJUDICATE_EFFECTIVENESS`, `BOUND_ESIGNATURE_REQUIRED` |
| POST | `/capas/:id/cascade-items` | CAPA owner | cascade-item fields (electronic-signed) | `201` | `capas:add_cascade_item` | `CAPA_CASCADE_ITEM_CREATED` | `CAPA_IMMUTABLE_FINAL_STATE`, validation |
| PATCH | `/capas/:id/cascade-items/:itemId` | assignee or CAPA owner | cascade-item fields (electronic-signed) | `200` | `capas:update_cascade_item` | `CAPA_CASCADE_ITEM_UPDATED` | `CAPA_IMMUTABLE_FINAL_STATE`, validation |
| PATCH | `/capas/:id/status` | qa_reviewer / closure_authority | new status + reason (electronic-signed; Controlled Approval Modal e-sign for `verified` and `closed`) | `200` | `capas:transition_status` | `CAPA_STATUS_TRANSITIONED` | `STATE_TRANSITION_NOT_ALLOWED`, validation |
| POST | `/capas/:id/approve` | qa_reviewer | reason (electronic-signed + MFA + Controlled Approval Modal) | `200` | `capas:approve` | `CAPA_APPROVED` | `CAPA_SOD_VIOLATION_CREATOR_CANNOT_APPROVE`, `STATE_NOT_COMPLETED`, `MISSING_FOUNDER_COSIGN` (for critical) |
| POST | `/capas/:id/verify` | qa_reviewer | reason + bound e-sign | `200` | `capas:verify` | `CAPA_VERIFIED` | `STATE_NOT_EFFECTIVENESS_CHECK`, `EFFECTIVENESS_OUTCOME_NOT_EFFECTIVE`, `BOUND_ESIGNATURE_REQUIRED` |
| POST | `/capas/:id/close` | closure_authority | reason + bound e-sign + closure-rationale | `200` | `capas:close` | `CAPA_CLOSED` | `STATE_NOT_VERIFIED`, `CAPA_CLOSURE_BLOCKED_BY_OPEN_ACTION_ITEMS`, `CAPA_CLOSURE_BLOCKED_BY_OPEN_CASCADE_ITEMS`, `CLOSURE_RATIONALE_REQUIRED`, `CAPA_SOD_VIOLATION_CLOSER_CANNOT_BE_CREATOR_OR_OWNER`, `BOUND_ESIGNATURE_REQUIRED` |
| POST | `/executive/capas/:id/reopen` | executive authority | reason (electronic-signed + MFA + co-sign) | `200` | `capas:reopen_executive` | `CAPA_REOPENED` | `STATE_NOT_CLOSED`, `CAPA_SOD_VIOLATION_REOPEN_COSIGNER_CANNOT_BE_CLOSURE_AUTHORITY` |

### 6.4 Workflow requirements (inline above and in §4 journeys)

### 6.5 Business rules

- **BR-18-01** — Every CAPA MUST have at least one source linkage (`source_type` + `source_id`) per DEC-18-04.
- **BR-18-02** — Source-record existence MUST be validated at the application layer for ALL declared source types (`deviation`, `rca`, `complaint`, `oos`, `finding`, `audit_observation`, `change_control`, `supplier_ncr`); cross-tenant source linkage forbidden.
- **BR-18-03** — Every CAPA MUST have at least one scope anchor (`study_id`, `site_id`, `product_id`, `supplier_id`, or `batch_id`).
- **BR-18-04** — Lifecycle state machine per DEC-18-02; reopen is governed transition `closed → in_progress` per DEC-18-22 (does NOT mutate or erase prior closed evidence).
- **BR-18-05** — Owner assignment enforces SoD-18-05 (owner ≠ discoverer of source record).
- **BR-18-06** — Action-item completion enforces SoD-18-02 (completion reviewer ≠ assignee).
- **BR-18-07** — Effectiveness-check outcome enforces SoD-18-03 (reviewer ≠ CAPA owner).
- **BR-18-08** — Effectiveness-check outcome `effective` allows advancement to `verified`; `partial` requires documented decision; `ineffective` requires re-CAPA per DEC-18-07.
- **BR-18-09** — CAPA approval enforces SoD-18-01 (approver ≠ creator/owner) + Controlled Approval Modal e-signature; CAPA-specific HITL decision record created (DEC-18-09).
- **BR-18-10** — Critical-CAPA approval requires `final_quality_approver` + executive authority co-sign per DEC-18-21; SoD-18-07 enforced.
- **BR-18-11** — CAPA verification (`effectiveness_check → verified`) requires bound e-signature; `verified_e_sig_id` persisted on CAPA header.
- **BR-18-12** — CAPA closure (`verified → closed`) requires bound e-signature; `closed_e_sig_id` persisted on CAPA header; SoD-18-04 enforced; 4-prerequisite check (state `verified`, all action items + cascade items in terminal status, effectiveness outcome captured, closure-rationale captured).
- **BR-18-13** — Post-verification / post-closure immutability enforced via `assertCapaMutable(...)` on every mutation route across `capas`, action-item, effectiveness-check, and cascade-item services (DEC-18-15).
- **BR-18-14** — Reopen is a governed transition event from `closed → in_progress` per DEC-18-22 + SoD-18-06; appends new lifecycle event + new CAPA iteration; does NOT mutate or erase prior closed evidence.
- **BR-18-15** — Every regulated mutation emits to URS-06 substrate with reason-for-change discipline after `draft` (DEC-18-19).
- **BR-18-16** — `capa_created` event emitted on CAPA creation; downstream consumers (URS-30 notifications, dashboard service) consume.
- **BR-18-17** — Static deterministic AI may surface advisory similarity / signal output; generative AI prohibited in CAPA prioritisation disposition, effectiveness-check outcome, closure, and reopen decision paths (DEC-18-18).
- **BR-18-18** — MIRA copilot read-only mapping `capa → capas` for closed CAPAs; no MIRA write paths.
- **BR-18-19** — Audit-log writes atomic with originating action per URS-04 BR-04-15.
- **BR-18-20** — Canonical status set MUST be aligned across backend workflow, shared DB type, shared domain type, and frontend hook per DEC-18-23.

### 6.6 Audit substrate

Module 18 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):

`CAPA_CREATED`, `CAPA_UPDATED`, `CAPA_RELINKED`, `CAPA_OWNER_ASSIGNED`, `CAPA_ACTION_ITEM_CREATED`, `CAPA_ACTION_ITEM_UPDATED`, `CAPA_ACTION_ITEM_CLOSED`, `CAPA_EFFECTIVENESS_CHECK_SCHEDULED`, `CAPA_EFFECTIVENESS_CHECK_EXECUTED`, `CAPA_EFFECTIVENESS_OUTCOME_CAPTURED`, `CAPA_CASCADE_ITEM_CREATED`, `CAPA_CASCADE_ITEM_UPDATED`, `CAPA_CASCADE_ITEM_CLOSED`, `CAPA_STATUS_TRANSITIONED`, `CAPA_APPROVED`, `CAPA_VERIFIED`, `CAPA_CLOSED`, `CAPA_REOPENED`, `CAPA_HITL_DECISION_OPENED`, `CAPA_HITL_DECISION_DECIDED`, `CAPA_SOD_VIOLATION_CREATOR_CANNOT_APPROVE`, `CAPA_SOD_VIOLATION_OWNER_CANNOT_BE_DISCOVERER`, `CAPA_SOD_VIOLATION_OWNER_CANNOT_ADJUDICATE_EFFECTIVENESS`, `CAPA_SOD_VIOLATION_COMPLETION_REVIEWER_CANNOT_BE_ASSIGNEE`, `CAPA_SOD_VIOLATION_CLOSER_CANNOT_BE_CREATOR_OR_OWNER`, `CAPA_SOD_VIOLATION_REOPEN_COSIGNER_CANNOT_BE_CLOSURE_AUTHORITY`, `CAPA_GENAI_PROHIBITED`, `CAPA_IMMUTABLE_FINAL_STATE`, `PLATFORM_TENANT_ACCESS_USED`, `PLATFORM_TENANT_ACCESS_DENIED`, `CAPA_REGISTER_VIEW_OPENED`, `CAPA_INSPECTION_PREP_EXPORTED`.

The following events are emitted by upstream / downstream modules and consumed (read-only) by Module 18 dashboards: `DEVIATION_INVESTIGATING`, `RCA_CONCLUSION_CREATED` (primary trigger from URS-17), `OOS_PHASE_2_OPEN`, `COMPLAINT_INVESTIGATION_OPENED`, `FINDING_OPENED`, `INSPECTION_OBSERVATION_OPENED`, `CHANGE_CONTROL_APPROVED`, `SUPPLIER_NCR_OPENED`.

### 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 |
|---|---|---|
| CAPA prioritisation disposition | NONE — internal Annex 22 prohibition | Manual decision; CAPA-owner-signed system of record |
| Effectiveness-check outcome decision | NONE — internal Annex 22 prohibition | Manual decision; effectiveness-reviewer-signed (bound e-sig) system of record |
| CAPA closure decision | NONE — internal Annex 22 prohibition | Manual closure; deterministic 4-prerequisite check; bound e-sig |
| CAPA reopen decision | NONE — internal Annex 22 prohibition | Manual reopen; executive authority co-sign |
| AI similar-CAPA suggestion (advisory) | YES — static deterministic over closed CAPAs | ARCH-AI-001 AC-2/3/4/7 |
| AI historical-effectiveness pattern (advisory) | YES — static deterministic; never autonomous | ARCH-AI-001 AC-2/3/4/7 |
| MIRA copilot read-only retrieval over closed CAPAs | YES — read-only | URS-32 RAG; mapping `capa → capas` |

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 + URS-04 HITL non-bypassable orchestration. 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] --> M18
 M15[URS-15 OOS / OOT] --> M18
 M16[URS-16 Deviations] --> M18
 M17[URS-17 RCA] --> M18
 M21[URS-21 Findings] --> M18
 M22[URS-22 Inspection Mgmt] --> M18
 M13[URS-13 Change Control] <--> M18
 M11[URS-11 Supplier NCR] --> M18
 M18 --> M28[URS-28 Training cascade]
 M18 --> M12[URS-12 Document Control cascade]
 M18 --> M11sup[URS-11 Supplier Requalification cascade]
 M18 --> M06[URS-06 Audit substrate]
 M18 --> M30[URS-30 Notifications]
 M22 <-- M18
 M26[URS-26 APQR] <-- M18
 M32[URS-32 MIRA AI] <-- M18 (read-only)
 ANNEX22[Internal Annex 22 control — forward-looking] -.governs.-> M18
 ARCHAI[ARCH-AI-001] -.governs advisory AI.-> M18
 AIAct[Internal EU AI Act Annex III high-risk classification — forward-looking] -.classifies.-> M18
```

Diagram 7.1-A — Module 18 cross-module wiring.

### 7.2 Change-Impact Matrix (CIM)

| Asset | Cross-module consumers | Direction | Class |
|---|---|---|---|
| CAPA event vocabulary | URS-22, URS-26, URS-30 | Outbound | Class 3 (add) |
| Cascade-item linkage | URS-13, URS-28, URS-12, URS-11 | Outbound | Class 2 |
| CAPA register | URS-21, URS-22, URS-26 | Outbound | Class 2 |
| Source linkage FKs | URS-14, URS-15, URS-16, URS-17, URS-21, URS-22, URS-13, URS-11 | 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 CAPA prioritisation disposition, effectiveness-check outcome decisions, closure-disposition decisions, and reopen decisions. Static deterministic AI may surface similar prior CAPAs and historical effectiveness patterns as advisory.
- Verixa internally classifies AI-assisted CAPA prioritisation 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.
- CAPA-specific HITL decision orchestration through URS-04 `hitl` subsystem with `entity_type = 'capa'` MUST be created for every approval / verification / closure / reopen transition (DEC-18-09).
- MIRA copilot read-only mapping `capa → capas` for closed CAPAs (per URS-32). MIRA MUST NOT write to any CAPA table.
- AI service errors degrade gracefully: similarity panel hides if the AI service is unavailable; the CAPA core workflow proceeds.

---

## 9. Performance / scalability

- CAPA register listing supports filters by `status`, `priority`, `source_type`, scope dimensions; 95th-percentile response time MUST be ≤ 500 ms for tenants up to 100,000 CAPAs.
- CAPA detail aggregation (action items + effectiveness checks + cascade items) returns within ≤ 300 ms for CAPAs up to 100 child rows.
- Concurrent CAPA mutation by independent owners MUST not deadlock; row-level locking on the CAPA header.

---

## 10. Localisation / i18n

UI strings, lifecycle state labels, action-type labels, cascade-type labels, 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 | CAPA create / relink | inline error |
| CROSS_TENANT_SOURCE_LINKAGE_FORBIDDEN | 400 | CAPA create / relink | inline error |
| SCOPE_ANCHOR_REQUIRED | 400 | CAPA create | inline error |
| SOURCE_LINKAGE_REQUIRED | 400 | CAPA create | inline error |
| CAPA_SOD_VIOLATION_OWNER_CANNOT_BE_DISCOVERER | 403 | owner assignment | inline error |
| CAPA_SOD_VIOLATION_CREATOR_CANNOT_APPROVE | 403 | CAPA approve | inline error |
| CAPA_SOD_VIOLATION_OWNER_CANNOT_ADJUDICATE_EFFECTIVENESS | 403 | effectiveness outcome | inline error |
| CAPA_SOD_VIOLATION_COMPLETION_REVIEWER_CANNOT_BE_ASSIGNEE | 403 | action-item close | inline error |
| CAPA_SOD_VIOLATION_CLOSER_CANNOT_BE_CREATOR_OR_OWNER | 403 | CAPA close | inline error |
| CAPA_SOD_VIOLATION_REOPEN_COSIGNER_CANNOT_BE_CLOSURE_AUTHORITY | 403 | CAPA reopen | inline error |
| CAPA_IMMUTABLE_FINAL_STATE | 403 | any mutation post-verification / post-closure | inline error citing 21 CFR Part 11 §11.10(e) |
| REASON_FOR_CHANGE_REQUIRED | 400 | CAPA update / relink | inline error |
| BOUND_ESIGNATURE_REQUIRED | 400 | verify / close / effectiveness outcome | inline error |
| EFFECTIVENESS_OUTCOME_NOT_EFFECTIVE | 409 | CAPA verify | inline error |
| STATE_NOT_DRAFT | 409 | lifecycle endpoints | inline error |
| STATE_NOT_OPEN | 409 | lifecycle endpoints | inline error |
| STATE_NOT_ASSIGNED | 409 | lifecycle endpoints | inline error |
| STATE_NOT_IN_PROGRESS | 409 | lifecycle endpoints | inline error |
| STATE_NOT_COMPLETED | 409 | CAPA approve | inline error |
| STATE_NOT_EFFECTIVENESS_CHECK | 409 | execute / outcome / verify | inline error |
| STATE_NOT_VERIFIED | 409 | CAPA close | inline error |
| STATE_NOT_CLOSED | 409 | CAPA reopen | inline error |
| STATE_TRANSITION_NOT_ALLOWED | 409 | status transition | inline error |
| CAPA_CLOSURE_BLOCKED_BY_OPEN_ACTION_ITEMS | 409 | CAPA close | inline error listing open action items |
| CAPA_CLOSURE_BLOCKED_BY_OPEN_CASCADE_ITEMS | 409 | CAPA close | inline error listing open cascade items |
| CAPA_CLOSURE_BLOCKED_BY_MISSING_EFFECTIVENESS_OUTCOME | 409 | CAPA close | inline error |
| CLOSURE_RATIONALE_REQUIRED | 400 | CAPA close | inline error |
| MISSING_FOUNDER_COSIGN | 401 | CAPA approve (critical) | open executive authority co-sign request |
| CAPA_GENAI_PROHIBITED | 403 | any AI surface that would write to CAPA 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 CAPA with non-existent source record | back end | `400 SOURCE_RECORD_NOT_FOUND` | inline error |
| Create CAPA without scope anchor | back end | `400 SCOPE_ANCHOR_REQUIRED` | inline error |
| Discoverer attempts to be CAPA owner | back end | `403 CAPA_SOD_VIOLATION_OWNER_CANNOT_BE_DISCOVERER` | inline error |
| Creator attempts to approve own CAPA | back end | `403 CAPA_SOD_VIOLATION_CREATOR_CANNOT_APPROVE` | inline error |
| CAPA owner attempts to adjudicate effectiveness | back end | `403 CAPA_SOD_VIOLATION_OWNER_CANNOT_ADJUDICATE_EFFECTIVENESS` | inline error |
| Action-item assignee attempts to be completion reviewer | back end | `403 CAPA_SOD_VIOLATION_COMPLETION_REVIEWER_CANNOT_BE_ASSIGNEE` | inline error |
| Close CAPA with open action items | back end | `409 CAPA_CLOSURE_BLOCKED_BY_OPEN_ACTION_ITEMS` | inline error listing items |
| Close CAPA with open cascade items | back end | `409 CAPA_CLOSURE_BLOCKED_BY_OPEN_CASCADE_ITEMS` | inline error listing items |
| Verify CAPA without `effective` outcome | back end | `409 EFFECTIVENESS_OUTCOME_NOT_EFFECTIVE` | inline error |
| Edit on closed CAPA | back end | `403 CAPA_IMMUTABLE_FINAL_STATE` | inline error |
| Reopen by original closure authority | back end | `403 CAPA_SOD_VIOLATION_REOPEN_COSIGNER_CANNOT_BE_CLOSURE_AUTHORITY` | inline error |
| GenAI invocation in prioritisation / effectiveness / closure / reopen path | back end runtime block | `403 CAPA_GENAI_PROHIBITED` | inline error |

---

## 12. Security and Observability

### 12.1 Security envelope

Tenant isolation via TDAL.withTenant per QS-5; RLS on every CAPA-scoped table per QS-6; permission checks per QS-7; structured error handling per QS-9; e-signature via URS-04 Controlled Approval Modal with bound payload persistence per DEC-18-13; MFA step-up for executive authority co-sign and reopen.

### 12.2 Observability

| Signal | Threshold | Action |
|---|---|---|
| CAPA closure rate per QA reviewer (high outliers) | > 95th percentile | Quality review |
| CAPA reopen rate per CAPA | > 1 reopen per CAPA | Quality oversight surface |
| Time from CAPA assignment to closure (SLA) | > 90 days | Notification to QA Lead |
| Effectiveness outcome `ineffective` rate | > 10% per quarter | Quality oversight surface |
| `CAPA_SOD_VIOLATION_*` events | any single event | high; SOC chat |
| `CAPA_GENAI_PROHIBITED` events | any single event | high; SOC chat |
| `PLATFORM_TENANT_ACCESS_USED` events | any single event | medium; SOC e-mail |

### 12.3 Reports

| Report | Purpose | Owner |
|---|---|---|
| Open CAPA register | Active CAPAs by lifecycle state and priority | QA |
| Overdue CAPAs | CAPAs past `due_date` not yet `closed` | QA |
| Effectiveness outcome distribution | `effective` / `partial` / `ineffective` per quarter per source type | QA |
| Cascade-item completion rate | % of cascade items closed within due-date | QA |
| Reopen audit register | Reopened CAPAs with executive authority attribution | QA, executive authority |
| Closure-time metric | `closed_at - assigned_at` mean per source type per quarter (DEC-18-20) | QA, dashboard |
| Cross-tenant indices (platform-admin support / break-glass only) | Aggregate Module 18 events | `platform_admin` (support / break-glass only with reason, support-ticket reference, electronic signature, `PLATFORM_TENANT_ACCESS_USED` audit emit, SOC alert) |

Exports:

- CAPA evidence pack (zipped: full CAPA + action items + effectiveness checks + cascade items + lifecycle events + URS-06 audit excerpt with hash-chain).

---

## 13. Data integrity (ALCOA+)

| Principle | How met |
|---|---|
| Attributable | Every CAPA mutation carries `created_by` / `updated_by` / `closed_by_user_id` / `verified_by_user_id` / signed-by per QS-2 |
| Legible | UI surfaces the CAPA detail with lifecycle history and audit trail |
| Contemporaneous | Server-generated timestamps per QS-3 |
| Original | Soft-delete only on CAPA header; post-verification / post-closure immutability for action items + effectiveness checks + cascade items per DEC-18-15 |
| Accurate | App-level source-record validation across ALL declared source types; SoD enforcement at every approval / verification / closure / reopen; bound e-signature persistence on closure |
| Complete | All CAPA mutations audited; CAPA-specific HITL orchestration enforces non-bypassable approval |
| Consistent | URS-06 chain integrity; cross-tenant cascade preserved; canonical status set aligned across layers per DEC-18-23 |
| Enduring | Long-term retention; chain sealing at tenant offboarding per URS-08 |
| Available | CAPA register surface; auditor read access per URS-22 |

---

## 14. Regulatory Mapping

### 14.1 Predicate-rule applicability matrix

| Regulatory authority | Predicate | Module 18 obligation |
|---|---|---|
| FDA | 21 CFR Part 11 §11.10(a) — System validation | Module 18 must be validated per QS-15, QS-16; URS-18-VAL-* gates |
| FDA | 21 CFR Part 11 §11.10(d) — Limit access to authorised individuals | Three-guard RBAC + Authority Profile + HITL non-bypassable |
| 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; bound e-sig persistence per DEC-18-13 |
| FDA | 21 CFR Part 211 §211.192 (Production record review for unexplained discrepancies) | CAPA workflow trigger from URS-16 |
| FDA | 21 CFR §820.100 (Corrective and Preventive Action — medical devices) | CAPA workflow including action items, effectiveness checks, cascade items, closure |
| EMA | EU GMP Annex 11 §4 / §9 / §12 / §16 | Module 18 validation, audit, security, incident handling |
| EMA / PIC/S | EU GMP Chapter 1 §1.4 (Pharmaceutical Quality System) | CAPA element of PQS |
| MHRA | MHRA Data Integrity Guidance (2018) — ALCOA+ | §13 mapping |
| Health Canada | C.02.020 — GMP records | CAPA register and retention |
| ICH | ICH Q9 — Quality Risk Management | Risk-based CAPA prioritisation |
| ICH | ICH Q10 — Pharmaceutical QMS §3.2.4 | CAPA element |
| ICH | ICH E6(R3) — GCP | Clinical CAPA taxonomy |
| OECD | OECD GLP | GLP CAPA 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 (CAPA / corrective-and-preventive-action handling within GMP) + Schedule M-III (where distribution-CAPA scope) + New Drugs and Clinical Trials Rules 2019 (where clinical-protocol CAPA is in scope) + CDSCO GCP guidance (where clinical / study CAPA scope) + Medical Devices Rules 2017 (where device / combination-product CAPA scope) — Applicable per India tenant operation and jurisdictional regulatory assessment | CAPA register, action items, effectiveness checks, cascade items, closure with bound e-signature, reopen audit chain; external jurisdictional legal / RA confirmation required for clause / form applicability per India CAPA scope |

---

## 15. URS Requirements Register

### 15.1 Front-end (FE)

| ID | Requirement | Priority |
|---|---|---|
| URS-18-FE-001 | Module 18 landing route at `/capas` | MUST |
| URS-18-FE-002 | CAPA register table with filters by `status`, `priority`, `source_type`, scope dimensions | MUST |
| URS-18-FE-003 | CAPA detail tabbed view (overview, action items, effectiveness checks, cascade items, lifecycle history, audit) | MUST |
| URS-18-FE-004 | Create-CAPA wizard with source-type picker | MUST |
| URS-18-FE-005 | Action-item editor with closure-evidence picker | MUST |
| URS-18-FE-006 | Effectiveness-check panel (schedule / execute / adjudicate) | MUST |
| URS-18-FE-007 | Cascade-item editor with downstream-record picker | MUST |
| URS-18-FE-008 | Approval modal (Controlled Approval Modal — URS-04) with SoD-18-01 enforcement surface | MUST |
| URS-18-FE-009 | Critical-CAPA approval matrix per DEC-18-21 | MUST |
| URS-18-FE-010 | Verification modal with bound e-signature | MUST |
| URS-18-FE-011 | Closure modal with prerequisite check + bound e-signature | MUST |
| URS-18-FE-012 | Executive authority reopen modal (executive only) | MUST |
| URS-18-FE-013 | CAPA audit trail view consumed from URS-06 | MUST |
| URS-18-FE-014 | CAPA dashboard with metrics per DEC-18-20 | MUST |
| URS-18-FE-015 | AI advisory similarity panel (visibly labelled per ARCH-AI-001 AC-3) | MUST |
| URS-18-FE-016 | Internal Annex 22 GenAI prohibition surface (no AI offered in prioritisation / effectiveness / closure / reopen UI) | MUST (negative requirement) |
| URS-18-FE-017 | All Module 18 surfaces meet WCAG 2.1 Level AA | MUST |

### 15.2 Back-end (BE)

| ID | Requirement | Priority |
|---|---|---|
| URS-18-BE-001 | CAPA service `create(...)` validates source linkage for ALL declared source types | MUST |
| URS-18-BE-002 | Cross-tenant source linkage forbidden | MUST |
| URS-18-BE-003 | Owner assignment enforces SoD-18-05 | MUST |
| URS-18-BE-004 | Action-item add / update / close (with SoD-18-02 on completion review) | MUST |
| URS-18-BE-005 | Effectiveness-check schedule + execute + outcome capture (with SoD-18-03) | MUST |
| URS-18-BE-006 | Effectiveness adjudication per DEC-18-07 (`effective` advances; `partial` requires decision; `ineffective` blocks + opens re-CAPA) | MUST |
| URS-18-BE-007 | Cascade-item add / update / close with downstream-record FK | MUST |
| URS-18-BE-008 | CAPA-specific HITL decision orchestration through URS-04 `hitl` subsystem with `entity_type = 'capa'` | MUST |
| URS-18-BE-009 | Bound e-signature persistence on verification (`verified_e_sig_id`) and closure (`closed_e_sig_id`) per DEC-18-11 + DEC-18-13 | MUST |
| URS-18-BE-010 | Approval enforces SoD-18-01 + Controlled Approval Modal e-signature | MUST |
| URS-18-BE-011 | Critical-CAPA approval matrix per DEC-18-21 with SoD-18-07 | MUST |
| URS-18-BE-012 | Closure enforces SoD-18-04 + 4-prerequisite check (state `verified`, all action items + cascade items terminal, effectiveness outcome captured, closure-rationale captured) | MUST |
| URS-18-BE-013 | Post-verification / post-closure immutability via `assertCapaMutable(...)` on every mutation route across `capas`, action-item, effectiveness-check, and cascade-item services | MUST |
| URS-18-BE-014 | Reopen as governed transition `closed → in_progress` per DEC-18-22 + SoD-18-06; appends new lifecycle event + new CAPA iteration | MUST |
| URS-18-BE-015 | Audit-log writes atomic with originating action per URS-04 BR-04-15 | MUST |
| URS-18-BE-016 | Reason-for-change captured for every CAPA UPDATE after `draft` | MUST |
| URS-18-BE-017 | Multi-dimensional context persistence: `study_id`, `site_id`, `product_id`, `supplier_id`, `batch_id` per registry schema | MUST |
| URS-18-BE-018 | Canonical status set aligned across backend workflow, shared DB type, shared domain type, and frontend hook per DEC-18-23 | MUST |
| URS-18-BE-019 | Closure-time metric formula = `closed_at - assigned_at` per DEC-18-20 | MUST |

### 15.3 Data (DATA)

| ID | Requirement | Priority |
|---|---|---|
| URS-18-DATA-001 | `capas` per DEC-18-01 with required source linkage and scope anchor enforcement | MUST |
| URS-18-DATA-002 | `capa_action_items` with assignment, due-date, closure-evidence | MUST |
| URS-18-DATA-003 | `capa_effectiveness_checks` with completion + outcome routes (typed DB schema aligned to registry) | MUST |
| URS-18-DATA-004 | `capa_cascade_items` with downstream-record FK (typed DB schema aligned to registry) | MUST |
| URS-18-DATA-005 | `capa_lifecycle_events` append-only with hash chain | MUST |
| URS-18-DATA-006 | `capa_approvals` per-slot signature table for critical-CAPA approval matrix | MUST |
| URS-18-DATA-007 | RLS on every CAPA-scoped table per QS-6 | MUST |
| URS-18-DATA-008 | Bound e-signature payload persistence on `closed_e_sig_id` and `verified_e_sig_id` | MUST |

### 15.4 AI / HITL (AI)

| ID | Requirement | Priority |
|---|---|---|
| URS-18-AI-001 | NO LLM / GenAI in CAPA prioritisation / effectiveness outcome / closure / reopen decision paths per the internal Annex 22 control | MUST (negative) |
| URS-18-AI-002 | Static deterministic AI MAY surface similar prior CAPAs (advisory only) per ARCH-AI-001 AC-2 | MUST |
| URS-18-AI-003 | Advisory output visibly labelled per ARCH-AI-001 AC-3 | MUST |
| URS-18-AI-004 | Advisory output never autonomously writes to CAPA tables per ARCH-AI-001 AC-4 | MUST |
| URS-18-AI-005 | AI service errors degrade gracefully per ARCH-AI-001 AC-7 | MUST |
| URS-18-AI-006 | MIRA copilot read-only mapping `capa → capas` for closed CAPAs (per URS-32); no MIRA write path | MUST |
| URS-18-AI-007 | Internal forward-looking AI governance evidence (EU AI Act Art. 13 transparency principles) | MUST |
| URS-18-AI-008 | Internal forward-looking AI governance evidence (EU AI Act Annex III high-risk classification approach) | MUST |
| URS-18-AI-009 | CAPA-specific HITL decision orchestration through URS-04 `hitl` subsystem | MUST |

### 15.5 Audit (AUD)

| ID | Requirement | Priority |
|---|---|---|
| URS-18-AUD-001 | Every Module 18 mutation produces an audit row through URS-06 | MUST |
| URS-18-AUD-002 | Audit-write failure rolls back originating action | MUST |
| URS-18-AUD-003 | HITL decision linkage captured in audit trail | MUST |
| URS-18-AUD-004 | Bound e-signature evidence captured at verification + closure | MUST |

### 15.6 Validation (VAL)

| ID | Requirement | Status |
|---|---|---|
| URS-18-VAL-001 | Installation Qualification | Pending |
| URS-18-VAL-002 | Operational Qualification | Pending |
| URS-18-VAL-003 | Performance Qualification | Pending |
| URS-18-VAL-004 | RLS enforcement evidence | Pending |
| URS-18-VAL-005 | URS-06 chain integrity evidence | Pending |
| URS-18-VAL-006 | SoD enforcement evidence (SoD-18-01..07) | Pending |
| URS-18-VAL-007 | Post-verification / post-closure immutability evidence (DEC-18-15) | Pending |
| URS-18-VAL-008 | Migration evidence (canonical status alignment across layers per DEC-18-23; `assertCapaMutable(...)` extension; bound e-sig persistence; HITL orchestration; source-record validation across all declared source types; multi-dimensional context persistence; effectiveness completion / outcome routes; cascade-item typed-DB alignment) | Pending |
| URS-18-VAL-009 | Internal forward-looking AI governance evidence (EU GMP Annex 22 Draft 2025 GenAI prohibition control) | Pending |
| URS-18-VAL-010 | ARCH-AI-001 AC-2/3/4/7 advisory AI evidence pack | Pending |
| URS-18-VAL-011 | Internal forward-looking AI governance evidence (EU AI Act Annex III high-risk classification approach) | Pending |
| URS-18-VAL-012 | Internal forward-looking AI governance evidence (EU AI Act Art. 13 transparency principles) | Pending |
| URS-18-VAL-013 | Critical-CAPA executive authority co-sign procedural evidence per DEC-18-21 | Pending |
| URS-18-VAL-014 | Reopen executive authority co-sign procedural evidence per DEC-18-22 + SoD-18-06 | Pending |
| URS-18-VAL-015 | CAPA-specific HITL orchestration evidence per DEC-18-09 | Pending |
| URS-18-VAL-016 | Bound e-signature persistence evidence per DEC-18-13 | Pending |
| URS-18-VAL-017 | Source-record validation evidence across all declared source types per DEC-18-04 | Pending |
| URS-18-VAL-018 | Multi-dimensional context persistence evidence per DEC-18-17 | Pending |
| URS-18-VAL-019 | Effectiveness completion / outcome routes evidence per DEC-18-06 | Pending |
| URS-18-VAL-020 | Cascade-item typed-DB alignment evidence per DEC-18-08 | Pending |
| URS-18-VAL-021 | Closure-time metric formula evidence per DEC-18-20 | Pending |

### 15.7 Integration (INT)

| ID | Requirement | Priority |
|---|---|---|
| URS-18-INT-001 | URS-14 Complaints inbound source linkage | MUST |
| URS-18-INT-002 | URS-15 OOS / OOT inbound source linkage | MUST |
| URS-18-INT-003 | URS-16 Deviations inbound source linkage | MUST |
| URS-18-INT-004 | URS-17 RCA inbound (`rca_conclusion_created` event consumer + source linkage) | MUST |
| URS-18-INT-005 | URS-21 Findings inbound source linkage | MUST |
| URS-18-INT-006 | URS-22 Inspection observation inbound source linkage | MUST |
| URS-18-INT-007 | URS-13 Change Control bidirectional (precipitating change inbound; cascade-item outbound) | MUST |
| URS-18-INT-008 | URS-11 Supplier NCR inbound; supplier requalification cascade outbound | MUST |
| URS-18-INT-009 | URS-12 Document Control cascade outbound | MUST |
| URS-18-INT-010 | URS-28 Training cascade outbound | MUST |
| URS-18-INT-011 | URS-22 Inspection Mgmt outbound (CAPA register accessible to inspection-readiness export) | MUST |
| URS-18-INT-012 | URS-26 APQR outbound | MUST |
| URS-18-INT-013 | URS-30 Notifications outbound | MUST |
| URS-18-INT-014 | URS-32 MIRA AI inbound (read-only mapping `capa → capas` for closed CAPAs) | MUST |
| URS-18-INT-015 | URS-06 audit substrate inbound | MUST |
| URS-18-INT-016 | URS-04 Controlled Approval Modal contract + HITL subsystem + e-signature subsystem | MUST |
| URS-18-INT-017 | URS-05 Authority Profile registry consumer | MUST |
| URS-18-INT-018 | Internal forward-looking AI governance evidence (EU GMP Annex 22 Draft 2025) | MUST |
| URS-18-INT-019 | Internal forward-looking AI governance evidence (EU AI Act Annex III high-risk classification approach) | MUST |

### 15.8 Reports (REP)

| ID | Requirement | Priority |
|---|---|---|
| URS-18-REP-001 | Open CAPA register | MUST |
| URS-18-REP-002 | Overdue CAPA list | MUST |
| URS-18-REP-003 | Effectiveness outcome distribution | MUST |
| URS-18-REP-004 | Cascade-item completion rate | MUST |
| URS-18-REP-005 | Reopen audit register with executive authority attribution | MUST |
| URS-18-REP-006 | Closure-time metric per DEC-18-20 | MUST |
| URS-18-REP-007 | CAPA evidence pack export | MUST |

### 15.9 Workflow (WF)

| ID | Requirement | Priority |
|---|---|---|
| URS-18-WF-001 | CAPA lifecycle state machine per DEC-18-02 | MUST |
| URS-18-WF-002 | Owner assignment per SoD-18-05 | MUST |
| URS-18-WF-003 | Action-item completion per SoD-18-02 | MUST |
| URS-18-WF-004 | Effectiveness adjudication per DEC-18-07 + SoD-18-03 | MUST |
| URS-18-WF-005 | Approval per DEC-18-13 + SoD-18-01 + HITL | MUST |
| URS-18-WF-006 | Critical-CAPA approval matrix per DEC-18-21 + SoD-18-07 | MUST |
| URS-18-WF-007 | Verification per DEC-18-11 + bound e-sig | MUST |
| URS-18-WF-008 | Closure per DEC-18-16 + SoD-18-04 + bound e-sig | MUST |
| URS-18-WF-009 | Reopen as governed transition per DEC-18-22 + SoD-18-06 | MUST |

### 15.10 Functional acceptance (FUN)

| ID | Requirement | Priority |
|---|---|---|
| URS-18-FUN-001 | CAPA create with source linkage validation across all declared source types | MUST |
| URS-18-FUN-002 | CAPA approve with SoD-18-01 enforcement | MUST |
| URS-18-FUN-003 | CAPA verify with bound e-sig | MUST |
| URS-18-FUN-004 | CAPA close with 4-prerequisite check + bound e-sig | MUST |
| URS-18-FUN-005 | CAPA reopen by executive authority with SoD-18-06 | MUST |
| URS-18-FUN-006 | Post-verification / post-closure mutation blocked per DEC-18-15 | MUST |

---

## 16. Test cases and Acceptance criteria

### 16.1 Test cases (TC)

| ID | Test |
|---|---|
| TC-18-01 | CAPA happy path from deviation source → owner assign → action items → effectiveness check → adjudicate effective → verify → close |
| TC-18-02 | CAPA from RCA source happy path (consumes `rca_conclusion_created` event) |
| TC-18-03 | CAPA from complaint source happy path |
| TC-18-04 | CAPA from OOS source happy path |
| TC-18-05 | CAPA from finding source happy path |
| TC-18-06 | CAPA from audit observation source happy path |
| TC-18-07 | CAPA from change-control source happy path |
| TC-18-08 | CAPA from supplier NCR source happy path |
| TC-18-09 | CAPA create with non-existent source returns `400 SOURCE_RECORD_NOT_FOUND` (across all declared source types) |
| TC-18-10 | CAPA create cross-tenant source returns `400 CROSS_TENANT_SOURCE_LINKAGE_FORBIDDEN` |
| TC-18-11 | CAPA create without scope anchor returns `400 SCOPE_ANCHOR_REQUIRED` |
| TC-18-12 | Discoverer attempts to be CAPA owner returns `403 CAPA_SOD_VIOLATION_OWNER_CANNOT_BE_DISCOVERER` |
| TC-18-13 | Creator attempts to approve own CAPA returns `403 CAPA_SOD_VIOLATION_CREATOR_CANNOT_APPROVE` |
| TC-18-14 | CAPA owner attempts to adjudicate effectiveness returns `403 CAPA_SOD_VIOLATION_OWNER_CANNOT_ADJUDICATE_EFFECTIVENESS` |
| TC-18-15 | Action-item assignee attempts completion review returns `403 CAPA_SOD_VIOLATION_COMPLETION_REVIEWER_CANNOT_BE_ASSIGNEE` |
| TC-18-16 | Critical-CAPA approval requires `final_quality_approver` + executive authority co-sign per DEC-18-21 |
| TC-18-17 | Verify requires `effective` outcome; otherwise `409 EFFECTIVENESS_OUTCOME_NOT_EFFECTIVE` |
| TC-18-18 | Verify requires bound e-signature; without it `400 BOUND_ESIGNATURE_REQUIRED` |
| TC-18-19 | Close requires bound e-signature; without it `400 BOUND_ESIGNATURE_REQUIRED` |
| TC-18-20 | Close with open action items returns `409 CAPA_CLOSURE_BLOCKED_BY_OPEN_ACTION_ITEMS` |
| TC-18-21 | Close with open cascade items returns `409 CAPA_CLOSURE_BLOCKED_BY_OPEN_CASCADE_ITEMS` |
| TC-18-22 | Close without closure-rationale returns `400 CLOSURE_RATIONALE_REQUIRED` |
| TC-18-23 | Mutation on verified or closed CAPA returns `403 CAPA_IMMUTABLE_FINAL_STATE` |
| TC-18-24 | Reopen by original closure authority returns `403 CAPA_SOD_VIOLATION_REOPEN_COSIGNER_CANNOT_BE_CLOSURE_AUTHORITY` |
| TC-18-25 | Reopen by executive authority transitions `closed → in_progress`; appends new lifecycle event; preserves prior closed evidence |
| TC-18-26 | Effectiveness outcome `ineffective` blocks `verified` advancement and requires re-CAPA |
| TC-18-27 | Internal Annex 22 negative test: any GenAI invocation in prioritisation / effectiveness / closure / reopen path blocked at runtime + lint |
| TC-18-28 | Multi-dimensional context: `study_id`, `site_id`, `product_id`, `supplier_id`, `batch_id` persisted per registry schema |
| TC-18-29 | Race-condition test on `display_id` generation under concurrent creates per DEC-18-03 |
| TC-18-30 | Audit-write failure rolls back originating action |
| TC-18-31 | Platform identity outside support envelope returns `403 PLATFORM_TENANT_ACCESS_DENIED`; SOC alert fires |
| TC-18-32 | Closure-time metric computation = `closed_at - assigned_at` |

### 16.2 Acceptance criteria (AC)

| ID | Acceptance criterion |
|---|---|
| AC-18-01 | Every CAPA carries at least one source linkage and at least one scope anchor; existence validated for all declared source types. |
| AC-18-02 | SoD-18-01 enforced: CAPA approver ≠ creator/owner. |
| AC-18-03 | SoD-18-02 enforced: action-item completion reviewer ≠ assignee. |
| AC-18-04 | SoD-18-03 enforced: effectiveness reviewer ≠ CAPA owner. |
| AC-18-05 | SoD-18-04 enforced: closure authority ≠ creator/owner. |
| AC-18-06 | SoD-18-05 enforced: owner ≠ discoverer of source record. |
| AC-18-07 | SoD-18-06 enforced: executive reopen co-signer ≠ original closure authority. |
| AC-18-08 | Critical-CAPA approval matrix per DEC-18-21 enforced; SoD-18-07 enforced. |
| AC-18-09 | Bound e-signature persisted on verification (`verified_e_sig_id`) and closure (`closed_e_sig_id`). |
| AC-18-10 | Post-verification / post-closure immutability per DEC-18-15 enforced via `assertCapaMutable(...)` on every mutation route across `capas`, action-item, effectiveness-check, and cascade-item services. |
| AC-18-11 | Reopen is governed transition per DEC-18-22; appends new CAPA iteration without mutating prior closed evidence. |
| AC-18-12 | CAPA-specific HITL decision orchestration through URS-04 `hitl` subsystem with `entity_type = 'capa'` for every approval / verification / closure / reopen transition. |
| AC-18-13 | Internal Annex 22 GenAI prohibition enforced runtime + lint per DEC-18-18. |
| AC-18-14 | Internal forward-looking AI governance evidence (EU AI Act Annex III high-risk classification approach) maintained. |
| AC-18-15 | Internal forward-looking AI governance evidence (EU AI Act Art. 13 transparency principles) maintained for all AI surfaces. |
| AC-18-16 | URS-06 hash-chain integrity preserved on every CAPA mutation. |
| AC-18-17 | Closure-time metric formula = `closed_at - assigned_at` per DEC-18-20. |
| AC-18-18 | Canonical status set aligned across backend workflow, shared DB type, shared domain type, and frontend hook per DEC-18-23. |
| AC-18-19 | CAPA evidence pack export includes full CAPA + action items + effectiveness checks + cascade items + lifecycle events + URS-06 audit excerpt with hash-chain. |

---

## 17. Validation evidence pack

### 17.1 Validation gate

URS-18-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.
- Canonical status alignment applied (backend workflow, shared DB type, shared domain type, frontend hook all aligned to DEC-18-02 canonical state set per DEC-18-23).
- `assertCapaMutable(...)` extended to action-item, effectiveness-check, and cascade-item mutators per DEC-18-15.
- Source-record validation applied at service layer for ALL declared source types per DEC-18-04.
- Multi-dimensional context persistence aligned: `study_id`, `site_id`, `product_id`, `supplier_id`, `batch_id` persisted per registry schema.
- Bound e-signature payload persistence on `verified_e_sig_id` and `closed_e_sig_id` per DEC-18-13.
- CAPA-specific HITL decision orchestration through URS-04 `hitl` subsystem with `entity_type = 'capa'` per DEC-18-09.
- Effectiveness-check completion / outcome routes mounted per DEC-18-06.
- Cascade-item typed-DB alignment per DEC-18-08.
- Closure-time metric formula = `closed_at - assigned_at` per DEC-18-20.
- Reopen route mounted with executive authority + SoD-18-06 + reason per DEC-18-22.

### 17.2 Validation evidence index

- IQ pack (installation qualification).
- OQ pack (operational qualification per CAPA happy path + negative paths).
- PQ pack (performance qualification per §9 thresholds).
- RLS evidence per QS-6.
- URS-06 chain integrity evidence per DEC-18-19.
- SoD enforcement evidence (SoD-18-01..07).
- Post-verification / post-closure immutability evidence.
- Critical-CAPA executive authority co-sign procedural evidence.
- Reopen executive authority co-sign procedural evidence.
- CAPA-specific HITL orchestration evidence.
- Bound e-signature persistence evidence.
- Source-record validation evidence across all declared source types.
- Multi-dimensional context persistence evidence.
- Effectiveness completion / outcome routes evidence.
- Cascade-item typed-DB alignment evidence.
- Closure-time metric formula 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 18 inputs)

| ID | Decision |
|---|---|
| DEC-18-01..23 | All Module 18 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 (HITL orchestration + Controlled Approval Modal + bound e-sig) | 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 | Bidirectional (supplier NCR inbound; supplier requalification cascade outbound) | URS-11 module URS |
| URS-12 Document Control | Bidirectional (closure-evidence inbound; document-revision cascade outbound) | URS-12 module URS |
| URS-13 Change Control | Bidirectional (precipitating change inbound; change-control cascade outbound) | 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; primary upstream) | URS-16 module URS |
| URS-17 RCA | Inbound (`rca_conclusion_created` event consumer + source linkage) | URS-17 module URS |
| URS-21 Findings | Inbound (source linkage) | URS-21 module URS |
| URS-22 Inspection Mgmt | Bidirectional (audit-observation inbound; CAPA register 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-28 Training | Outbound (training cascade) | URS-28 module URS |
| URS-30 Notifications | Outbound | URS-30 module URS |
| URS-32 MIRA AI | Outbound (read-only mapping `capa → capas`) | 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 18 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 + CAPA-specific HITL orchestration) | ✓ |
| 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-18-VAL-008 (Migration Evidence Gate) and the §17 validation evidence pack are satisfied. **No Module 18 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-verification / post-closure immutability + critical-CAPA executive co-sign + reopen executive co-sign + CAPA-specific HITL orchestration + bound e-signature persistence + source-record validation across all declared source types + multi-dimensional context persistence + effectiveness completion / outcome routes + cascade-item typed-DB alignment + closure-time metric formula evidence are itemised in §17.
- **Specification ready for compliance review?** Yes — ALCOA+, 21 CFR Part 11, 21 CFR §211.192, 21 CFR §820.100, 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-18-VAL-008 + §17 evidence complete.

---

## Appendix A — Module 18 End-to-End Composite (Source → Open → Action Items → Effectiveness Check → Verify → Close → Immutable / Reopen)

```mermaid
flowchart TD
 A[Source: Deviation/RCA/Complaint/OOS/Finding/Audit Obs/Change Control/Supplier NCR] --> B[Create CAPA - draft]
 B --> C[Submit for Assignment - open]
 C --> D[Owner Assigned - SoD-18-05 - assigned]
 D --> E[Work Started - in_progress]
 E --> F[Add Action Items + Cascade Items]
 F --> G[Action Items Completed - SoD-18-02 - completed]
 G --> H[Schedule Effectiveness Check]
 H --> I[Execute Effectiveness Check]
 I --> J[Adjudicate Outcome - SoD-18-03 + bound e-sig]
 J -- effective --> K[Verify - bound e-sig - verified]
 J -- partial --> L{Documented Decision?}
 L -- accept --> K
 L -- re-CAPA --> M[Open re-CAPA via re_capa_id]
 J -- ineffective --> M
 K --> N[All Action Items + Cascade Items Terminal? Effectiveness Outcome Captured? Closure Rationale?]
 N -- yes --> O{Critical CAPA?}
 N -- no --> P[Closure Blocked]
 O -- yes --> Q[final_quality_approver + Executive Authority Co-Sign per DEC-18-21 + SoD-18-07 - bound e-sig]
 O -- no --> R[Closure Authority Sign - SoD-18-04 + bound e-sig]
 Q --> S[closed]
 R --> S
 S --> T[Immutable Parent + Children per DEC-18-15]
 T -. Reopen Path .-> U[Executive Authority Reopen - DEC-18-22 + SoD-18-06]
 U --> V[closed -> in_progress; new CAPA iteration appended; prior closed evidence preserved]
 V --> E
 H -. Internal Annex 22 control .-> W[NO GenAI in prioritisation / effectiveness outcome / closure / reopen paths per DEC-18-18]
```

Diagram Appendix A — Module 18 End-to-End Composite. Source → CAPA create → owner assignment with cross-module linkage → action items + cascade items → effectiveness check schedule + execute + adjudicate (with re-CAPA on `partial` accepted alternative or `ineffective` outcome) → verification with bound e-sig → 4-prerequisite closure check → critical-CAPA matrix per DEC-18-21 + SoD-18-07 (executive authority co-sign) → standard closure per DEC-18-16 + SoD-18-04 + bound e-sig → immutable parent + children per DEC-18-15 → executive-authority-cosigned reopen path per DEC-18-22 + SoD-18-06; CAPA-specific HITL orchestration through URS-04 `hitl` subsystem on every approval / verification / closure / reopen. 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 prioritisation / effectiveness / closure / reopen 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 18 User Requirements Specification —