# Verixa — User Requirements Specification # Module 20: Reviews | Field | Value | |---|---| | Document ID | VRX-URS-20 | | 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-20-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 `reviews`, expected API mount `/api/v1/reviews/*`, expected child finding ownership through the `findings` module (URS-21 sibling), expected Authority Profile + HITL + e-signature integration through the `authority` and `hitl` subsystems for non-bypassable approval / rejection / close / reopen, expected event-bus emission for `review_created` and `review_status_changed`, expected MIRA context integration through the `MIRA context` mapping. 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**. AI-assisted reviews surfaces (AI review summary, AI finding suggestion, AI compliance-gap highlight, MIRA reviews copilot, MIRA context integration on the review record) 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 review path; review creation, evidence gathering, finding documentation, reviewer e-signature, and review closure shall be executable when AI services are disabled, degraded, or overridden by the reviewer. **AI-generated review content shall be visibly labelled as advisory and shall NOT be written to the review record as a reviewer-attributable conclusion; the reviewer's signature shall authenticate the review conclusion. No AI service shall be the sole path to open, advance, or close a review.** This module binds ARCH-AI-001 AC-1, 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 reviewer-attributable conclusions, review-status-transition disposition, approval, rejection, and closure decision paths. Static deterministic AI may surface similar prior reviews and historical finding patterns; the reviewer's signed conclusion is the system of record. Jurisdiction-specific legal enforceability of Annex 22 and the EU AI Act remains subject to a future jurisdiction-specific legal assessment. | | Regulatory Classification | Critical infrastructure substrate — operates the canonical Reviews register, the review lifecycle state machine (`draft → under_review → pending_approval → approved | rejected → closed`; reopen is a governed transition event from `closed → draft` per DEC-20-22 + SoD-20-06 that appends a new review iteration and does not mutate or erase the prior closed evidence), the review type catalogue (`gxp_review` / `vendor_audit` / `internal_audit` / `csv_review` / `process_review`; tenant-extensible), the multi-dimensional context capture (`study_id`, `site_id`, `product_id`, `supplier_id`, `batch_id`, `project_id`), the child-finding lifecycle linkage to URS-21 with status-gated finding creation, the Authority Profile + HITL + e-signature gates on every status transition, the post-approval / post-closure record immutability across the review header and child findings, the controlled reopen workflow with executive authority co-sign, the MIRA copilot read-only context integration on review records (read-only mapping `review → reviews`), the review-progress controlled progression logic, the per-jurisdictional regulatory expectations under FDA 21 CFR Part 11, EU GMP Annex 11 §16 (incident management) / Annex 11 §4 (validation) / Annex 11 §15 (periodic review), MHRA Data Integrity, ICH Q10 §3.2.5 (management review), and ISO 19011 (audit principles). | | Date of Issue | 2026-05-06 | | Module Owner (Engineering) | Quality / Reviews Squad | | Module Owner (Quality Validation) | CSV / CSA Lead — Reviews | | 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 Reviews module (Module 20). 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 reviews substrate: the canonical Reviews register; the lifecycle state machine (`draft → under_review → pending_approval → approved | rejected → closed` with reopen as a governed transition event from `closed → draft` per executive authority co-sign + reason — DEC-20-22 + SoD-20-06 — that appends a new review iteration without mutating or erasing the prior closed evidence); the review type catalogue (`gxp_review`, `vendor_audit`, `internal_audit`, `csv_review`, `process_review`) at launch with tenant-configurable extension per DEC-20-23; the multi-dimensional context capture (`study_id`, `site_id`, `product_id`, `supplier_id`, `batch_id`, `project_id`) with at least one scope anchor required and aligned with the platform context filter; the child-finding lifecycle linkage to URS-21 Findings with status-gated finding creation (findings creatable only while the parent review is in `draft` or `under_review`); the Authority Profile + HITL + e-signature gates on every status transition (`withAuthority(.)` + Controlled Approval Modal e-signature + HITL decision orchestration; user-role string comparison alone is not sufficient); the bound e-signature persistence on approval and closure (`approved_e_sig_id` and `closed_e_sig_id`); the post-approval / post-closure record immutability across the review header and child findings; the controlled reopen workflow with executive authority co-sign; the MIRA copilot read-only context integration through the `useMiraRecord('review', id)` mapping, with no MIRA write paths; the review-progress controlled progression logic computed from milestone events (not free-form numeric assignment); the controlled `notes` capture on transitions (every transition persists a `notes` payload with `from_state`, `to_state`, `note_text`, signer attribution, and bound e-signature reference); the audit trail coverage with reason-for-change discipline; the canonical-status-model alignment; 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 20 accessible to non-domain engineers, product owners, validation engineers, and quality reviewers. ### 0.3 Cross-references - **URS-01** Authentication, Session & Access Control — identity envelope for every review mutation - **URS-02** RBAC & Permissions — the `reviews:*` permission set - **URS-03** Context Gate & Approval Scope — context-gate enforcement for review scope dimensions - **URS-04** Workflow / HITL / E-Signature / Approval Authority — Controlled Approval Modal contract for review approval / rejection / close / reopen - **URS-05** Authority Profile / Delegation / SoD — Authority Profiles consumed (`reviewer_authority`, `review_approver_authority`, `final_quality_approver`, `executive_authority`) - **URS-06** Audit Trail / Hash Chain / Tamper-Evident — append-only audit substrate - **URS-07** Study Management — study-scope dimension consumed - **URS-08** Tenant Management Lifecycle — tenant context for review records - **URS-09** Site / Facility Management — site-scope dimension consumed - **URS-10** Product / SKU / Drug Master Data — product-scope dimension consumed - **URS-11** Supplier Management — supplier-scope dimension consumed; vendor-audit source linkage - **URS-12** Document Control / SOP — affected-document linkage; closure-evidence document references - **URS-13** Change Control — review-precipitated change linkage where finding requires platform change - **URS-14** Complaints — complaint-precipitated review linkage where periodic review covers complaint trend - **URS-15** OOS / OOT — OOS-precipitated review linkage where periodic review covers OOS trend - **URS-16** Deviations — deviation-precipitated review linkage where periodic review covers deviation trend - **URS-17** RCA — RCA references for root-cause-driven review - **URS-18** CAPA — CAPA outbound where finding requires corrective / preventive action - **URS-21** Findings — child-finding entity ownership (sibling-module) - **URS-22** Inspection Mgmt — audit-observation reviews; inspection-readiness export - **URS-23** Batch Records — batch-scope dimension consumed - **URS-26** APQR — periodic product quality review consumer - **URS-30** Notifications — notification delivery for review lifecycle events - **URS-32** MIRA AI — read-only MIRA copilot context integration on review records - **URS-35** Infrastructure / Backup-Restore — operational continuity ### 0.4 Plain-language primer In a regulated pharmaceutical operation, **review is the regulator's primary periodic assurance discipline**. Whether it is a periodic GxP review, a vendor audit, an internal audit, a CSV review, or a process review, the marketing authorisation holder is obligated by **EU GMP Chapter 1 §1.4 (Pharmaceutical Quality System), EU GMP Annex 11 §15 (Periodic Review), ICH Q10 §3.2.5 (Management Review), MHRA Data Integrity Guidance, and ISO 19011 (audit principles)** to (1) open a controlled review record with a documented scope, (2) gather evidence, (3) document findings (with downstream linkage to URS-21), (4) obtain reviewer-independent approval with bound e-signature, and (5) close the review only after all blocking findings have been disposed. Module 20 is the target specification for this regulated workflow. The most common mistake in regulated review is **closure without finding disposition**. The regulator's tell-tale at inspection is a review marked `closed` with open findings still present in URS-21. Module 20 enforces the pathway: closure requires all child findings to be in terminal status; child findings are creatable only while the parent review is in `draft` or `under_review` (status-gated per DEC-20-08); approval requires reviewer independence (SoD-20-01: approver ≠ creator) and bound e-signature; reopen is a governed transition that appends a new review iteration without erasing the prior closed evidence. The **AI-assistance** dimension is critical. Static deterministic AI may surface "similar prior reviews" or "historical finding patterns by review type" as advisory help. AI-generated content (LLMs / MIRA copilot) is **prohibited** from being written to the review record as a reviewer-attributable conclusion; AI suggestions MAY be displayed as advisory but the reviewer's signature authenticates the review conclusion under the internal Annex 22 Draft 2025 forward-looking AI governance control. MIRA copilot is read-only context for closed reviews via the `useMiraRecord('review', id)` mapping; no AI service writes to `reviews` or `review_findings` tables. 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-20-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 | |---|---| | Review | A controlled record of a structured periodic or event-driven examination of a regulated process, system, vendor, or product, including evidence gathering, finding documentation, and reviewer-signed approval. | | Review type | The launch-supported category of review: `gxp_review` / `vendor_audit` / `internal_audit` / `csv_review` / `process_review`. Tenant-extensible. | | Finding | A documented observation arising from the review, owned by URS-21 Findings (sibling module); linked to the parent review via `review_id`. | | Status-gated finding creation | The DEC-20-08 control that findings MAY be created only while the parent review is in `draft` or `under_review`. | | Reviewer | The user who conducts the review and signs the review conclusion. | | Approver | The user who approves the review (subject to SoD-20-01: approver ≠ creator). | | Closure authority | The user who signs the review closure (subject to SoD-20-04). | | Notes | The narrative justification captured at every status transition; persisted and audited. | | Progress | The reviewer's controlled progression indicator (0.100%); not free-form numeric assignment but driven by review milestone events. | | MIRA context | The read-only context mapping `review → reviews` exposed to MIRA copilot for closed reviews. | | Reopen | A governed transition event from `closed → draft` requiring executive authority co-sign and documented reason; appends a new review iteration without mutating prior closed evidence. | | Reviewer independence | The Segregation-of-Duties enforcement that the review approver MUST NOT be the review creator (SoD-20-01). | | 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 reviewer-attributable conclusions, status-transition disposition, approval, rejection, and closure. Binding predicate-rule obligations remain those listed in §14. | | MIRA | The platform's read-only AI copilot service; for Module 20 MIRA is read-only context on review records via the `useMiraRecord('review', id)` mapping. | ### 0.7 Module-20 architectural picture ```mermaid flowchart TD U[Reviewer / Approver / Closure Authority] --> RV[/Reviews register/] RV --> F[Child findings via URS-21] RV --> NOTES[Transition notes captured + audited] RV --> PROG[Controlled progression] RV --> APPROVE[Approval HITL + Authority Profile + bound e-sign + SoD-20-01] APPROVE --> CLOSE[Closure HITL + bound e-sign + SoD-20-04] CLOSE -. governed reopen + executive co-sign.-> RV M22[URS-22 Inspection Mgmt] --> RV M11[URS-11 Vendor Audit Source] --> RV M07[URS-07 Study Periodic Review] --> RV M10[URS-10 Product Periodic Review] --> RV M14[URS-14 Complaint Trend] --> RV M15[URS-15 OOS Trend] --> RV M16[URS-16 Deviation Trend] --> RV RV -. finding to action.-> M21[URS-21 Findings] M21 -. finding to CAPA.-> M18[URS-18 CAPA] M30[URS-30 Notifications] <-- RV M32[URS-32 MIRA AI] <-- RV (read-only context) M26[URS-26 APQR] <-- RV ARCHAI[ARCH-AI-001] -.governs advisory AI.-> RV ANNEX22[Internal Annex 22 control — forward-looking; not enacted predicate rule] -.governs.-> APPROVE ANNEX22 -.governs.-> CLOSE ANNEX22 -.governs.-> NOTES ``` Diagram 0.7-A — Module 20 architectural picture. The target `reviews` code module is the expected owner of the review register, lifecycle, type catalogue, multi-dimensional context, child-finding linkage to URS-21, transition notes capture, controlled progression, Authority Profile + HITL + e-signature gates on every status transition, MIRA context integration, 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 reviewer-attributable conclusions, approval, rejection, and closure decision paths. 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 RV[(reviews)] --> FN[(findings via URS-21 review_id FK)] RV --> LCE[(review_lifecycle_events)] RV --> APPR[(review_approvals)] RV --> NOTES[(review_transition_notes)] RV --> PROG[(review_progress_events)] ``` Diagram 0.8-A — Module 20 entity-relationship overview. The target `reviews` code module is the expected owner of 5 tables (review header, lifecycle events, approvals signature-slot, transition notes, progress events); child findings are owned by URS-21 with FK 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 20 — Reviews. 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_20_specification` change-class tag. --- ## 2. Scope ### 2.1 In scope #### Reviews Registry - The Reviews master registry per DEC-20-01: per-tenant registry with `id`, `tenant_id`, `display_id` (server-authoritative `REV-{YYYY}-{nnnnnn}` per DEC-20-03), `title`, `description`, `type` (`gxp_review` / `vendor_audit` / `internal_audit` / `csv_review` / `process_review`), `gxp_class` (where applicable), `study_id` (FK URS-07 nullable), `site_id` (FK URS-09 nullable), `product_id` (FK URS-10 nullable; persisted on the registry header with strong typing), `supplier_id` (FK URS-11 nullable), `batch_id` (FK URS-23 nullable), `project_id` (nullable), `assignee_id` (the primary reviewer), `due_date`, `status` (`draft` / `under_review` / `pending_approval` / `approved` / `rejected` / `closed`), `progress` (integer 0.100; controlled progression), `created_by`, `created_at`, `updated_at`, `approved_at` (nullable), `approved_by_user_id` (nullable), `approved_e_sig_id` (nullable), `rejected_at` (nullable), `rejected_by_user_id` (nullable), `rejected_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 scope anchor** (`study_id`, `site_id`, `product_id`, `supplier_id`, `batch_id`, or `project_id`) is required. - Server-authoritative race-safe review number per DEC-20-03 via DB sequence. #### Review Lifecycle - Lifecycle state machine per DEC-20-02: `draft → under_review → pending_approval → approved | rejected → closed`; reopen is a governed transition event from `closed → draft` per DEC-20-22 + SoD-20-06 that appends a new review iteration and a new lifecycle event without mutating or erasing the prior closed evidence. **Reopen MUST NOT erase the prior closed evidence.** A `rejected` review may transition back to `draft` once the rejection rationale has been addressed (controlled re-loop per DEC-20-02; SoD-20-05 enforced — re-loop initiator MUST capture a remediation rationale). - Each transition is electronically signed; all transitions log dual-write to `review_lifecycle_events` + URS-06 substrate. - Canonical-status alignment per DEC-20-23: the canonical state set (`draft`, `under_review`, `pending_approval`, `approved`, `rejected`, `closed`) MUST be aligned across `packages/backend/src/modules/reviews/workflow.ts`, `packages/backend/src/modules/reviews/service.ts`, `packages/shared/src/types/db.ts`, and `packages/frontend/src/api/hooks/useReviews.ts`. #### Authority + HITL + E-Signature on Status Transitions - Authority gate per DEC-20-04: every status transition MUST go through `withAuthority(.)` Authority Profile resolution and the Controlled Approval Modal e-signature contract (URS-04). User-role string comparison alone is not sufficient. SoD-20-01 enforced at approval (approver ≠ creator). - HITL decision orchestration per DEC-20-05: every approval / rejection / closure / reopen transition MUST create a HITL decision record in the URS-04 platform `hitl` subsystem with `entity_type = 'review'`, `entity_id = review_id`, decision-type appropriate to the transition. - Bound e-signature persistence per DEC-20-13: approval persists `approved_e_sig_id` and `approved_by_user_id`; rejection persists `rejected_e_sig_id` and `rejected_by_user_id`; closure persists `closed_e_sig_id` and `closed_by_user_id`. #### Transition Notes Capture - Transition notes capture per DEC-20-06: every status transition MUST persist a `notes` payload in `review_transition_notes` with `from_state`, `to_state`, `note_text`, `note_signed_by_user_id`, `note_signed_at`, `note_signed_e_sig_id`. Accepting `notes` in the transition body without persisting or auditing them is not sufficient; transition notes MUST be persisted and audited. #### Controlled Progression - Controlled progression per DEC-20-07: `progress` is computed from review milestone events (e.g., evidence-uploaded, finding-added, finding-disposed, reviewer-section-completed) rather than free-form numeric assignment. Tenant administrators MAY configure milestone weights through the methodology-config surface; platform defaults set evenly weighted milestones per review type. #### Status-Gated Child-Finding Creation - Child-finding creation per DEC-20-08: findings (URS-21) MAY be created against a parent review only while the parent review is in `draft` or `under_review`. Attempts to create findings on a review in `pending_approval`, `approved`, `rejected`, or `closed` state MUST return `FINDING_CREATION_BLOCKED_BY_REVIEW_STATE`. Findings already attached to the review remain accessible to URS-21's normal lifecycle. #### Multi-Dimensional Context - Context model per DEC-20-09: `MODULE_CONTEXT_CONFIG['review']` declares `study`, `site`, `product`, `supplier`, `batch`, `project` filtering as applicable per scope dimensions captured on the registry record. The persistence layer MUST persist `study_id`, `site_id`, `product_id`, `supplier_id`, `batch_id`, `project_id` per the registry schema; the typed DB layer and the platform context filter MUST agree on this set. #### Type Catalogue - Review type catalogue per DEC-20-10: `gxp_review` / `vendor_audit` / `internal_audit` / `csv_review` / `process_review` at launch. Tenant administrators MAY configure tenant-specific review types through `review_type_config`; custom types are tracked but at launch only the five platform-default types drive the workflow logic. #### Final-State Immutability - Post-approval / post-closure immutability per DEC-20-15: once a review reaches `approved` or `closed` (the IMMUTABLE_STATUSES set), the review header and child findings (insofar as they are linked to this parent review) become immutable from review-side mutations. Any mutation attempt MUST return `REVIEW_IMMUTABLE_FINAL_STATE` with the 21 CFR Part 11 §11.10(e) message. This guard applies via `assertReviewMutable(.)` on every mutation route. #### Closure - Review closure per DEC-20-16: closure requires the review to be in `approved` state, all child findings (URS-21) in terminal status (`closed` / `voided` per URS-21 lifecycle), and a closure-rationale captured. Closure is e-signed by the closure authority (`final_quality_approver`); SoD-20-04 enforced (closure authority ≠ creator). #### Reopen - Reopen per DEC-20-22: reopen is a governed transition event from `closed → draft`; requires `executive_authority` co-sign + documented reason; appends a new lifecycle event and a new review iteration; **does NOT mutate or erase the prior closed evidence**. SoD-20-06 enforced: the executive-authority reopen co-signer cannot be the original closure authority. #### MIRA Context Integration - MIRA context integration per DEC-20-18: the read-only `useMiraRecord('review', id)` mapping is the canonical MIRA integration for review records. MIRA reads the review context (`review → reviews` mapping) and answers questions in natural language. **MIRA MUST NOT write to `reviews` or `review_*` tables.** AI-generated content surfaced in the UI is visibly labelled as advisory and is NOT auto-saved to the review record. #### Audit Trail - Audit trail per DEC-20-19: every review mutation (create, update, status transition with notes, approval, rejection, closure, reopen, soft delete) 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`. HITL decision linkage and bound-signature evidence captured at the appropriate lifecycle transition. ### 2.2 Out of scope - Finding lifecycle itself (forward URS-21 Findings — Module 20 governs the parent review and the status-gated creation rule, but URS-21 owns finding lifecycle, disposition, and CAPA cascade). - CAPA workflow (forward URS-18 CAPA — Module 21 emits the CAPA cascade event downstream from a finding; Module 20 only governs the parent review). - Standalone audit programme management at the multi-review level (forward URS-22 Inspection Mgmt at launch hosts the inspection-programme view for audit observations; tenant programme calendars are out of scope at launch). - AI-generated reviewer-attributable conclusions (explicitly prohibited per DEC-20-18). ### 2.3 Closed launch decisions | ID | Decision | |---|---| | DEC-20-01 | Reviews master registry shape and per-tenant scoping. | | DEC-20-02 | Lifecycle state machine: `draft → under_review → pending_approval → approved | rejected → closed`. Reopen is a governed transition event from `closed → draft` per DEC-20-22 + SoD-20-06; appends a new lifecycle event + new review iteration without mutating or erasing prior closed evidence. A `rejected` review may transition back to `draft` once rejection rationale has been addressed (SoD-20-05 enforced). | | DEC-20-03 | Server-authoritative race-safe `REV-{YYYY}-{nnnnnn}` numbering via DB sequence. | | DEC-20-04 | Authority gate: every status transition goes through `withAuthority(.)` + Controlled Approval Modal e-signature; user-role string comparison alone is not sufficient. SoD-20-01 enforced at approval. | | DEC-20-05 | HITL decision orchestration through URS-04 `hitl` subsystem with `entity_type = 'review'` for every approval / rejection / closure / reopen transition. | | DEC-20-06 | Transition notes capture: every transition persists `notes` payload (`from_state`, `to_state`, `note_text`, `note_signed_by`, `note_signed_at`, `note_signed_e_sig_id`);. | | DEC-20-07 | Controlled progression: `progress` is computed from review milestone events; tenant-configurable milestone weights;. | | DEC-20-08 | Status-gated child-finding creation: findings (URS-21) creatable only while parent review is in `draft` or `under_review`;. | | DEC-20-09 | Multi-dimensional context: persistence layer MUST persist `study_id`, `site_id`, `product_id`, `supplier_id`, `batch_id`, `project_id` per the registry schema (resolves audit REV-REQ-001 typed-DB alignment for `product_id` and REV-REQ-009 context-filter conflict). | | DEC-20-10 | Review type catalogue: `gxp_review` / `vendor_audit` / `internal_audit` / `csv_review` / `process_review` at launch; tenant-extensible. | | DEC-20-11 | Reviewer / approver / closure authority gating through RBAC + Authority Profile + HITL non-bypassable workflow. | | DEC-20-12 | Segregation-of-duties enforcement: SoD-20-01.07 across creator, approver, closure authority, reopen co-signer, rejection re-loop initiator, finding-creation gating, critical-review matrix. | | DEC-20-13 | Bound e-signature payload capture per Controlled Approval Modal contract (URS-04); `approved_e_sig_id`, `rejected_e_sig_id`, and `closed_e_sig_id` persisted on the review header. | | DEC-20-14 | Audit trail: every mutation emits to URS-06 substrate with reason-for-change discipline; HITL decision linkage and bound-signature evidence captured at appropriate lifecycle transitions. | | DEC-20-15 | Post-approval / post-closure immutability across review header and child-finding linkage; IMMUTABLE_STATUSES = {`approved`, `closed`}; `assertReviewMutable(.)` guard on every mutation route. | | DEC-20-16 | Review closure requires `approved` state, all child findings in terminal status (per URS-21 lifecycle), closure-rationale captured, e-signature by `final_quality_approver`; SoD-20-04 enforced. | | DEC-20-17 | Multi-dimensional context capture supports periodic-review of complaints / OOS / deviations (URS-14 / URS-15 / URS-16) by carrying source-trend references; trend evidence is read-only inbound. | | DEC-20-18 | AI architecture binding: MIRA copilot read-only context integration via `useMiraRecord('review', id)` mapping; AI-generated content visibly labelled as advisory and NOT written to `reviews` or `review_*` tables; reviewer's signature authenticates the conclusion. | | DEC-20-19 | Audit trail: every mutation emits to URS-06 substrate with reason-for-change discipline. | | DEC-20-20 | Critical-review matrix: where review type is `vendor_audit` for a critical supplier (per URS-11) or `internal_audit` of a high-risk site (per URS-09), approval requires `final_quality_approver` + executive authority co-sign per SoD-20-07. | | DEC-20-21 | Reopen of closed review is a governed transition event from `closed → draft`; requires `executive_authority` co-sign + reason; appends a new lifecycle event + new review iteration; does NOT mutate or erase prior closed evidence. SoD-20-06: executive reopen co-signer ≠ original closure authority. | | DEC-20-22 | (Reserved for cross-reference compatibility — duplicate of DEC-20-21 in adjacent linkage tables.) | | DEC-20-23 | Canonical status-model alignment across backend service, shared DB type, and frontend hooks. | --- ## 3. Roles, Authority Profiles, Segregation of Duties ### 3.1 Roles consumed (URS-02 catalogue) | Role key | Description | |---|---| | `viewer` | Read-only access within Module 20. | | `reviewer` | Conducts the review; gathers evidence; documents findings (delegates to URS-21 finding creation). | | `senior_reviewer` | Senior reviewer who may close out review sections; signs reviewer-attributable conclusions. | | `qa_approver` | QA approver who signs review approval (subject to SoD-20-01). | | `quality_lead` | Module 20 administrative oversight within tenant. | | `closure_authority` | Authority who signs review closure (subject to SoD-20-04). | | `auditor` | Read access to reviews and review audit trail. | | `admin` | Module 20 tenant-administrative actions (type catalogue configuration, milestone weight configuration). | | `platform_admin` | Verixa platform — tenant-scoped Module 20 actions are support / break-glass only with reason, support-ticket reference, electronic signature, `PLATFORM_TENANT_ACCESS_USED` audit emit, and SOC alert; routine tenant review administration belongs to tenant `admin` users. | | `super_admin` | Verixa super-admin — tenant-scoped Module 20 actions are support / break-glass only under the same controls as `platform_admin`. | | `executive_authority` | Founder / Chairman & MD — co-signs critical-review approvals per DEC-20-20 and reopen events per DEC-20-21. | ### 3.2 Authority Profiles (URS-05) | Authority Profile | Purpose | |---|---| | `reviewer_authority` | Reviewer conduct of review (evidence gathering + finding linkage). | | `senior_reviewer_authority` | Senior reviewer-attributable conclusion sign-off. | | `review_approver_authority` | Review approval sign by QA approver (subject to SoD-20-01). | | `final_quality_approver` | Review approval and closure sign by final quality approver. | | `closure_authority` | Review closure sign per DEC-20-16. | | `executive_authority` | Founder co-sign for critical-review approval per DEC-20-20 and reopen per DEC-20-21. | | `review_reopen_executive_authority` | Executive authority for reopen (DEC-20-21). | ### 3.3 Permissions (Module 20 owns) - `reviews:read` - `reviews:create` - `reviews:update` (with reason-for-change) - `reviews:transition_status` (with authority + Controlled Approval Modal e-sign + notes) - `reviews:approve` (with authority + SoD-20-01 + bound e-sign) - `reviews:reject` (with authority + bound e-sign + rejection-rationale) - `reviews:close` (with authority + bound e-sign + SoD-20-04) - `reviews:reopen_executive` (executive authority + SoD-20-06) - `reviews:configure_type_catalogue` (admin) - `reviews:configure_progression_milestones` (admin) - `reviews:read_audit` ### 3.4 Segregation-of-Duties constraints | ID | Constraint | |---|---| | SoD-20-01 | The review approver MUST NOT be the review creator. | | SoD-20-02 | The senior-reviewer-attributable conclusion sign-off MUST NOT be the sole evidence-gatherer for that review (where evidence-gathering is captured at line-item level). | | SoD-20-03 | The rejection-rationale signer MUST NOT be the original assignee of the review. | | SoD-20-04 | The closure authority MUST NOT be the review creator. | | SoD-20-05 | The rejection re-loop initiator MUST capture a remediation rationale; re-loop returns the review to `draft`. | | SoD-20-06 | The executive-authority reopen co-signer MUST NOT be the original closure authority. | | SoD-20-07 | Critical-review approval matrix: no single user can satisfy two required slots (`final_quality_approver` + executive authority). | ### 3.5 Worked SoD examples **Example 1: Standard internal-audit review.** A senior reviewer creates `REV-2026-000456` (`type = internal_audit`) for a quarterly internal audit of the manufacturing area. Evidence is gathered, three child findings are added via URS-21. Review transitions `draft → under_review`. Findings are dispositioned per URS-21 lifecycle. Review transitions `under_review → pending_approval` with notes captured. The QA approver (different from the senior reviewer per SoD-20-01) opens the approval surface, opens Controlled Approval Modal (URS-04), enters password / meaningOfSignature / reasonForChange, submits. Service validates `withAuthority(.)`, validates SoD-20-01, persists `approved_e_sig_id`. Review transitions `pending_approval → approved`. Closure authority (different from creator per SoD-20-04) signs closure with bound e-signature; closure validates all findings in terminal status. Review `closed`. **Example 2: Critical vendor-audit approval requires executive authority co-sign (DEC-20-20).** A vendor audit of a critical API supplier (per URS-11 `criticality = critical`) reaches `pending_approval`. Approval requires `final_quality_approver` + executive authority co-sign per DEC-20-20. SoD-20-07 enforced (no user can satisfy two slots). **Example 3: SoD-20-01 enforcement — creator attempts to approve own review.** The senior reviewer who created `REV-2026-000457` attempts to approve it. Service rejects with HTTP 403 + `REVIEW_SOD_VIOLATION_CREATOR_CANNOT_APPROVE`. URS-06 records the attempt. **Example 4: Status-gated child-finding creation negative path (DEC-20-08).** User attempts to create a child finding on `REV-2026-000458` while it is in `pending_approval`. URS-21 service rejects with HTTP 409 + `FINDING_CREATION_BLOCKED_BY_REVIEW_STATE`. The proper path is to add findings while the review is `draft` or `under_review`. **Example 5: Rejection with re-loop (DEC-20-02 + SoD-20-05).** QA approver rejects `REV-2026-000459` with documented rejection rationale. Service persists `rejected_e_sig_id`, `rejected_at`. Original reviewer addresses the rationale, captures a remediation rationale, and transitions the review `rejected → draft` (SoD-20-05). New evidence gathered; new approval cycle. **Example 6: Post-approval mutation attempt blocked (DEC-20-15).** A user attempts to update the review title on an approved review. Service rejects with HTTP 403 + `REVIEW_IMMUTABLE_FINAL_STATE`. The proper path: reopen via executive authority co-sign per DEC-20-21, update, re-approve. **Example 7: Governed reopen by executive authority (DEC-20-21).** A new audit observation suggests that a previously closed internal-audit review missed a critical control. QA proposes reopen. Executive authority opens the reopen surface, reviews QA rationale, e-signs reopen via `review_reopen_executive_authority` with documented reason. SoD-20-06 enforced. Review transitions `closed → draft`. Prior closed evidence preserved; a new review iteration appends. **Example 8: AI-suggested content as advisory only (DEC-20-18).** MIRA copilot surfaces "Similar prior reviews flagged the following compliance gaps:." as advisory help in a side panel. The reviewer reviews and decides which gaps are applicable; only the reviewer-authored content is written to the review record. AI suggestions are not auto-saved per ARCH-AI-001 AC-4. ### 3.6 Role-permission matrix (Module 20 administrative surface only) | Permission | viewer | reviewer | senior_reviewer | qa_approver | quality_lead | closure_authority | auditor | admin | platform_admin | super_admin | |---|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:| | `reviews:read` | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | support / break-glass only | support / break-glass only | | `reviews:create` | ✗ | ✓ | ✓ | ✓ | ✓ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only | | `reviews:update` (with reason-for-change) | ✗ | ✓ | ✓ | ✓ | ✓ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only | | `reviews:transition_status` (with authority + e-sign + notes) | ✗ | ✓ | ✓ | ✓ | ✓ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only | | `reviews:approve` (with SoD-20-01 + bound e-sign) | ✗ | ✗ | ✗ | ✓ | ✓ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only | | `reviews:reject` (with bound e-sign + rejection-rationale) | ✗ | ✗ | ✗ | ✓ | ✓ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only | | `reviews:close` (with bound e-sign + SoD-20-04) | ✗ | ✗ | ✗ | ✗ | ✓ | ✓ | ✗ | ✓ | support / break-glass only | support / break-glass only | | `reviews:reopen_executive` (executive authority + SoD-20-06) | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ (executive authority only) | | `reviews:configure_type_catalogue` | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only | | `reviews:configure_progression_milestones` | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✓ | support / break-glass only | support / break-glass only | | `reviews: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 reviewer / approval / closure roles. --- ## 4. End-to-End User Journeys The 28 launch user journeys cover the full reviews lifecycle: create per review type, status transitions with notes, controlled progression, child-finding creation, status-gated finding-creation negative paths, approval (standard and critical), rejection with re-loop, closure, reopen, AI advisory MIRA context, AI prohibition negative paths, India CDSCO scope, multi-dimensional context, and immutability negative paths. ### J-01 — Create GxP review A senior reviewer creates `REV-2026-000456` with `type = gxp_review`, `gxp_class = critical`, study scope captured. Module 20 service `create(.)` validates the scope anchor (DEC-20-09), assigns server-authoritative `REV-2026-000456` (DEC-20-03), state `draft`. URS-06 records create. ### J-02 — Create vendor audit review QA reviewer opens a vendor audit `type = vendor_audit` linked to a critical supplier (URS-11). Module 20 captures supplier scope; assigns `REV-2026-000457`. State `draft`. ### J-03 — Create internal audit review Senior auditor opens an internal audit `type = internal_audit` for the manufacturing area; site scope captured. Assigns `REV-2026-000458`. ### J-04 — Create CSV review Validation lead opens a CSV review `type = csv_review` for a recently delivered system change; project scope captured. Assigns `REV-2026-000459`. ### J-05 — Create process review Process owner opens a process review `type = process_review` for a process under continuous improvement; product scope captured. Assigns `REV-2026-000460`. ### J-06 — Create review without scope anchor returns error Reviewer submits a review with no scope dimensions captured. Service rejects with HTTP 400 + `SCOPE_ANCHOR_REQUIRED`. URS-06 records the attempt. ### J-07 — Status transition `draft → under_review` with notes Reviewer transitions the review to `under_review` via `PATCH /reviews/:id/status` with body `{ to_state: "under_review", notes: "Audit team assembled; evidence-gathering plan locked" }`. Service validates `withAuthority(.)`, persists transition + notes (DEC-20-06). URS-06 records the transition. ### J-08 — Create child finding while review is `under_review` Reviewer adds a child finding via URS-21 sibling-module `POST /findings` with `review_id = REV-2026-000456`. URS-21 service validates the parent review state (DEC-20-08) — `under_review` allows finding creation. Finding `FND-2026-000789` created. ### J-09 — Status-gated finding-creation negative path User attempts to create a child finding on a review in `pending_approval` state. URS-21 service rejects with HTTP 409 + `FINDING_CREATION_BLOCKED_BY_REVIEW_STATE`. URS-06 records the rejection. ### J-10 — Controlled progression event Reviewer marks an evidence-gathering milestone complete. Service emits a `review_progress_event` with `milestone_id`, recomputes `progress` per the configured milestone weights (DEC-20-07). UI surfaces the new progress value. ### J-11 — Status transition `under_review → pending_approval` Reviewer transitions the review to `pending_approval` via `PATCH /reviews/:id/status` with notes. Service validates `withAuthority(.)`, validates that all child findings are in non-`open_pending_disposition` states (per URS-21), persists transition + notes. ### J-12 — Approval with SoD-20-01 and bound e-signature (DEC-20-04 + DEC-20-13) QA approver (different from creator per SoD-20-01) opens the approval surface, opens Controlled Approval Modal, enters password / meaningOfSignature / reasonForChange, submits. Service validates SoD-20-01, persists `approved_e_sig_id`, `approved_by_user_id`, `approved_at`. Review transitions `pending_approval → approved`. URS-06 emits `REVIEW_APPROVED`. ### J-13 — Critical-review approval requires executive authority co-sign (DEC-20-20) A vendor-audit review of a critical supplier reaches `pending_approval`. Approval requires `final_quality_approver` + executive authority co-sign per DEC-20-20. SoD-20-07 enforced. ### J-14 — Rejection with rationale (DEC-20-02) QA approver rejects `REV-2026-000459` via `POST /reviews/:id/reject` with documented rejection rationale + bound e-signature. Service persists `rejected_e_sig_id`, `rejected_at`, rejection-rationale. Review transitions `pending_approval → rejected`. URS-06 emits `REVIEW_REJECTED`. ### J-15 — Rejection re-loop (SoD-20-05) Original reviewer addresses the rejection rationale, captures a remediation rationale, transitions the review `rejected → draft` via `PATCH /reviews/:id/status` with `notes` capturing the remediation. URS-06 records the re-loop transition. ### J-16 — Closure with SoD-20-04 (DEC-20-16) Closure authority (different from creator per SoD-20-04) signs closure via `POST /reviews/:id/close` with bound e-signature + closure-rationale. Service validates review is `approved`, all child findings in terminal status (per URS-21), closure-rationale captured. Persists `closed_e_sig_id`, `closed_at`, `closed_by_user_id`. Review transitions to `closed`. URS-06 emits `REVIEW_CLOSED`. ### J-17 — Closure blocked by open child findings Closure authority attempts to close a review with open child findings. Service rejects with HTTP 409 + `REVIEW_CLOSURE_BLOCKED_BY_OPEN_FINDINGS` listing the open findings. URS-06 records the attempt. ### J-18 — Closure without rationale returns error Closure authority attempts to close a review without closure-rationale. Service rejects with HTTP 400 + `CLOSURE_RATIONALE_REQUIRED`. ### J-19 — Post-approval mutation negative path (DEC-20-15) User attempts to update the review title on an approved review. Service rejects with HTTP 403 + `REVIEW_IMMUTABLE_FINAL_STATE` and the 21 CFR Part 11 §11.10(e) message. URS-06 records the attempt. ### J-20 — Governed reopen by executive authority (DEC-20-21) QA proposes reopen of `REV-2026-000459` (closed). Executive authority opens the reopen surface, reviews QA rationale, e-signs reopen via `review_reopen_executive_authority` with documented reason. SoD-20-06 enforced. Review transitions `closed → draft`. The prior closed evidence is preserved; a new review iteration appends. URS-06 emits `REVIEW_REOPENED`. ### J-21 — MIRA copilot read-only context (DEC-20-18 / URS-32) A reviewer opens MIRA copilot from a closed review. MIRA reads the review context (`review → reviews` mapping per `useMiraRecord` hook) and answers questions about prior reviews in natural language. MIRA MUST NOT write to any review table. ### J-22 — AI-suggested content as advisory only (DEC-20-18) MIRA copilot surfaces "Similar prior reviews flagged the following compliance gaps:." as advisory help in a side panel. The reviewer reviews; only reviewer-authored content is written to the review record. ### J-23 — AI prohibition runtime block (DEC-20-18) User attempts to invoke "AI-write reviewer conclusion" via an experimental UI surface that would write to `reviews`. Runtime block returns HTTP 403 + `REVIEW_GENAI_PROHIBITED`. URS-06 records the attempt. ### J-24 — Multi-dimensional context capture (DEC-20-09) Reviewer opens a process review spanning multiple sites. Captures `site_id` for the primary site, `process_scope` description in `description`. The persistence layer persists `study_id`, `site_id`, `product_id`, `supplier_id`, `batch_id`, `project_id` per the registry schema. ### J-25 — Notes capture audit (DEC-20-06) Auditor inspects the audit trail for `REV-2026-000456`. Every status transition shows persisted notes with signing-user attribution, ALCOA+ compliant. URS-21 sibling findings audit trail is also accessible. ### J-26 — Tenant type catalogue extension (DEC-20-10) Tenant administrator opens the type catalogue admin surface, adds a tenant-specific type `regulatory_review`. Service persists the tenant type in `review_type_config`. Workflow logic at launch supports the five platform-default types only; tenant types are tracked but use the GxP-review default workflow. ### J-27 — India CDSCO worked example A pharma manufacturer in India operates Module 20 for periodic GxP reviews per Schedule M. Module 20 carries study / product scope per the 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 review records originating from India tenant operation, subject to per-tenant jurisdictional regulatory assessment. ### J-28 — Platform-identity break-glass A platform support engineer needs to inspect a tenant's review for an inspection-readiness query. They open the platform support / break-glass surface, capture support-ticket reference, electronic signature, reason. Service emits `PLATFORM_TENANT_ACCESS_USED` to URS-06; SOC alert routed; tenant-scoped read access granted under the controlled support / break-glass envelope. --- ## 5. Front-end Module 20 ### 5.1 Routes | Route | Purpose | |---|---| | `/reviews` | Module 20 landing — Reviews register filtered by tenant + scope dimensions | | `/reviews/:id` | Review detail with tabbed view (overview, child findings via URS-21, lifecycle history with notes, audit, MIRA context) | | `/reviews/new` | Review creation surface (with type picker + scope picker) | | `/reviews/:id/transition` | Status transition surface with notes capture | | `/reviews/:id/approve` | Approval surface (Controlled Approval Modal) | | `/reviews/:id/reject` | Rejection surface (Controlled Approval Modal + rationale) | | `/reviews/:id/close` | Closure surface (Controlled Approval Modal + rationale) | | `/reviews/:id/reopen` | Reopen surface (executive authority only) | | `/reviews/admin/type-catalogue` | Tenant type catalogue admin | | `/reviews/admin/progression-milestones` | Tenant progression milestone configuration admin | ### 5.2 Components - **ReviewsRegisterTable** — paginated, filterable table of reviews. - **ReviewDetailTabs** — tabbed view of a review with overview, child findings, lifecycle history with notes, audit, MIRA context. - **CreateReviewWizard** — multi-step: type picker → scope-dimension capture → assignee selection → submit. - **ReviewStatusStepper** — visual stepper showing the lifecycle states with current state highlighted. - **TransitionNotesCaptureForm** — notes capture at every transition (DEC-20-06). - **ChildFindingPanel** — embedded URS-21 finding-create UI; status-gated per DEC-20-08. - **ProgressionDial** — controlled progression indicator driven by milestone events. - **ApprovalModal** — Controlled Approval Modal (URS-04) with SoD-20-01 enforcement. - **CriticalReviewApprovalMatrix** — multi-sign matrix for critical-review approval (DEC-20-20). - **RejectionModal** — Controlled Approval Modal + rejection-rationale capture. - **ClosureModal** — closure surface with prerequisite check + bound e-signature. - **ExecutiveAuthorityReopenModal** — executive-authority-only reopen. - **ReviewAuditTrailView** — full review audit trail consumed from URS-06. - **MIRAReviewContextPanel** — read-only MIRA copilot context integration via `useMiraRecord('review', id)` (DEC-20-18); AI suggestions visibly labelled as advisory. ### 5.3 Accessibility WCAG 2.1 Level AA. Keyboard-navigable. Screen-reader labels for all interactive elements, including the ReviewStatusStepper. --- ## 6. Back-end Module 20 ### 6.1 Architecture overview ```mermaid flowchart LR ROUTES[reviews.routes.ts] --> SVC[reviews.service.ts + workflow.ts] SVC --> DB[(reviews tables)] SVC --> AUDIT[(URS-06 audit substrate)] SVC --> HITL[(URS-04 HITL subsystem entity_type=review)] SVC --> ESIG[(URS-04 e-signature subsystem)] SVC --> EVT[event-bus emit review_created / review_status_changed] SVC --> FIND[(URS-21 findings linkage)] SVC --> MIRA[(URS-32 MIRA context read-only)] ``` Diagram 6.1-A — Module 20 architecture overview. The target `reviews` code module is the expected owner of routes, services, workflow validation, DB persistence, event emission, and MIRA context integration; 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; URS-21 owns child findings with FK linkage. ### 6.1.1 Review lifecycle state machine (full) ```mermaid stateDiagram-v2 [*] --> draft : create draft --> under_review : transition_signed (DEC-20-04 + notes) under_review --> pending_approval : transition_signed (DEC-20-04 + notes; child-finding creation locked) pending_approval --> approved : approval_signed (DEC-20-04 + SoD-20-01 + bound e-sig) pending_approval --> rejected : rejection_signed (DEC-20-04 + bound e-sig + rationale) rejected --> draft : re_loop_signed (DEC-20-02 + SoD-20-05 + remediation rationale) approved --> closed : closure_signed (DEC-20-16 + SoD-20-04 + bound e-sig + 3-prerequisite check) closed --> draft : reopen — governed transition (DEC-20-21 + SoD-20-06; appends new lifecycle event + new review iteration; does NOT mutate or erase prior closed evidence) closed --> [*] : immutable parent + linked findings DEC-20-15 note right of under_review SoD-20-01: approver ≠ creator SoD-20-02: senior-reviewer conclusion ≠ sole evidence-gatherer SoD-20-03: rejection-rationale signer ≠ original assignee SoD-20-04: closure authority ≠ creator SoD-20-05: re-loop initiator captures remediation rationale SoD-20-06: reopen co-signer ≠ original closure authority SoD-20-07: critical-review matrix — no user can hold two slots DEC-20-08: child-finding creation gated to draft / under_review only end note ``` Diagram 6.1-B — Review lifecycle state machine including authority-gated transitions, executive-authority-cosigned reopen path (DEC-20-21), rejection re-loop (DEC-20-02), and post-approval / post-closure parent + linked-finding immutability (DEC-20-15). ### 6.2 Data model requirements | Entity | Purpose | Key fields | Required | Unique | Tenant isolation | Versioning | Retention | Soft-delete | Audit | E-sig link | |---|---|---|---|---|---|---|---|---|---|---| | `reviews` | Canonical review record per DEC-20-01 | `id`, `tenant_id`, `display_id`, `title`, `description`, `type`, `gxp_class`, `study_id` (FK URS-07 nullable), `site_id` (FK URS-09 nullable), `product_id` (FK URS-10 nullable; typed-DB alignment), `supplier_id` (FK URS-11 nullable), `batch_id` (FK URS-23 nullable), `project_id` (nullable), `assignee_id`, `due_date`, `status`, `progress`, `created_by`, `created_at`, `updated_at`, `approved_at` (nullable), `approved_by_user_id` (nullable), `approved_e_sig_id` (nullable), `rejected_at` (nullable), `rejected_by_user_id` (nullable), `rejected_e_sig_id` (nullable), `rejection_rationale` (nullable), `closed_at` (nullable), `closed_by_user_id` (nullable), `closed_e_sig_id` (nullable), `closure_rationale` (nullable), `deleted_at` (nullable) | per-state | unique(`tenant_id`, `display_id`) | RLS on `tenant_id` | stateful + append-only audit | retain (long-term) | yes (soft-delete only) | yes | yes | | `review_lifecycle_events` | Append-only lifecycle transition log | `id`, `tenant_id`, `review_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(`review_id`, `id`); unique(`record_hash`) | RLS via review tenant | append-only | retain (long-term) | not applicable | yes | yes | | `review_approvals` | Per-approval signature-slot table per DEC-20-04 / DEC-20-20 | `id`, `tenant_id`, `review_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(`review_id`, `slot_role`, `slot_user_id`) | RLS via review tenant | append-only | retain (long-term) | not applicable | yes | yes | | `review_transition_notes` | Transition notes per DEC-20-06 | `id`, `tenant_id`, `review_id`, `from_state`, `to_state`, `note_text`, `note_signed_by_user_id`, `note_signed_at`, `note_signed_e_sig_id` | core required | unique(`review_id`, `from_state`, `to_state`, `note_signed_at`) | RLS via review tenant | append-only | retain (long-term) | not applicable | yes | yes | | `review_progress_events` | Controlled progression events per DEC-20-07 | `id`, `tenant_id`, `review_id`, `milestone_id`, `milestone_label`, `recorded_by_user_id`, `recorded_at`, `cumulative_progress` | core required | unique(`review_id`, `milestone_id`) | RLS via review tenant | append-only | retain (long-term) | not applicable | yes | not applicable | | `review_type_config` | Tenant type catalogue per DEC-20-10 | `id`, `tenant_id`, `type`, `label`, `is_platform_default`, `effective_from`, `effective_to` (nullable) | core required | unique(`tenant_id`, `type`, `effective_from`) | RLS on `tenant_id` | versioned | retain (long-term) | not applicable | yes | not applicable | ### 6.3 API requirements | Method | Endpoint | Actor | Request | Response | Permission | Audit | Error codes | |---|---|---|---|---|---|---|---| | GET | `/reviews` | tenant-scoped | filters | `Review[]` with child-finding summary count | tenant base role + `audit:read` | `REVIEW_REGISTER_VIEW_OPENED` once per session | none | | GET | `/reviews/:id` | tenant-scoped | none | full review detail with child findings linkage | `reviews:read` | none | `NOT_FOUND` | | POST | `/reviews` | reviewer | type + scope-dimension fields (electronic-signed) | `201` (state `draft`) | `reviews:create` | `REVIEW_CREATED` (and emits `review_created` event) | `SCOPE_ANCHOR_REQUIRED`, `INVALID_TYPE`, validation | | PATCH | `/reviews/:id` | reviewer | partial fields (electronic-signed; reason-for-change required after `draft`) | `200` | `reviews:update` | `REVIEW_UPDATED` | `REVIEW_IMMUTABLE_FINAL_STATE`, `REASON_FOR_CHANGE_REQUIRED`, validation | | PATCH | `/reviews/:id/status` | reviewer / qa_approver / closure_authority | new status + notes (electronic-signed; Controlled Approval Modal e-sign for `approved`, `rejected`, `closed`) | `200` | `reviews:transition_status` | `REVIEW_STATUS_TRANSITIONED` (and emits `review_status_changed` event; persists notes per DEC-20-06) | `STATE_TRANSITION_NOT_ALLOWED`, `NOTES_REQUIRED`, `BOUND_ESIGNATURE_REQUIRED`, validation | | POST | `/reviews/:id/approve` | qa_approver | reason (electronic-signed + MFA + Controlled Approval Modal) | `200` | `reviews:approve` | `REVIEW_APPROVED` | `REVIEW_SOD_VIOLATION_CREATOR_CANNOT_APPROVE`, `STATE_NOT_PENDING_APPROVAL`, `MISSING_FOUNDER_COSIGN` (for critical), `BOUND_ESIGNATURE_REQUIRED` | | POST | `/reviews/:id/reject` | qa_approver | rejection rationale + bound e-sign | `200` | `reviews:reject` | `REVIEW_REJECTED` | `STATE_NOT_PENDING_APPROVAL`, `REJECTION_RATIONALE_REQUIRED`, `BOUND_ESIGNATURE_REQUIRED` | | POST | `/reviews/:id/close` | closure_authority | closure rationale + bound e-sign | `200` | `reviews:close` | `REVIEW_CLOSED` | `STATE_NOT_APPROVED`, `REVIEW_CLOSURE_BLOCKED_BY_OPEN_FINDINGS`, `CLOSURE_RATIONALE_REQUIRED`, `REVIEW_SOD_VIOLATION_CLOSER_CANNOT_BE_CREATOR`, `BOUND_ESIGNATURE_REQUIRED` | | POST | `/executive/reviews/:id/reopen` | executive authority | reason (electronic-signed + MFA + co-sign) | `200` | `reviews:reopen_executive` | `REVIEW_REOPENED` | `STATE_NOT_CLOSED`, `REVIEW_SOD_VIOLATION_REOPEN_COSIGNER_CANNOT_BE_CLOSURE_AUTHORITY` | | DELETE | `/reviews/:id` | quality_lead | reason (electronic-signed) | `200` (soft-delete) | `reviews:update` | `REVIEW_SOFT_DELETED` | `REVIEW_IMMUTABLE_FINAL_STATE` | ### 6.4 Workflow requirements (inline above and in §4 journeys) ### 6.5 Business rules - **BR-20-01** — Every review MUST have at least one scope anchor per DEC-20-09. - **BR-20-02** — Lifecycle state machine per DEC-20-02; reopen is governed transition `closed → draft` per DEC-20-21 (does NOT mutate or erase prior closed evidence). - **BR-20-03** — Every status transition MUST go through `withAuthority(.)` + Controlled Approval Modal e-signature (. - **BR-20-04** — Every status transition MUST persist `notes` payload per DEC-20-06 . - **BR-20-05** — `progress` MUST be computed from review milestone events per DEC-20-07; static `0` assignment is. - **BR-20-06** — Child findings (URS-21) are creatable only while parent review is in `draft` or `under_review` per DEC-20-08. - **BR-20-07** — Approval enforces SoD-20-01 (approver ≠ creator) + Controlled Approval Modal e-signature; HITL decision record created per DEC-20-05. - **BR-20-08** — Critical-review approval requires `final_quality_approver` + executive authority co-sign per DEC-20-20; SoD-20-07 enforced. - **BR-20-09** — Rejection requires bound e-signature + rejection-rationale persisted on the review header. - **BR-20-10** — Rejection re-loop transitions `rejected → draft` per DEC-20-02 + SoD-20-05; remediation rationale captured. - **BR-20-11** — Closure requires `approved` state, all child findings in terminal status (per URS-21 lifecycle), closure-rationale captured, bound e-signature; SoD-20-04 enforced. - **BR-20-12** — Bound e-signature persistence: `approved_e_sig_id`, `rejected_e_sig_id`, `closed_e_sig_id` persisted on the review header. - **BR-20-13** — Post-approval / post-closure immutability enforced via `assertReviewMutable(.)` on every mutation route (DEC-20-15). - **BR-20-14** — Reopen is a governed transition event from `closed → draft` per DEC-20-21 + SoD-20-06; appends new lifecycle event + new review iteration; does NOT mutate or erase prior closed evidence. - **BR-20-15** — Every regulated mutation emits to URS-06 substrate with reason-for-change discipline after `draft` (DEC-20-19). - **BR-20-16** — `review_created` and `review_status_changed` events emitted on respective lifecycle moments; downstream consumers (URS-30 notifications, URS-22 inspection-readiness, URS-26 APQR) consume. - **BR-20-17** — MIRA copilot read-only mapping `review → reviews` per DEC-20-18; no MIRA write paths; AI-generated content visibly labelled as advisory and NOT auto-saved to the review record. - **BR-20-18** — Audit-log writes atomic with originating action per URS-04 BR-04-15. - **BR-20-19** — Canonical status set MUST be aligned across backend service, shared DB type, workflow code, and frontend hooks per DEC-20-23. ### 6.6 Audit substrate Module 20 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): `REVIEW_CREATED`, `REVIEW_UPDATED`, `REVIEW_STATUS_TRANSITIONED`, `REVIEW_APPROVED`, `REVIEW_REJECTED`, `REVIEW_REJECTION_RE_LOOP_INITIATED`, `REVIEW_CLOSED`, `REVIEW_REOPENED`, `REVIEW_SOFT_DELETED`, `REVIEW_PROGRESS_MILESTONE_RECORDED`, `REVIEW_HITL_DECISION_OPENED`, `REVIEW_HITL_DECISION_DECIDED`, `REVIEW_TRANSITION_NOTES_CAPTURED`, `REVIEW_SOD_VIOLATION_CREATOR_CANNOT_APPROVE`, `REVIEW_SOD_VIOLATION_CLOSER_CANNOT_BE_CREATOR`, `REVIEW_SOD_VIOLATION_REOPEN_COSIGNER_CANNOT_BE_CLOSURE_AUTHORITY`, `REVIEW_GENAI_PROHIBITED`, `REVIEW_IMMUTABLE_FINAL_STATE`, `PLATFORM_TENANT_ACCESS_USED`, `PLATFORM_TENANT_ACCESS_DENIED`, `REVIEW_REGISTER_VIEW_OPENED`, `REVIEW_INSPECTION_PREP_EXPORTED`. The following events are emitted by upstream / downstream modules and consumed (read-only) by Module 20: `FINDING_CREATED` (from URS-21; informational only — finding linkage is FK on the URS-21 side), `FINDING_DISPOSED` (from URS-21; informs closure-prerequisite check), `INSPECTION_OBSERVATION_OPENED` (from URS-22 — may precipitate a review). ### 6.7 Architecture binding — Internal Annex 22 GenAI prohibition control + ARCH-AI-001 (AC-1, AC-2, AC-3, AC-4, AC-7) + internal EU AI Act Art. 13 transparency principles (forward-looking; not enacted predicate rule; binding predicate-rule obligations remain those listed in §14) | Surface | AI use permitted | Governance | |---|---|---| | Reviewer-attributable conclusion authoring | NONE — internal Annex 22 prohibition | Manual decision; reviewer-signed system of record | | Status-transition disposition | NONE — internal Annex 22 prohibition | Manual decision; bound e-sig + notes | | Approval decision | NONE — internal Annex 22 prohibition | Manual decision; bound e-sig; `final_quality_approver` | | Rejection decision | NONE — internal Annex 22 prohibition | Manual decision; bound e-sig + rejection-rationale | | Closure decision | NONE — internal Annex 22 prohibition | Manual closure; deterministic 3-prerequisite check; bound e-sig | | AI similar-review suggestion (advisory) | YES — static deterministic over closed reviews | ARCH-AI-001 AC-2/3/4/7 | | AI compliance-gap highlight (advisory) | YES — static deterministic; never autonomous | ARCH-AI-001 AC-2/3/4/7 | | MIRA copilot read-only context on review | YES — read-only via `useMiraRecord('review', id)` | URS-32 RAG; mapping `review → reviews`; advisory visibly labelled per DEC-20-18 | Internal AI-governance obligations aligned with EU AI Act Art. 13 transparency principles (treated as internal forward-looking control, not enacted predicate rule) include AI-specific QMS, transparency labelling, technical documentation, ongoing monitoring, human oversight; supported by ARCH-AI-001 architectural reference + URS-06 audit substrate + Authority-gated workflow + URS-04 HITL non-bypassable orchestration. Jurisdiction-specific legal enforceability remains subject to a future jurisdiction-specific legal assessment. Binding predicate-rule obligations remain those listed in §14. --- ## 7. Cross-Module Wiring and Change-Impact ### 7.1 Cross-module wiring ```mermaid flowchart LR M22[URS-22 Inspection Mgmt] --> M20 M11[URS-11 Vendor Audit Source] --> M20 M07[URS-07 Study Periodic] --> M20 M10[URS-10 Product Periodic] --> M20 M14[URS-14 Complaint Trend] --> M20 M15[URS-15 OOS Trend] --> M20 M16[URS-16 Deviation Trend] --> M20 M20 --> M21[URS-21 Findings] M21 -. finding to CAPA.-> M18[URS-18 CAPA] M20 --> M06[URS-06 Audit substrate] M20 --> M30[URS-30 Notifications] M22 <-- M20 M26[URS-26 APQR] <-- M20 M32[URS-32 MIRA AI] <-- M20 (read-only context) ANNEX22[Internal Annex 22 control — forward-looking] -.governs.-> M20 ARCHAI[ARCH-AI-001] -.governs advisory AI.-> M20 ``` Diagram 7.1-A — Module 20 cross-module wiring. ### 7.2 Change-Impact Matrix (CIM) | Asset | Cross-module consumers | Direction | Class | |---|---|---|---| | Review event vocabulary | URS-22, URS-26, URS-30 | Outbound | Class 3 (add) | | Review type catalogue | tenant admin | Inbound (configurable) | Class 2 | | Review register | URS-21, URS-22, URS-26 | Outbound | Class 2 | | MIRA context mapping | URS-32 | Outbound (read-only) | Class 1 (rename) | --- ## 8. AI / HITL controls - ARCH-AI-001 architectural reference applies. AC-1: AI surfaces optional. 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 reviewer-attributable conclusions, status-transition disposition, approval, rejection, and closure decision paths. Static deterministic AI may surface similar prior reviews and historical finding patterns as advisory. - MIRA copilot read-only mapping `review → reviews` via `useMiraRecord('review', id)` (per URS-32). MIRA MUST NOT write to any review table. AI-generated content visibly labelled as advisory. - AI service errors degrade gracefully: similarity panel hides if the AI service is unavailable; the reviews core workflow proceeds. --- ## 9. Performance / scalability - Reviews register listing supports filters by `status`, `type`, `assignee`, scope dimensions; 95th-percentile response time MUST be ≤ 500 ms for tenants up to 100,000 reviews. - Review detail aggregation (parent review + child findings summary) returns within ≤ 300 ms for reviews up to 100 child findings. - Concurrent review mutation by independent reviewers MUST not deadlock; row-level locking on the review header. --- ## 10. Localisation / i18n UI strings, lifecycle state labels, 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 | |---|---|---|---| | SCOPE_ANCHOR_REQUIRED | 400 | review create | inline error | | INVALID_TYPE | 400 | review create | inline error | | REVIEW_SOD_VIOLATION_CREATOR_CANNOT_APPROVE | 403 | review approve | inline error | | REVIEW_SOD_VIOLATION_CLOSER_CANNOT_BE_CREATOR | 403 | review close | inline error | | REVIEW_SOD_VIOLATION_REOPEN_COSIGNER_CANNOT_BE_CLOSURE_AUTHORITY | 403 | review reopen | inline error | | REVIEW_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 | review update | inline error | | NOTES_REQUIRED | 400 | review status transition | inline error | | BOUND_ESIGNATURE_REQUIRED | 400 | approve / reject / close | inline error | | REJECTION_RATIONALE_REQUIRED | 400 | review reject | inline error | | STATE_TRANSITION_NOT_ALLOWED | 409 | status transition | inline error | | STATE_NOT_DRAFT | 409 | lifecycle endpoints | inline error | | STATE_NOT_UNDER_REVIEW | 409 | lifecycle endpoints | inline error | | STATE_NOT_PENDING_APPROVAL | 409 | review approve / reject | inline error | | STATE_NOT_APPROVED | 409 | review close | inline error | | STATE_NOT_CLOSED | 409 | review reopen | inline error | | FINDING_CREATION_BLOCKED_BY_REVIEW_STATE | 409 | finding create against review (URS-21 surface) | inline error | | REVIEW_CLOSURE_BLOCKED_BY_OPEN_FINDINGS | 409 | review close | inline error listing open findings | | CLOSURE_RATIONALE_REQUIRED | 400 | review close | inline error | | MISSING_FOUNDER_COSIGN | 401 | review approve (critical) | open executive authority co-sign request | | REVIEW_GENAI_PROHIBITED | 403 | any AI surface that would write to review tables | inline error citing internal Annex 22 control | | AUDIT_TRAIL_WRITE_FAILED | 500 | any state-changing action | toast; the originating action did NOT commit | | PLATFORM_TENANT_ACCESS_DENIED | 403 | platform identity outside support envelope | inline error; SOC alert | ### 11.3 Negative-path catalogue | Scenario | Detection | Response | UI behaviour | |---|---|---|---| | Create review without scope anchor | back end | `400 SCOPE_ANCHOR_REQUIRED` | inline error | | Status transition without notes | back end | `400 NOTES_REQUIRED` | inline error | | Status transition by user without authority | back end | `403 PERMISSION_DENIED` (URS-02 envelope) | inline error | | Creator attempts to approve own review | back end | `403 REVIEW_SOD_VIOLATION_CREATOR_CANNOT_APPROVE` | inline error | | Approve without bound e-sig | back end | `400 BOUND_ESIGNATURE_REQUIRED` | inline error | | Create finding on review in `pending_approval` | back end (URS-21) | `409 FINDING_CREATION_BLOCKED_BY_REVIEW_STATE` | inline error | | Edit on approved or closed review | back end | `403 REVIEW_IMMUTABLE_FINAL_STATE` | inline error | | Reject without rationale | back end | `400 REJECTION_RATIONALE_REQUIRED` | inline error | | Close with open findings | back end | `409 REVIEW_CLOSURE_BLOCKED_BY_OPEN_FINDINGS` | inline error | | Close without rationale | back end | `400 CLOSURE_RATIONALE_REQUIRED` | inline error | | Reopen by original closure authority | back end | `403 REVIEW_SOD_VIOLATION_REOPEN_COSIGNER_CANNOT_BE_CLOSURE_AUTHORITY` | inline error | | GenAI invocation in reviewer-conclusion / approval / closure path | back end runtime block | `403 REVIEW_GENAI_PROHIBITED` | inline error | --- ## 12. Security and Observability ### 12.1 Security envelope Tenant isolation via TDAL.withTenant per QS-5; RLS on every review-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-20-13; MFA step-up for executive authority co-sign and reopen. ### 12.2 Observability | Signal | Threshold | Action | |---|---|---| | Review approval rate per QA approver (high outliers) | > 95th percentile | Quality review | | Review rejection rate per QA approver | > 25% per quarter | Quality oversight | | Review reopen rate per review | > 1 reopen per review | Quality oversight surface | | Time from review creation to closure (SLA) | > 90 days | Notification to QA Lead | | `REVIEW_SOD_VIOLATION_*` events | any single event | high; SOC chat | | `REVIEW_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 reviews register | Active reviews by lifecycle state and type | QA | | Reviews awaiting approval | Reviews in `pending_approval` past `due_date` | QA | | Critical-review register | `vendor_audit` for critical suppliers, `internal_audit` for high-risk sites | QA, executive authority | | Reopen audit register | Reopened reviews with executive authority attribution | QA, executive authority | | Closure-blocked register | Reviews with closure blocked by open findings | QA | | Cross-tenant indices (platform-admin support / break-glass only) | Aggregate Module 20 events | `platform_admin` (support / break-glass only with reason, support-ticket reference, electronic signature, `PLATFORM_TENANT_ACCESS_USED` audit emit, SOC alert) | Exports: - Review evidence pack (zipped: full review + child findings (URS-21) + lifecycle events with notes + approvals + URS-06 audit excerpt with hash-chain). --- ## 13. Data integrity (ALCOA+) | Principle | How met | |---|---| | Attributable | Every review mutation carries `created_by` / `updated_by` / signed-by per QS-2 | | Legible | UI surfaces the review detail with lifecycle history and audit trail | | Contemporaneous | Server-generated timestamps per QS-3 | | Original | Soft-delete only on review header; post-approval / post-closure immutability for header and child-finding linkage per DEC-20-15 | | Accurate | Authority-gated transitions; SoD enforcement at every approval / closure / reopen; bound e-signature persistence; transition notes audited | | Complete | All review mutations audited; HITL decision orchestration enforces non-bypassable approval; transition notes persisted per DEC-20-06 | | Consistent | URS-06 chain integrity; canonical status set aligned across layers per DEC-20-23 | | Enduring | Long-term retention; chain sealing at tenant offboarding per URS-08 | | Available | Reviews register surface; auditor read access per URS-22 | --- ## 14. Regulatory Mapping ### 14.1 Predicate-rule applicability matrix | Regulatory authority | Predicate | Module 20 obligation | |---|---|---| | FDA | 21 CFR Part 11 §11.10(a) — System validation | Module 20 must be validated per QS-15, QS-16; URS-20-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-20-13 | | FDA | 21 CFR Part 211 §211.180(e) (annual product quality review) | Periodic-review element | | EMA | EU GMP Annex 11 §15 (Periodic Review) | Module 20 periodic-review element | | EMA | EU GMP Annex 11 §4 (Validation) | CSV-review type | | EMA | EU GMP Annex 11 §16 (Incident Management) | Audit observation review | | EMA / PIC/S | EU GMP Chapter 1 §1.4 (Pharmaceutical Quality System) | Review element of PQS | | MHRA | MHRA Data Integrity Guidance (2018) — ALCOA+ | §13 mapping | | Health Canada | C.02.020 — GMP records | Review register and retention | | ICH | ICH Q10 §3.2.5 (Management Review) | Periodic management-review element | | ICH | ICH E6(R3) — GCP | Clinical periodic-review | | ISO | ISO 19011 (Audit principles) | Internal-audit + vendor-audit principles | | GAMP | GAMP 5 Cat 5 — Custom application | Validation per §17 | | FDA | FDA CSA Final Guidance (Sep 2025) | CSV-review risk-based testing | | WHO | TRS 996 Annex 5 — Good data management | ALCOA+ implementation | | Internal architectural control (forward-looking; not enacted predicate rule) | EU GMP Annex 22 (Draft 2025) | Internal forward-looking AI governance evidence (Annex 22 platform reference) | | Internal architectural control (forward-looking; not enacted predicate rule) | EU AI Act Art. 13 — Transparency principles | Visible advisory labelling (jurisdiction-specific legal enforceability subject to future legal assessment) | | India CDSCO (per applicable scope) | India Drugs and Cosmetics Act 1940 + Drugs Rules 1945 + Revised Schedule M (periodic review within GMP / CSV review where applicable) + Schedule M-III (where distribution-review scope) + New Drugs and Clinical Trials Rules 2019 (where clinical periodic review is in scope) + CDSCO GCP guidance (where clinical / study review scope) + Medical Devices Rules 2017 (where device / combination-product review scope) — Applicable per India tenant operation and jurisdictional regulatory assessment | Reviews register, type catalogue, child-finding linkage to URS-21, approval with reviewer-independent SoD + bound e-sig, closure with executive authority co-sign for critical, reopen audit chain; external jurisdictional legal / RA confirmation required for clause / form applicability per India review scope | --- ## 15. URS Requirements Register ### 15.1 Front-end (FE) | ID | Requirement | Priority | |---|---|---| | URS-20-FE-001 | Module 20 landing route at `/reviews` | MUST | | URS-20-FE-002 | Reviews register table with filters by `status`, `type`, `assignee`, scope dimensions | MUST | | URS-20-FE-003 | Review detail tabbed view (overview, child findings, lifecycle history with notes, audit, MIRA context) | MUST | | URS-20-FE-004 | Create-review wizard with type picker + scope picker | MUST | | URS-20-FE-005 | Status stepper showing lifecycle states with current state highlighted | MUST | | URS-20-FE-006 | Transition-notes capture form (DEC-20-06) | MUST | | URS-20-FE-007 | Embedded child-finding panel (URS-21) with status-gated creation per DEC-20-08 | MUST | | URS-20-FE-008 | Progression dial driven by milestone events (DEC-20-07) | MUST | | URS-20-FE-009 | Approval modal (Controlled Approval Modal — URS-04) with SoD-20-01 enforcement | MUST | | URS-20-FE-010 | Critical-review approval matrix per DEC-20-20 | MUST | | URS-20-FE-011 | Rejection modal with rationale capture | MUST | | URS-20-FE-012 | Closure modal with prerequisite check + bound e-signature | MUST | | URS-20-FE-013 | Executive authority reopen modal (executive only) | MUST | | URS-20-FE-014 | Review audit trail view consumed from URS-06 | MUST | | URS-20-FE-015 | MIRA review context panel (read-only) per DEC-20-18 | MUST | | URS-20-FE-016 | AI-suggested content visibly labelled as advisory; not auto-saved | MUST | | URS-20-FE-017 | All Module 20 surfaces meet WCAG 2.1 Level AA | MUST | ### 15.2 Back-end (BE) | ID | Requirement | Priority | |---|---|---| | URS-20-BE-001 | Review service `create(.)` validates scope anchor and persists `product_id` per typed-DB alignment | MUST | | URS-20-BE-002 | Status transition route uses `withAuthority(.)` + Controlled Approval Modal e-sign (replaces user-role string comparison) | MUST | | URS-20-BE-003 | Transition notes persisted per DEC-20-06 | MUST | | URS-20-BE-004 | Controlled progression computed from milestone events per DEC-20-07 | MUST | | URS-20-BE-005 | Status-gated child-finding creation enforced via URS-21 service | MUST | | URS-20-BE-006 | CAPA-style HITL decision orchestration through URS-04 `hitl` subsystem with `entity_type = 'review'` per DEC-20-05 | MUST | | URS-20-BE-007 | Bound e-signature persistence on approval (`approved_e_sig_id`), rejection (`rejected_e_sig_id`), and closure (`closed_e_sig_id`) per DEC-20-13 | MUST | | URS-20-BE-008 | Approval enforces SoD-20-01 + Controlled Approval Modal e-signature | MUST | | URS-20-BE-009 | Critical-review approval matrix per DEC-20-20 with SoD-20-07 | MUST | | URS-20-BE-010 | Closure enforces SoD-20-04 + 3-prerequisite check (state `approved`, all child findings terminal, closure-rationale captured) | MUST | | URS-20-BE-011 | Post-approval / post-closure immutability via `assertReviewMutable(.)` on every mutation route | MUST | | URS-20-BE-012 | Reopen as governed transition `closed → draft` per DEC-20-21 + SoD-20-06 | MUST | | URS-20-BE-013 | Audit-log writes atomic with originating action per URS-04 BR-04-15 | MUST | | URS-20-BE-014 | Reason-for-change captured for every UPDATE after `draft` | MUST | | URS-20-BE-015 | Multi-dimensional context persistence: `study_id`, `site_id`, `product_id`, `supplier_id`, `batch_id`, `project_id` per registry schema | MUST | | URS-20-BE-016 | Canonical status set aligned across backend service, shared DB type, workflow code, and frontend hooks per DEC-20-23 | MUST | | URS-20-BE-017 | `review_created` and `review_status_changed` events emitted | MUST | ### 15.3 Data (DATA) | ID | Requirement | Priority | |---|---|---| | URS-20-DATA-001 | `reviews` per DEC-20-01 with required scope anchor enforcement and `product_id` typed-DB alignment | MUST | | URS-20-DATA-002 | `review_lifecycle_events` append-only with hash chain | MUST | | URS-20-DATA-003 | `review_approvals` per-slot signature table | MUST | | URS-20-DATA-004 | `review_transition_notes` per DEC-20-06 | MUST | | URS-20-DATA-005 | `review_progress_events` per DEC-20-07 | MUST | | URS-20-DATA-006 | `review_type_config` tenant catalogue per DEC-20-10 | MUST | | URS-20-DATA-007 | RLS on every review-scoped table per QS-6 | MUST | | URS-20-DATA-008 | Bound e-signature payload persistence on `approved_e_sig_id`, `rejected_e_sig_id`, `closed_e_sig_id` | MUST | ### 15.4 AI / HITL (AI) | ID | Requirement | Priority | |---|---|---| | URS-20-AI-001 | NO LLM / GenAI in reviewer-attributable conclusions / approval / rejection / closure decision paths per the internal Annex 22 control | MUST (negative) | | URS-20-AI-002 | Static deterministic AI MAY surface similar prior reviews (advisory only) per ARCH-AI-001 AC-2 | MUST | | URS-20-AI-003 | Advisory output visibly labelled per ARCH-AI-001 AC-3 | MUST | | URS-20-AI-004 | Advisory output never autonomously writes to review tables per ARCH-AI-001 AC-4 | MUST | | URS-20-AI-005 | AI service errors degrade gracefully per ARCH-AI-001 AC-7 | MUST | | URS-20-AI-006 | MIRA copilot read-only mapping `review → reviews` via `useMiraRecord('review', id)` (per URS-32); no MIRA write path | MUST | | URS-20-AI-007 | Internal forward-looking AI governance evidence (EU AI Act Art. 13 transparency principles) | MUST | | URS-20-AI-008 | CAPA-style HITL decision orchestration through URS-04 `hitl` subsystem | MUST | ### 15.5 Audit (AUD) | ID | Requirement | Priority | |---|---|---| | URS-20-AUD-001 | Every Module 20 mutation produces an audit row through URS-06 | MUST | | URS-20-AUD-002 | Audit-write failure rolls back originating action | MUST | | URS-20-AUD-003 | HITL decision linkage captured in audit trail | MUST | | URS-20-AUD-004 | Bound e-signature evidence captured at approval, rejection, and closure | MUST | | URS-20-AUD-005 | Transition notes captured and persisted per DEC-20-06 | MUST | ### 15.6 Validation (VAL) | ID | Requirement | Status | |---|---|---| | URS-20-VAL-001 | Installation Qualification | Pending | | URS-20-VAL-002 | Operational Qualification | Pending | | URS-20-VAL-003 | Performance Qualification | Pending | | URS-20-VAL-004 | RLS enforcement evidence | Pending | | URS-20-VAL-005 | URS-06 chain integrity evidence | Pending | | URS-20-VAL-006 | SoD enforcement evidence (SoD-20-01.07) | Pending | | URS-20-VAL-007 | Post-approval / post-closure immutability evidence (DEC-20-15) | Pending | | URS-20-VAL-008 | Migration evidence (canonical status alignment across layers per DEC-20-23; `assertReviewMutable(.)` extension; bound e-sig persistence; HITL orchestration; status-gated child-finding creation per DEC-20-08; transition-notes persistence per DEC-20-06; controlled progression per DEC-20-07; multi-dimensional context persistence; `product_id` typed-DB alignment; authority-gated status transitions replacing user-role string comparison) | Pending | | URS-20-VAL-009 | Internal forward-looking AI governance evidence (EU GMP Annex 22 Draft 2025 GenAI prohibition control) | Pending | | URS-20-VAL-010 | ARCH-AI-001 AC-1/2/3/4/7 advisory AI evidence pack | Pending | | URS-20-VAL-011 | Internal forward-looking AI governance evidence (EU AI Act Art. 13 transparency principles) | Pending | | URS-20-VAL-012 | Critical-review executive authority co-sign procedural evidence per DEC-20-20 | Pending | | URS-20-VAL-013 | Reopen executive authority co-sign procedural evidence per DEC-20-21 + SoD-20-06 | Pending | | URS-20-VAL-014 | Review-specific HITL orchestration evidence per DEC-20-05 | Pending | | URS-20-VAL-015 | Bound e-signature persistence evidence per DEC-20-13 | Pending | | URS-20-VAL-016 | Status-gated child-finding creation evidence per DEC-20-08 | Pending | | URS-20-VAL-017 | Transition-notes persistence evidence per DEC-20-06 | Pending | | URS-20-VAL-018 | Controlled progression evidence per DEC-20-07 | Pending | | URS-20-VAL-019 | Multi-dimensional context persistence evidence per DEC-20-09 | Pending | | URS-20-VAL-020 | Authority-gated status transitions evidence (replacing user-role comparison) per DEC-20-04 | Pending | ### 15.7 Integration (INT) | ID | Requirement | Priority | |---|---|---| | URS-20-INT-001 | URS-21 Findings outbound (child-finding linkage + status-gated creation enforcement) | MUST | | URS-20-INT-002 | URS-22 Inspection Mgmt inbound (audit observation precipitating review) + outbound (review register accessible to inspection-readiness export) | MUST | | URS-20-INT-003 | URS-11 Supplier inbound (vendor-audit source linkage) | MUST | | URS-20-INT-004 | URS-07 Study inbound (study periodic-review scope) | MUST | | URS-20-INT-005 | URS-10 Product inbound (product periodic-review scope) | MUST | | URS-20-INT-006 | URS-14 Complaints inbound (complaint trend periodic-review) | MUST | | URS-20-INT-007 | URS-15 OOS inbound (OOS trend periodic-review) | MUST | | URS-20-INT-008 | URS-16 Deviations inbound (deviation trend periodic-review) | MUST | | URS-20-INT-009 | URS-26 APQR outbound | MUST | | URS-20-INT-010 | URS-30 Notifications outbound | MUST | | URS-20-INT-011 | URS-32 MIRA AI outbound (read-only context via `useMiraRecord('review', id)`) | MUST | | URS-20-INT-012 | URS-06 audit substrate inbound | MUST | | URS-20-INT-013 | URS-04 Controlled Approval Modal contract + HITL subsystem + e-signature subsystem | MUST | | URS-20-INT-014 | URS-05 Authority Profile registry consumer | MUST | | URS-20-INT-015 | Internal forward-looking AI governance evidence (EU GMP Annex 22 Draft 2025) | MUST | | URS-20-INT-016 | Internal forward-looking AI governance evidence (EU AI Act Art. 13 transparency principles) | MUST | ### 15.8 Reports (REP) | ID | Requirement | Priority | |---|---|---| | URS-20-REP-001 | Open reviews register | MUST | | URS-20-REP-002 | Reviews awaiting approval | MUST | | URS-20-REP-003 | Critical-review register | MUST | | URS-20-REP-004 | Reopen audit register with executive authority attribution | MUST | | URS-20-REP-005 | Closure-blocked register | MUST | | URS-20-REP-006 | Review evidence pack export | MUST | ### 15.9 Workflow (WF) | ID | Requirement | Priority | |---|---|---| | URS-20-WF-001 | Review lifecycle state machine per DEC-20-02 | MUST | | URS-20-WF-002 | Authority-gated status transitions per DEC-20-04 | MUST | | URS-20-WF-003 | Transition notes capture per DEC-20-06 | MUST | | URS-20-WF-004 | Controlled progression per DEC-20-07 | MUST | | URS-20-WF-005 | Status-gated child-finding creation per DEC-20-08 | MUST | | URS-20-WF-006 | Approval per DEC-20-04 + SoD-20-01 + bound e-sig + HITL | MUST | | URS-20-WF-007 | Critical-review approval matrix per DEC-20-20 + SoD-20-07 | MUST | | URS-20-WF-008 | Rejection + re-loop per DEC-20-02 + SoD-20-05 | MUST | | URS-20-WF-009 | Closure per DEC-20-16 + SoD-20-04 + bound e-sig | MUST | | URS-20-WF-010 | Reopen as governed transition per DEC-20-21 + SoD-20-06 | MUST | ### 15.10 Functional acceptance (FUN) | ID | Requirement | Priority | |---|---|---| | URS-20-FUN-001 | Review create with scope anchor enforcement | MUST | | URS-20-FUN-002 | Review approve with SoD-20-01 enforcement + bound e-sig | MUST | | URS-20-FUN-003 | Review reject with rationale + bound e-sig | MUST | | URS-20-FUN-004 | Review close with 3-prerequisite check + bound e-sig | MUST | | URS-20-FUN-005 | Review reopen by executive authority with SoD-20-06 | MUST | | URS-20-FUN-006 | Post-approval / post-closure mutation blocked per DEC-20-15 | MUST | | URS-20-FUN-007 | Status-gated child-finding creation enforced per DEC-20-08 | MUST | --- ## 16. Test cases and Acceptance criteria ### 16.1 Test cases (TC) | ID | Test | |---|---| | TC-20-01 | GxP review happy path: create → under_review → child findings added → pending_approval → approve → close | | TC-20-02 | Vendor audit happy path | | TC-20-03 | Internal audit happy path | | TC-20-04 | CSV review happy path | | TC-20-05 | Process review happy path | | TC-20-06 | Create review without scope anchor returns `400 SCOPE_ANCHOR_REQUIRED` | | TC-20-07 | Status transition without notes returns `400 NOTES_REQUIRED` | | TC-20-08 | Status transition by user without authority returns `403 PERMISSION_DENIED` | | TC-20-09 | Creator attempts to approve own review returns `403 REVIEW_SOD_VIOLATION_CREATOR_CANNOT_APPROVE` | | TC-20-10 | Approve without bound e-sig returns `400 BOUND_ESIGNATURE_REQUIRED` | | TC-20-11 | Critical-review approval requires `final_quality_approver` + executive authority co-sign per DEC-20-20 | | TC-20-12 | Rejection without rationale returns `400 REJECTION_RATIONALE_REQUIRED` | | TC-20-13 | Rejection re-loop transitions `rejected → draft` with remediation rationale (SoD-20-05) | | TC-20-14 | Create finding on review in `pending_approval` returns `409 FINDING_CREATION_BLOCKED_BY_REVIEW_STATE` | | TC-20-15 | Close review with open child findings returns `409 REVIEW_CLOSURE_BLOCKED_BY_OPEN_FINDINGS` | | TC-20-16 | Close review without rationale returns `400 CLOSURE_RATIONALE_REQUIRED` | | TC-20-17 | Mutation on approved or closed review returns `403 REVIEW_IMMUTABLE_FINAL_STATE` | | TC-20-18 | Reopen by original closure authority returns `403 REVIEW_SOD_VIOLATION_REOPEN_COSIGNER_CANNOT_BE_CLOSURE_AUTHORITY` | | TC-20-19 | Reopen by executive authority transitions `closed → draft`; appends new lifecycle event; preserves prior closed evidence | | TC-20-20 | MIRA copilot read-only context via `useMiraRecord('review', id)`; MIRA write paths blocked | | TC-20-21 | AI-suggested content visibly labelled; not auto-saved to review record | | TC-20-22 | Internal Annex 22 negative test: any GenAI invocation in reviewer-conclusion / approval / closure path blocked at runtime + lint | | TC-20-23 | Multi-dimensional context: `study_id`, `site_id`, `product_id`, `supplier_id`, `batch_id`, `project_id` persisted per registry schema | | TC-20-24 | Race-condition test on `display_id` generation under concurrent creates per DEC-20-03 | | TC-20-25 | Audit-write failure rolls back originating action | | TC-20-26 | Transition notes captured and audited per DEC-20-06 | | TC-20-27 | Controlled progression event recorded; cumulative progress recomputed per DEC-20-07 | | TC-20-28 | Platform identity outside support envelope returns `403 PLATFORM_TENANT_ACCESS_DENIED`; SOC alert fires | ### 16.2 Acceptance criteria (AC) | ID | Acceptance criterion | |---|---| | AC-20-01 | Every review carries at least one scope anchor; existence validated. | | AC-20-02 | Every status transition uses `withAuthority(.)` + Controlled Approval Modal e-sign per DEC-20-04. | | AC-20-03 | Every status transition persists notes per DEC-20-06. | | AC-20-04 | `progress` computed from milestone events per DEC-20-07. | | AC-20-05 | Child findings creatable only while parent review in `draft` or `under_review` per DEC-20-08. | | AC-20-06 | SoD-20-01 enforced: review approver ≠ creator. | | AC-20-07 | SoD-20-04 enforced: closure authority ≠ creator. | | AC-20-08 | SoD-20-06 enforced: executive reopen co-signer ≠ original closure authority. | | AC-20-09 | Critical-review approval matrix per DEC-20-20 enforced; SoD-20-07 enforced. | | AC-20-10 | Bound e-signature persisted on approval (`approved_e_sig_id`), rejection (`rejected_e_sig_id`), and closure (`closed_e_sig_id`). | | AC-20-11 | Post-approval / post-closure immutability per DEC-20-15 enforced via `assertReviewMutable(.)` on every mutation route. | | AC-20-12 | Reopen is governed transition per DEC-20-21; appends new review iteration without mutating prior closed evidence. | | AC-20-13 | Review-specific HITL decision orchestration through URS-04 `hitl` subsystem with `entity_type = 'review'`. | | AC-20-14 | Internal Annex 22 GenAI prohibition enforced runtime + lint per DEC-20-18. | | AC-20-15 | Internal forward-looking AI governance evidence (EU AI Act Art. 13 transparency principles) maintained for all AI surfaces. | | AC-20-16 | URS-06 hash-chain integrity preserved on every review mutation. | | AC-20-17 | Canonical status set aligned across backend service, shared DB type, workflow code, and frontend hooks per DEC-20-23. | | AC-20-18 | Review evidence pack export includes full review + child findings + lifecycle events with notes + approvals + URS-06 audit excerpt with hash-chain. | --- ## 17. Validation evidence pack ### 17.1 Validation gate URS-20-VAL-008 (Migration Evidence Gate) MUST be satisfied before "Released for validation execution": - Schema migration applied with `IF NOT EXISTS` / `IF EXISTS` guards per QS-13. - Canonical status alignment applied (backend service, shared DB type, workflow code, and frontend hook all aligned to DEC-20-02 canonical state set per DEC-20-23). - `product_id` typed-DB alignment applied (current `db as any` removed). - Authority-gated status transitions replace user-role string comparison per DEC-20-04. - Transition-notes persistence applied per DEC-20-06. - Controlled progression computed from milestone events per DEC-20-07. - Status-gated child-finding creation enforced via URS-21 service per DEC-20-08. - `assertReviewMutable(.)` extended to every mutation route per DEC-20-15. - Bound e-signature payload persistence on `approved_e_sig_id`, `rejected_e_sig_id`, `closed_e_sig_id` per DEC-20-13. - Review-specific HITL decision orchestration through URS-04 `hitl` subsystem with `entity_type = 'review'` per DEC-20-05. - Multi-dimensional context persistence aligned: `study_id`, `site_id`, `product_id`, `supplier_id`, `batch_id`, `project_id` persisted per registry schema. - Reopen route mounted with executive authority + SoD-20-06 + reason per DEC-20-21. ### 17.2 Validation evidence index - IQ pack (installation qualification). - OQ pack (operational qualification per review happy path + negative paths). - PQ pack (performance qualification per §9 thresholds). - RLS evidence per QS-6. - URS-06 chain integrity evidence per DEC-20-19. - SoD enforcement evidence (SoD-20-01.07). - Post-approval / post-closure immutability evidence. - Critical-review executive authority co-sign procedural evidence. - Reopen executive authority co-sign procedural evidence. - Review-specific HITL orchestration evidence. - Bound e-signature persistence evidence. - Status-gated child-finding creation evidence. - Transition-notes persistence evidence. - Controlled progression evidence. - Multi-dimensional context persistence evidence. - Authority-gated status transitions 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 Art. 13 transparency principles). - ARCH-AI-001 AC-1/2/3/4/7 advisory AI evidence pack. --- ## 18. Cross-module dependencies and integration points ### 18.1 Closed Decision Register (Module 20 inputs) | ID | Decision | |---|---| | DEC-20-01.23 | All Module 20 closed launch decisions per §2.3. | ### 18.2 Cross-module dependencies | Linked module | Direction | Source | |---|---|---| | URS-01 Authentication | Inbound | URS-01 module URS | | URS-02 RBAC | Inbound | URS-02 module URS | | URS-03 Context Gate | Inbound | URS-03 module URS | | URS-04 Workflow / HITL / E-Sign | Inbound (HITL orchestration + Controlled Approval Modal + bound e-sig) | URS-04 module URS | | URS-05 Authority Profile | Inbound | URS-05 module URS | | URS-06 Audit Trail | Inbound | URS-06 module URS | | URS-07 Study Management | Inbound (study periodic-review scope) | URS-07 module URS | | URS-08 Tenant Management | Inbound (tenant context) | URS-08 module URS | | URS-09 Site / Facility | Inbound (site scope) | URS-09 module URS | | URS-10 Product / SKU | Inbound (product periodic-review scope) | URS-10 module URS | | URS-11 Supplier Management | Inbound (vendor-audit source linkage) | URS-11 module URS | | URS-12 Document Control | Inbound (closure-evidence + affected-document references) | URS-12 module URS | | URS-13 Change Control | Outbound (review-precipitated change linkage) | URS-13 module URS | | URS-14 Complaints | Inbound (complaint trend periodic-review) | URS-14 module URS | | URS-15 OOS / OOT | Inbound (OOS trend periodic-review) | URS-15 module URS | | URS-16 Deviations | Inbound (deviation trend periodic-review) | URS-16 module URS | | URS-17 RCA | Inbound (RCA reference for root-cause-driven review) | URS-17 module URS | | URS-18 CAPA | Outbound (finding-precipitated CAPA cascade via URS-21) | URS-18 module URS | | URS-21 Findings | Outbound (child-finding linkage + status-gated creation enforcement) | URS-21 module URS | | URS-22 Inspection Mgmt | Bidirectional (audit-observation inbound; review 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-30 Notifications | Outbound | URS-30 module URS | | URS-32 MIRA AI | Outbound (read-only context via `useMiraRecord('review', id)`) | 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 Art. 13 (transparency principles) | Internal forward-looking architectural reference (not enacted predicate rule) | EU AI Act | --- ## 19. Completeness Checklist | Item | Met | |---|---| | Header + mapping + Code Modules Mapped + Architecture Bindings (ARCH-AI-001 + Annex 22 + Art. 13) | ✓ | | Glossary, primer, worked examples, regulatory anchors | ✓ | | Audience and stakeholders | ✓ | | Roles + Authority Profile catalogue + SoD constraints | ✓ | | Role-permission matrix (Module 20 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 + Art. 13 architecture reference section | ✓ | | Cross-module wiring + Change-Impact Matrix per §7 | ✓ | | AI / Automation / HITL controls (with internal Annex 22 prohibition + MIRA read-only context) | ✓ | | 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-20-VAL-008 (Migration Evidence Gate) and the §17 validation evidence pack are satisfied. **No Module 20 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-1/2/3/4/7 advisory AI evidence + EU AI Act Art. 13 transparency + SoD enforcement + post-approval / post-closure immutability + critical-review executive co-sign + reopen executive co-sign + review-specific HITL orchestration + bound e-signature persistence + status-gated child-finding creation + transition-notes persistence + controlled progression + multi-dimensional context persistence + authority-gated status transitions evidence are itemised in §17. - **Specification ready for compliance review?** Yes — ALCOA+, 21 CFR Part 11, 21 CFR Part 211 §211.180(e), EU GMP Annex 11 §15 / §4 / §16, EU GMP Chapter 1 §1.4, MHRA ALCOA+, ICH Q10 §3.2.5, ICH E6(R3), ISO 19011, GAMP 5 Cat 5, FDA CSA, WHO TRS 996 Annex 5 — all mapped in §14. EU GMP Annex 22 (Draft 2025) and EU AI Act Art. 13 transparency principles are treated as internal forward-looking architectural controls; jurisdiction-specific legal enforceability remains subject to a future jurisdiction-specific legal assessment. - **Specification ready for inspector / client review?** Yes — 28 journeys (§4), full requirements register (§15), evidence pack index (§17.2). - **Specification ready for Founder approval?** Yes. - **Blocking gaps?** None internal. - **Two-step release path:** 1. **Approved Controlled URS — released for engineering implementation and validation planning.** 2. **Released for validation execution.** After URS-20-VAL-008 + §17 evidence complete. --- ## Appendix A — Module 20 End-to-End Composite (Create → Status Transitions with Notes → Child Findings via URS-21 → Approve → Close → Immutable / Reopen) ```mermaid flowchart TD A[Trigger: Periodic / Audit Observation / Vendor Audit / CSV / Process] --> B[Create Review - draft] B --> C[Status Transition with Notes - draft -> under_review per DEC-20-04 + DEC-20-06] C --> D[Add Child Findings via URS-21 - status-gated per DEC-20-08] D --> E[Controlled Progression Events per DEC-20-07] E --> F[Status Transition - under_review -> pending_approval per DEC-20-04 + DEC-20-06] F --> G{QA Approver Decision} G -- approve --> H{Critical Review?} G -- reject --> I[Reject - bound e-sig + rationale] H -- yes --> J[final_quality_approver + Executive Authority Co-Sign per DEC-20-20 + SoD-20-07 + bound e-sig] H -- no --> K[Standard Approval - SoD-20-01 + bound e-sig] J --> L[approved] K --> L I --> M[rejected] M --> N[Re-loop with Remediation Rationale per SoD-20-05] N --> B L --> O[All Child Findings Terminal? Closure Rationale?] O -- yes --> P[Closure Authority Sign - SoD-20-04 + bound e-sig - closed] O -- no --> Q[Closure Blocked] P --> R[Immutable Parent + Linked Findings per DEC-20-15] R -. Reopen Path.-> S[Executive Authority Reopen - DEC-20-21 + SoD-20-06] S --> T[closed -> draft; new review iteration appended; prior closed evidence preserved] T --> B D -. MIRA read-only context.-> U[useMiraRecord review id - per DEC-20-18 - AI advisory only - NOT auto-saved] ``` Diagram Appendix A — Module 20 End-to-End Composite. Trigger → review create → authority-gated status transitions with notes capture → child findings via URS-21 (status-gated per DEC-20-08) → controlled progression events → critical-review matrix per DEC-20-20 + SoD-20-07 (executive authority co-sign) or standard approval per DEC-20-04 + SoD-20-01 + bound e-sig → rejection re-loop per DEC-20-02 + SoD-20-05 → 3-prerequisite closure check → closure per DEC-20-16 + SoD-20-04 + bound e-sig → immutable parent + linked findings per DEC-20-15 → executive-authority-cosigned reopen path per DEC-20-21 + SoD-20-06; MIRA copilot read-only context integration per DEC-20-18. Verixa treats EU GMP Annex 22 Draft 2025 and EU AI Act Art. 13 transparency principles as internal forward-looking AI governance controls unless a jurisdiction-specific legal assessment determines otherwise; under the internal control, generative AI is prohibited in reviewer-attributable conclusions / approval / rejection / closure decision paths. ARCH-AI-001 governs advisory deterministic AI in similarity / signal surfacing. Binding predicate-rule obligations remain those listed in §14. — End of Module 20 User Requirements Specification —