# Verixa — User Requirements Specification

# Module 19: Risk Assessment

| Field | Value |
|---|---|
| Document ID | VRX-URS-19 |
| 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-19-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 `risk-assessments`, expected API mount `/api/v1/risk-assessments/*`, expected configuration ownership for risk methodologies / scoring scales / risk-matrices through the `config` subsystem, expected authority + HITL + e-signature integration through the `authority` and `hitl` subsystems for non-bypassable approval, expected audit-log integration through the `audit-log` subsystem, expected RPN propagation to `deviations` for source-linked assessments. 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** and the **high-process-risk classification in FDA CSA Final Guidance (September 2025)**, unless a jurisdiction-specific legal assessment determines otherwise. AI-assisted risk surfaces (AI risk scoring, AI severity / likelihood / detectability suggestion, AI control-adequacy assessment, MIRA risk copilot, AI mitigation recommendation, AI similar-risk surfacing) 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 risk scoring, assessment, and mitigation planning path; risk assessment creation, scoring, review, approval, and closure shall be executable when AI services are disabled, degraded, or overridden by the assessor or risk-review committee. **No AI service shall be the sole path to finalize a risk score or dispose a risk assessment; a qualified human assessor with documented authority shall sign the risk conclusion.** This module binds ARCH-AI-001 AC-2, AC-3, AC-4, and AC-7. Verixa treats **EU GMP Annex 22 Draft 2025** as an internal forward-looking architectural control (not an enacted predicate rule); under that internal control, generative / probabilistic AI is **PROHIBITED** in risk-score finalisation, risk-assessment approval, mitigation-effectiveness adjudication, and closure decision paths. Static deterministic AI may surface similar prior assessments and historical risk-pattern data; 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 Risk Assessment register, the assessment lifecycle state machine (`draft → in_progress → completed → approved → closed`; reopen is a governed transition event from `closed → in_progress` per DEC-19-22 + SoD-19-06 that appends a new assessment iteration and does not mutate or erase the prior closed evidence), the source-linkage controls (deviation per URS-16, change-control per URS-13, supplier per URS-11, study per URS-07, product per URS-10, site per URS-09, validation per URS-07 / URS-09, regulatory-intelligence per URS-27, free-form `proactive_assessment`) with app-level existence validation across all declared source types, the multi-dimensional context capture (`study_id`, `site_id`, `product_id`, `supplier_id`, `batch_id`, `process_scope`), the methodology configuration (FMEA — Failure Mode and Effects Analysis; HACCP — Hazard Analysis and Critical Control Points; PHA — Preliminary Hazard Analysis; HAZOP — Hazard and Operability Study; Bowtie; What-If; Fault Tree per URS-17 reference; ICH Q9 risk-management framework), the risk-entry and risk-mitigation lifecycle, the deterministic RPN computation (`severity × likelihood × detectability`) with auditable risk-matrix configuration, the risk-level derivation against tenant-configured matrix thresholds, the controlled approval with reviewer-independent SoD enforcement and bound e-signature, the post-approval / post-closure record immutability across the assessment header, risk entries, and mitigations, the controlled reopen workflow, the deviation-linked RPN propagation, the per-jurisdictional regulatory expectations under FDA 21 CFR Part 11, ICH Q9 (Quality Risk Management), ICH Q10 (Pharmaceutical Quality System), EU GMP Annex 11 §1, EU GMP Annex 15, ISO 14971 (medical-device risk management where applicable), and MHRA Data Integrity. |
| Date of Issue | 2026-05-06 |
| Module Owner (Engineering) | Quality / Risk Squad |
| Module Owner (Quality Validation) | CSV / CSA Lead — Risk Assessment |
| 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 Risk Assessment module (Module 19). 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 risk-management substrate: the canonical risk assessment register; the lifecycle state machine (`draft → in_progress → completed → approved → closed` with reopen as a governed transition event from `closed → in_progress` per executive authority co-sign + reason — DEC-19-22 + SoD-19-06 — that appends a new assessment iteration without mutating or erasing the prior closed evidence); the source-linkage controls (deviation per URS-16, change-control per URS-13, supplier per URS-11, study per URS-07, product per URS-10, site per URS-09, validation per URS-07 / URS-09, regulatory-intelligence per URS-27, plus free-form `proactive_assessment`) with app-level existence validation extended across all declared source types; the methodology catalogue (FMEA, HACCP, PHA, HAZOP, Bowtie, What-If, Fault Tree, ICH Q9 framework) with tenant-configurable methodology + scoring scales + risk-matrix thresholds; the risk-entry and risk-mitigation lifecycle with assignment, due-date, control-adequacy capture; the deterministic RPN computation (`severity × likelihood × detectability`) under auditable risk-matrix configuration; the risk-level derivation against tenant-configured matrix thresholds (`negligible` / `low` / `medium` / `high` / `critical`); the multi-dimensional context model (`study_id`, `site_id`, `product_id`, `supplier_id`, `batch_id`, `process_scope`) with at least one scope anchor required and aligned with the platform context filter; the controlled approval workflow with reviewer-independent SoD enforcement (SoD-19-01: approver ≠ creator), Controlled Approval Modal e-signature, and bound `approved_e_sig_id` persistence on the assessment header; the post-approval / post-closure record immutability across the assessment header, risk entries, and mitigations enforced via `assertRiskAssessmentMutable(...)` on every mutation route; the controlled reopen workflow with executive authority co-sign and rationale; the deviation-linked RPN propagation when a deviation-source assessment reaches `approved`; 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 risk-score finalisation, risk-assessment approval, mitigation-effectiveness adjudication, and closure decision paths; the canonical-status-model alignment across backend service, shared DB types, shared domain types, and frontend hooks; the audit trail coverage with reason-for-change discipline; the configurable methodology catalogue and risk-matrix at tenant level; 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 19 accessible to non-domain engineers, product owners, validation engineers, and quality risk-assessors.

### 0.3 Cross-references

- **URS-01** Authentication, Session & Access Control — identity envelope for every assessment mutation
- **URS-02** RBAC & Permissions — the `risk-assessments:*` permission set
- **URS-03** Context Gate & Approval Scope — context-gate enforcement for assessment scope dimensions
- **URS-04** Workflow / HITL / E-Signature / Approval Authority — Controlled Approval Modal contract for assessment approval and reopen
- **URS-05** Authority Profile / Delegation / SoD — Authority Profiles consumed (`risk_assessor_authority`, `risk_review_authority`, `final_quality_approver`, `executive_authority`)
- **URS-06** Audit Trail / Hash Chain / Tamper-Evident — append-only audit substrate
- **URS-07** Study Management — study-scope dimension consumed; validation-source linkage
- **URS-08** Tenant Management Lifecycle — tenant context for assessment records
- **URS-09** Site / Facility Management — site-scope dimension consumed; validation-source linkage
- **URS-10** Product / SKU / Drug Master Data — product-scope dimension consumed
- **URS-11** Supplier Management — supplier-scope dimension consumed; supplier-source linkage
- **URS-12** Document Control / SOP — affected-document linkage; closure-evidence document references
- **URS-13** Change Control — change-control source linkage; change-control cascade outbound where mitigation precipitates change
- **URS-14** Complaints — complaint-precipitated risk source linkage
- **URS-15** OOS / OOT — OOS-precipitated risk source linkage
- **URS-16** Deviations — deviation-source linkage with RPN propagation
- **URS-17** RCA — RCA references for root-cause-driven risk re-assessment
- **URS-18** CAPA — CAPA outbound for high / critical risk-level mitigation
- **URS-21** Findings — finding-source linkage
- **URS-22** Inspection Mgmt — audit observation-source linkage
- **URS-23** Batch Records — batch-scope dimension consumed
- **URS-27** Regulatory Intelligence — regulatory-intelligence source linkage
- **URS-30** Notifications — notification delivery for assessment lifecycle events
- **URS-32** MIRA AI — read-only MIRA copilot context for closed assessments (no write path)
- **URS-35** Infrastructure / Backup-Restore — operational continuity

### 0.4 Plain-language primer

In a regulated pharmaceutical operation, **risk assessment is the regulator's expected discipline before any change, any unusual deviation, or any new product / process is committed to**. When a deviation suggests systemic risk, when a change request crosses the Class 2 / Class 3 threshold, when a new supplier is introduced, when a new product is launched, or when regulatory intelligence indicates a new failure mode, the marketing authorisation holder is obligated by **ICH Q9 (Quality Risk Management), ICH Q10 (Pharmaceutical Quality System), EU GMP Annex 11 §1, EU GMP Annex 15, FDA CSA Final Guidance (September 2025), and ISO 14971 (medical-device risk management where applicable)** to (1) open a controlled risk assessment record, (2) apply a recognised methodology (FMEA, HACCP, PHA, HAZOP, Bowtie, What-If, Fault Tree, or the ICH Q9 framework), (3) capture risk entries with severity / likelihood / detectability scores, (4) compute RPN deterministically, (5) derive risk level against the tenant's configured matrix, (6) plan mitigations with named owners and due dates, (7) re-score after mitigation to demonstrate reduction, (8) obtain reviewer-independent approval with bound e-signature, and (9) close only when residual risk is `acceptable` per the matrix. Module 19 is the target specification for this regulated workflow.

The most common mistake in regulated risk assessment is **AI-generated risk scoring without human qualification**. The regulator's tell-tale at inspection is a risk score that traces back to an AI suggestion with no documented assessor sign-off. Module 19 enforces the pathway: every risk score is human-attributable; AI may suggest severity / likelihood / detectability values as advisory help only; final scoring is the human assessor's signed decision; approval requires reviewer independence and bound e-signature. The internal Annex 22 / EU AI Act Annex III high-risk control prohibits generative AI in risk-score finalisation, risk-assessment approval, mitigation-effectiveness adjudication, and closure decision paths.

The **AI-assistance** dimension is critical. Static deterministic AI may surface "similar prior risk assessments" or "historical risk-pattern data" or "common mitigation patterns for this risk type" as advisory help. Generative AI (LLMs / MIRA copilot) is **prohibited** from writing to the risk-score finalisation, the approval decision, the mitigation-effectiveness adjudication, or the closure decision under the internal Annex 22 Draft 2025 forward-looking AI governance control. MIRA copilot may read closed assessments for read-only context but no AI service writes to `risk_assessments`, `risk_entries`, or `risk_mitigations` 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-19-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 |
|---|---|
| Risk Assessment | The structured evaluation of potential harm from a process, product, system, or change, including severity, likelihood, and detectability scoring, mitigation planning, and residual-risk acceptance. |
| Methodology | A recognised structured technique used to systematically derive risk: FMEA, HACCP, PHA, HAZOP, Bowtie, What-If, Fault Tree, or the ICH Q9 framework. |
| FMEA | Failure Mode and Effects Analysis — bottom-up technique computing RPN per failure mode. |
| HACCP | Hazard Analysis and Critical Control Points — process-based technique used in sterile manufacturing and food-grade analogues. |
| PHA | Preliminary Hazard Analysis — early-phase qualitative hazard identification. |
| HAZOP | Hazard and Operability Study — node-based deviation analysis used in continuous-process operations. |
| Bowtie | Top-event analysis combining fault-tree (causes) with event-tree (consequences). |
| What-If | Brainstorming-based hazard identification. |
| Fault Tree | Top-down deductive failure analysis (cross-references URS-17 fault-tree implementation). |
| Risk Entry | A single risk row within an assessment with severity, likelihood, detectability, RPN, derived risk level. |
| Risk Mitigation | A planned action to reduce severity, likelihood, or improve detectability; carries assigned owner, due date, control-adequacy assessment, and post-mitigation re-score. |
| RPN | Risk Priority Number — `severity × likelihood × detectability`; deterministic; never AI-computed for the final value. |
| Risk level | The categorical risk derived from RPN against the tenant-configured matrix thresholds: `negligible` / `low` / `medium` / `high` / `critical`. |
| Risk matrix | The tenant-configured mapping from RPN to risk level; configurable per methodology; versioned. |
| Source linkage | The mandatory FK to the precipitating context (deviation per URS-16, change-control per URS-13, supplier per URS-11, study per URS-07, product per URS-10, site per URS-09, validation per URS-07 / URS-09, regulatory-intelligence per URS-27, or `proactive_assessment` for proactive QMS-driven assessments). |
| Scope anchor | At least one of `study_id`, `site_id`, `product_id`, `supplier_id`, `batch_id`, `process_scope` MUST be captured on every assessment record. |
| Control adequacy | The reviewer's evaluation of whether existing controls are adequate to maintain risk at acceptable level. |
| Residual risk | The risk level remaining after planned mitigations are implemented and re-scored. |
| Reviewer independence | The Segregation-of-Duties enforcement that the assessment approver MUST NOT be the assessment creator (SoD-19-01). |
| Reopen | A governed transition event from `closed → in_progress` requiring executive authority co-sign and documented reason; appends a new assessment iteration without mutating prior closed evidence. |
| ARCH-AI-001 | Platform architecture binding requiring manual continuity for every AI surface (AC-1..AC-7). |
| Annex 22 | EU GMP Annex 22 (Draft 2025). Verixa treats Annex 22 and EU AI Act high-risk / transparency concepts as internal forward-looking AI governance controls unless a jurisdiction-specific legal assessment determines otherwise. Under the internal control, generative / probabilistic AI is prohibited in risk-score finalisation, approval, mitigation-effectiveness adjudication, and closure. Binding predicate-rule obligations remain those listed in §14. |
| MIRA | The platform's read-only AI copilot service; for Module 19 MIRA is read-only over closed assessments and never writes to risk-assessment tables. |
| RPN propagation | Deterministic update of the source deviation's RPN field when a deviation-linked risk assessment reaches `approved`. |

### 0.7 Module-19 architectural picture

```mermaid
flowchart TD
 U[Risk Assessor / Reviewer / Approver] --> RA[/Risk Assessment register/]
 RA --> RE[Risk entries with severity/likelihood/detectability]
 RE --> RPN[Deterministic RPN computation]
 RPN --> RL[Risk level derived from tenant matrix]
 RA --> MIT[Mitigations with assigned owner + due date + control adequacy]
 MIT --> POST[Post-mitigation re-score]
 POST --> RES[Residual risk assessment]
 RA --> APPROVE[Approval HITL + e-sign + SoD-19-01]
 APPROVE --> CLOSE[Closure HITL + bound e-sign + SoD-19-04]
 CLOSE -. governed reopen + executive co-sign .-> RA
 M16[URS-16 Deviations] --> RA
 M13[URS-13 Change Control] --> RA
 M11[URS-11 Supplier] --> RA
 M07[URS-07 Study] --> RA
 M10[URS-10 Product] --> RA
 M09[URS-09 Site] --> RA
 M27[URS-27 Reg Intelligence] --> RA
 RA -. RPN propagation when approved .-> M16
 RA -. high/critical risk .-> M18[URS-18 CAPA]
 RA -. mitigation precipitates change .-> M13
 M30[URS-30 Notifications] <-- RA
 M32[URS-32 MIRA AI] <-- RA (read-only)
 ARCHAI[ARCH-AI-001] -.governs advisory AI.-> RA
 ANNEX22[Internal Annex 22 control — forward-looking; not enacted predicate rule] -.governs.-> RPN
 ANNEX22 -.governs.-> APPROVE
 ANNEX22 -.governs.-> CLOSE
 AIAct[Internal EU AI Act Annex III high-risk classification — forward-looking] -.classifies.-> RA
 CSA[Internal FDA CSA high-process-risk classification — forward-looking] -.classifies.-> RA
```

Diagram 0.7-A — Module 19 architectural picture. The target `risk-assessments` code module is the expected owner of the assessment register, lifecycle, source linkage, methodology catalogue, risk-entry lifecycle, deterministic RPN computation, risk-matrix derivation, mitigation lifecycle with re-score, controlled 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 risk-score finalisation, approval, mitigation-effectiveness adjudication, and closure decision paths and the module is internally classified high-risk AI. ARCH-AI-001 governs advisory deterministic AI in similarity / signal surfacing. Binding predicate-rule obligations remain those listed in §14.

### 0.8 Entity-relationship overview

```mermaid
flowchart LR
 RA[(risk_assessments)] --> RE[(risk_entries)]
 RA --> MIT[(risk_mitigations)]
 MIT --> POST[(risk_post_mitigation_scores)]
 RA --> LCE[(risk_assessment_lifecycle_events)]
 RA --> APPR[(risk_assessment_approvals)]
 CFG[(risk_methodology_config)] --> RA
 CFG --> MTRX[(risk_matrix_versions)]
```

Diagram 0.8-A — Module 19 entity-relationship overview. The target `risk-assessments` code module is the expected owner of 7 tables (assessment header, risk entries, risk mitigations, post-mitigation scores, lifecycle events, approvals, and methodology / matrix configuration 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 19 — Risk Assessment. 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_19_specification` change-class tag.

---

## 2. Scope

### 2.1 In scope

#### Risk Assessment Registry

- The risk assessment master registry per DEC-19-01: per-tenant registry with `id`, `tenant_id`, `display_id` (server-authoritative `RISK-{YYYY}-{nnnnnn}` per DEC-19-03), `title`, `description`, `methodology` (`fmea` / `haccp` / `pha` / `hazop` / `bowtie` / `what_if` / `fault_tree` / `ich_q9_framework`), `source_type` (`deviation` / `change_control` / `supplier` / `study` / `product` / `site` / `validation` / `regulatory_intelligence` / `proactive_assessment`), `source_id` (nullable for `proactive_assessment`), `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), `process_scope` (text describing the bounded process under assessment), `assessor_user_id` (nullable until assigned), `assigned_to_user_id` (nullable; persisted on the assessment header), `risk_matrix_version_id` (FK to `risk_matrix_versions` for the matrix used at scoring), `methodology_config_id` (FK to `risk_methodology_config`), `aggregate_rpn` (computed; max RPN across risk entries), `aggregate_risk_level` (computed from `aggregate_rpn` against the matrix), `lifecycle_state` (`draft` / `in_progress` / `completed` / `approved` / `closed`), `created_by`, `created_at`, `updated_at`, `approved_at` (nullable), `approved_by_user_id` (nullable), `approved_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` non-null; `source_id` required for non-`proactive_assessment` types) is required. **At least one scope anchor** (`study_id`, `site_id`, `product_id`, `supplier_id`, `batch_id`, or `process_scope`) is required.
- Server-authoritative race-safe assessment number per DEC-19-03 via DB sequence.

#### Source Linkage and Validation

- Source-linkage validation per DEC-19-04: every risk assessment MUST be linked to one of the nine declared source types. The linked record's existence MUST be validated at the application layer for ALL non-`proactive_assessment` source types.
- Cross-tenant source linkage is forbidden: the linked source record MUST be in the same tenant as the assessment being created.

#### Risk Assessment Lifecycle

- Lifecycle state machine per DEC-19-02: `draft → in_progress → completed → approved → closed`; reopen is a governed transition event from `closed → in_progress` per DEC-19-22 + SoD-19-06 that appends a new assessment iteration and a new lifecycle event without mutating or erasing the prior closed evidence. **Reopen MUST NOT erase the prior closed evidence.**
- Each transition is electronically signed; all transitions log dual-write to `risk_assessment_lifecycle_events` + URS-06 substrate.
- Canonical-status alignment per DEC-19-23: the canonical state set (`draft`, `in_progress`, `completed`, `approved`, `closed`) MUST be aligned across `packages/backend/src/modules/risk-assessments/service.ts`, `packages/shared/src/types/db.ts`, `packages/shared/src/types/risk.ts`, `packages/shared/src/types/risk-enhanced.ts`, and `packages/frontend/src/api/hooks/useRiskAssessments.ts`.

#### Methodology Configuration and Risk Matrix

- Methodology configuration per DEC-19-05: tenant-scoped methodology catalogue (`risk_methodology_config`) declares which methodologies are enabled, each methodology's scoring scale (typically 1-5 or 1-10 per dimension), and the RPN matrix-version reference. Tenant administrators MAY configure tenant-specific scoring scales; platform provides defaults for FMEA (1-10 severity / likelihood / detectability with RPN range 1-1000) and ICH Q9 framework defaults at launch.
- Risk matrix versioning per DEC-19-06: tenant risk matrices (`risk_matrix_versions`) carry `id`, `tenant_id`, `methodology_id`, `version`, `effective_from`, `effective_to`, `severity_max`, `likelihood_max`, `detectability_max`, `risk_level_thresholds_jsonb` (mapping RPN ranges to `negligible` / `low` / `medium` / `high` / `critical`). Risk matrix changes require URS-13 Change Control.

#### Risk Entry Lifecycle

- Risk-entry entity per DEC-19-07: `id`, `tenant_id`, `risk_assessment_id`, `entry_label`, `failure_mode_or_hazard`, `failure_effect`, `failure_cause`, `existing_controls_jsonb` (array of existing controls with effectiveness rating), `severity` (integer 1..matrix.severity_max), `likelihood` (integer 1..matrix.likelihood_max), `detectability` (integer 1..matrix.detectability_max), `rpn` (computed deterministically as `severity × likelihood × detectability`; never AI-set for final value), `risk_level` (computed deterministically against `risk_matrix_versions.risk_level_thresholds_jsonb`), `created_by`, `created_at`, `updated_at`. Risk entries support add, update, list within the parent assessment.
- RPN computation per DEC-19-08: RPN MUST be computed by the deterministic formula `severity × likelihood × detectability` server-side at every entry create / update; AI MUST NOT compute the final RPN value.

#### Risk Mitigation Lifecycle

- Mitigation entity per DEC-19-09: `id`, `tenant_id`, `risk_entry_id`, `mitigation_description`, `mitigation_type` (`design_change` / `procedural_control` / `training_control` / `engineering_control` / `administrative_control` / `monitoring_control`), `assigned_user_id`, `due_date`, `status` (`open` / `in_progress` / `completed` / `cancelled`), `control_adequacy` (`adequate` / `partially_adequate` / `inadequate`; reviewer-signed), `closure_evidence_document_id` (FK URS-12 nullable), `created_by`, `created_at`, `closed_at` (nullable), `closed_by_user_id` (nullable). Mitigations support add, update, list within the parent assessment.
- Post-mitigation re-score entity per DEC-19-10: `id`, `tenant_id`, `risk_entry_id`, `mitigation_id`, `post_severity`, `post_likelihood`, `post_detectability`, `post_rpn` (deterministic), `post_risk_level` (deterministic), `re_scored_by_user_id`, `re_scored_at`. Re-scores MUST be created when mitigations close; the residual risk is reported on the assessment.

#### Approval and Bound E-Signature

- Approval gate per DEC-19-11: assessment approval requires `risk-assessments:approve` permission, `withAuthority(...)` Authority Profile resolution, and Controlled Approval Modal e-signature. SoD-19-01 enforced: the approver MUST NOT be the creator. Approval transitions the assessment to `approved`; persists `approved_e_sig_id`, `approved_by_user_id`, `approved_at` on the header. Approval MUST NOT be executed via the generic update route; a dedicated approval route with the controls above is required.
- Bound e-signature persistence per DEC-19-13: the approval transition MUST capture an e-signature payload via the URS-04 Controlled Approval Modal and persist `approved_e_sig_id` on the assessment header. The closure transition MUST persist `closed_e_sig_id`.

#### Final-State Immutability

- Post-approval / post-closure immutability per DEC-19-15: once an assessment reaches `approved` or `closed` (the IMMUTABLE_STATUSES set), the assessment header, risk entries, and mitigations become immutable. Any mutation attempt MUST return `RISK_ASSESSMENT_IMMUTABLE_FINAL_STATE` with the 21 CFR Part 11 §11.10(e) message. This guard applies via `assertRiskAssessmentMutable(...)` on every mutation route across the assessment-header, risk-entry, and mitigation services.

#### Closure

- Risk assessment closure per DEC-19-16: closure requires the assessment to be `approved`, all open mitigations in terminal status (`completed` or `cancelled`), residual risk re-scored to `acceptable` per matrix (or `partially_adequate` controls accepted with documented rationale signed by `final_quality_approver`), and a closure-rationale captured. Closure is e-signed by the closure authority (`final_quality_approver`); SoD-19-04 enforced (closure authority ≠ creator).

#### Reopen

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

#### Multi-Dimensional Context

- Context model per DEC-19-17: `MODULE_CONTEXT_CONFIG['risk-assessment']` declares `study`, `site`, `product`, `supplier`, `batch` filtering as applicable per scope dimensions captured on the assessment registry record. The persistence layer MUST persist `study_id`, `site_id`, `product_id`, `supplier_id`, `batch_id`, `process_scope` 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-19-18: NO direct LLM / generative AI write to `risk_assessments`, `risk_entries`, or `risk_mitigations`. Static deterministic AI MAY surface "similar prior risk assessments", "historical risk-pattern data by source type", "common mitigation patterns for this risk type", and "suggested severity / likelihood / detectability values from prior assessments" as advisory; advisory output is visibly labelled per ARCH-AI-001 AC-3 and never autonomously writes per AC-4. The final RPN value MUST be computed by the deterministic formula, not by AI. MIRA copilot read-only context for closed assessments is permitted; MIRA write paths are prohibited.

#### Audit Trail

- Audit trail per DEC-19-19: every assessment mutation (create, update, risk-entry add / update / delete, mitigation add / update / close, post-mitigation re-score, status transition, approval, 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, control-adequacy adjudication, and closure-signoff evidence captured at the appropriate lifecycle transition.

#### Deviation RPN Propagation

- RPN propagation per DEC-19-14: when an assessment with `source_type = 'deviation'` reaches `approved`, the service propagates the assessment's `aggregate_rpn` and `aggregate_risk_level` to the source deviation's risk fields per URS-16. SoD-19-05 enforced: the propagation is performed system-side based on the human-signed approval; the propagation event is audited as `RISK_ASSESSMENT_RPN_PROPAGATED_TO_DEVIATION`.

#### CAPA Cascade for High / Critical Risk

- CAPA cascade per DEC-19-20: when an approved assessment carries `aggregate_risk_level = high` or `critical`, the assessment surface MUST present a "Open CAPA from this risk" action and emit a `risk_assessment_high_risk_approved` event consumable by URS-18 CAPA. The cascade is recommended (not mandatory) at launch; tenant policy MAY make it mandatory.

#### Configurable Methodology Catalogue

- Configurable methodology catalogue per DEC-19-21: tenant administrators MAY add tenant-specific methodologies through the `risk_methodology_config` table; platform provides launch defaults (FMEA, HACCP, PHA, HAZOP, Bowtie, What-If, Fault Tree, ICH Q9 framework). Custom methodologies are tracked but at launch only the eight platform-default methodologies are supported in the workflow logic.

### 2.2 Out of scope

- CAPA workflow itself (forward URS-18 CAPA — Module 19 emits the high / critical risk event but does not own CAPA workflow).
- Root-cause analysis methodology (forward URS-17 RCA — Module 19 may reference RCA findings but does not own RCA workflow).
- Risk-matrix change control workflow (URS-13 Change Control governs matrix changes; Module 19 only consumes versioned matrices).
- AI-driven decision-making on risk-score finalisation, approval, mitigation effectiveness, or closure (explicitly prohibited per DEC-19-18; AI suggestion paths are advisory only).

### 2.3 Closed launch decisions

| ID | Decision |
|---|---|
| DEC-19-01 | Risk assessment master registry shape and per-tenant scoping. |
| DEC-19-02 | Lifecycle state machine: `draft → in_progress → completed → approved → closed`. Reopen is a governed transition event from `closed → in_progress` per DEC-19-22 + SoD-19-06; appends a new lifecycle event + new assessment iteration without mutating or erasing prior closed evidence. |
| DEC-19-03 | Server-authoritative race-safe `RISK-{YYYY}-{nnnnnn}` numbering via DB sequence. |
| DEC-19-04 | Source linkage: at least one of nine declared source types required; `source_id` required for non-`proactive_assessment` types; existence validated at application layer for ALL non-`proactive_assessment` source types; cross-tenant source linkage forbidden. |
| DEC-19-05 | Methodology configuration at tenant level: FMEA, HACCP, PHA, HAZOP, Bowtie, What-If, Fault Tree, ICH Q9 framework at launch; tenant-configurable scoring scales. |
| DEC-19-06 | Risk-matrix versioning per methodology with `risk_level_thresholds_jsonb`; matrix changes require URS-13 Change Control. |
| DEC-19-07 | Risk-entry entity model with severity / likelihood / detectability / RPN / risk_level / failure mode / failure effect / failure cause / existing controls. |
| DEC-19-08 | RPN deterministic computation: `severity × likelihood × detectability`; AI MUST NOT compute the final RPN value. |
| DEC-19-09 | Mitigation entity model with assignment, due-date, control-adequacy capture; SoD-19-02 enforced (control-adequacy adjudicator ≠ assigned mitigator). |
| DEC-19-10 | Post-mitigation re-score entity to capture residual risk; re-score required at mitigation closure. |
| DEC-19-11 | Approval gate: `risk-assessments:approve` permission + `withAuthority(...)` Authority Profile resolution + Controlled Approval Modal e-signature; SoD-19-01 enforced; approval MUST NOT be executed via the generic update route. |
| DEC-19-12 | Segregation-of-duties enforcement: SoD-19-01..07 across creator, approver, control-adequacy adjudicator, closure authority, reopen co-signer. |
| DEC-19-13 | E-signature binding payload capture per Controlled Approval Modal contract (URS-04); `approved_e_sig_id` and `closed_e_sig_id` persisted on the assessment header. |
| DEC-19-14 | Deviation RPN propagation when a deviation-source assessment reaches `approved`. |
| DEC-19-15 | Post-approval / post-closure immutability across assessment header, risk entries, and mitigations; IMMUTABLE_STATUSES = {`approved`, `closed`}; `assertRiskAssessmentMutable(...)` guard on every mutation route. |
| DEC-19-16 | Closure requires `approved` state, all mitigations in terminal status, residual risk re-scored to `acceptable` (or partially-adequate accepted with rationale), closure-rationale captured, e-signature by `final_quality_approver`; SoD-19-04 enforced. |
| DEC-19-17 | Multi-dimensional context: persistence layer MUST persist `study_id`, `site_id`, `product_id`, `supplier_id`, `batch_id`, `process_scope` per the registry schema; the typed DB layer and the platform context filter MUST agree on this set. |
| DEC-19-18 | AI architecture binding: NO direct LLM / generative AI write to risk-assessment tables; AI MUST NOT compute final RPN; static deterministic AI advisory only; MIRA read-only context for closed assessments. |
| DEC-19-19 | Audit trail: every mutation emits to URS-06 substrate with reason-for-change discipline after `draft`. |
| DEC-19-20 | CAPA cascade: high / critical risk approval emits `risk_assessment_high_risk_approved` event consumable by URS-18. |
| DEC-19-21 | Configurable methodology catalogue at tenant level; platform default methodologies. |
| DEC-19-22 | Reopen of closed assessment is a governed transition event from `closed → in_progress`; requires `executive_authority` co-sign + reason; appends a new lifecycle event + new assessment iteration; does NOT mutate or erase prior closed evidence. SoD-19-06: executive reopen co-signer ≠ original closure authority. |
| DEC-19-23 | Canonical status-model alignment across backend service, shared DB type, shared domain types, and frontend hooks to the canonical state set defined in DEC-19-02. |

---

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

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

| Role key | Description |
|---|---|
| `viewer` | Read-only access within Module 19. |
| `risk_assessor` | Creates risk assessments; adds risk entries; computes RPN; plans mitigations. |
| `risk_review_committee_member` | Member of the tenant's Risk Review Committee; reviews assessments and signs control-adequacy adjudications. |
| `qa_reviewer` | QA reviewer who approves the assessment (subject to SoD-19-01). |
| `quality_lead` | Module 19 administrative oversight within tenant. |
| `closure_authority` | Authority who signs assessment closure (subject to SoD-19-04). |
| `auditor` | Read access to assessments and assessment audit trail. |
| `admin` | Module 19 tenant-administrative actions (methodology configuration, risk-matrix versioning per URS-13). |
| `platform_admin` | Verixa platform — tenant-scoped Module 19 actions are support / break-glass only with reason, support-ticket reference, electronic signature, `PLATFORM_TENANT_ACCESS_USED` audit emit, and SOC alert; routine tenant assessment administration belongs to tenant `admin` users. |
| `super_admin` | Verixa super-admin — tenant-scoped Module 19 actions are support / break-glass only under the same controls as `platform_admin`. |
| `executive_authority` | Founder / Chairman & MD — co-signs reopen events per DEC-19-22 and critical-risk approval matrix per DEC-19-21. |

### 3.2 Authority Profiles (URS-05)

| Authority Profile | Purpose |
|---|---|
| `risk_assessor_authority` | Risk-assessment creation and risk-entry scoring. |
| `risk_review_authority` | Risk Review Committee member sign-off on control adequacy and mitigation effectiveness. |
| `final_quality_approver` | Risk-assessment approval and closure sign by final quality approver. |
| `closure_authority` | Risk-assessment closure sign per DEC-19-16. |
| `executive_authority` | Founder co-sign for critical-risk approval matrix and reopen per DEC-19-22. |
| `risk_reopen_executive_authority` | Executive authority for reopen (DEC-19-22). |

### 3.3 Permissions (Module 19 owns)

- `risk-assessments:read`
- `risk-assessments:create`
- `risk-assessments:update` (with reason-for-change)
- `risk-assessments:add_risk_entry`
- `risk-assessments:update_risk_entry`
- `risk-assessments:delete_risk_entry` (tombstone-preserved)
- `risk-assessments:add_mitigation`
- `risk-assessments:update_mitigation`
- `risk-assessments:close_mitigation` (with SoD-19-02)
- `risk-assessments:adjudicate_control_adequacy` (with authority + SoD-19-02)
- `risk-assessments:re_score_post_mitigation`
- `risk-assessments:approve` (with authority + SoD-19-01 + bound e-sig)
- `risk-assessments:close` (with authority + bound e-sig + SoD-19-04)
- `risk-assessments:reopen_executive` (executive authority + SoD-19-06)
- `risk-assessments:configure_methodology` (admin)
- `risk-assessments:configure_matrix` (admin + URS-13 Change Control)
- `risk-assessments:read_audit`

### 3.4 Segregation-of-Duties constraints

| ID | Constraint |
|---|---|
| SoD-19-01 | The risk assessment approver MUST NOT be the assessment creator. |
| SoD-19-02 | The control-adequacy adjudicator MUST NOT be the mitigation assigned-to user. |
| SoD-19-03 | The post-mitigation re-scorer MUST NOT be the mitigation assigned-to user. |
| SoD-19-04 | The closure authority MUST NOT be the assessment creator. |
| SoD-19-05 | RPN propagation to source deviation is system-performed based on a human-signed approval; the propagation is audited and not directly user-initiated. |
| SoD-19-06 | The executive-authority reopen co-signer MUST NOT be the original closure authority. |
| SoD-19-07 | Critical-risk approval (where `aggregate_risk_level = critical`) requires `final_quality_approver` + executive authority co-sign; no single user can satisfy two slots. |

### 3.5 Worked SoD examples

**Example 1: Standard FMEA risk assessment from a deviation.** A QA reviewer opens a major deviation `DEV-2026-001234`. They open a risk assessment with `methodology = fmea`, `source_type = deviation`. The risk assessor (different from the QA reviewer per assessment-flow) adds three risk entries with severity / likelihood / detectability scores (e.g., S=8, L=6, D=4 → RPN=192 → derived `high` level). Two mitigations are planned with assigned users and due dates. The Risk Review Committee member adjudicates control adequacy. After mitigation closure, post-mitigation re-score reduces the RPN to 32 → `low`. The QA reviewer (different from the assessment creator per SoD-19-01) approves the assessment with Controlled Approval Modal e-signature; service persists `approved_e_sig_id`. RPN propagation fires: source deviation `DEV-2026-001234` receives the aggregate RPN. The closure authority (different from the creator per SoD-19-04) signs closure with bound e-signature. Assessment `closed`.

**Example 2: Critical-risk approval requires executive authority co-sign (DEC-19-21).** An assessment for a sterile-filtration process change reaches `aggregate_risk_level = critical`. Approval requires `final_quality_approver` + executive authority co-sign per SoD-19-07.

**Example 3: SoD-19-01 enforcement — creator attempts to approve own assessment.** The risk assessor who created `RISK-2026-000456` attempts to approve it. Service rejects with HTTP 403 + `RISK_SOD_VIOLATION_CREATOR_CANNOT_APPROVE`. URS-06 records the attempt.

**Example 4: SoD-19-02 enforcement — mitigation owner attempts to adjudicate own control adequacy.** The mitigation assigned-to user attempts to sign the control-adequacy adjudication. Service rejects with HTTP 403 + `RISK_SOD_VIOLATION_MITIGATION_OWNER_CANNOT_ADJUDICATE_CONTROL`. URS-06 records the attempt.

**Example 5: AI-suggested score requires human qualification (DEC-19-18).** Static deterministic AI surfaces "Similar prior assessments suggest severity = 7" as advisory help. The risk assessor reviews and decides severity = 8 based on additional context. The score is human-attributed; AI suggestion is advisory only and does not autonomously write per ARCH-AI-001 AC-4.

**Example 6: AI prohibition runtime block (DEC-19-18).** A user attempts to invoke "AI-finalize RPN" via an experimental UI surface that would bypass the deterministic computation. Runtime block returns HTTP 403 + `RISK_GENAI_PROHIBITED`. URS-06 records the attempt.

**Example 7: Post-approval mutation attempt blocked (DEC-19-15).** An approved assessment is found to have a typo in the failure-effect description. The assessor attempts a direct edit. Service rejects with HTTP 403 + `RISK_ASSESSMENT_IMMUTABLE_FINAL_STATE`. The proper path: reopen via executive authority co-sign per DEC-19-22, edit, re-approve.

**Example 8: Governed reopen by executive authority (DEC-19-22).** A new regulatory finding shows that a previously approved assessment underestimated likelihood. QA proposes reopen. Executive authority e-signs reopen via `risk_reopen_executive_authority` with documented reason. SoD-19-06 enforced. Assessment transitions `closed → in_progress`. Prior closed evidence preserved; a new assessment iteration appends.

**Example 9: Deviation RPN propagation (DEC-19-14).** When `RISK-2026-000456` (linked to `DEV-2026-001234`) reaches `approved`, the service propagates `aggregate_rpn` and `aggregate_risk_level` to the deviation's risk fields. The propagation event is audited as `RISK_ASSESSMENT_RPN_PROPAGATED_TO_DEVIATION` and bears the human approval attribution (SoD-19-05).

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

| Permission | viewer | risk_assessor | risk_review_committee_member | qa_reviewer | quality_lead | closure_authority | auditor | admin | platform_admin | super_admin |
|---|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|
| `risk-assessments:read` | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | support / break-glass only | support / break-glass only |
| `risk-assessments:create` | ✗ | ✓ | ✓ | ✓ | ✓ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only |
| `risk-assessments:update` (with reason-for-change) | ✗ | ✓ | ✓ | ✓ | ✓ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only |
| `risk-assessments:add_risk_entry` | ✗ | ✓ | ✓ | ✓ | ✓ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only |
| `risk-assessments:update_risk_entry` | ✗ | ✓ | ✓ | ✓ | ✓ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only |
| `risk-assessments:delete_risk_entry` (tombstone-preserved) | ✗ | ✓ | ✓ | ✓ | ✓ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only |
| `risk-assessments:add_mitigation` | ✗ | ✓ | ✓ | ✓ | ✓ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only |
| `risk-assessments:update_mitigation` | ✗ | ✓ | ✓ | ✓ | ✓ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only |
| `risk-assessments:close_mitigation` (with SoD-19-02) | ✗ | ✓ | ✓ | ✓ | ✓ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only |
| `risk-assessments:adjudicate_control_adequacy` (with SoD-19-02) | ✗ | ✗ | ✓ | ✓ | ✓ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only |
| `risk-assessments:re_score_post_mitigation` (with SoD-19-03) | ✗ | ✓ | ✓ | ✓ | ✓ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only |
| `risk-assessments:approve` (with SoD-19-01 + bound e-sig) | ✗ | ✗ | ✗ | ✓ | ✓ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only |
| `risk-assessments:close` (with bound e-sig + SoD-19-04) | ✗ | ✗ | ✗ | ✗ | ✓ | ✓ | ✗ | ✓ | support / break-glass only | support / break-glass only |
| `risk-assessments:reopen_executive` (executive authority + SoD-19-06) | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ (executive authority only) |
| `risk-assessments:configure_methodology` | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only |
| `risk-assessments:configure_matrix` (with URS-13 Change Control) | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only |
| `risk-assessments: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 within their study-grant scope; cannot hold assessment / approval / closure roles.

---

## 4. End-to-End User Journeys

The 28 launch user journeys cover the full risk-assessment lifecycle: create from each source type, methodology selection, risk-entry scoring, mitigation lifecycle, post-mitigation re-score, control-adequacy adjudication, approval (standard and critical-risk), closure, reopen, AI advisory surface, AI prohibition negative paths, deviation RPN propagation, India CDSCO scope, multi-dimensional context, and immutability negative paths.

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

A QA reviewer opens a major deviation `DEV-2026-001234`. They click "Open Risk Assessment". Module 19 service `create(...)` validates the `deviation_id` exists same-tenant (DEC-19-04), captures applicable scope dimensions from the deviation context (DEC-19-17), assigns server-authoritative `RISK-2026-000456` (DEC-19-03), state `draft`, methodology defaults to FMEA (configurable). URS-06 records create.

### J-02 — Create risk assessment from a change-control (URS-13 source)

Change-control coordinator opens a Class 2 change request requiring impact assessment. Module 19 service validates the `change_request_id` exists same-tenant; captures applicable scope; assigns `RISK-2026-000457`. State `draft`.

### J-03 — Create risk assessment from a supplier (URS-11 source)

Supplier-quality lead opens a risk assessment for a new critical supplier qualification. Module 19 validates the `supplier_id` exists same-tenant; captures supplier scope.

### J-04 — Create risk assessment from a study (URS-07 source)

Study lead opens a risk assessment for a new clinical study before activation. Module 19 validates the `study_id` exists same-tenant; captures study scope.

### J-05 — Create risk assessment from a product (URS-10 source)

Product owner opens a risk assessment for a new product launch. Module 19 validates the `product_id` exists same-tenant; captures product scope.

### J-06 — Create risk assessment from a site (URS-09 source)

Site head opens a risk assessment for a new manufacturing facility commissioning. Module 19 validates the `site_id` exists same-tenant; captures site scope.

### J-07 — Create risk assessment from validation (URS-07 / URS-09 source)

Validation lead opens a risk-based validation assessment per FDA CSA. Module 19 validates the validation `source_id` exists same-tenant.

### J-08 — Create risk assessment from regulatory intelligence (URS-27 source)

Regulatory affairs lead opens a risk assessment in response to a new regulatory observation from URS-27. Module 19 validates the regulatory-intelligence `source_id` exists same-tenant.

### J-09 — Create proactive risk assessment (no source)

Quality lead opens a proactive risk assessment for a process under continuous improvement. `source_type = proactive_assessment`; `source_id = null`. Process scope is required.

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

Risk assessor submits an assessment 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-11 — Add risk entries with severity / likelihood / detectability scoring

Risk assessor adds three risk entries via `POST /risk-assessments/:id/entries` with `failure_mode_or_hazard`, `failure_effect`, `failure_cause`, `existing_controls_jsonb`, `severity = 8`, `likelihood = 6`, `detectability = 4`. Service computes `rpn = 192` deterministically (DEC-19-08), derives `risk_level = high` from the matrix. URS-06 records each add.

### J-12 — AI-suggested scoring as advisory only (DEC-19-18)

Static deterministic AI surfaces "Similar prior assessments suggested severity = 7 for this failure mode" as advisory. Risk assessor reviews and decides severity = 8 based on additional context. Score is human-attributed.

### J-13 — Add mitigations

Risk assessor adds two mitigations via `POST /risk-assessments/:id/mitigations` with `mitigation_description`, `mitigation_type`, assigned user, due date. Status `open`. URS-06 records each add.

### J-14 — Mitigation closure with SoD-19-02

Mitigation assignee A completes the mitigation, captures `closure_evidence_document_id` linking to URS-12. The control-adequacy adjudicator (different from the assignee per SoD-19-02) signs `control_adequacy = adequate`. Mitigation transitions to `completed`. URS-06 records the close.

### J-15 — Post-mitigation re-score with SoD-19-03

Re-scorer (different from the mitigation assigned-to user per SoD-19-03) records post-mitigation scores via `POST /risk-assessments/:id/entries/:entryId/post-mitigation-scores` with `post_severity = 4`, `post_likelihood = 4`, `post_detectability = 2`. Service computes `post_rpn = 32`, derives `post_risk_level = low`. URS-06 records the re-score.

### J-16 — Approval with SoD-19-01 and bound e-signature (DEC-19-11 + DEC-19-13)

QA reviewer (different from the assessment creator per SoD-19-01) opens the approval surface, reviews the risk entries + mitigations + re-scores, opens Controlled Approval Modal (URS-04), enters password / meaningOfSignature / reasonForChange, submits. Service validates SoD-19-01, persists `approved_e_sig_id`, `approved_by_user_id`, `approved_at`. Assessment transitions to `approved`. URS-06 emits `RISK_ASSESSMENT_APPROVED` with the e-signature attribution.

### J-17 — Critical-risk approval requires executive authority co-sign (DEC-19-21 / SoD-19-07)

An assessment reaches `aggregate_risk_level = critical`. Approval requires `final_quality_approver` + executive authority co-sign per DEC-19-21. SoD-19-07 enforced (no user can satisfy two slots).

### J-18 — Deviation RPN propagation (DEC-19-14)

When `RISK-2026-000456` (linked to `DEV-2026-001234`) reaches `approved`, the service propagates `aggregate_rpn` and `aggregate_risk_level` to the deviation's risk fields per URS-16. Event `RISK_ASSESSMENT_RPN_PROPAGATED_TO_DEVIATION` audited; SoD-19-05 enforced (system-performed propagation based on human approval).

### J-19 — High / critical risk CAPA cascade (DEC-19-20)

An approved assessment carries `aggregate_risk_level = high`. The assessment surface presents an "Open CAPA from this risk" action. The CAPA owner clicks; URS-18 service consumes the `risk_assessment_high_risk_approved` event payload to seed a new CAPA.

### J-20 — Closure with bound e-signature and SoD-19-04

Closure authority (different from creator per SoD-19-04) signs closure via `POST /risk-assessments/:id/close` with bound e-signature. Service validates assessment is `approved`, all mitigations in terminal status, residual risk re-scored to `acceptable` (or partially-adequate accepted with rationale), closure-rationale captured. Persists `closed_e_sig_id`, `closed_at`, `closed_by_user_id`. Assessment transitions to `closed`. URS-06 emits `RISK_ASSESSMENT_CLOSED`.

### J-21 — Closure blocked by open mitigations

Closure authority attempts to close an assessment with open mitigations. Service rejects with HTTP 409 + `RISK_ASSESSMENT_CLOSURE_BLOCKED_BY_OPEN_MITIGATIONS` listing the open mitigations.

### J-22 — Closure blocked by missing residual re-score

Closure authority attempts to close an assessment without post-mitigation re-scores. Service rejects with HTTP 409 + `RISK_ASSESSMENT_CLOSURE_BLOCKED_BY_MISSING_RESIDUAL_RE_SCORE`.

### J-23 — Post-approval mutation negative path (DEC-19-15)

User attempts to update a risk-entry score on an approved assessment. Service rejects with HTTP 403 + `RISK_ASSESSMENT_IMMUTABLE_FINAL_STATE` and the 21 CFR Part 11 §11.10(e) message. The proper path is reopen via DEC-19-22.

### J-24 — Governed reopen by executive authority (DEC-19-22)

A new regulatory finding shows that a previously approved assessment underestimated likelihood. QA proposes reopen. Executive authority opens the reopen surface, reviews QA rationale, e-signs reopen via `risk_reopen_executive_authority` with documented reason. SoD-19-06 enforced. Assessment transitions `closed → in_progress`. Prior closed evidence preserved; a new assessment iteration appends. URS-06 emits `RISK_ASSESSMENT_REOPENED`.

### J-25 — AI prohibition runtime block (DEC-19-18)

User attempts to invoke "AI-finalize RPN" via an experimental UI surface that would bypass the deterministic computation. Runtime block returns HTTP 403 + `RISK_GENAI_PROHIBITED`. URS-06 records the attempt.

### J-26 — MIRA copilot read-only context (URS-32)

A reviewer opens MIRA copilot from a closed assessment. MIRA reads the assessment context (`risk-assessment → risk_assessments` mapping per URS-32) and answers questions about prior assessments in natural language. MIRA MUST NOT write to any risk-assessment table.

### J-27 — Multi-dimensional context capture (DEC-19-17)

Risk assessor opens an assessment for a process spanning multiple sites. They capture `site_id` for the primary site, `process_scope` for the bounded process. The persistence layer persists `study_id`, `site_id`, `product_id`, `supplier_id`, `batch_id`, `process_scope` per the registry schema.

### J-28 — India CDSCO worked example

A pharma manufacturer in India (CDSCO Form 25 / Form 28 manufacturing licence holder) operates Module 19 for ICH Q9 quality risk management. Module 19 carries methodology selection per process; the assessment 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 risk-assessment records originating from India tenant operation, subject to per-tenant jurisdictional regulatory assessment.

---

## 5. Front-end Module 19

### 5.1 Routes

| Route | Purpose |
|---|---|
| `/risk-assessments` | Module 19 landing — assessment register filtered by tenant + scope dimensions |
| `/risk-assessments/:id` | Assessment detail with tabbed view (overview, risk entries with matrix view, mitigations, post-mitigation re-scores, lifecycle history, audit) |
| `/risk-assessments/new` | Assessment creation surface (with source-type picker + methodology picker) |
| `/risk-assessments/:id/entries` | Risk-entry editor with severity / likelihood / detectability scoring |
| `/risk-assessments/:id/mitigations` | Mitigation editor |
| `/risk-assessments/:id/approve` | Approval surface (Controlled Approval Modal) |
| `/risk-assessments/:id/close` | Closure surface |
| `/risk-assessments/:id/reopen` | Reopen surface (executive authority only) |
| `/risk-assessments/admin/methodology-config` | Tenant methodology configuration admin |
| `/risk-assessments/admin/matrix-versions` | Tenant risk-matrix version admin (with URS-13 Change Control) |

### 5.2 Components

- **RiskAssessmentRegisterTable** — paginated, filterable table of assessments.
- **RiskAssessmentDetailTabs** — tabbed view of an assessment.
- **CreateRiskAssessmentWizard** — multi-step: source-type picker → source-record selection → methodology picker → scope-dimension capture → submit.
- **RiskEntryEditor** — risk-entry add / view / update with severity / likelihood / detectability inputs and deterministic RPN computation surface.
- **RiskMatrixView** — visual matrix of risk entries by RPN / risk level.
- **MitigationEditor** — mitigation add / view / update / close with control-adequacy adjudication.
- **PostMitigationReScorePanel** — post-mitigation re-score capture with residual-risk surface.
- **AIAdvisorySimilarRiskPanel** — visibly-labelled AI advisory similarity surface (per ARCH-AI-001 AC-3); scoring suggestion advisory only.
- **ApprovalModal** — Controlled Approval Modal (URS-04) with SoD-19-01 enforcement.
- **CriticalRiskApprovalMatrix** — multi-sign matrix for critical-risk approval (DEC-19-21 + SoD-19-07).
- **ClosureModal** — closure surface with prerequisite check + bound e-signature.
- **ExecutiveAuthorityReopenModal** — executive-authority-only reopen.
- **RiskAssessmentAuditTrailView** — full assessment audit trail consumed from URS-06.
- **TenantMethodologyConfigPanel** — tenant methodology and matrix-version administration (admin only).

### 5.3 Accessibility

WCAG 2.1 Level AA. Keyboard-navigable. Screen-reader labels for all interactive elements, including the RiskMatrixView (with non-visual fallback for matrix structure per URS-29 if applicable).

---

## 6. Back-end Module 19

### 6.1 Architecture overview

```mermaid
flowchart LR
 ROUTES[risk-assessments.routes.ts] --> SVC[risk-assessments.service.ts]
 SVC --> DB[(risk-assessment tables)]
 SVC --> AUDIT[(URS-06 audit substrate)]
 SVC --> HITL[(URS-04 HITL subsystem entity_type=risk_assessment)]
 SVC --> ESIG[(URS-04 e-signature subsystem)]
 SVC --> EVT_RPN[deviation RPN propagation event]
 EVT_RPN --> M16[URS-16 Deviations]
 SVC --> EVT_HIGH[risk_assessment_high_risk_approved event]
 EVT_HIGH --> M18[URS-18 CAPA]
```

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

### 6.1.1 Risk-assessment lifecycle state machine (full)

```mermaid
stateDiagram-v2
 [*] --> draft : create
 draft --> in_progress : risk_entries_started
 in_progress --> completed : mitigations_planned_and_re_scored
 completed --> approved : approval_signed (DEC-19-11 + SoD-19-01 + bound e-sig)
 approved --> closed : closure_signed (DEC-19-16 + SoD-19-04 + bound e-sig + 4-prerequisite check)
 closed --> in_progress : reopen — governed transition (DEC-19-22 + SoD-19-06; appends new lifecycle event + new assessment iteration; does NOT mutate or erase prior closed evidence)
 closed --> [*] : immutable parent + children DEC-19-15
 note right of in_progress
 SoD-19-01: approver ≠ creator
 SoD-19-02: control-adequacy adjudicator ≠ mitigation owner
 SoD-19-03: post-mitigation re-scorer ≠ mitigation owner
 SoD-19-04: closure authority ≠ creator
 SoD-19-05: RPN propagation system-performed; audited
 SoD-19-06: reopen co-signer ≠ original closure authority
 SoD-19-07: critical-risk matrix — no user can hold two slots
 end note
```

Diagram 6.1-B — Risk-assessment lifecycle state machine including approval gate, executive-authority-cosigned reopen path (DEC-19-22), and post-approval / post-closure parent + child immutability (DEC-19-15).

### 6.2 Data model requirements

| Entity | Purpose | Key fields | Required | Unique | Tenant isolation | Versioning | Retention | Soft-delete | Audit | E-sig link |
|---|---|---|---|---|---|---|---|---|---|---|
| `risk_assessments` | Canonical risk assessment record per DEC-19-01 | `id`, `tenant_id`, `display_id`, `title`, `description`, `methodology`, `source_type`, `source_id` (nullable for proactive), `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), `process_scope`, `assessor_user_id` (nullable), `assigned_to_user_id` (nullable), `risk_matrix_version_id`, `methodology_config_id`, `aggregate_rpn` (computed), `aggregate_risk_level` (computed), `lifecycle_state`, `created_by`, `created_at`, `updated_at`, `approved_at` (nullable), `approved_by_user_id` (nullable), `approved_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`); semantic uniqueness on `(tenant_id, lower(title), source_type, source_id)` warning-only | RLS on `tenant_id` | stateful + append-only audit | retain (long-term) | yes (soft-delete only) | yes | yes |
| `risk_entries` | Per-assessment risk entry per DEC-19-07 | `id`, `tenant_id`, `risk_assessment_id`, `entry_label`, `failure_mode_or_hazard`, `failure_effect`, `failure_cause`, `existing_controls_jsonb`, `severity`, `likelihood`, `detectability`, `rpn` (computed deterministically), `risk_level` (computed), `created_by`, `created_at`, `updated_at`, `removed_at` (nullable; tombstone), `removed_by` (nullable), `removed_reason` (nullable) | core required | unique(`risk_assessment_id`, `entry_label`) | RLS via assessment tenant | stateful with tombstone | retain (long-term) | yes (tombstone-preserved) | yes | not applicable |
| `risk_mitigations` | Per-entry mitigation per DEC-19-09 | `id`, `tenant_id`, `risk_entry_id`, `mitigation_description`, `mitigation_type`, `assigned_user_id`, `due_date`, `status`, `control_adequacy`, `control_adequacy_signed_e_sig_id` (nullable), `control_adequacy_signed_by_user_id` (nullable), `closure_evidence_document_id` (FK URS-12 nullable), `created_by`, `created_at`, `closed_at` (nullable), `closed_by_user_id` (nullable) | core required | unique(`risk_entry_id`, `id`) | RLS via assessment tenant | stateful | retain (long-term) | not applicable | yes | yes |
| `risk_post_mitigation_scores` | Per-entry post-mitigation re-score per DEC-19-10 | `id`, `tenant_id`, `risk_entry_id`, `mitigation_id`, `post_severity`, `post_likelihood`, `post_detectability`, `post_rpn`, `post_risk_level`, `re_scored_by_user_id`, `re_scored_at` | core required | unique(`risk_entry_id`, `mitigation_id`) | RLS via assessment tenant | append-only | retain (long-term) | not applicable | yes | not applicable |
| `risk_methodology_config` | Tenant methodology configuration per DEC-19-05 | `id`, `tenant_id`, `methodology`, `severity_max`, `likelihood_max`, `detectability_max`, `enabled`, `effective_from`, `effective_to` (nullable) | core required | unique(`tenant_id`, `methodology`, `effective_from`) | RLS on `tenant_id` | versioned | retain (long-term) | not applicable | yes | not applicable |
| `risk_matrix_versions` | Tenant risk-matrix version per DEC-19-06 | `id`, `tenant_id`, `methodology`, `version`, `effective_from`, `effective_to` (nullable), `severity_max`, `likelihood_max`, `detectability_max`, `risk_level_thresholds_jsonb`, `change_control_id` (FK URS-13) | core required | unique active(`tenant_id`, `methodology`) | RLS on `tenant_id` | versioned | retain (long-term) | not applicable | yes | yes |
| `risk_assessment_lifecycle_events` | Append-only lifecycle transition log | `id`, `tenant_id`, `risk_assessment_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(`risk_assessment_id`, `id`); unique(`record_hash`) | RLS via assessment tenant | append-only | retain (long-term) | not applicable | yes | yes |
| `risk_assessment_approvals` | Per-approval signature-slot table per DEC-19-11 / DEC-19-21 | `id`, `tenant_id`, `risk_assessment_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(`risk_assessment_id`, `slot_role`, `slot_user_id`) | RLS via assessment tenant | append-only | retain (long-term) | not applicable | yes | yes |

### 6.3 API requirements

| Method | Endpoint | Actor | Request | Response | Permission | Audit | Error codes |
|---|---|---|---|---|---|---|---|
| GET | `/risk-assessments` | tenant-scoped | filters | `RiskAssessment[]` | tenant base role + `audit:read` | `RISK_ASSESSMENT_REGISTER_VIEW_OPENED` once per session | none |
| GET | `/risk-assessments/:id` | tenant-scoped | none | full assessment detail with risk entries + mitigations + re-scores | `risk-assessments:read` | none | `NOT_FOUND` |
| GET | `/risk-assessments/:id/full` | tenant-scoped | none | enhanced detail aggregation (assessment + entries + mitigations + re-scores + matrix view) | `risk-assessments:read` | none | `NOT_FOUND` |
| POST | `/risk-assessments` | risk assessor | source linkage + methodology + scope-dimension fields (electronic-signed) | `201` (state `draft`) | `risk-assessments:create` | `RISK_ASSESSMENT_CREATED` | `SOURCE_RECORD_NOT_FOUND`, `CROSS_TENANT_SOURCE_LINKAGE_FORBIDDEN`, `SCOPE_ANCHOR_REQUIRED`, `SOURCE_LINKAGE_REQUIRED`, `METHODOLOGY_NOT_ENABLED`, validation |
| PATCH | `/risk-assessments/:id` | risk assessor | partial fields (electronic-signed; reason-for-change required after `draft`) | `200` | `risk-assessments:update` | `RISK_ASSESSMENT_UPDATED` | `RISK_ASSESSMENT_IMMUTABLE_FINAL_STATE`, `REASON_FOR_CHANGE_REQUIRED`, validation |
| POST | `/risk-assessments/:id/entries` | risk assessor | risk-entry fields (severity / likelihood / detectability) (electronic-signed) | `201` | `risk-assessments:add_risk_entry` | `RISK_ENTRY_ADDED` (RPN computed deterministically) | `RISK_ASSESSMENT_IMMUTABLE_FINAL_STATE`, `SCORE_OUT_OF_RANGE`, validation |
| PATCH | `/risk-assessments/:id/entries/:entryId` | risk assessor | risk-entry fields (electronic-signed; reason-for-change required) | `200` | `risk-assessments:update_risk_entry` | `RISK_ENTRY_UPDATED` (RPN re-computed deterministically) | `RISK_ASSESSMENT_IMMUTABLE_FINAL_STATE`, `REASON_FOR_CHANGE_REQUIRED`, `SCORE_OUT_OF_RANGE`, validation |
| DELETE | `/risk-assessments/:id/entries/:entryId` | risk assessor | reason (electronic-signed) | `200` (tombstone) | `risk-assessments:delete_risk_entry` | `RISK_ENTRY_REMOVED` | `RISK_ASSESSMENT_IMMUTABLE_FINAL_STATE`, `REMOVAL_REASON_REQUIRED` |
| POST | `/risk-assessments/:id/mitigations` | risk assessor | mitigation fields (electronic-signed) | `201` | `risk-assessments:add_mitigation` | `RISK_MITIGATION_ADDED` | `RISK_ASSESSMENT_IMMUTABLE_FINAL_STATE`, validation |
| PATCH | `/risk-assessments/:id/mitigations/:mitId` | mitigation assignee or risk assessor | mitigation fields (electronic-signed) | `200` | `risk-assessments:update_mitigation` | `RISK_MITIGATION_UPDATED` | `RISK_ASSESSMENT_IMMUTABLE_FINAL_STATE`, validation |
| POST | `/risk-assessments/:id/mitigations/:mitId/close` | risk assessor | closure evidence (electronic-signed) | `200` | `risk-assessments:close_mitigation` | `RISK_MITIGATION_CLOSED` | `RISK_ASSESSMENT_IMMUTABLE_FINAL_STATE`, validation |
| POST | `/risk-assessments/:id/mitigations/:mitId/control-adequacy` | review committee or QA | control-adequacy + bound e-sig | `200` | `risk-assessments:adjudicate_control_adequacy` | `RISK_MITIGATION_CONTROL_ADEQUACY_ADJUDICATED` | `RISK_SOD_VIOLATION_MITIGATION_OWNER_CANNOT_ADJUDICATE_CONTROL`, `BOUND_ESIGNATURE_REQUIRED` |
| POST | `/risk-assessments/:id/entries/:entryId/post-mitigation-scores` | re-scorer (≠ mitigation owner per SoD-19-03) | post-mitigation scores (electronic-signed) | `201` | `risk-assessments:re_score_post_mitigation` | `RISK_POST_MITIGATION_RE_SCORED` (post_rpn computed deterministically) | `RISK_ASSESSMENT_IMMUTABLE_FINAL_STATE`, `RISK_SOD_VIOLATION_RE_SCORER_CANNOT_BE_MITIGATION_OWNER`, `SCORE_OUT_OF_RANGE` |
| POST | `/risk-assessments/:id/approve` | qa_reviewer | reason (electronic-signed + MFA + Controlled Approval Modal + bound e-sig) | `200` | `risk-assessments:approve` | `RISK_ASSESSMENT_APPROVED` (and emits RPN propagation for deviation-source per DEC-19-14 + emits high-risk CAPA event for high/critical per DEC-19-20) | `RISK_SOD_VIOLATION_CREATOR_CANNOT_APPROVE`, `STATE_NOT_COMPLETED`, `MISSING_FOUNDER_COSIGN` (for critical), `BOUND_ESIGNATURE_REQUIRED` |
| POST | `/risk-assessments/:id/close` | closure_authority | reason + bound e-sig + closure-rationale | `200` | `risk-assessments:close` | `RISK_ASSESSMENT_CLOSED` | `STATE_NOT_APPROVED`, `RISK_ASSESSMENT_CLOSURE_BLOCKED_BY_OPEN_MITIGATIONS`, `RISK_ASSESSMENT_CLOSURE_BLOCKED_BY_MISSING_RESIDUAL_RE_SCORE`, `CLOSURE_RATIONALE_REQUIRED`, `RISK_SOD_VIOLATION_CLOSER_CANNOT_BE_CREATOR`, `BOUND_ESIGNATURE_REQUIRED` |
| POST | `/executive/risk-assessments/:id/reopen` | executive authority | reason (electronic-signed + MFA + co-sign) | `200` | `risk-assessments:reopen_executive` | `RISK_ASSESSMENT_REOPENED` | `STATE_NOT_CLOSED`, `RISK_SOD_VIOLATION_REOPEN_COSIGNER_CANNOT_BE_CLOSURE_AUTHORITY` |
| POST | `/admin/risk-assessments/methodology-config` | admin | methodology fields | `201` | `risk-assessments:configure_methodology` | `RISK_METHODOLOGY_CONFIGURED` | validation |
| POST | `/admin/risk-assessments/matrix-versions` | admin | matrix fields + URS-13 change-control id | `201` | `risk-assessments:configure_matrix` | `RISK_MATRIX_VERSION_PUBLISHED` | `URS_13_CHANGE_CONTROL_REQUIRED`, validation |

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

### 6.5 Business rules

- **BR-19-01** — Every risk assessment MUST have one source linkage per DEC-19-04; `source_id` required for non-`proactive_assessment` types.
- **BR-19-02** — Source-record existence MUST be validated at the application layer for ALL non-`proactive_assessment` source types; cross-tenant source linkage forbidden.
- **BR-19-03** — Every assessment MUST have at least one scope anchor (`study_id`, `site_id`, `product_id`, `supplier_id`, `batch_id`, or `process_scope`).
- **BR-19-04** — Lifecycle state machine per DEC-19-02; reopen is governed transition `closed → in_progress` per DEC-19-22 (does NOT mutate or erase prior closed evidence).
- **BR-19-05** — RPN MUST be computed deterministically as `severity × likelihood × detectability` server-side; AI MUST NOT compute final RPN (DEC-19-08).
- **BR-19-06** — Risk level MUST be derived deterministically from RPN against the active risk-matrix version's `risk_level_thresholds_jsonb`.
- **BR-19-07** — Risk-entry removal preserves logical tombstone (no physical delete); evidence integrity preserved.
- **BR-19-08** — Mitigation closure enforces SoD-19-02 (control-adequacy adjudicator ≠ mitigation owner) + bound e-signature on adjudication.
- **BR-19-09** — Post-mitigation re-score enforces SoD-19-03 (re-scorer ≠ mitigation owner); re-score required at mitigation closure.
- **BR-19-10** — Approval enforces SoD-19-01 (approver ≠ creator) + Controlled Approval Modal e-signature; `approved_e_sig_id` persisted; approval NOT executed via generic update route.
- **BR-19-11** — Critical-risk approval requires `final_quality_approver` + executive authority co-sign per DEC-19-21; SoD-19-07 enforced.
- **BR-19-12** — Closure enforces SoD-19-04 + 4-prerequisite check (state `approved`, all mitigations terminal, residual re-score acceptable, closure-rationale captured) + bound e-signature; `closed_e_sig_id` persisted.
- **BR-19-13** — Post-approval / post-closure immutability enforced via `assertRiskAssessmentMutable(...)` on every mutation route across `risk-assessments`, risk-entry, mitigation, and re-score services (DEC-19-15).
- **BR-19-14** — Reopen is a governed transition event from `closed → in_progress` per DEC-19-22 + SoD-19-06; appends new lifecycle event + new assessment iteration; does NOT mutate or erase prior closed evidence.
- **BR-19-15** — Deviation RPN propagation when a deviation-source assessment reaches `approved`; SoD-19-05 (system-performed; audited).
- **BR-19-16** — High / critical risk approval emits `risk_assessment_high_risk_approved` event consumable by URS-18 CAPA per DEC-19-20.
- **BR-19-17** — Every regulated mutation emits to URS-06 substrate with reason-for-change discipline after `draft`.
- **BR-19-18** — Static deterministic AI may surface advisory similarity / signal output; generative AI prohibited in risk-score finalisation, approval, control-adequacy adjudication, and closure decision paths (DEC-19-18).
- **BR-19-19** — MIRA copilot read-only mapping `risk-assessment → risk_assessments` for closed assessments; no MIRA write paths.
- **BR-19-20** — Audit-log writes atomic with originating action per URS-04 BR-04-15.
- **BR-19-21** — Risk-matrix version changes require URS-13 Change Control linkage.
- **BR-19-22** — Canonical status set MUST be aligned across backend service, shared DB type, shared domain types (`risk.ts` and `risk-enhanced.ts`), and frontend hooks per DEC-19-23.

### 6.6 Audit substrate

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

`RISK_ASSESSMENT_CREATED`, `RISK_ASSESSMENT_UPDATED`, `RISK_ENTRY_ADDED`, `RISK_ENTRY_UPDATED`, `RISK_ENTRY_REMOVED`, `RISK_MITIGATION_ADDED`, `RISK_MITIGATION_UPDATED`, `RISK_MITIGATION_CLOSED`, `RISK_MITIGATION_CONTROL_ADEQUACY_ADJUDICATED`, `RISK_POST_MITIGATION_RE_SCORED`, `RISK_ASSESSMENT_APPROVED`, `RISK_ASSESSMENT_CLOSED`, `RISK_ASSESSMENT_REOPENED`, `RISK_ASSESSMENT_RPN_PROPAGATED_TO_DEVIATION`, `RISK_ASSESSMENT_HIGH_RISK_APPROVED` (CAPA cascade event), `RISK_METHODOLOGY_CONFIGURED`, `RISK_MATRIX_VERSION_PUBLISHED`, `RISK_SOD_VIOLATION_CREATOR_CANNOT_APPROVE`, `RISK_SOD_VIOLATION_MITIGATION_OWNER_CANNOT_ADJUDICATE_CONTROL`, `RISK_SOD_VIOLATION_RE_SCORER_CANNOT_BE_MITIGATION_OWNER`, `RISK_SOD_VIOLATION_CLOSER_CANNOT_BE_CREATOR`, `RISK_SOD_VIOLATION_REOPEN_COSIGNER_CANNOT_BE_CLOSURE_AUTHORITY`, `RISK_GENAI_PROHIBITED`, `RISK_ASSESSMENT_IMMUTABLE_FINAL_STATE`, `PLATFORM_TENANT_ACCESS_USED`, `PLATFORM_TENANT_ACCESS_DENIED`, `RISK_ASSESSMENT_REGISTER_VIEW_OPENED`, `RISK_ASSESSMENT_INSPECTION_PREP_EXPORTED`.

The following events are emitted by upstream / downstream modules and consumed (read-only) by Module 19 dashboards: `DEVIATION_INVESTIGATING`, `CHANGE_CONTROL_OPENED`, `SUPPLIER_ONBOARDED`, `STUDY_ACTIVATED`, `PRODUCT_LAUNCHED`, `SITE_QUALIFIED`, `REGULATORY_INTELLIGENCE_OBSERVATION`.

### 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 + internal FDA CSA high-process-risk classification (forward-looking; not enacted predicate rules; binding predicate-rule obligations remain those listed in §14)

| Surface | AI use permitted | Governance |
|---|---|---|
| RPN final value computation | NONE — deterministic formula only | Server-computed `severity × likelihood × detectability`; AI prohibited |
| Risk-score finalisation | NONE — internal Annex 22 prohibition | Manual decision; assessor-signed |
| Risk-assessment approval decision | NONE — internal Annex 22 prohibition | Manual decision; bound e-sig; `final_quality_approver` |
| Mitigation control-adequacy adjudication | NONE — internal Annex 22 prohibition | Manual decision; bound e-sig; reviewer ≠ mitigation owner |
| Risk-assessment closure decision | NONE — internal Annex 22 prohibition | Manual closure; deterministic 4-prerequisite check; bound e-sig |
| AI similar-assessment suggestion (advisory) | YES — static deterministic over closed assessments | ARCH-AI-001 AC-2/3/4/7 |
| AI severity / likelihood / detectability suggestion (advisory) | YES — static deterministic; never autonomous | ARCH-AI-001 AC-2/3/4/7 |
| MIRA copilot read-only retrieval over closed assessments | YES — read-only | URS-32 RAG; mapping `risk-assessment → risk_assessments` |

Internal AI-governance obligations aligned with EU AI Act Annex III high-risk classification and FDA CSA high-process-risk classification (treated as internal forward-looking controls, not enacted predicate rules) 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 + deterministic RPN computation. 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
 M16[URS-16 Deviations] --> M19
 M13[URS-13 Change Control] --> M19
 M11[URS-11 Supplier] --> M19
 M07[URS-07 Study] --> M19
 M10[URS-10 Product] --> M19
 M09[URS-09 Site] --> M19
 M27[URS-27 Reg Intelligence] --> M19
 M19 -. RPN propagation .-> M16
 M19 -. high/critical risk event .-> M18[URS-18 CAPA]
 M19 -. mitigation precipitates change .-> M13
 M19 --> M06[URS-06 Audit substrate]
 M19 --> M30[URS-30 Notifications]
 M22[URS-22 Inspection Mgmt] <-- M19
 M26[URS-26 APQR] <-- M19
 M32[URS-32 MIRA AI] <-- M19 (read-only)
 ANNEX22[Internal Annex 22 control — forward-looking] -.governs.-> M19
 ARCHAI[ARCH-AI-001] -.governs advisory AI.-> M19
 AIAct[Internal EU AI Act Annex III high-risk classification — forward-looking] -.classifies.-> M19
 CSA[Internal FDA CSA high-process-risk classification — forward-looking] -.classifies.-> M19
```

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

### 7.2 Change-Impact Matrix (CIM)

| Asset | Cross-module consumers | Direction | Class |
|---|---|---|---|
| Risk-assessment event vocabulary | URS-22, URS-26, URS-30 | Outbound | Class 3 (add) |
| RPN propagation event | URS-16 | Outbound | Class 1 (rename) / Class 3 (add) |
| High/critical risk CAPA cascade event | URS-18 | Outbound | Class 3 (add) |
| Methodology catalogue and matrix versions | tenant admin (URS-13 Change Control) | Inbound | Class 1 |

---

## 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 risk-score finalisation, risk-assessment approval, mitigation-effectiveness adjudication, and closure decision paths. Static deterministic AI may surface similar prior assessments and historical risk-pattern data as advisory.
- Verixa internally classifies AI-assisted risk scoring as high-risk AI under internal AI governance, aligned with the high-risk classification approach in EU AI Act Annex III and the high-process-risk classification in FDA CSA Final Guidance (September 2025), unless a jurisdiction-specific legal assessment determines otherwise.
- RPN MUST be computed deterministically server-side; AI MUST NOT compute final RPN.
- MIRA copilot read-only mapping `risk-assessment → risk_assessments` for closed assessments (per URS-32). MIRA MUST NOT write to any risk-assessment table.
- AI service errors degrade gracefully: similarity panel hides if the AI service is unavailable; the risk-assessment core workflow proceeds.

---

## 9. Performance / scalability

- Risk-assessment register listing supports filters by `lifecycle_state`, `methodology`, `aggregate_risk_level`, scope dimensions; 95th-percentile response time MUST be ≤ 500 ms for tenants up to 100,000 assessments.
- RPN computation per risk entry returns within ≤ 50 ms.
- Matrix view rendering for assessments up to 200 entries returns within ≤ 300 ms.
- Concurrent assessment mutation by independent assessors MUST not deadlock; row-level locking on the assessment header.

---

## 10. Localisation / i18n

UI strings, lifecycle state labels, methodology labels, risk-level labels, mitigation 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 | risk-assessment create | inline error |
| CROSS_TENANT_SOURCE_LINKAGE_FORBIDDEN | 400 | risk-assessment create | inline error |
| SCOPE_ANCHOR_REQUIRED | 400 | risk-assessment create | inline error |
| SOURCE_LINKAGE_REQUIRED | 400 | risk-assessment create | inline error |
| METHODOLOGY_NOT_ENABLED | 400 | risk-assessment create | inline error |
| SCORE_OUT_OF_RANGE | 400 | risk-entry add / update; post-mitigation re-score | inline error |
| RISK_SOD_VIOLATION_CREATOR_CANNOT_APPROVE | 403 | risk-assessment approve | inline error |
| RISK_SOD_VIOLATION_MITIGATION_OWNER_CANNOT_ADJUDICATE_CONTROL | 403 | mitigation control-adequacy | inline error |
| RISK_SOD_VIOLATION_RE_SCORER_CANNOT_BE_MITIGATION_OWNER | 403 | post-mitigation re-score | inline error |
| RISK_SOD_VIOLATION_CLOSER_CANNOT_BE_CREATOR | 403 | risk-assessment close | inline error |
| RISK_SOD_VIOLATION_REOPEN_COSIGNER_CANNOT_BE_CLOSURE_AUTHORITY | 403 | risk-assessment reopen | inline error |
| RISK_ASSESSMENT_IMMUTABLE_FINAL_STATE | 403 | any mutation post-approval / post-closure | inline error citing 21 CFR Part 11 §11.10(e) |
| REASON_FOR_CHANGE_REQUIRED | 400 | risk-assessment / risk-entry update | inline error |
| REMOVAL_REASON_REQUIRED | 400 | risk-entry remove | inline error |
| BOUND_ESIGNATURE_REQUIRED | 400 | approve / close / control-adequacy | inline error |
| STATE_NOT_DRAFT | 409 | lifecycle endpoints | inline error |
| STATE_NOT_IN_PROGRESS | 409 | lifecycle endpoints | inline error |
| STATE_NOT_COMPLETED | 409 | risk-assessment approve | inline error |
| STATE_NOT_APPROVED | 409 | risk-assessment close | inline error |
| STATE_NOT_CLOSED | 409 | risk-assessment reopen | inline error |
| RISK_ASSESSMENT_CLOSURE_BLOCKED_BY_OPEN_MITIGATIONS | 409 | risk-assessment close | inline error listing open mitigations |
| RISK_ASSESSMENT_CLOSURE_BLOCKED_BY_MISSING_RESIDUAL_RE_SCORE | 409 | risk-assessment close | inline error |
| CLOSURE_RATIONALE_REQUIRED | 400 | risk-assessment close | inline error |
| MISSING_FOUNDER_COSIGN | 401 | risk-assessment approve (critical) | open executive authority co-sign request |
| URS_13_CHANGE_CONTROL_REQUIRED | 400 | matrix version publish | inline error |
| RISK_GENAI_PROHIBITED | 403 | any AI surface that would write to risk-assessment tables OR finalize RPN | 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 assessment with non-existent source | back end | `400 SOURCE_RECORD_NOT_FOUND` | inline error |
| Create assessment without scope anchor | back end | `400 SCOPE_ANCHOR_REQUIRED` | inline error |
| Severity / likelihood / detectability out of range | back end | `400 SCORE_OUT_OF_RANGE` | inline error |
| Creator attempts to approve own assessment | back end | `403 RISK_SOD_VIOLATION_CREATOR_CANNOT_APPROVE` | inline error |
| Mitigation owner attempts to adjudicate own control adequacy | back end | `403 RISK_SOD_VIOLATION_MITIGATION_OWNER_CANNOT_ADJUDICATE_CONTROL` | inline error |
| Mitigation owner attempts post-mitigation re-score | back end | `403 RISK_SOD_VIOLATION_RE_SCORER_CANNOT_BE_MITIGATION_OWNER` | inline error |
| Edit on approved or closed assessment | back end | `403 RISK_ASSESSMENT_IMMUTABLE_FINAL_STATE` | inline error |
| Approve assessment before completion | back end | `409 STATE_NOT_COMPLETED` | inline error |
| Approve without bound e-sig | back end | `400 BOUND_ESIGNATURE_REQUIRED` | inline error |
| Close with open mitigations | back end | `409 RISK_ASSESSMENT_CLOSURE_BLOCKED_BY_OPEN_MITIGATIONS` | inline error |
| Close without residual re-score | back end | `409 RISK_ASSESSMENT_CLOSURE_BLOCKED_BY_MISSING_RESIDUAL_RE_SCORE` | inline error |
| Reopen by original closure authority | back end | `403 RISK_SOD_VIOLATION_REOPEN_COSIGNER_CANNOT_BE_CLOSURE_AUTHORITY` | inline error |
| GenAI invocation in scoring / approval / control-adequacy / closure path | back end runtime block | `403 RISK_GENAI_PROHIBITED` | inline error |
| Matrix publish without URS-13 link | back end | `400 URS_13_CHANGE_CONTROL_REQUIRED` | inline error |

---

## 12. Security and Observability

### 12.1 Security envelope

Tenant isolation via TDAL.withTenant per QS-5; RLS on every assessment-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-19-13; MFA step-up for executive authority co-sign and reopen.

### 12.2 Observability

| Signal | Threshold | Action |
|---|---|---|
| Critical-risk approval rate (high outliers per quarter) | > 95th percentile | Quality oversight surface |
| Reopen rate per assessment | > 1 reopen per assessment | Quality oversight |
| Time from assessment creation to approval (SLA) | > 30 days | Notification to QA Lead |
| `RISK_SOD_VIOLATION_*` events | any single event | high; SOC chat |
| `RISK_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 risk-assessment register | Active assessments by lifecycle state and risk level | QA |
| High / critical risk register | High and critical risk assessments | QA |
| Mitigation overdue list | Open mitigations past `due_date` | QA |
| Reopen audit register | Reopened assessments with executive authority attribution | QA, executive authority |
| Matrix-version history | Risk-matrix versioning per methodology with URS-13 linkage | Admin, QA |
| Cross-tenant indices (platform-admin support / break-glass only) | Aggregate Module 19 events | `platform_admin` (support / break-glass only with reason, support-ticket reference, electronic signature, `PLATFORM_TENANT_ACCESS_USED` audit emit, SOC alert) |

Exports:

- Risk-assessment evidence pack (zipped: full assessment + risk entries + mitigations + post-mitigation re-scores + lifecycle events + URS-06 audit excerpt with hash-chain).

---

## 13. Data integrity (ALCOA+)

| Principle | How met |
|---|---|
| Attributable | Every assessment mutation carries `created_by` / `updated_by` / `signed_by` per QS-2 |
| Legible | UI surfaces the assessment detail with lifecycle history and audit trail |
| Contemporaneous | Server-generated timestamps per QS-3 |
| Original | Tombstone-preserved deletion for risk entries; post-approval / post-closure immutability for header / entries / mitigations per DEC-19-15 |
| Accurate | App-level source-record validation across all declared source types; deterministic RPN computation; SoD enforcement at every approval / closure / reopen; bound e-signature persistence |
| Complete | All assessment mutations audited; RPN propagation event audited; high-risk CAPA cascade event audited |
| Consistent | URS-06 chain integrity; canonical status set aligned across layers per DEC-19-23; matrix versioning per URS-13 |
| Enduring | Long-term retention; chain sealing at tenant offboarding per URS-08 |
| Available | Assessment register surface; auditor read access per URS-22 |

---

## 14. Regulatory Mapping

### 14.1 Predicate-rule applicability matrix

| Regulatory authority | Predicate | Module 19 obligation |
|---|---|---|
| FDA | 21 CFR Part 11 §11.10(a) — System validation | Module 19 must be validated per QS-15, QS-16; URS-19-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-19-13 |
| FDA | FDA CSA Final Guidance (September 2025) | Risk-based testing; high-process-risk AI classification per internal forward-looking control |
| EMA | EU GMP Annex 11 §1 / §4 / §9 / §12 / §16 | Risk-based approach; Module 19 validation, audit, security, incident handling |
| EMA / PIC/S | EU GMP Annex 15 (Qualification and Validation) | Risk-based qualification triggers |
| EMA / PIC/S | EU GMP Chapter 1 §1.4 (Pharmaceutical Quality System) | Risk-management element of PQS |
| ICH | ICH Q9 (Quality Risk Management) | Methodology framework — primary anchor |
| ICH | ICH Q10 (Pharmaceutical QMS) | Risk-management element |
| ICH | ICH E6(R3) — GCP | Clinical risk management |
| ISO | ISO 14971 (Medical-device risk management) | Conditional (medical-device tenants) |
| MHRA | MHRA Data Integrity Guidance (2018) — ALCOA+ | §13 mapping |
| Health Canada | C.02.020 — GMP records | Risk-assessment register and retention |
| GAMP | GAMP 5 Cat 5 — Custom application | Validation per §17 |
| 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) |
| Internal architectural control (forward-looking; not enacted predicate rule) | FDA CSA high-process-risk AI classification | Internal high-process-risk AI governance aligned with FDA CSA approach (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 (risk-management within GMP per ICH Q9 anchor) + Schedule M-III (where distribution-risk scope) + New Drugs and Clinical Trials Rules 2019 (where clinical-trial risk scope) + CDSCO GCP guidance (where clinical / study risk scope) + Medical Devices Rules 2017 (where device / combination-product risk scope) — Applicable per India tenant operation and jurisdictional regulatory assessment | Risk-assessment register, methodology configuration (FMEA / HACCP / PHA / HAZOP / Bowtie / What-If / Fault Tree / ICH Q9), deterministic RPN computation, mitigation lifecycle, approval with reviewer-independent SoD + bound e-sig, closure with executive co-sign for critical risk, reopen audit chain; external jurisdictional legal / RA confirmation required for clause / form applicability per India risk-assessment scope |

---

## 15. URS Requirements Register

### 15.1 Front-end (FE)

| ID | Requirement | Priority |
|---|---|---|
| URS-19-FE-001 | Module 19 landing route at `/risk-assessments` | MUST |
| URS-19-FE-002 | Assessment register table with filters by `lifecycle_state`, `methodology`, `aggregate_risk_level`, scope dimensions | MUST |
| URS-19-FE-003 | Assessment detail tabbed view (overview, risk entries with matrix view, mitigations, post-mitigation re-scores, lifecycle history, audit) | MUST |
| URS-19-FE-004 | Create-assessment wizard with source-type + methodology pickers | MUST |
| URS-19-FE-005 | Risk-entry editor with severity / likelihood / detectability inputs + deterministic RPN surface | MUST |
| URS-19-FE-006 | Risk matrix view (visual matrix of entries by RPN / risk level) | MUST |
| URS-19-FE-007 | Mitigation editor with control-adequacy adjudication surface | MUST |
| URS-19-FE-008 | Post-mitigation re-score panel | MUST |
| URS-19-FE-009 | AI advisory similarity panel with suggested score values (visibly labelled per ARCH-AI-001 AC-3) | MUST |
| URS-19-FE-010 | Approval modal (Controlled Approval Modal — URS-04) with SoD-19-01 enforcement surface | MUST |
| URS-19-FE-011 | Critical-risk approval matrix per DEC-19-21 + SoD-19-07 | MUST |
| URS-19-FE-012 | Closure modal with prerequisite check + bound e-signature | MUST |
| URS-19-FE-013 | Executive authority reopen modal (executive only) | MUST |
| URS-19-FE-014 | Assessment audit trail view consumed from URS-06 | MUST |
| URS-19-FE-015 | Tenant methodology configuration panel (admin only) | MUST |
| URS-19-FE-016 | Risk-matrix version admin (admin only; URS-13 Change Control linkage) | MUST |
| URS-19-FE-017 | Internal Annex 22 GenAI prohibition surface (no AI offered in scoring finalisation / approval / control-adequacy / closure UI) | MUST (negative requirement) |
| URS-19-FE-018 | All Module 19 surfaces meet WCAG 2.1 Level AA | MUST |

### 15.2 Back-end (BE)

| ID | Requirement | Priority |
|---|---|---|
| URS-19-BE-001 | Risk-assessment service `create(...)` validates source linkage for ALL non-`proactive_assessment` source types | MUST |
| URS-19-BE-002 | Cross-tenant source linkage forbidden | MUST |
| URS-19-BE-003 | RPN deterministic computation (`severity × likelihood × detectability`) at every entry create / update | MUST |
| URS-19-BE-004 | Risk-level deterministic derivation against active risk-matrix version's `risk_level_thresholds_jsonb` | MUST |
| URS-19-BE-005 | Risk-entry add / update / tombstone-preserved removal | MUST |
| URS-19-BE-006 | Mitigation add / update / close (with SoD-19-02 on control-adequacy adjudication + bound e-sig) | MUST |
| URS-19-BE-007 | Post-mitigation re-score with SoD-19-03 enforcement | MUST |
| URS-19-BE-008 | Approval enforces SoD-19-01 + Controlled Approval Modal e-signature + `approved_e_sig_id` persistence; NOT executed via generic update route | MUST |
| URS-19-BE-009 | Critical-risk approval matrix per DEC-19-21 with SoD-19-07 | MUST |
| URS-19-BE-010 | Closure enforces SoD-19-04 + 4-prerequisite check + bound e-sig + `closed_e_sig_id` persistence | MUST |
| URS-19-BE-011 | Post-approval / post-closure immutability via `assertRiskAssessmentMutable(...)` on every mutation route across `risk-assessments`, risk-entry, mitigation, and re-score services | MUST |
| URS-19-BE-012 | Reopen as governed transition `closed → in_progress` per DEC-19-22 + SoD-19-06 | MUST |
| URS-19-BE-013 | Audit-log writes atomic with originating action per URS-04 BR-04-15 | MUST |
| URS-19-BE-014 | Reason-for-change captured for every UPDATE after `draft` | MUST |
| URS-19-BE-015 | Multi-dimensional context persistence: `study_id`, `site_id`, `product_id`, `supplier_id`, `batch_id`, `process_scope` per registry schema | MUST |
| URS-19-BE-016 | `assigned_to_user_id` persisted on assessment header | MUST |
| URS-19-BE-017 | Canonical status set aligned across backend service, shared DB type, shared domain types, and frontend hooks per DEC-19-23 | MUST |
| URS-19-BE-018 | Deviation RPN propagation when deviation-source assessment reaches `approved` per DEC-19-14 | MUST |
| URS-19-BE-019 | High / critical risk CAPA cascade event emission per DEC-19-20 | MUST |
| URS-19-BE-020 | Risk-matrix version changes require URS-13 Change Control linkage | MUST |

### 15.3 Data (DATA)

| ID | Requirement | Priority |
|---|---|---|
| URS-19-DATA-001 | `risk_assessments` per DEC-19-01 with required source linkage and scope anchor enforcement | MUST |
| URS-19-DATA-002 | `risk_entries` with severity / likelihood / detectability / RPN / risk_level | MUST |
| URS-19-DATA-003 | `risk_mitigations` typed-DB schema with strong typing (no `db as any` casts) | MUST |
| URS-19-DATA-004 | `risk_post_mitigation_scores` for residual-risk capture | MUST |
| URS-19-DATA-005 | `risk_methodology_config` tenant catalogue | MUST |
| URS-19-DATA-006 | `risk_matrix_versions` versioned with URS-13 Change Control linkage | MUST |
| URS-19-DATA-007 | `risk_assessment_lifecycle_events` append-only with hash chain | MUST |
| URS-19-DATA-008 | `risk_assessment_approvals` per-slot signature table for critical-risk matrix | MUST |
| URS-19-DATA-009 | RLS on every assessment-scoped table per QS-6 | MUST |
| URS-19-DATA-010 | Bound e-signature payload persistence on `approved_e_sig_id` and `closed_e_sig_id` | MUST |

### 15.4 AI / HITL (AI)

| ID | Requirement | Priority |
|---|---|---|
| URS-19-AI-001 | NO LLM / GenAI in risk-score finalisation / approval / control-adequacy / closure decision paths per the internal Annex 22 control | MUST (negative) |
| URS-19-AI-002 | RPN MUST be computed deterministically; AI MUST NOT compute final RPN | MUST (negative) |
| URS-19-AI-003 | Static deterministic AI MAY surface similar prior assessments + suggested scores (advisory only) per ARCH-AI-001 AC-2 | MUST |
| URS-19-AI-004 | Advisory output visibly labelled per ARCH-AI-001 AC-3 | MUST |
| URS-19-AI-005 | Advisory output never autonomously writes to risk-assessment tables per ARCH-AI-001 AC-4 | MUST |
| URS-19-AI-006 | AI service errors degrade gracefully per ARCH-AI-001 AC-7 | MUST |
| URS-19-AI-007 | MIRA copilot read-only mapping `risk-assessment → risk_assessments` for closed assessments (per URS-32); no MIRA write path | MUST |
| URS-19-AI-008 | Internal forward-looking AI governance evidence (EU AI Act Art. 13 transparency principles) | MUST |
| URS-19-AI-009 | Internal forward-looking AI governance evidence (EU AI Act Annex III high-risk classification approach) | MUST |
| URS-19-AI-010 | Internal forward-looking AI governance evidence (FDA CSA high-process-risk AI classification) | MUST |

### 15.5 Audit (AUD)

| ID | Requirement | Priority |
|---|---|---|
| URS-19-AUD-001 | Every Module 19 mutation produces an audit row through URS-06 | MUST |
| URS-19-AUD-002 | Audit-write failure rolls back originating action | MUST |
| URS-19-AUD-003 | RPN propagation event audited as `RISK_ASSESSMENT_RPN_PROPAGATED_TO_DEVIATION` | MUST |
| URS-19-AUD-004 | High-risk CAPA cascade event audited | MUST |
| URS-19-AUD-005 | Bound e-signature evidence captured at approval + closure | MUST |

### 15.6 Validation (VAL)

| ID | Requirement | Status |
|---|---|---|
| URS-19-VAL-001 | Installation Qualification | Pending |
| URS-19-VAL-002 | Operational Qualification | Pending |
| URS-19-VAL-003 | Performance Qualification | Pending |
| URS-19-VAL-004 | RLS enforcement evidence | Pending |
| URS-19-VAL-005 | URS-06 chain integrity evidence | Pending |
| URS-19-VAL-006 | SoD enforcement evidence (SoD-19-01..07) | Pending |
| URS-19-VAL-007 | Post-approval / post-closure immutability evidence (DEC-19-15) | Pending |
| URS-19-VAL-008 | Migration evidence (canonical status alignment across layers per DEC-19-23; `assertRiskAssessmentMutable(...)` extension; bound e-sig persistence; source-record validation across all declared source types; multi-dimensional context persistence; `assigned_to_user_id` persistence; `risk_mitigations` typed-DB alignment; deterministic RPN computation; matrix-version URS-13 linkage; approval-route extraction from generic update path) | Pending |
| URS-19-VAL-009 | Internal forward-looking AI governance evidence (EU GMP Annex 22 Draft 2025 GenAI prohibition control) | Pending |
| URS-19-VAL-010 | ARCH-AI-001 AC-2/3/4/7 advisory AI evidence pack | Pending |
| URS-19-VAL-011 | Internal forward-looking AI governance evidence (EU AI Act Annex III high-risk classification approach) | Pending |
| URS-19-VAL-012 | Internal forward-looking AI governance evidence (EU AI Act Art. 13 transparency principles) | Pending |
| URS-19-VAL-013 | Internal forward-looking AI governance evidence (FDA CSA high-process-risk AI classification) | Pending |
| URS-19-VAL-014 | Critical-risk executive authority co-sign procedural evidence per DEC-19-21 | Pending |
| URS-19-VAL-015 | Reopen executive authority co-sign procedural evidence per DEC-19-22 + SoD-19-06 | Pending |
| URS-19-VAL-016 | Bound e-signature persistence evidence per DEC-19-13 | Pending |
| URS-19-VAL-017 | Source-record validation evidence across all non-proactive source types per DEC-19-04 | Pending |
| URS-19-VAL-018 | Multi-dimensional context persistence evidence per DEC-19-17 | Pending |
| URS-19-VAL-019 | Deterministic RPN computation evidence per DEC-19-08 | Pending |
| URS-19-VAL-020 | Risk-matrix versioning + URS-13 linkage evidence per DEC-19-06 | Pending |
| URS-19-VAL-021 | Deviation RPN propagation evidence per DEC-19-14 | Pending |
| URS-19-VAL-022 | High-risk CAPA cascade event evidence per DEC-19-20 | Pending |

### 15.7 Integration (INT)

| ID | Requirement | Priority |
|---|---|---|
| URS-19-INT-001 | URS-13 Change Control inbound (precipitating change source linkage; matrix-version change control) | MUST |
| URS-19-INT-002 | URS-16 Deviations bidirectional (deviation source linkage inbound; RPN propagation outbound) | MUST |
| URS-19-INT-003 | URS-11 Supplier inbound (supplier source linkage) | MUST |
| URS-19-INT-004 | URS-07 Study inbound (study source linkage; validation source linkage) | MUST |
| URS-19-INT-005 | URS-10 Product inbound (product source linkage) | MUST |
| URS-19-INT-006 | URS-09 Site inbound (site source linkage; validation source linkage) | MUST |
| URS-19-INT-007 | URS-27 Regulatory Intelligence inbound | MUST |
| URS-19-INT-008 | URS-18 CAPA outbound (`risk_assessment_high_risk_approved` event) | MUST |
| URS-19-INT-009 | URS-22 Inspection Mgmt outbound | MUST |
| URS-19-INT-010 | URS-26 APQR outbound | MUST |
| URS-19-INT-011 | URS-30 Notifications outbound | MUST |
| URS-19-INT-012 | URS-32 MIRA AI outbound (read-only mapping `risk-assessment → risk_assessments`) | MUST |
| URS-19-INT-013 | URS-06 audit substrate inbound | MUST |
| URS-19-INT-014 | URS-04 Controlled Approval Modal contract + HITL subsystem + e-signature subsystem | MUST |
| URS-19-INT-015 | URS-05 Authority Profile registry consumer | MUST |
| URS-19-INT-016 | Internal forward-looking AI governance evidence (EU GMP Annex 22 Draft 2025) | MUST |
| URS-19-INT-017 | Internal forward-looking AI governance evidence (EU AI Act Annex III high-risk classification approach) | MUST |
| URS-19-INT-018 | Internal forward-looking AI governance evidence (FDA CSA high-process-risk AI classification) | MUST |

### 15.8 Reports (REP)

| ID | Requirement | Priority |
|---|---|---|
| URS-19-REP-001 | Open risk-assessment register | MUST |
| URS-19-REP-002 | High / critical risk register | MUST |
| URS-19-REP-003 | Mitigation overdue list | MUST |
| URS-19-REP-004 | Reopen audit register with executive authority attribution | MUST |
| URS-19-REP-005 | Matrix-version history | MUST |
| URS-19-REP-006 | Risk-assessment evidence pack export | MUST |

### 15.9 Workflow (WF)

| ID | Requirement | Priority |
|---|---|---|
| URS-19-WF-001 | Risk-assessment lifecycle state machine per DEC-19-02 | MUST |
| URS-19-WF-002 | RPN deterministic computation per DEC-19-08 | MUST |
| URS-19-WF-003 | Mitigation control-adequacy adjudication per SoD-19-02 + bound e-sig | MUST |
| URS-19-WF-004 | Post-mitigation re-score per SoD-19-03 | MUST |
| URS-19-WF-005 | Approval per DEC-19-11 + SoD-19-01 + bound e-sig | MUST |
| URS-19-WF-006 | Critical-risk approval matrix per DEC-19-21 + SoD-19-07 | MUST |
| URS-19-WF-007 | Closure per DEC-19-16 + SoD-19-04 + bound e-sig | MUST |
| URS-19-WF-008 | Reopen as governed transition per DEC-19-22 + SoD-19-06 | MUST |
| URS-19-WF-009 | Deviation RPN propagation per DEC-19-14 | MUST |
| URS-19-WF-010 | High-risk CAPA cascade per DEC-19-20 | MUST |

### 15.10 Functional acceptance (FUN)

| ID | Requirement | Priority |
|---|---|---|
| URS-19-FUN-001 | Risk-assessment create with source linkage validation across all declared source types | MUST |
| URS-19-FUN-002 | Risk-assessment approve with SoD-19-01 enforcement + bound e-sig | MUST |
| URS-19-FUN-003 | Risk-assessment close with 4-prerequisite check + bound e-sig | MUST |
| URS-19-FUN-004 | Risk-assessment reopen by executive authority with SoD-19-06 | MUST |
| URS-19-FUN-005 | Post-approval / post-closure mutation blocked per DEC-19-15 | MUST |
| URS-19-FUN-006 | RPN deterministic computation; AI cannot finalize | MUST |

---

## 16. Test cases and Acceptance criteria

### 16.1 Test cases (TC)

| ID | Test |
|---|---|
| TC-19-01 | Risk-assessment happy path from deviation source → risk entries → mitigations → post-mitigation re-score → approve → close |
| TC-19-02 | Assessment from change-control source happy path |
| TC-19-03 | Assessment from supplier source happy path |
| TC-19-04 | Assessment from study source happy path |
| TC-19-05 | Assessment from product source happy path |
| TC-19-06 | Assessment from site source happy path |
| TC-19-07 | Assessment from validation source happy path |
| TC-19-08 | Assessment from regulatory-intelligence source happy path |
| TC-19-09 | Proactive assessment (no source) happy path |
| TC-19-10 | Create assessment with non-existent source returns `400 SOURCE_RECORD_NOT_FOUND` |
| TC-19-11 | Create assessment cross-tenant source returns `400 CROSS_TENANT_SOURCE_LINKAGE_FORBIDDEN` |
| TC-19-12 | Create assessment without scope anchor returns `400 SCOPE_ANCHOR_REQUIRED` |
| TC-19-13 | Severity / likelihood / detectability out of range returns `400 SCORE_OUT_OF_RANGE` |
| TC-19-14 | RPN deterministic computation: `severity × likelihood × detectability` |
| TC-19-15 | Risk-level derivation against active matrix `risk_level_thresholds_jsonb` |
| TC-19-16 | Creator attempts to approve own assessment returns `403 RISK_SOD_VIOLATION_CREATOR_CANNOT_APPROVE` |
| TC-19-17 | Mitigation owner attempts control-adequacy returns `403 RISK_SOD_VIOLATION_MITIGATION_OWNER_CANNOT_ADJUDICATE_CONTROL` |
| TC-19-18 | Mitigation owner attempts post-mitigation re-score returns `403 RISK_SOD_VIOLATION_RE_SCORER_CANNOT_BE_MITIGATION_OWNER` |
| TC-19-19 | Critical-risk approval requires `final_quality_approver` + executive authority co-sign per DEC-19-21 |
| TC-19-20 | Approve without bound e-sig returns `400 BOUND_ESIGNATURE_REQUIRED` |
| TC-19-21 | Approve via generic update route blocked (must go through approve route) |
| TC-19-22 | Mutation on approved or closed assessment returns `403 RISK_ASSESSMENT_IMMUTABLE_FINAL_STATE` |
| TC-19-23 | Close with open mitigations returns `409 RISK_ASSESSMENT_CLOSURE_BLOCKED_BY_OPEN_MITIGATIONS` |
| TC-19-24 | Close without residual re-score returns `409 RISK_ASSESSMENT_CLOSURE_BLOCKED_BY_MISSING_RESIDUAL_RE_SCORE` |
| TC-19-25 | Reopen by original closure authority returns `403 RISK_SOD_VIOLATION_REOPEN_COSIGNER_CANNOT_BE_CLOSURE_AUTHORITY` |
| TC-19-26 | Reopen by executive authority transitions `closed → in_progress`; appends new lifecycle event; preserves prior closed evidence |
| TC-19-27 | Internal Annex 22 negative test: any GenAI invocation in scoring / approval / control-adequacy / closure path blocked at runtime + lint |
| TC-19-28 | AI cannot finalize RPN: runtime block returns `403 RISK_GENAI_PROHIBITED` |
| TC-19-29 | Risk-entry tombstone preservation on delete |
| TC-19-30 | Multi-dimensional context: `study_id`, `site_id`, `product_id`, `supplier_id`, `batch_id`, `process_scope` persisted per registry schema |
| TC-19-31 | Deviation RPN propagation when deviation-source assessment reaches `approved` |
| TC-19-32 | High-risk CAPA cascade event emission when `aggregate_risk_level = high` or `critical` and assessment approved |
| TC-19-33 | Race-condition test on `display_id` generation under concurrent creates per DEC-19-03 |
| TC-19-34 | Audit-write failure rolls back originating action |
| TC-19-35 | Matrix-version publish without URS-13 linkage returns `400 URS_13_CHANGE_CONTROL_REQUIRED` |
| TC-19-36 | Platform identity outside support envelope returns `403 PLATFORM_TENANT_ACCESS_DENIED`; SOC alert fires |

### 16.2 Acceptance criteria (AC)

| ID | Acceptance criterion |
|---|---|
| AC-19-01 | Every assessment carries one source linkage (with `source_id` for non-proactive types) and at least one scope anchor; existence validated for all non-proactive source types. |
| AC-19-02 | RPN computed deterministically `severity × likelihood × detectability` server-side; AI cannot finalize. |
| AC-19-03 | Risk level derived deterministically against active matrix `risk_level_thresholds_jsonb`. |
| AC-19-04 | SoD-19-01 enforced: approver ≠ creator. |
| AC-19-05 | SoD-19-02 enforced: control-adequacy adjudicator ≠ mitigation owner. |
| AC-19-06 | SoD-19-03 enforced: post-mitigation re-scorer ≠ mitigation owner. |
| AC-19-07 | SoD-19-04 enforced: closure authority ≠ creator. |
| AC-19-08 | SoD-19-06 enforced: executive reopen co-signer ≠ original closure authority. |
| AC-19-09 | Critical-risk approval matrix per DEC-19-21 enforced; SoD-19-07 enforced. |
| AC-19-10 | Bound e-signature persisted on approval (`approved_e_sig_id`) and closure (`closed_e_sig_id`). |
| AC-19-11 | Post-approval / post-closure immutability per DEC-19-15 enforced via `assertRiskAssessmentMutable(...)` on every mutation route. |
| AC-19-12 | Reopen is governed transition per DEC-19-22; appends new assessment iteration without mutating prior closed evidence. |
| AC-19-13 | Internal Annex 22 GenAI prohibition enforced runtime + lint per DEC-19-18. |
| AC-19-14 | Internal forward-looking AI governance evidence (EU AI Act Annex III + FDA CSA high-process-risk classification approach) maintained. |
| AC-19-15 | Internal forward-looking AI governance evidence (EU AI Act Art. 13 transparency principles) maintained for all AI surfaces. |
| AC-19-16 | URS-06 hash-chain integrity preserved on every assessment mutation. |
| AC-19-17 | Deviation RPN propagation on deviation-source approval per DEC-19-14. |
| AC-19-18 | High-risk CAPA cascade event emission per DEC-19-20. |
| AC-19-19 | Matrix-version changes require URS-13 Change Control linkage. |
| AC-19-20 | Canonical status set aligned across backend service, shared DB types, shared domain types, and frontend hooks per DEC-19-23. |
| AC-19-21 | Risk-assessment evidence pack export includes full assessment + risk entries + mitigations + post-mitigation re-scores + lifecycle events + URS-06 audit excerpt with hash-chain. |

---

## 17. Validation evidence pack

### 17.1 Validation gate

URS-19-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 across backend service, shared DB type, shared domain types (`risk.ts` + `risk-enhanced.ts`), and frontend hooks per DEC-19-23.
- `assertRiskAssessmentMutable(...)` extended to risk-entry, mitigation, and re-score mutators per DEC-19-15.
- Source-record validation applied at service layer for ALL non-`proactive_assessment` source types per DEC-19-04.
- Multi-dimensional context persistence aligned: `study_id`, `site_id`, `product_id`, `supplier_id`, `batch_id`, `process_scope` persisted per registry schema.
- `assigned_to_user_id` persisted on assessment header.
- `risk_mitigations` typed-DB contract applied (no `db as any` casts).
- Deterministic RPN computation server-side at every entry create / update per DEC-19-08.
- Approval route extracted from the generic update route per DEC-19-11; bound e-signature persistence on `approved_e_sig_id` and `closed_e_sig_id` per DEC-19-13.
- Risk-matrix version changes require URS-13 Change Control linkage per DEC-19-06.
- Reopen route mounted with executive authority + SoD-19-06 + reason per DEC-19-22.
- Deviation RPN propagation evidence per DEC-19-14.

### 17.2 Validation evidence index

- IQ pack (installation qualification).
- OQ pack (operational qualification per assessment happy path + negative paths).
- PQ pack (performance qualification per §9 thresholds).
- RLS evidence per QS-6.
- URS-06 chain integrity evidence per DEC-19-19.
- SoD enforcement evidence (SoD-19-01..07).
- Post-approval / post-closure immutability evidence.
- Critical-risk executive authority co-sign procedural evidence.
- Reopen executive authority co-sign procedural evidence.
- Bound e-signature persistence evidence.
- Source-record validation evidence across all non-proactive source types.
- Multi-dimensional context persistence evidence.
- Deterministic RPN computation evidence.
- Risk-matrix versioning + URS-13 linkage evidence.
- Deviation RPN propagation evidence.
- High-risk CAPA cascade event 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).
- Internal forward-looking AI governance evidence (FDA CSA high-process-risk AI classification).
- 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 19 inputs)

| ID | Decision |
|---|---|
| DEC-19-01..23 | All Module 19 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 (Controlled Approval Modal + bound e-sig + HITL) | 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 source linkage; validation source linkage; study scope) | URS-07 module URS |
| URS-08 Tenant Management | Inbound (tenant context) | URS-08 module URS |
| URS-09 Site / Facility | Inbound (site source linkage; validation source linkage; site scope) | URS-09 module URS |
| URS-10 Product / SKU | Inbound (product source linkage; product scope) | URS-10 module URS |
| URS-11 Supplier Management | Inbound (supplier source linkage; supplier scope) | URS-11 module URS |
| URS-12 Document Control | Inbound (closure-evidence + affected-document references) | URS-12 module URS |
| URS-13 Change Control | Bidirectional (precipitating change inbound; matrix-version change outbound; mitigation-precipitated change outbound) | URS-13 module URS |
| URS-14 Complaints | Inbound (complaint-precipitated risk source linkage) | URS-14 module URS |
| URS-15 OOS / OOT | Inbound (OOS-precipitated risk source linkage) | URS-15 module URS |
| URS-16 Deviations | Bidirectional (deviation source linkage inbound; RPN propagation outbound) | URS-16 module URS |
| URS-17 RCA | Inbound (RCA reference for root-cause-driven re-assessment) | URS-17 module URS |
| URS-18 CAPA | Outbound (`risk_assessment_high_risk_approved` event consumer) | URS-18 module URS |
| URS-21 Findings | Inbound (finding-source linkage) | URS-21 module URS |
| URS-22 Inspection Mgmt | Bidirectional (audit-observation source inbound; assessment 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-27 Regulatory Intelligence | Inbound (regulatory-intelligence source linkage) | URS-27 module URS |
| URS-30 Notifications | Outbound | URS-30 module URS |
| URS-32 MIRA AI | Outbound (read-only mapping `risk-assessment → risk_assessments`) | 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 |
| FDA CSA (high-process-risk AI classification approach) | Internal forward-looking architectural reference (not enacted predicate rule) | FDA CSA |

---

## 19. Completeness Checklist

| Item | Met |
|---|---|
| Header + mapping + Code Modules Mapped + Architecture Bindings (ARCH-AI-001 + Annex 22 + Annex III high-risk + FDA CSA high-process-risk) | ✓ |
| Glossary, primer, worked examples, regulatory anchors | ✓ |
| Audience and stakeholders | ✓ |
| Roles + Authority Profile catalogue + SoD constraints | ✓ |
| Role-permission matrix (Module 19 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 + FDA CSA architecture reference section | ✓ |
| Cross-module wiring + Change-Impact Matrix per §7 | ✓ |
| AI / Automation / HITL controls (with internal Annex 22 prohibition + deterministic RPN) | ✓ |
| 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-19-VAL-008 (Migration Evidence Gate) and the §17 validation evidence pack are satisfied. **No Module 19 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 + FDA CSA high-process-risk evidence + SoD enforcement + post-approval / post-closure immutability + critical-risk executive co-sign + reopen executive co-sign + bound e-signature persistence + source-record validation across all non-proactive source types + multi-dimensional context persistence + deterministic RPN computation + risk-matrix versioning + URS-13 linkage + deviation RPN propagation + high-risk CAPA cascade event evidence are itemised in §17.
- **Specification ready for compliance review?** Yes — ALCOA+, 21 CFR Part 11, FDA CSA Final Guidance (Sep 2025), EU GMP Annex 11 §1/§4/§9/§12/§16, EU GMP Annex 15, EU GMP Chapter 1 §1.4, MHRA ALCOA+, ICH Q9 / Q10 / E6(R3), ISO 14971, GAMP 5 Cat 5, WHO TRS 996 Annex 5 — all mapped in §14. EU GMP Annex 22 (Draft 2025), EU AI Act Regulation 2024/1689 (Annex III high-risk classification approach + Art. 13 transparency principles), and FDA CSA high-process-risk AI classification 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-19-VAL-008 + §17 evidence complete.

---

## Appendix A — Module 19 End-to-End Composite (Source → Methodology → Risk Entries → Mitigations → Re-Score → Approve → Close → Immutable / Reopen)

```mermaid
flowchart TD
 A[Source: Deviation/Change Control/Supplier/Study/Product/Site/Validation/Reg Intelligence/Proactive] --> B[Create Risk Assessment - draft]
 B --> C[Methodology Selection - FMEA/HACCP/PHA/HAZOP/Bowtie/What-If/Fault Tree/ICH Q9]
 C --> D[Add Risk Entries with Severity/Likelihood/Detectability]
 D --> E[Deterministic RPN Computation]
 E --> F[Risk Level Derived from Tenant Matrix]
 F --> G[Add Mitigations with Assigned Owner + Due Date]
 G --> H[Mitigation Closure - SoD-19-02 control-adequacy adjudication + bound e-sig]
 H --> I[Post-Mitigation Re-Score - SoD-19-03]
 I --> J[Residual Risk Captured]
 J --> K[completed]
 K --> L{Critical Risk Level?}
 L -- yes --> M[final_quality_approver + Executive Authority Co-Sign per DEC-19-21 + SoD-19-07 + bound e-sig]
 L -- no --> N[QA Reviewer Approval - SoD-19-01 + bound e-sig]
 M --> O[approved]
 N --> O
 O -. RPN propagation when deviation-source .-> P[URS-16 Deviation RPN updated per DEC-19-14]
 O -. high/critical risk .-> Q[URS-18 CAPA cascade event per DEC-19-20]
 O --> R[All Mitigations Terminal? Residual Re-Score Acceptable? Closure Rationale?]
 R -- yes --> S[Closure Authority Sign - SoD-19-04 + bound e-sig - closed]
 R -- no --> T[Closure Blocked]
 S --> U[Immutable Parent + Children per DEC-19-15]
 U -. Reopen Path .-> V[Executive Authority Reopen - DEC-19-22 + SoD-19-06]
 V --> W[closed -> in_progress; new assessment iteration appended; prior closed evidence preserved]
 W --> D
 D -. Internal Annex 22 control .-> X[NO GenAI in scoring finalisation / approval / control-adequacy / closure paths per DEC-19-18; AI cannot finalize RPN]
```

Diagram Appendix A — Module 19 End-to-End Composite. Source → assessment create → methodology selection → risk entries with deterministic RPN computation → risk level derivation → mitigations → control-adequacy adjudication with bound e-sig → post-mitigation re-score → residual-risk capture → critical-risk matrix per DEC-19-21 + SoD-19-07 (executive authority co-sign) → standard approval per DEC-19-11 + SoD-19-01 + bound e-sig → deviation RPN propagation per DEC-19-14 + high-risk CAPA cascade event per DEC-19-20 → 4-prerequisite closure check → closure per DEC-19-16 + SoD-19-04 + bound e-sig → immutable parent + children per DEC-19-15 → executive-authority-cosigned reopen path per DEC-19-22 + SoD-19-06. 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 scoring finalisation / approval / control-adequacy / closure decision paths and the module is internally classified high-risk AI under both EU AI Act Annex III and FDA CSA high-process-risk approaches. ARCH-AI-001 governs advisory deterministic AI in similarity / signal surfacing. Binding predicate-rule obligations remain those listed in §14.

— End of Module 19 User Requirements Specification —