# Verixa — User Requirements Specification

# Module 13: Change Control

| Field | Value |
|---|---|
| Document ID | VRX-URS-13 |
| Version | 1.0 |
| Status | Final — ready for QA, Validation, Regulatory Affairs, Information Security, Change Control Manager, 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-13-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 `change-control`. Expected API mount `/api/v1/change-control`. Expected route / service / workflow / schema / type / migration / authority-hook ownership within the `change-control` module. Implementation evidence remains subject to repository verification and validation evidence. |
| Architecture Bindings | Verixa treats **EU GMP Annex 22 (Draft 2025)** as an internal forward-looking architectural control for AI governance; it is not cited as an enacted predicate rule. Change Control approvals on critical regulated changes (sterile manufacturing parameters, batch release criteria, registered specifications, validated processes) **PROHIBIT** LLM / generative-AI use in the approval decision path under this internal architectural control. Static, deterministic AI may be used in advisory roles (impact-assessment domain suggestion, deviation-link suggestion) under internal AI governance aligned with EU AI Act Article 13 transparency principles, governed by ARCH-AI-001 AC-1..AC-7 (manual primary path, advisory secondary, visible advisory labelling, no autonomous write to system of record, full AI audit trail, override capability, graceful degradation). No AI service may be the sole path to approve, classify, implement, verify, or close a Change Control. 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 Change Control register, the change-request lifecycle state machine, the impact-assessment matrix, the approval matrix and quorum control, the authority and segregation-of-duties enforcement, the implementation-step planning and execution evidence, the post-change effectiveness verification, the closure prerequisites, and the cross-module linkage to documents, libraries, suppliers, products, sites, regulatory items, and batches. Module 13 is the change-governance substrate every other URS module references for any regulated change to a validated system, process, product specification, site, supplier, equipment, or procedure. |
| Date of Issue | 2026-05-06 |
| Module Owner (Engineering) | Change Control Squad |
| Module Owner (Quality Validation) | CSV / CSA Lead — Change Control |
| Module Owner (Compliance) | Quality Assurance, Regulatory Affairs, Change Control Manager |
| Approving Authority | Founder / Chairman & MD; QA Head; Validation Head; RA Head; Information Security Head; Change Control Manager |

---

## 0. Document Framing

### 0.1 Purpose of this document

This URS defines the target expected state for Verixa's Change Control module (Module 13). It is the binding contract between product, engineering, quality validation, regulatory affairs, change-control management, manufacturing, supply chain, information security, and the executive authority for the design, implementation, validation, release, and on-going periodic review of the regulated change-governance substrate: the canonical change-request register; the change-request lifecycle state machine (`draft → impact_assessment → cab_review → approved → implementing → verification → closed`, plus terminal `rejected` and `withdrawn`); the structured impact-assessment workflow with required cross-functional category coverage; the Change Approval Board (CAB) approval matrix with explicit quorum, non-duplication, and SoD enforcement; the authority-gated, e-signature-bound final approval; the explicit implementation-step planning, execution, and verification surface; the post-change effectiveness verification with non-bypassable closure prerequisites; the rejection / conditional-approval / reopen / supersede / withdraw governance; and the cross-module linkage to documents, libraries, suppliers, products, sites, regulatory items, batches, deviations, complaints, OOS/OOT investigations, CAPAs, and findings. Compliance with this URS is mandatory.

### 0.2 Audience

Engineering, QA, Validation, Regulatory Affairs, Change-Control management, Manufacturing, Supply Chain, Quality Operations, 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 13 accessible to non-domain engineers, product owners, validation engineers, and change-control coordinators.

### 0.3 How to read this document

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 (strong recommendation) or MAY (option).

### 0.4 Plain-language primer for non-domain readers

In a regulated pharmaceutical operation, **nothing changes silently**. If you change a Standard Operating Procedure (SOP), a manufacturing process, a packaging specification, a supplier of a critical excipient, an equipment configuration, a validated computer system, or a regulatory commitment — the change must follow a written change-control procedure, be assessed for its impact across quality, regulatory, manufacturing, supply, and product, be approved by the named approvers per a written approval matrix, be implemented per a documented plan, be verified post-implementation through an effectiveness check, and be closed only when verification confirms the change achieved its intent without unintended consequences. This is the regulator's expectation under **21 CFR Part 211.100, EU GMP Annex 15, ICH Q10, ICH Q12, FDA Quality Systems Guidance, and PIC/S PE 009**. Module 13 is the target specification for this regulated workflow.

A **change request (CR)** is the regulated record. It is created by an originator (the person proposing the change), describes what is changing and why, identifies the scope (which study, site, product, supplier, regulatory item, document, or library record is affected), and starts in `draft` state. The originator edits the draft until it is complete enough to submit. On submission the change request transitions to `impact_assessment` — the cross-functional evaluation phase.

In **impact assessment**, named functions evaluate the change through their domain lens. The launch impact-assessment matrix covers: Quality (does this affect product quality, stability, registered specifications?), Regulatory Affairs (does this require regulatory submission or notification?), Manufacturing (does this affect process validation, batch records, equipment qualification?), Supply Chain (does this affect supplier qualification, material specifications?), Engineering (does this affect equipment, facilities, utilities?), Validation (does this require re-validation or re-qualification?), and Documentation (does this require document revision in URS-12?). Each function adds an `impact_item` with the affected entity type (`document`, `process`, `equipment`, `training`, `sop`, `work_instruction`, `site`, `product`, `supplier`, `regulatory_item`, `library_record`, `batch`, `submission`), the expected impact, and the recommended action. The impact assessment is electronically signed by each contributing function and is non-bypassable: the change request cannot move forward to CAB review until the required cross-functional categories are covered.

In **CAB review**, the Change Approval Board (CAB) — a tenant-configured group typically including QA, RA, Engineering, Manufacturing, and the appropriate functional leads — reviews the impact assessment, the proposed implementation, and the verification plan. The CAB applies the approval matrix: each change classification (Major / Minor / Administrative / Like-for-Like) carries its own required approver list and quorum. A single approver cannot finalise the request: the platform enforces matrix coverage and quorum before the request can transition to `approved`. The CAB may approve unconditionally, approve with conditions (the change is approved but specific conditions must be discharged before closure), or reject. Rejection and conditional approval are first-class state metadata on the change request.

The **final approval** is authority-gated and e-signature-bound. The platform's `withAuthority(...)` hook checks that the user holds the `final_quality_approver` Authority Profile, validates delegation chains, and requires e-signature with `meaningOfSignature` and `reasonForChange` per the Controlled Approval Modal contract. **Segregation-of-Duties** is enforced at the service layer: the change-request creator cannot also be an impact assessor or final approver; an impact assessor for a given category cannot also be the final approver for that change. This is non-bypassable.

After approval the change moves to `implementing`. **Implementation steps** are explicit records — each step has a description, a responsible person, planned and actual start/end dates, completion attribution, and evidence references. The platform exposes explicit transitions to start implementation and to mark implementation complete. The change cannot move to `verification` until all required implementation steps are complete.

In **verification**, the post-implementation **effectiveness checks** are executed per the verification plan. Each effectiveness check has a description, a planned check date, an actual outcome (`effective` / `partial` / `ineffective`), an issue payload describing what was found, and reviewer attribution. The change cannot **close** until: every required implementation step is complete; every required effectiveness check returned `effective`; every condition (for conditional approvals) has been discharged with evidence; and every linked record (document revisions, training tasks, supplier requalifications, regulatory commitments) has been updated. Closure is e-signed.

**Rejection** and **conditional approval** are explicit on the change-request record. A rejected change request is terminal. A conditional approval is approved-with-conditions; closure is blocked until conditions discharge. **Withdraw** is a pre-CAB-decision terminal state initiated by the originator (the originator changed their mind before the CAB approved or rejected). **Reopen** and **supersede** are governed transitions: a closed change request can be superseded by a new change request that references it; reopening a closed change request requires a executive authority co-sign and a documented reason.

Cross-module linkage is first-class: a change request can affect a document (URS-12) — in which case the document revision is created or planned within URS-12 and linked to the change request as an impact item; can affect a supplier (URS-11) — supplier change notifications and qualification updates are linked; can affect a product (URS-10) — specification changes and registration impacts are linked; can affect a site (URS-09) — facility / equipment / utility changes are linked; can affect a regulatory item (URS-27) — regulatory commitments are tracked; can affect a batch (URS-23) — batch records are flagged for the change boundary; can be precipitated by a deviation (URS-16) — the deviation linkage is captured in the change request; and can implement a CAPA (URS-18) — the change request is the implementation vehicle. The audit trail captures the full chain.

Verixa treats **EU GMP Annex 22 (Draft 2025)** as an internal forward-looking architectural control; under that internal control, the use of generative / probabilistic AI in critical Change Control decisions is **prohibited**. Module 13 does not use LLM / generative AI in the approval, classification, or closure decision paths. Static, deterministic AI may provide advisory suggestions (e.g., "this change historically required Regulatory Affairs review — would you like to add an impact item?") under internal AI governance aligned with EU AI Act Article 13 transparency principles, governed by ARCH-AI-001. All advisory output is visibly labelled and never autonomously writes to the change-request system of record. Jurisdiction-specific legal enforceability remains subject to a future jurisdiction-specific legal assessment.

Module 13 is the **substrate that every change in the regulated operation flows through** — the inspector's most common request after the audit trail and the procedural document is the change-control register and the evidence that every change followed the procedure.

### 0.5 Change Request lifecycle diagram

```mermaid
stateDiagram-v2
  state "Change Request Lifecycle" as CRLC {
    [*] --> draft : Originator creates request
    draft --> impact_assessment : Originator submits to impact assessment
    draft --> withdrawn : Originator withdraws (terminal)
    impact_assessment --> draft : Returned for additional context
    impact_assessment --> cab_review : All required impact categories covered + signed
    cab_review --> impact_assessment : CAB requests further information
    cab_review --> approved : All required approvers e-sign approve (matrix + quorum + SoD)
    cab_review --> approved_with_conditions : CAB approves with conditions
    cab_review --> rejected : CAB e-signs rejection (terminal)
    approved --> implementing : start_implementation transition
    approved_with_conditions --> implementing : start_implementation transition
    implementing --> verification : implementation_complete transition (all required steps)
    verification --> closed : closure e-signed (steps complete + checks effective + conditions discharged + linkages updated)
    closed --> superseded : new CR references this one
    closed --> reopened : executive authority co-sign + documented reason
    reopened --> impact_assessment : returns to assessment for re-evaluation
    rejected --> [*]
    withdrawn --> [*]
    superseded --> [*]
  }
```

Diagram 0.5-A — Change Request lifecycle. Every transition is electronically signed; the matrix-quorum-SoD trio is enforced at the `cab_review → approved` boundary; closure prerequisites are non-bypassable; reopen requires executive authority co-sign per DEC-13-22.

### 0.6 Glossary of key terms used in this document

| Term | Definition |
|---|---|
| Approved | Change-request state after CAB approval matrix and quorum are satisfied with e-signature attribution. |
| Approved with conditions | CAB approval with explicit conditions that must be discharged before closure. |
| 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 critical GMP decisions. Binding predicate-rule obligations remain those listed in §14. |
| CAB | Change Approval Board; the tenant-configured group that reviews and approves change requests per the per-classification approval matrix. |
| Change Classification | Major / Minor / Administrative / Like-for-Like — drives the approval matrix, regulatory notification requirement, and re-validation requirement. |
| Change Impact Item | Structured cross-functional impact record with affected entity type, expected impact, recommended action, and signed contributing-function attribution. |
| Change Request (CR) | The regulated change-control record (also: change request, change-control request). |
| Closed | Terminal change-request state after closure prerequisites satisfied and closure e-signed. |
| Conditional Approval | Approval contingent on documented conditions that must be discharged before closure. |
| Draft | Pre-submission editing state. |
| Effectiveness Check | Post-implementation verification with outcome `effective` / `partial` / `ineffective`; non-bypassable for closure. |
| ICH Q12 Established Conditions | Per ICH Q12, the regulatory dossier elements that, if changed, require regulatory submission; differentiates Major from Minor changes. |
| Impact Assessment | The cross-functional evaluation phase before CAB review; required category coverage is non-bypassable. |
| Implementation Step | Explicit step record with responsible person, planned and actual dates, completion attribution, and evidence. |
| Major Change | Change that affects regulatory commitments, product quality / safety / efficacy, registered specifications, or requires re-validation / re-qualification. |
| Minor Change | Change that does not affect regulatory commitments; targeted assessment; targeted re-validation may apply. |
| Administrative Change | Change with no quality / regulatory impact (e.g., typo, contact information). |
| Like-for-Like Change | Replacement of equipment / material with equivalent; equivalence demonstrated. |
| Quorum | Minimum number of required approvers signing per the change classification matrix. |
| Reopen | executive-authority-co-signed governed transition from `closed` back to `impact_assessment` for re-evaluation. |
| Rejected | Terminal change-request state after CAB rejection. |
| SoD (Segregation-of-Duties) | Service-layer enforced separation between creator, impact assessor for a category, and final approver. |
| Supersede | Closed change-request relationship to a successor change request. |
| Verification | Post-implementation phase in which effectiveness checks are executed. |
| Withdrawn | Pre-CAB-decision terminal state initiated by originator. |

### 0.7 Module 13 architectural picture

```mermaid
graph LR
  subgraph M13 [Module 13 — Change Control]
    CR[Change Request Registry<br/>code: change-control]
    CRLC[Change Request Lifecycle<br/>workflow.ts]
    CIA[Impact Assessment<br/>change_impact_items]
    CAB[CAB Review + Approval Matrix + Quorum<br/>change_approvals]
    AUTH[Authority Gate + SoD + E-Sign<br/>authority-check.ts]
    IMPL[Implementation Steps<br/>change_implementation_steps]
    VER[Effectiveness Checks<br/>change_effectiveness_checks]
    CLOSE[Closure Prerequisites<br/>service.ts closure gate]
    LINK[Cross-module linkage]
  end

  M01[URS-01 Auth] --> AUTH
  M02[URS-02 RBAC] --> CR
  M03[URS-03 Active Scope] --> CR
  M04[URS-04 Workflow / E-Sign] --> AUTH
  M05[URS-05 Authority Profiles<br/>final_quality_approver] --> AUTH
  M06[URS-06 Audit Substrate] <-- CR
  M07[URS-07 Study] <--> CR
  M09[URS-09 Site] <--> LINK
  M10[URS-10 Product] <--> LINK
  M11[URS-11 Supplier] <--> LINK
  M12[URS-12 Documents / Libraries] <--> LINK
  M14[URS-14 Complaints] --> CR
  M16[URS-16 Deviations] --> CR
  M18[URS-18 CAPA] <--> CR
  M21[URS-21 Findings] <--> CR
  M22[URS-22 Inspection Mgmt] <--> CR
  M23[URS-23 Batch Records] <--> LINK
  M27[URS-27 Regulatory Intelligence] --> LINK
  M30[URS-30 Notifications] --> CRLC
  ANNEX22[Internal Annex 22 critical-decision GenAI prohibition control — forward-looking; not enacted predicate rule] -.governs.-> CAB
  ANNEX22 -.governs.-> CLOSE
  ARCHAI[ARCH-AI-001] -.governs advisory AI.-> CIA
```

Diagram 0.7-A — Module 13 architectural picture. The target `change-control` code module is the expected owner of the registry, lifecycle, impact-assessment, approval matrix, authority/SoD/e-sign gate, implementation-step planning, effectiveness verification, and closure prerequisites; 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 the approval and closure decision paths. ARCH-AI-001 governs advisory AI in impact-assessment domain suggestion. Binding predicate-rule obligations remain those listed in §14.

---

## 1. Module Purpose

Module 13 establishes Change Control as the canonical substrate for "every regulated change to a validated system, process, product, specification, site, supplier, equipment, or procedure" in Verixa. It owns the change-request register, the lifecycle state machine, the impact-assessment matrix, the CAB approval matrix with quorum and SoD enforcement, the authority-gated e-signature-bound final approval, the explicit implementation-step planning and execution, the post-change effectiveness verification, the non-bypassable closure prerequisites, and the cross-module linkage to documents, libraries, suppliers, products, sites, regulatory items, batches, deviations, complaints, OOS/OOT investigations, CAPAs, findings, and inspection records. Module 13 is consumed by URS-09 (site changes), URS-10 (specification changes, registration impacts), URS-11 (supplier change notifications, supplier qualification updates), URS-12 (document revision linkage), URS-14 (complaints precipitating changes), URS-16 (deviations precipitating changes), URS-18 (CAPAs implemented through change), URS-21 (findings precipitating changes), URS-22 (inspection observations precipitating changes), URS-23 (batch boundary change), URS-27 (regulatory commitments), URS-28 (training updates following changes), URS-30 (notifications), and any module that produces or links to a regulated change.

Module 13 is the **single source of truth for "show me the change, the impact, the approvers, the implementation, the verification, and the closure"** — the inspector's third most common request after the audit trail and the procedural documents.

---

## 2. Scope

### 2.1 In scope

#### Change Request register (code: `change-control`)

- The change-request master registry per DEC-13-01: per-tenant registry of every change request with `id`, `tenant_id`, `display_id`, `title`, `description`, `change_classification` (`major` / `minor` / `administrative` / `like_for_like`), `originator_user_id`, `originator_role`, `created_at`, `lifecycle_state`, **scoped business anchor** persisted on the row: `study_id` (nullable), `site_id` (nullable), `product_id` (nullable), `supplier_id` (nullable), `regulatory_feed_item_id` (nullable), `document_id` (nullable), `document_library_id` (nullable). At least one anchor is required (purely unscoped change requests are not allowed per CC-REQ-001). 
- Change classification at launch: `major` (affects regulatory commitments — requires regulatory notification / amendment; affects product quality, safety, efficacy; requires re-validation or re-qualification); `minor` (no regulatory commitment impact; targeted assessment; targeted re-validation may apply); `administrative` (no quality / regulatory impact — typo correction, contact information); `like_for_like` (replacement of equipment / material with equivalent; equivalence demonstrated; targeted assessment).
- Change-request lifecycle state machine per DEC-13-02: `draft → impact_assessment → cab_review → approved | approved_with_conditions → implementing → verification → closed`; plus terminal `rejected` and `withdrawn`; plus reopen path `closed → reopened → impact_assessment` requiring executive authority co-sign per DEC-13-22; plus `closed → superseded` relationship to a successor change request. 
- Soft-delete / archive semantics: Archive and reopen behaviour MUST be explicitly controlled through governed lifecycle routes. Soft-delete metadata, where present, MUST NOT be used as an uncontrolled deletion path.

#### Impact Assessment (code: see §6.1)

- Structured impact assessment per DEC-13-03: `change_impact_items` with `change_request_id`, `affected_entity_type` (`document`, `process`, `equipment`, `training`, `sop`, `work_instruction`, `site`, `product`, `supplier`, `regulatory_item`, `library_record`, `batch`, `submission`, `cleanroom_certification`, `licence_evidence`, `analytical_method`), `affected_entity_id`, `assessor_user_id`, `assessor_function` (`quality` / `regulatory` / `manufacturing` / `supply_chain` / `engineering` / `validation` / `documentation` / `it_security`), `expected_impact`, `recommended_action`, `signed_at`, `signature_id`. 
- Required category coverage matrix per DEC-13-04: each change classification carries a required category coverage. Major changes require coverage of Quality + Regulatory + Manufacturing + Validation; Minor changes require coverage of Quality + the affected functional category; Administrative changes require Quality only; Like-for-Like changes require Quality + Engineering + Manufacturing. The platform enforces required coverage non-bypassably at the `impact_assessment → cab_review` transition. 
- Each impact item is electronically signed by the contributing function. 

#### CAB Approval Matrix, Quorum, and Non-Duplication (code: see §6.1)

- CAB approval matrix per DEC-13-05: each change classification carries a per-tenant-configurable required approver list with quorum minimums. Default launch matrix: Major change requires QA Head + RA Head + Manufacturing Head + Engineering Head + Validation Lead (quorum 5); Minor change requires QA Head + functional lead (quorum 2); Administrative change requires QA Lead (quorum 1); Like-for-Like change requires QA Lead + Engineering Lead (quorum 2). Critical-system changes (sterile parameters, batch release criteria, vaccine antigen sequences, cell-therapy protocols) additionally require executive authority co-sign per DEC-13-21. 
- Non-duplication: a single user cannot satisfy two required approver slots in the same matrix (e.g., the same person cannot count as both QA Head and RA Head).
- Approval decision per row: `approved` / `rejected` / `conditional`. The platform aggregates approvals: `approved` requires all required matrix slots e-signed `approved`; `approved_with_conditions` requires all required slots either `approved` or `conditional`; `rejected` requires any single required slot e-signed `rejected` (one rejection blocks). 

#### Authority, SoD, E-Signature (code: see §6.1)

- Final approval is authority-gated: route uses `withAuthority({ requiredAuthorityKey: 'final_quality_approver', requiresEsign: true, requiresDelegationValidation: true })`. 
- Service-layer SoD enforcement per DEC-13-06: the change-request originator (`originator_user_id`) cannot be a CAB approver for the same request; an impact assessor for a category cannot be the final approver for that change in that category. 
- E-signature binding per DEC-13-07: the route persists `esig_id` and `esig_hash` from payload; the service additionally verifies the e-signature record at the service boundary against URS-04 e-signature substrate before persisting the approval row. 

#### Implementation Steps (code: see §6.1)

- Implementation-step planning per DEC-13-08: each change request carries 1..N `change_implementation_steps` with `step_id`, `description`, `responsible_user_id`, `planned_start`, `planned_end`, `actual_start`, `actual_end`, `status` (`planned` / `in_progress` / `complete` / `blocked`), `completion_attribution_user_id`, `completion_signature_id`, `evidence_references_jsonb`. 
- Explicit lifecycle transitions per DEC-13-09: `start_implementation` (approved → implementing); `complete_implementation` (implementing → verification, requires all required steps complete). 
- Step uniqueness rule per DEC-13-10: no two implementation steps can share the same description within a change request without an explicit "intentional duplicate" flag.

#### Effectiveness Verification and Closure (code: see §6.1)

- Effectiveness check per DEC-13-11: each change request carries 1..N `change_effectiveness_checks` with `check_id`, `description`, `planned_check_date`, `actual_check_date`, `outcome` (`effective` / `partial` / `ineffective`), `issue_payload_jsonb`, `verifier_user_id`, `verifier_signature_id`. Required check schedule is configurable by change classification (default: Major = 6-month effectiveness check; Minor = 3-month; Administrative = none required; Like-for-Like = 3-month equivalence verification). 
- Non-bypassable closure prerequisites per DEC-13-12: a change request cannot transition `verification → closed` unless ALL of the following are true:
  1. Every required implementation step is `complete` and signed.
  2. Every required effectiveness check has `outcome = effective` (not `partial`, not `ineffective`).
  3. Every condition (for `approved_with_conditions`) is discharged with documented evidence and e-signature.
  4. Every cross-module linkage flagged for update has been updated (linked document revisions effective; linked supplier requalifications updated; linked training tasks issued; linked regulatory commitments updated).
  5. Closure attestation is e-signed by the final closure authority.
- 

#### Rejection / Conditional / Reopen / Supersede / Withdraw

- Rejection: any required CAB approver e-signs `rejected` → request state transitions to `rejected` (terminal). 
- Conditional approval: per DEC-13-13, conditions are first-class records with `condition_id`, `description`, `discharge_evidence`, `discharger_user_id`, `discharger_signature_id`. Closure blocked until all conditions discharged.
- Reopen: `closed → reopened → impact_assessment` requires executive authority co-sign per DEC-13-22; reason captured.
- Supersede: `closed → superseded` relationship via successor `change_request_id`; the superseding request references the predecessor.
- Withdraw: pre-CAB-decision terminal state initiated by originator; documented reason captured.

#### Cross-Module Linkage

- Documents (URS-12) — major-revision linkage; document references in impact items.
- Document Library (URS-12) — library-record references in impact items.
- Suppliers (URS-11) — supplier change notifications (SCN) precipitate change requests; supplier qualification updates linked.
- Products (URS-10) — specification changes; registration impacts.
- Sites (URS-09) — site / facility / equipment / utility changes.
- Studies (URS-07) — study scope changes.
- Regulatory Intelligence (URS-27) — regulatory commitments; submission triggers.
- Batch Records (URS-23) — batch boundary; before/after change.
- Deviations (URS-16) — deviations precipitate changes via `related_deviation_id`.
- Complaints (URS-14) — complaints precipitate changes.
- OOS/OOT (URS-15) — investigations precipitate changes.
- CAPA (URS-18) — change is the CAPA implementation vehicle.
- Findings (URS-21) — findings precipitate changes.
- Inspection Management (URS-22) — inspection observations precipitate changes.
- 

#### Audit Trail

- Every Change Control mutation calls `auditTrailService.log()` with full attribution. 
- Lifecycle transitions log dual-write to `change_request_state_events` + URS-06 audit substrate.
- Authority gate, SoD violation, and executive authority co-sign events log to `auth_audit_log` (URS-06 substrate).

#### Search, Reports, Filters, Productivity

- List filters per DEC-13-14: by classification, lifecycle state, originator, scope (study / site / product / supplier / document / regulatory item), date range, due-for-effectiveness-check, overdue-implementation-step.
- Reports per §9: change-request inventory, lifecycle aging, approval-decision SLA, effectiveness-check pass rate, overdue-step queue, conditional-discharge queue.

### 2.2 Out of scope

The following are NOT in Module 13 scope:

- **Document revision execution** — URS-12 owns document creation, review, approval, distribution, retirement. Module 13 references documents and links revisions, but does not execute them.
- **Training records, training assignments** — URS-28 owns training. Module 13 raises training-update requirements as impact items; URS-28 owns the training record.
- **Supplier qualification execution** — URS-11 owns supplier qualification. Module 13 references suppliers and links qualification-update requirements.
- **Regulatory submission** — URS-27 owns submissions. Module 13 references regulatory commitments and links submission triggers.
- **Authentication, RBAC, scope** — URS-01 / URS-02 / URS-03. Module 13 consumes these.
- **E-signature substrate** — URS-04. Module 13 consumes the Controlled Approval Modal contract (password + meaningOfSignature + reasonForChange).
- **Authority Profile registry** — URS-05. Module 13 consumes `final_quality_approver` and other Authority Profiles.
- **Audit substrate** — URS-06. Module 13 writes to it.
- **Generative / probabilistic AI in critical decision paths** — prohibited under the internal Annex 22 Draft 2025 forward-looking AI governance control (not enacted predicate rule); jurisdiction-specific legal enforceability subject to future legal assessment. Binding predicate-rule obligations remain those listed in §14.

### 2.3 Closed launch decisions

The following decisions are **closed** for launch and recorded in §18.1 with their rationale:

| ID | Decision | Disposition |
|---|---|---|
| DEC-13-01 | Change-request master registry shape and per-tenant scoping | Locked;. |
| DEC-13-02 | Lifecycle state machine | Locked: `draft → impact_assessment → cab_review → approved \| approved_with_conditions → implementing → verification → closed`; plus `rejected`, `withdrawn`, `reopened`, `superseded` + CC-008. |
| DEC-13-03 | Impact-assessment data model | Locked: `change_impact_items` with extended `affected_entity_type` enum. |
| DEC-13-04 | Required category coverage matrix per classification | Locked per §2.1; non-bypassable at `impact_assessment → cab_review`. |
| DEC-13-05 | CAB approval matrix and quorum at launch | Locked per §2.1; tenant-configurable above the launch defaults. |
| DEC-13-06 | SoD rules (creator-vs-assessor-vs-approver) | Locked: service-layer enforced. |
| DEC-13-07 | E-signature service-boundary verification | Locked: service verifies `esig_id` against URS-04 substrate, not just trusts route payload. |
| DEC-13-08 | Implementation-step model | Locked per §2.1; uniqueness rule per DEC-13-10. |
| DEC-13-09 | Explicit lifecycle transitions for implementation and verification | Locked: `start_implementation` and `complete_implementation` route/service exposed. |
| DEC-13-10 | Implementation-step uniqueness | Locked: no duplicate descriptions without explicit "intentional duplicate" flag. |
| DEC-13-11 | Effectiveness-check schedule defaults | Locked: Major = 6-month; Minor = 3-month; Administrative = none required; Like-for-Like = 3-month equivalence. |
| DEC-13-12 | Closure prerequisites (5-point) | Locked per §2.1; non-bypassable. |
| DEC-13-13 | Conditional approval condition model | Locked: conditions are first-class records with discharge evidence + e-signature. |
| DEC-13-14 | List filters at launch | Locked per §2.1. |
| DEC-13-15 | Cross-module linkage breadth | Locked per §2.1: documents, libraries, suppliers, products, sites, regulatory items, batches, deviations, complaints, OOS, CAPA, findings, inspections. |
| DEC-13-16 | Soft-delete + archive semantics | Locked: `deleted_at` exists; explicit archive route MUST. |
| DEC-13-17 | Audit-trail coverage on impact, step, check actions | Locked: full coverage. |
| DEC-13-18 | Annex 22 GenAI prohibition in critical Change Control decisions | Locked: NO LLM / generative AI in approval, classification, or closure decision paths. |
| DEC-13-19 | ARCH-AI-001 binding for advisory AI | Locked: advisory impact-assessment domain suggestion permitted; AC-1..AC-7 binding. |
| DEC-13-20 | EU AI Act Art. 13 advisory transparency | Locked: visible advisory labelling on every AI suggestion. |
| DEC-13-21 | executive authority co-sign on critical-system changes | Locked: sterile parameters, batch release criteria, vaccine antigen sequences, cell-therapy protocols, registered specifications. |
| DEC-13-22 | Reopen requires executive authority co-sign | Locked: `closed → reopened` requires executive authority e-signature + documented reason. |
| DEC-13-23 | Tenant-offboarding cascade | Locked: open change requests transition to `archived_for_audit`; closed records preserved per retention class. |
| DEC-13-24 | ICH Q12 Established Conditions auto-classification | Locked: changes touching Established Conditions auto-flagged Major regardless of originator's proposed classification. |
| DEC-13-25 | Regulatory submission gating | Locked: Major changes that affect registered specifications cannot transition `approved → implementing` without an open URS-27 regulatory submission record. |

---

## 3. User Roles and Permissions

### 3.1 Architecture

Module 13 consumes the URS-01 authenticated identity, the URS-02 RBAC permission grants, the URS-03 active scope, the URS-04 workflow / e-signature substrate, and the URS-05 Authority Profile registry. Module 13 does not maintain an independent user identity model; it consumes the platform's three-guard hierarchy — RoleGuard, PermissionGuard, AuthorityGuard — and exposes role-permission-authority matrices for each Module 13 surface.

### 3.2 Role definitions

| Role | Purpose | Module 13 ownership |
|---|---|---|
| `viewer` | Read-only access to change requests within scope | Read change requests; read impact items; read implementation steps; read effectiveness checks |
| `change_originator` | Per-tenant authoring authority for change requests | All `viewer` + create/draft change requests; submit to impact assessment; withdraw own draft |
| `impact_assessor` | Cross-functional impact-assessment authority | All `viewer` + add/sign impact items in own functional category |
| `cab_member` | CAB approval-matrix participation | All `impact_assessor` + e-sign approval / conditional / rejection per classification matrix |
| `quality_lead` | Quality oversight and CAB participation | All `cab_member` + approve QA-owned change types + co-sign closure attestation |
| `regulatory_affairs_lead` | Regulatory affairs oversight | All `cab_member` + assess regulatory impact + flag ICH Q12 Established Conditions auto-classification |
| `manufacturing_lead` | Manufacturing oversight | All `cab_member` + assess process / equipment / utility impact |
| `validation_lead` | Validation / qualification oversight | All `cab_member` + assess re-validation / re-qualification requirement |
| `engineering_lead` | Engineering / facilities oversight | All `cab_member` + assess equipment / facility / utility impact |
| `supply_chain_lead` | Supply chain oversight | All `cab_member` + assess supplier / material impact |
| `change_implementation_owner` | Implementation-step responsible role | All `viewer` + execute and complete implementation steps + sign step completion |
| `effectiveness_verifier` | Post-change effectiveness verification | All `viewer` + execute and sign effectiveness checks |
| `change_closure_authority` | Closure attestation authority | All `quality_lead` + e-sign closure attestation |
| `admin` | Tenant-level administration | All `quality_lead` + manage tenant approval-matrix configuration + manage classification rules |
| `platform_admin` | Verixa platform administration | Tenant-scoped Module 13 actions are support / break-glass only (with reason, support-ticket reference, electronic signature, `PLATFORM_TENANT_ACCESS_USED` audit emit, SOC alert). Routine tenant change-control administration is the responsibility of tenant `admin` users and the configured tenant CAB roster. |
| `super_admin` | Verixa super-admin | All `platform_admin` + emergency platform-level executive break-glass operations |

### 3.3 Authority Profiles consumed by Module 13

| Authority Profile | Description |
|---|---|
| `final_quality_approver` | E-signature authority to e-sign final approval row in CAB approval matrix (evidence in `authority-check.ts`) |
| `cab_approval_matrix_member` | Per-classification approval-matrix slot authority |
| `change_impact_assessment` | Authority to add/sign an impact item in a functional category |
| `change_implementation_complete` | Authority to e-sign implementation-step completion |
| `change_effectiveness_verification` | Authority to e-sign effectiveness check |
| `change_closure_authority` | Authority to e-sign closure attestation |
| `change_condition_discharge` | Authority to discharge a conditional-approval condition |
| `change_rejection_authority` | Authority to e-sign rejection |
| `change_reopen_executive_authority` | executive authority to co-sign a closed change-request reopen |
| `critical_system_executive_authority` | executive authority to co-sign critical-system change approval (DEC-13-21) |
| `change_archive` | Authority to archive a withdrawn or rejected change request |

### 3.4 Segregation-of-Duties rules

| SoD Rule | Description |
|---|---|
| SoD-13-01 | The originator of a change request cannot also be a CAB approver for the same request. |
| SoD-13-02 | An impact assessor for a functional category cannot also be the final approver for that change in that category. |
| SoD-13-03 | The same user cannot satisfy two required approver slots in the same approval matrix (e.g., the same person cannot count as both QA Head and RA Head). |
| SoD-13-04 | The user who completes an implementation step cannot also e-sign the effectiveness check that verifies that step's outcome. |
| SoD-13-05 | The user who e-signs a condition discharge cannot also be the user who originally authored the condition. |
| SoD-13-06 | The user who places a executive break-glass action (e.g., reopen, critical-system co-sign) cannot be the user who released or closed the prior state. |
| SoD-13-07 | The user who e-signs closure cannot also be the originator of the change request. |

### 3.5 Worked examples

**Example 1: Major change — sterile manufacturing parameter change.** A manufacturing process engineer (`change_originator`) opens a change request to update a sterile filtration setpoint on Line 3. Classification: Major (affects sterility assurance — critical-system per DEC-13-21). Scope: site_id (Manufacturing Site A), product_id (Product X), study_id (NULL — non-study). Submitted to impact assessment. Each named function adds an impact item: QA (sterility risk evaluation), RA (registered manufacturing condition — possible amendment per ICH Q12 EC), Manufacturing (line re-qualification needed), Validation (full re-validation required), Engineering (equipment configuration). Required category coverage satisfied. Submitted to CAB review. CAB matrix for Major: QA Head + RA Head + Manufacturing Head + Engineering Head + Validation Lead + executive authority (per DEC-13-21 critical-system). All sign approve. Final authority gate: `final_quality_approver` Authority Profile + e-signature with `meaningOfSignature` + `reasonForChange`. SoD enforced: originator cannot approve. Request `cab_review → approved`. `start_implementation`. Implementation steps: 1) update batch record template, 2) re-qualify line, 3) update SOP-MFG-014 (linked URS-12 document revision), 4) re-train operators (linked URS-28 training task), 5) submit ICH Q12 EC amendment to FDA (linked URS-27 submission). All steps complete. `complete_implementation → verification`. Effectiveness check at 6 months: `outcome=effective`. All conditions (none in this case) discharged. All linkages updated (document v2.0 effective; training complete; FDA amendment accepted). Closure attestation e-signed by `change_closure_authority`. Request `closed`.

**Example 2: Minor change — typo correction in a non-critical SOP.** A document owner opens a change request to correct a typo in `SOP-ADMIN-007`. Classification: Administrative. Scope: document_id (SOP-ADMIN-007). Impact assessment: Quality only required. CAB matrix for Administrative: QA Lead (quorum 1). Approved. Implementation: 1 step — correct typo via URS-12 minor revision. Effectiveness check: not required. Closure: signed. Request `closed`.

**Example 3: SoD enforcement — originator attempts to approve own change.** A `change_originator` opens a change request and is also a member of the CAB. They open the CAB approval interface for their own change. The platform's service-layer SoD-13-01 rule rejects: HTTP 403 with error code `CHANGE_CONTROL_SOD_VIOLATION_ORIGINATOR_CANNOT_APPROVE`. URS-06 audit substrate records the SoD-violation attempt as an `auth_audit` entry. The platform offers re-assignment: another qualified CAB member receives the slot.

**Example 4: Conditional approval workflow.** A change request to switch raw-material supplier is approved with the condition "supplier qualification audit must complete and pass within 90 days of change effective date." Conditions are first-class: `condition_id`, `description`, `discharge_evidence`, `discharger_user_id`, `discharger_signature_id`. The change moves to `implementing → verification` per the standard path. At day 60, the supplier audit completes successfully; the supplier_quality_lead discharges the condition with the audit evidence reference (URS-11 supplier audit record) and e-signature. Closure attempted; closure prerequisites checked: all impl steps complete ✓, all effectiveness checks effective ✓, all conditions discharged ✓, all linkages updated ✓. Closure e-signed; request `closed`.

**Example 5: Rejection.** A change request to skip a stability study for a registered product is opened by the originator. CAB review: RA Head e-signs `rejected` with reason "ICH Q1A(R2) requires stability study for registered products; skipping requires regulatory amendment". Request `cab_review → rejected` (terminal). The originator can submit a new change request with corrected scope; the rejected request is preserved for audit.

**Example 6: Reopen requires executive authority co-sign (DEC-13-22).** A closed change request is found, post-closure, to have an unverified effectiveness issue. QA proposes reopening. `closed → reopened` requires executive authority co-sign per DEC-13-22 with documented reason. executive authority e-signs reopen attestation. Request transitions back to `impact_assessment` for re-evaluation. URS-06 audit substrate captures the reopen chain.

**Example 7: Internal Annex 22 GenAI prohibition control in critical decision path (DEC-13-18).** A user attempts to invoke "AI-suggest CAB approval decision" — there is no such surface in Module 13 because under the internal Annex 22 Draft 2025 forward-looking AI governance control (DEC-13-18; not enacted predicate rule), generative / probabilistic AI is prohibited in approval, classification, and closure decision paths. The platform's static deterministic AI may suggest "Other change requests on this product line in the last 12 months" or "Suggested impact-assessment categories per pattern matching" — these are advisory under internal AI governance aligned with EU AI Act Art. 13 transparency principles, visibly labelled, and do not autonomously write to the system of record (ARCH-AI-001 AC-3, AC-4). Final classification, approval, and closure are 100% human decisions. 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; binding predicate-rule obligations remain those listed in §14.

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

| Permission | viewer | change_originator | impact_assessor | cab_member | quality_lead | regulatory_affairs_lead | change_implementation_owner | effectiveness_verifier | change_closure_authority | admin | platform_admin |
|---|---|---|---|---|---|---|---|---|---|---|---|
| `change-control:read` | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | support / break-glass only |
| `change-control:create` | ✗ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | support / break-glass only |
| `change-control:update_draft` | ✗ | ✓ | ✗ | ✗ | ✓ | ✓ | ✗ | ✗ | ✓ | ✓ | support / break-glass only |
| `change-control:submit_to_impact` | ✗ | ✓ | ✗ | ✗ | ✓ | ✓ | ✗ | ✗ | ✓ | ✓ | support / break-glass only |
| `change-control:withdraw` | ✗ | ✓ | ✗ | ✗ | ✓ | ✓ | ✗ | ✗ | ✗ | ✓ | support / break-glass only |
| `change-control:add_impact_item` | ✗ | ✗ | ✓ | ✓ | ✓ | ✓ | ✗ | ✗ | ✗ | ✓ | support / break-glass only |
| `change-control:submit_to_cab` | ✗ | ✓ | ✗ | ✗ | ✓ | ✓ | ✗ | ✗ | ✗ | ✓ | support / break-glass only |
| `change-control:approve` (with authority + SoD) | ✗ | ✗ | ✗ | ✓ | ✓ | ✓ | ✗ | ✗ | ✓ | ✓ | support / break-glass only |
| `change-control:reject` (with authority) | ✗ | ✗ | ✗ | ✓ | ✓ | ✓ | ✗ | ✗ | ✗ | ✓ | support / break-glass only |
| `change-control:start_implementation` | ✗ | ✗ | ✗ | ✗ | ✓ | ✗ | ✓ | ✗ | ✓ | ✓ | support / break-glass only |
| `change-control:add_implementation_step` | ✗ | ✗ | ✗ | ✗ | ✓ | ✗ | ✓ | ✗ | ✓ | ✓ | support / break-glass only |
| `change-control:complete_step` (with authority) | ✗ | ✗ | ✗ | ✗ | ✓ | ✗ | ✓ | ✗ | ✓ | ✓ | support / break-glass only |
| `change-control:complete_implementation` | ✗ | ✗ | ✗ | ✗ | ✓ | ✗ | ✓ | ✗ | ✓ | ✓ | support / break-glass only |
| `change-control:add_effectiveness_check` | ✗ | ✗ | ✗ | ✗ | ✓ | ✗ | ✗ | ✓ | ✓ | ✓ | support / break-glass only |
| `change-control:sign_effectiveness_check` (with authority) | ✗ | ✗ | ✗ | ✗ | ✓ | ✗ | ✗ | ✓ | ✓ | ✓ | support / break-glass only |
| `change-control:discharge_condition` (with authority + SoD) | ✗ | ✗ | ✓ | ✓ | ✓ | ✓ | ✗ | ✗ | ✗ | ✓ | support / break-glass only |
| `change-control:close` (with authority + SoD) | ✗ | ✗ | ✗ | ✗ | ✓ | ✗ | ✗ | ✗ | ✓ | ✓ | support / break-glass only |
| `change-control:reopen_executive_authority` (executive authority) | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ (executive authority only) |
| `change-control:critical_executive_authority_cosign` (executive authority) | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ (executive authority only) |
| `change-control:archive` (with authority) | ✗ | ✗ | ✗ | ✗ | ✓ | ✗ | ✗ | ✗ | ✗ | ✓ | support / break-glass only |
| `change-control:read_audit` | ✗ | ✗ | ✗ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | support / break-glass only |

---

## 4. End-to-End User Journeys

The 28 launch user journeys cover the full Change Control lifecycle: drafting, impact assessment, CAB approval matrix and quorum, authority/SoD/e-sign, implementation step planning and execution, effectiveness verification, closure prerequisites, rejection, conditional approval, reopen, supersede, withdraw, cross-module linkage, and executive break-glass governance.

### J-01 — Originator drafts a change request

A `change_originator` opens the create change-request interface. Selects classification (`major` / `minor` / `administrative` / `like_for_like`), selects scope (one or more of `study_id`, `site_id`, `product_id`, `supplier_id`, `regulatory_feed_item_id`, `document_id`, `document_library_id` — at least one required per CC-REQ-001), enters title, description. Saves as `draft`. URS-06 audit substrate records create.

### J-02 — Originator edits and submits to impact assessment

Originator iterates on draft. When complete, clicks "Submit to impact assessment". Platform validates: classification set, at least one scope anchor, title and description non-empty. Transitions `draft → impact_assessment`. URS-30 notifies named functional leads per the impact-assessment matrix for the classification. URS-06 records the transition.

### J-03 — Cross-functional impact assessment with required category coverage (CC-REQ-003)

A `quality_lead` opens the assigned impact-assessment task. Reviews the change. Adds an impact item: `affected_entity_type=product`, `affected_entity_id=Product-X`, `assessor_function=quality`, `expected_impact="potential stability impact"`, `recommended_action="require accelerated stability study"`. E-signs the impact item. Repeat for each required category (Quality + Regulatory + Manufacturing + Validation for Major). The platform tracks coverage; the `Submit to CAB review` action is disabled until all required categories per DEC-13-04 matrix are covered and signed.

### J-04 — Submission to CAB review

When required category coverage is complete, the originator (or QA lead) submits to CAB. Platform transitions `impact_assessment → cab_review`. URS-30 notifies CAB members per the per-classification matrix (DEC-13-05). The CAB members see the request in their queue.

### J-05 — CAB approval with matrix + quorum + non-duplication enforcement (CC-REQ-004)

A CAB member opens the request. Reviews impact assessment, proposed implementation plan, verification plan. E-signs `approved` on their slot via Controlled Approval Modal (password + meaningOfSignature + reasonForChange). The platform records the approval row. The platform aggregates: only when all required matrix slots are e-signed `approved` (and quorum minimum is met, and no single user satisfies two slots per SoD-13-03) does the request transition `cab_review → approved`. A single approval cannot finalise the request.

### J-06 — Authority gate + SoD enforcement on final approval (CC-REQ-005)

The final required approver e-signs. Route invokes `withAuthority({ requiredAuthorityKey: 'final_quality_approver', requiresEsign: true, requiresDelegationValidation: true })`. The service-layer SoD check (SoD-13-01, SoD-13-02, SoD-13-03) verifies: originator is not approving; impact assessor for category X is not approving for category X; this user does not satisfy any other slot in the matrix. Service-boundary verification of `esig_id` against URS-04 substrate. On success, request transitions `cab_review → approved`.

### J-07 — Conditional approval (DEC-13-13)

CAB approves with conditions. The approver e-signs `conditional` on their slot with a condition record: `description="supplier qualification audit must complete and pass within 90 days"`, `target_discharge_date=YYYY-MM-DD`. Platform aggregates: when all required slots are `approved` or `conditional`, request transitions `cab_review → approved_with_conditions`. Conditions are first-class and tracked on the change-request record.

### J-08 — Rejection (CC-REQ-011)

A required CAB member e-signs `rejected` with reason. Platform transitions `cab_review → rejected` (terminal). URS-30 notifies originator + all participants. The rejected request is preserved for audit; originator may submit a new request with corrected scope.

### J-09 — Withdraw before CAB decision

The originator (or `admin`) withdraws a change request before CAB renders a decision. Platform transitions `draft → withdrawn` or `impact_assessment → withdrawn` or `cab_review → withdrawn` (only valid from these pre-decision states). Reason captured. Withdrawn requests are preserved for audit.

### J-10 — Critical-system change requires executive authority co-sign (DEC-13-21)

A Major change to a critical system (sterile manufacturing parameter, batch release criterion, vaccine antigen sequence, cell-therapy protocol, registered specification) is detected by classification + scope analysis. The CAB matrix dynamically adds the executive authority slot. The executive authority e-signs co-approval via `critical_system_executive_authority` Authority Profile + Controlled Approval Modal. Without the executive authority slot signed, the request cannot transition to `approved`.

### J-11 — ICH Q12 Established Conditions auto-classification (DEC-13-24)

The originator submits a change classified as Minor. The platform's classification auditor detects that the change touches an ICH Q12 Established Condition (e.g., registered manufacturing process step). The platform auto-flags the change as Major regardless of the originator's proposed classification, with a banner explaining "this change touches an ICH Q12 Established Condition and is auto-classified as Major per DEC-13-24". The originator may submit a justification to revert (requires QA + RA co-sign), or accept the auto-classification.

### J-12 — Start implementation (CC-REQ-006)

An approved request is opened. The `change_implementation_owner` clicks "Start implementation". Platform transitions `approved → implementing` with explicit `start_implementation` route call (MUST

### J-13 — Add and execute implementation steps (CC-REQ-007)

The implementation owner adds steps: `description`, `responsible_user_id`, `planned_start`, `planned_end`. Each step is unique within the request (DEC-13-10). Responsible users execute their steps; mark `in_progress`; on completion, e-sign step completion via the Controlled Approval Modal with evidence references (`evidence_references_jsonb`). The platform records `actual_start`, `actual_end`, `completion_attribution_user_id`, `completion_signature_id`. URS-06 records each step event.

### J-14 — Complete implementation transition

When all required steps are `complete` and signed, the implementation owner clicks "Complete implementation". Platform validates: all required steps complete; no `blocked` steps remaining. Transitions `implementing → verification` with explicit `complete_implementation` route call. URS-30 notifies the verification team.

### J-15 — Effectiveness verification (CC-REQ-008)

An `effectiveness_verifier` opens the request. Reviews effectiveness-check schedule (default per classification per DEC-13-11). Executes the checks; for each check, records `actual_check_date`, `outcome` (`effective` / `partial` / `ineffective`), `issue_payload_jsonb`. E-signs each check via Controlled Approval Modal. SoD-13-04 enforced: cannot also be the user who completed the implementation step being verified.

### J-16 — Closure with non-bypassable prerequisites (CC-REQ-008)

The `change_closure_authority` opens the request. Clicks "Close". Platform runs the closure prerequisite check: (1) all required steps `complete` ✓, (2) all required checks `outcome=effective` ✓, (3) all conditions discharged ✓, (4) all linkages updated ✓. Closure attestation e-signed via Controlled Approval Modal. SoD-13-07 enforced: closure authority cannot be the originator. Transitions `verification → closed`. URS-06 records closure with verification basis.

### J-17 — Closure blocked by ineffective check

Closure is attempted on a request where one effectiveness check has `outcome=ineffective`. Platform rejects with HTTP 422 and error code `CHANGE_CONTROL_CLOSURE_BLOCKED_INEFFECTIVE_CHECK`; the response identifies the failing check. The user must remediate: extend implementation, add additional steps, re-run effectiveness check.

### J-18 — Closure blocked by undischarged condition

Closure is attempted on an `approved_with_conditions` request where a condition is undischarged. Platform rejects with `CHANGE_CONTROL_CLOSURE_BLOCKED_CONDITION_OPEN`; the response lists the open condition.

### J-19 — Discharge a conditional-approval condition (DEC-13-13)

The `change_condition_discharge` authority holder opens the condition. Records discharge evidence. E-signs discharge via Controlled Approval Modal. SoD-13-05 enforced: discharger cannot be the original condition author. Condition transitions to `discharged`.

### J-20 — Reopen a closed change request (DEC-13-22)

A QA lead identifies a post-closure issue (e.g., effectiveness check was signed prematurely; effectiveness was actually `partial` based on later observation). QA proposes reopen. Reopen requires executive authority co-sign per DEC-13-22 + documented reason. executive authority e-signs via `change_reopen_executive_authority` Authority Profile. Request transitions `closed → reopened → impact_assessment` for re-evaluation. URS-06 records the reopen chain.

### J-21 — Supersede a closed change request

A new change request explicitly references a prior closed request as the predecessor (e.g., the prior change is being superseded by an updated approach). Platform creates the relationship via `superseded_by_change_request_id`. The prior request transitions `closed → superseded` (terminal). The new request follows the standard lifecycle.

### J-22 — Cross-module linkage to URS-12 document revision (CC-REQ-009)

A change request includes an impact item `affected_entity_type=document`, `affected_entity_id=SOP-MFG-014`. On approval and transition to `implementing`, the platform creates an implementation step "Update SOP-MFG-014 to v2.0 per change". When the URS-12 document revision becomes effective, the linkage is updated; the implementation step's `completion_attribution_user_id` is the URS-12 document's approver-of-record; the linkage status transitions to `linkage_updated`.

### J-23 — Cross-module linkage to URS-11 supplier qualification

A change request includes `affected_entity_type=supplier`, `affected_entity_id=Supplier-X`. On approval, an implementation step "Requalify Supplier-X" is added. URS-11 supplier requalification is initiated; completion of requalification updates the linkage. Closure prerequisites check verifies linkage status.

### J-24 — Cross-module linkage to URS-27 regulatory submission (DEC-13-25)

A Major change affects a registered specification. The platform's classification auditor flags the change for regulatory submission gating per DEC-13-25. The request cannot transition `approved → implementing` until an open URS-27 regulatory submission record references this change. The CAB approval may proceed; implementation is gated.

### J-25 — Audit-trail review by inspector

An inspector requests evidence on a change request. The platform exports the change-request evidence pack: full request with classification, scope, originator; impact assessment with all signed impact items; CAB approval matrix with all approver e-signatures; implementation steps with completion attribution; effectiveness checks with verifier attribution; conditions with discharge evidence; cross-module linkages with status; closure attestation; full URS-06 audit trail with hash-chain integrity proof. Pack is watermarked, e-signed by `quality_lead`, exported as zipped PDF bundle.

### J-26 — Static deterministic AI advisory in impact-assessment domain suggestion (ARCH-AI-001)

When an impact assessor opens the add-impact-item interface, the platform's static deterministic AI suggests likely affected entity types based on pattern matching against historical change requests (e.g., "for changes to product specifications, the following functional categories typically apply: Quality, Regulatory, Manufacturing, Validation"). The suggestion is visibly labelled "AI-suggested — requires human review" (ARCH-AI-001 AC-3). The assessor confirms or overrides; the suggestion never autonomously writes to the impact assessment (AC-4). All advisory output is logged in `ai_requests` per AC-5. Per DEC-13-18 / Annex 22, NO generative / probabilistic AI is used; only static deterministic models.

### J-27 — executive break-glass on critical-system change

A regulatory inquiry requires immediate change to a critical system. Executive authority invokes `critical_system_executive_authority` authority on a fast-tracked Major change request. The standard CAB matrix still applies but the executive authority slot is added; standard SoD rules still apply; standard e-signature requirements still apply. The executive authority co-signs final approval; standard implementation, verification, closure follow.

### J-28 — Tenant offboarding cascade (DEC-13-23)

The tenant lifecycle (URS-08) transitions to `offboarding`. Module 13 receives the cascade signal: open change requests transition to `archived_for_audit` (preserved for audit retention); closed records preserved per retention class; new change requests blocked. URS-06 records the cascade.

---

## 5. Front-End Expected State

### 5.1 Routes

| Route | Purpose |
|---|---|
| `/change-control` | Change Control landing — list, filter by classification, lifecycle state, scope, date |
| `/change-control/new` | Create draft change request |
| `/change-control/:id` | Change request detail (lifecycle, impact, approvals, implementation, verification, closure) |
| `/change-control/:id/edit` | Edit draft change request |
| `/change-control/:id/impact` | Impact assessment interface |
| `/change-control/:id/cab` | CAB approval interface |
| `/change-control/:id/implementation` | Implementation step planning + execution |
| `/change-control/:id/verification` | Effectiveness check execution |
| `/change-control/:id/conditions` | Conditional approval condition management |
| `/change-control/:id/closure` | Closure attestation interface |
| `/change-control/:id/audit` | Per-request audit trail view |
| `/change-control/me/assignments` | My open Module 13 assignments (impact, CAB, implementation, verification, closure) |
| `/change-control/dashboard/aging` | Lifecycle aging dashboard |
| `/change-control/dashboard/sla` | Approval-decision SLA dashboard |
| `/change-control/dashboard/effectiveness` | Effectiveness-check pass-rate dashboard |
| `/change-control/dashboard/overdue` | Overdue implementation steps + overdue effectiveness checks |
| `/change-control/executive/reopen` | Executive authority reopen workflow (executive authority only) |
| `/change-control/executive/critical-cosign` | Executive authority critical-system co-sign queue (executive authority only) |
| `/change-control/admin/matrix` | Per-classification approval-matrix configuration (`admin`+) |
| `/change-control/admin/categories` | Required impact-assessment category configuration (`admin`+) |

### 5.2 Component requirements

- **ChangeRequestList / ChangeRequestCard** — display classification, lifecycle state, originator, scope anchors, age, due-for-action indicator.
- **ClassificationSelector** — major / minor / administrative / like-for-like with rule-based auto-classification banner (DEC-13-24 ICH Q12 EC).
- **ScopeAnchorPicker** — multi-select study / site / product / supplier / regulatory item / document / library record (at least one required per CC-REQ-001).
- **ImpactItemEditor** — affected entity type + ID + assessor function + expected impact + recommended action + e-sign.
- **RequiredCategoryCoverageMatrix** — visual matrix showing required categories per classification and which are covered.
- **CABApprovalMatrixViewer** — per-classification matrix with each required slot, current signature state, quorum indicator, non-duplication check.
- **ControlledApprovalModal** — password + meaningOfSignature + reasonForChange. NEVER ip / userAgent / timestamp / performedBy.
- **ApprovalDecisionPicker** — approve / conditional / reject; conditional requires condition record.
- **ImplementationStepEditor** — description + responsible + planned dates + status + completion sign.
- **StepCompletionSignModal** — Controlled Approval Modal + evidence reference picker.
- **EffectivenessCheckEditor** — description + planned date + outcome + issue payload + verifier sign.
- **ConditionDischargeEditor** — discharge evidence + e-sign; SoD-13-05 enforced visually.
- **ClosurePrerequisiteChecklistViewer** — five non-bypassable prerequisites with live status.
- **CrossModuleLinkagePanel** — linked entities (URS-12 documents, URS-11 suppliers, URS-10 products, URS-09 sites, URS-27 regulatory commitments, URS-23 batches, etc.) with linkage status.
- **AIAdvisoryBanner** — visible "AI-suggested — requires human review" banner over advisory impact-assessment domain suggestions (ARCH-AI-001 AC-3).
- **AuditTrailViewer** — chronological per-request event view with hash-chain integrity badge.
- **ExecutiveAuthorityReopenModal** — Executive-authority-only reopen workflow with mandatory reason and co-sign.

### 5.3 Accessibility and internationalisation

- WCAG 2.1 AA compliance for all components.
- Keyboard navigation: every interactive element reachable via tab; the Controlled Approval Modal is fully keyboard-operable.
- Screen reader: every action has an `aria-label`; AI advisory pills are announced explicitly.
- Internationalisation: all UI strings in resource files; date/time per user locale; numeric per locale.
- Colour contrast: AI advisory pill, lifecycle state badges, prerequisite checklist all meet 4.5:1 contrast.

---

## 6. Back-End Expected State

### 6.1 Domain entities

| Entity | Purpose | Code module |
|---|---|---|
| `change_requests` | Master change request registry | `change-control` |
| `change_request_state_events` | Lifecycle transition audit substrate | `change-control` |
| `change_impact_items` | Cross-functional impact records | `change-control` |
| `change_approvals` | CAB approval matrix rows | `change-control` |
| `change_approval_conditions` | First-class conditions on conditional approvals | `change-control` |
| `change_implementation_steps` | Implementation step records | `change-control` |
| `change_effectiveness_checks` | Post-change effectiveness verification records | `change-control` |
| `change_cross_module_linkages` | Linkage records to URS-12 docs, URS-11 suppliers, URS-10 products, etc. | `change-control` |
| `change_request_supersession_links` | Supersede relationships | `change-control` |
| `auth_audit_log` | Auth-related events (URS-06 substrate) | shared |
| `ai_requests` | Advisory AI request audit (URS-06 substrate) | shared |

### 6.1.1 Diagram 6.1-A — Module 13 entity-relationship overview

```mermaid
erDiagram
  CHANGE_REQUESTS ||--o{ CHANGE_REQUEST_STATE_EVENTS : emits
  CHANGE_REQUESTS ||--o{ CHANGE_IMPACT_ITEMS : has
  CHANGE_REQUESTS ||--o{ CHANGE_APPROVALS : has
  CHANGE_APPROVALS ||--o{ CHANGE_APPROVAL_CONDITIONS : carries
  CHANGE_REQUESTS ||--o{ CHANGE_IMPLEMENTATION_STEPS : has
  CHANGE_REQUESTS ||--o{ CHANGE_EFFECTIVENESS_CHECKS : has
  CHANGE_REQUESTS ||--o{ CHANGE_CROSS_MODULE_LINKAGES : has
  CHANGE_REQUESTS ||--o{ CHANGE_REQUEST_SUPERSESSION_LINKS : superseded_by
  TENANTS ||--o{ CHANGE_REQUESTS : owns
  STUDIES ||--o{ CHANGE_REQUESTS : scopes
  SITES ||--o{ CHANGE_REQUESTS : scopes
  PRODUCTS ||--o{ CHANGE_REQUESTS : scopes
  SUPPLIERS ||--o{ CHANGE_REQUESTS : scopes
  REGULATORY_FEED_ITEMS ||--o{ CHANGE_REQUESTS : scopes
  DOCUMENTS ||--o{ CHANGE_REQUESTS : scopes
  USERS ||--o{ CHANGE_REQUESTS : initiates
  USERS ||--o{ CHANGE_APPROVALS : approves
  USERS ||--o{ CHANGE_IMPLEMENTATION_STEPS : responsible_for
  USERS ||--o{ CHANGE_EFFECTIVENESS_CHECKS : verifies
  DEVIATIONS ||--o{ CHANGE_REQUESTS : precipitates
  CHANGE_REQUESTS ||--o{ AUTH_AUDIT_LOG : security_logged
  CHANGE_REQUESTS ||--o{ AI_REQUESTS : advisory_for
```

Diagram 6.1-A — Module 13 entity-relationship overview. The target `change-control` code module is the expected owner of 9 tables (extending the canonical baseline of 5 with conditions, supersession, state events, cross-module linkages); ownership is target binding and remains subject to repository verification and validation evidence. URS-06 substrate is consumed for auth and AI audit.

### 6.1.2 Diagram 6.1-B — Change Request lifecycle state machine (full)

```mermaid
stateDiagram-v2
  [*] --> draft : create
  draft --> impact_assessment : submit_to_impact (SoD validated)
  draft --> withdrawn : withdraw (terminal)
  impact_assessment --> draft : returned_for_context
  impact_assessment --> cab_review : submit_to_cab (required category coverage satisfied)
  impact_assessment --> withdrawn : withdraw (terminal)
  cab_review --> impact_assessment : cab_requests_information
  cab_review --> approved : matrix + quorum + SoD all satisfied + e-signed
  cab_review --> approved_with_conditions : matrix all approved/conditional + at least one condition
  cab_review --> rejected : any required slot e-signs reject (terminal)
  cab_review --> withdrawn : withdraw (terminal)
  approved --> implementing : start_implementation
  approved_with_conditions --> implementing : start_implementation
  implementing --> verification : complete_implementation (all required steps complete)
  verification --> closed : closure_e_signed (5 prerequisites satisfied)
  closed --> superseded : superseded_by new request (terminal)
  closed --> reopened : executive authority co-sign + reason
  reopened --> impact_assessment : re-evaluation
  rejected --> [*]
  withdrawn --> [*]
  superseded --> [*]
  note right of cab_review
    Matrix: per-classification required approver list
    Quorum: minimum signatures
    Non-duplication: SoD-13-03
    Authority gate: final_quality_approver
  end note
  note right of verification
    Effectiveness checks: outcome must be 'effective'
    SoD-13-04: verifier ≠ implementer
  end note
  note right of closed
    5 prerequisites:
    1. all required steps complete
    2. all checks effective
    3. all conditions discharged
    4. all linkages updated
    5. closure e-signed (SoD-13-07)
  end note
```

Diagram 6.1-B — Change Request lifecycle state machine. Full transition set including conditional approvals, reopen, supersede, and the explicit gating notes.

### 6.1.3 Diagram 6.1-C — CAB approval matrix, quorum, and SoD enforcement

```mermaid
flowchart TB
  Submit[Submit to CAB review] --> Matrix[Load classification matrix DEC-13-05]
  Matrix --> SlotsNeeded[Identify required approver slots + quorum]
  SlotsNeeded --> AssignNotify[URS-30 notify each required role]
  AssignNotify --> Approver[CAB member opens request]
  Approver --> SoDCheck{SoD-13-01..03 check}
  SoDCheck -- violates --> Reject403[HTTP 403 SOD_VIOLATION + audit log]
  SoDCheck -- ok --> AuthGate{withAuthority + e-sign}
  AuthGate -- denied --> Reject403b[HTTP 403 AUTHORITY_DENIED + audit log]
  AuthGate -- granted --> Decision{Decision}
  Decision -- approved --> InsertApproved[Insert change_approvals row approved + e-sig]
  Decision -- conditional --> InsertConditional[Insert conditional + condition record]
  Decision -- rejected --> InsertRejected[Insert rejected]
  InsertApproved --> Aggregate{Matrix complete?}
  InsertConditional --> Aggregate
  InsertRejected --> AggregateReject[Single reject = transition to rejected terminal]
  Aggregate -- all required slots approved --> StateApproved[change_request → approved]
  Aggregate -- mix of approved/conditional --> StateConditional[change_request → approved_with_conditions]
  Aggregate -- not yet --> Wait[Wait for remaining slots]
  Wait --> Approver
  AggregateReject --> StateRejected[change_request → rejected terminal]
  StateApproved --> Notify[URS-30 notify originator + implementation team]
  StateConditional --> Notify
  StateRejected --> Notify
```

Diagram 6.1-C — CAB approval matrix, quorum, and SoD enforcement. Per-classification matrix loaded, each slot evaluated through SoD + authority gates; aggregation rules enforce matrix completion or single-rejection terminal.

### 6.1.4 Diagram 6.1-D — Closure prerequisite checking

```mermaid
flowchart TD
  ClosureRequest[change_closure_authority requests close] --> Prereq1{All required impl steps complete?}
  Prereq1 -- no --> Block1[Reject: CHANGE_CONTROL_CLOSURE_BLOCKED_STEPS_INCOMPLETE]
  Prereq1 -- yes --> Prereq2{All required effectiveness checks 'effective'?}
  Prereq2 -- no --> Block2[Reject: CHANGE_CONTROL_CLOSURE_BLOCKED_INEFFECTIVE_CHECK]
  Prereq2 -- yes --> Prereq3{All conditions discharged?}
  Prereq3 -- no --> Block3[Reject: CHANGE_CONTROL_CLOSURE_BLOCKED_CONDITION_OPEN]
  Prereq3 -- yes --> Prereq4{All cross-module linkages updated?}
  Prereq4 -- no --> Block4[Reject: CHANGE_CONTROL_CLOSURE_BLOCKED_LINKAGE_PENDING]
  Prereq4 -- yes --> SoDCheck{SoD-13-07: closure authority ≠ originator?}
  SoDCheck -- no --> Block5[Reject: CHANGE_CONTROL_SOD_VIOLATION_CLOSURE]
  SoDCheck -- yes --> AuthGate{withAuthority change_closure_authority + e-sign}
  AuthGate -- denied --> Block6[Reject: AUTHORITY_DENIED]
  AuthGate -- granted --> Persist[Insert closure attestation + signature]
  Persist --> StateClose[change_request → closed]
  StateClose --> Notify[URS-30 notify all stakeholders]
  StateClose --> Audit[URS-06 hash-chained closure audit + verification basis]
```

Diagram 6.1-D — Closure prerequisite checking (CC-REQ-008). Five non-bypassable prerequisites + SoD + authority gate before closure transition.

### 6.2 Data model requirements

| Requirement | Statement |
|---|---|
| URS-13-DATA-001 | `change_requests` table with `id`, `tenant_id`, `display_id`, `title`, `description`, `change_classification`, `originator_user_id`, `originator_role`, `created_at`, `updated_at`, `lifecycle_state`, `study_id`, `site_id`, `product_id`, `supplier_id`, `regulatory_feed_item_id`, `document_id`, `document_library_id`, `related_deviation_id`, `superseded_by_change_request_id`, `deleted_at`.  |
| URS-13-DATA-002 | At least one scope anchor required per CC-REQ-001; check enforced at CREATE / UPDATE. |
| URS-13-DATA-003 | `change_request_state_events` append-only with `from_state`, `to_state`, `actor_user_id`, `at_timestamp`, `signature_id` (nullable), `reason` (nullable). |
| URS-13-DATA-004 | `change_impact_items` with extended `affected_entity_type` enum per CC-REQ-009. |
| URS-13-DATA-005 | `change_approvals` with `id`, `change_request_id`, `slot_role`, `assigned_user_id`, `signed_user_id` (nullable), `decision` (`approved` / `conditional` / `rejected`), `esig_id`, `esig_hash`, `signed_at`.  |
| URS-13-DATA-006 | `change_approval_conditions` with `id`, `approval_id`, `description`, `target_discharge_date`, `discharger_user_id` (nullable), `discharger_signature_id` (nullable), `discharged_at` (nullable). |
| URS-13-DATA-007 | `change_implementation_steps` with `id`, `change_request_id`, `description`, `responsible_user_id`, `planned_start`, `planned_end`, `actual_start`, `actual_end`, `status`, `completion_attribution_user_id`, `completion_signature_id`, `evidence_references_jsonb`.  |
| URS-13-DATA-008 | `change_effectiveness_checks` with `id`, `change_request_id`, `description`, `planned_check_date`, `actual_check_date`, `outcome`, `issue_payload_jsonb`, `verifier_user_id`, `verifier_signature_id`.  |
| URS-13-DATA-009 | `change_cross_module_linkages` with `id`, `change_request_id`, `target_module`, `target_entity_type`, `target_entity_id`, `linkage_status` (`pending` / `linkage_updated`), `updated_by_user_id`, `updated_at`.  |
| URS-13-DATA-010 | `change_request_supersession_links` with `predecessor_id`, `successor_id`, `reason`, `created_by`, `created_at`. |
| URS-13-DATA-011 | All Module 13 tables have RLS enabled per QS-6. |
| URS-13-DATA-012 | All mutations record to URS-06 audit substrate via `auditTrailService.log()` per QS-1. |

### 6.3 API requirements

| Endpoint | Method | Purpose | Priority |
|---|---|---|---|
| `/api/v1/change-control` | GET | List change requests within tenant + scope | MUST |
| `/api/v1/change-control` | POST | Create draft | MUST |
| `/api/v1/change-control/:id` | GET | Get change request | MUST |
| `/api/v1/change-control/:id` | PATCH | Update draft | MUST |
| `/api/v1/change-control/:id/withdraw` | POST | Withdraw pre-decision | MUST |
| `/api/v1/change-control/:id/submit-to-impact` | POST | Transition draft → impact_assessment | MUST |
| `/api/v1/change-control/:id/impact-items` | GET, POST | List + add impact items | MUST |
| `/api/v1/change-control/:id/submit-to-cab` | POST | Transition impact_assessment → cab_review (required category coverage check) | MUST |
| `/api/v1/change-control/:id/approvals` | GET | List approvals for request | MUST |
| `/api/v1/change-control/:id/approvals` | POST (with authority + SoD + e-sign) | Final approval row insert + matrix aggregation | MUST |
| `/api/v1/change-control/:id/approvals/:approvalId/condition` | POST | Add condition to conditional approval | MUST |
| `/api/v1/change-control/:id/approvals/:approvalId/condition/:conditionId/discharge` | POST (with authority + SoD) | Discharge condition | MUST |
| `/api/v1/change-control/:id/start-implementation` | POST (with authority) | Transition approved → implementing | MUST |
| `/api/v1/change-control/:id/implementation-steps` | GET, POST | List + add implementation steps | MUST |
| `/api/v1/change-control/:id/implementation-steps/:stepId` | PATCH | Update step (status, dates) | MUST |
| `/api/v1/change-control/:id/implementation-steps/:stepId/complete` | POST (with authority + e-sign) | E-sign step completion | MUST |
| `/api/v1/change-control/:id/complete-implementation` | POST (with authority) | Transition implementing → verification (steps complete check) | MUST |
| `/api/v1/change-control/:id/effectiveness-checks` | GET, POST | List + add checks | MUST |
| `/api/v1/change-control/:id/effectiveness-checks/:checkId/sign` | POST (with authority + SoD + e-sign) | E-sign check outcome | MUST |
| `/api/v1/change-control/:id/cross-module-linkages` | GET, POST | List + add cross-module linkages | MUST |
| `/api/v1/change-control/:id/cross-module-linkages/:linkageId/update` | PATCH | Mark linkage updated | MUST |
| `/api/v1/change-control/:id/close` | POST (with authority + SoD + e-sign + 5 prerequisites) | Closure attestation | MUST |
| `/api/v1/change-control/:id/reopen` | POST (executive authority + reason) | Reopen closed request | MUST |
| `/api/v1/change-control/:id/supersede` | POST | Mark as superseded by successor | MUST |
| `/api/v1/change-control/:id/archive` | POST (with authority) | Archive withdrawn or rejected | MUST |
| `/api/v1/change-control/:id/audit` | GET | Per-request audit trail | MUST |
| `/api/v1/change-control/me/assignments` | GET | My open assignments | MUST |
| `/api/v1/change-control/admin/matrix` | GET, PUT (with admin authority) | Per-classification approval-matrix configuration | MUST |
| `/api/v1/change-control/admin/categories` | GET, PUT (with admin authority) | Required impact-assessment category configuration | MUST |

### 6.4 Workflow / lifecycle requirements

- URS-13-WF-001: Change-request state transitions follow the canonical state machine in `workflow.ts`; unauthorised transitions are rejected with HTTP 422 and error code `CHANGE_CONTROL_INVALID_TRANSITION`.
- URS-13-WF-002: Submit-to-CAB transition validates required category coverage per DEC-13-04 matrix; missing coverage returns HTTP 422 with `CHANGE_CONTROL_REQUIRED_CATEGORY_MISSING`.
- URS-13-WF-003: CAB approval row insertion enforces SoD-13-01 (originator ≠ approver), SoD-13-02 (impact assessor for category ≠ approver for that category), SoD-13-03 (no double-slot satisfaction).
- URS-13-WF-004: CAB matrix aggregation: `approved` requires all required slots e-signed `approved`; `approved_with_conditions` requires all required slots `approved`/`conditional` with at least one `conditional`; `rejected` triggers on any single required slot `rejected`.
- URS-13-WF-005: Final approval requires `withAuthority({ requiredAuthorityKey: 'final_quality_approver', requiresEsign: true, requiresDelegationValidation: true })`; service-boundary verification of `esig_id` against URS-04 substrate.
- URS-13-WF-006: Critical-system changes (per DEC-13-21) auto-add executive authority slot to matrix.
- URS-13-WF-007: ICH Q12 EC auto-classification (DEC-13-24): scope analysis at submit-to-impact triggers Major auto-flag where applicable; originator override requires QA + RA co-sign.
- URS-13-WF-008: Start-implementation transition checks request is `approved` or `approved_with_conditions`.
- URS-13-WF-009: Complete-implementation transition checks all required implementation steps are `complete` and signed; no `blocked` steps.
- URS-13-WF-010: Effectiveness check signing enforces SoD-13-04 (verifier ≠ implementer for the verified step).
- URS-13-WF-011: Closure transition enforces 5 non-bypassable prerequisites per DEC-13-12 + SoD-13-07.
- URS-13-WF-012: Reopen transition requires executive authority + documented reason; SoD-13-06 enforced.
- URS-13-WF-013: Regulatory submission gating per DEC-13-25: Major changes affecting registered specifications cannot transition `approved → implementing` without an open URS-27 submission record.
- URS-13-WF-014: Withdraw is valid only from `draft`, `impact_assessment`, or `cab_review` states.

### 6.5 Business rules

- BR-13-01: At least one scope anchor required per CC-REQ-001.
- BR-13-02: Tenant isolation enforced via TDAL + RLS on every operation.
- BR-13-03: Implementation step uniqueness per DEC-13-10: no duplicate descriptions without explicit "intentional duplicate" flag.
- BR-13-04: Effectiveness check schedule defaults per DEC-13-11: Major = 6-month; Minor = 3-month; Administrative = none required; Like-for-Like = 3-month equivalence.
- BR-13-05: Reopen requires executive authority co-sign per DEC-13-22.
- BR-13-06: Critical-system changes require executive authority co-sign per DEC-13-21.
- BR-13-07: Tenant offboarding cascade per DEC-13-23: open requests archived; closed preserved.
- BR-13-08: Per Annex 22 / DEC-13-18: NO LLM / generative AI in approval, classification, or closure decision paths. Static deterministic AI is advisory only.
- BR-13-09: All advisory AI output is preserved in audit trail even when overridden per ARCH-AI-001 AC-6.
- BR-13-10: Audit trail is append-only per QS-1; no UPDATE or DELETE on `change_request_state_events`.

### 6.6 Audit trail requirements

- Every Module 13 mutation calls `auditTrailService.log()` with `tenantId`, `userId`, `action`, `resourceType`, `resourceId`, `details` (before-state + after-state), `ipAddress`, `timestamp`. Per QS-1.
- Lifecycle transitions log to `change_request_state_events` AND URS-06 audit substrate (dual write).
- Impact items, approvals (with conditions), implementation steps (add/update/complete), effectiveness checks (add/sign), cross-module linkages (add/update), closure all log to URS-06 per CC-REQ-010.
- Auth-related events (SoD violations, authority denials, executive authority co-signs) log to `auth_audit_log` (URS-06 substrate).
- Advisory AI requests log to `ai_requests` per ARCH-AI-001 AC-5.

### 6.7 Architecture binding — Annex 22 GenAI prohibition + ARCH-AI-001 advisory governance

| Surface | AI use permitted | Governance |
|---|---|---|
| CAB approval decision | NONE — Annex 22 prohibition | Manual decision only; no AI in approval path |
| Change classification | NONE — Annex 22 prohibition (rule-based ICH Q12 EC auto-flag is deterministic logic, not AI) | Manual classification + deterministic rule engine |
| Closure decision | NONE — Annex 22 prohibition | Manual closure attestation; deterministic prerequisite check |
| Effectiveness check outcome | NONE — Annex 22 prohibition | Manual verifier outcome only |
| Impact-assessment domain suggestion (advisory) | Static deterministic AI only | ARCH-AI-001 AC-1..AC-7; visible advisory labelling; no autonomous write; full audit trail |
| Cross-module linkage suggestion (advisory) | Static deterministic AI only | ARCH-AI-001 AC-1..AC-7 |
| Implementation step template suggestion (advisory) | Static deterministic AI only | ARCH-AI-001 AC-1..AC-7 |

 The Annex 22 prohibition is non-negotiable; no future change may introduce generative / probabilistic AI into the approval, classification, or closure decision paths.

---

## 7. Cross-Module Wiring and Change-Impact

### 7.1 Cross-module wiring

```mermaid
flowchart LR
  M01[URS-01 Auth] --> M13[Module 13]
  M02[URS-02 RBAC] --> M13
  M03[URS-03 Active Scope] --> M13
  M04[URS-04 Workflow / E-Sign] --> M13
  M05[URS-05 Authority Profiles] --> M13
  M06[URS-06 Audit Substrate] <-- M13
  M07[URS-07 Study] <--> M13
  M09[URS-09 Site] <--> M13
  M10[URS-10 Product] <--> M13
  M11[URS-11 Supplier] <--> M13
  M12[URS-12 Documents/Libraries] <--> M13
  M14[URS-14 Complaints] --> M13
  M15[URS-15 OOS/OOT] --> M13
  M16[URS-16 Deviations] --> M13
  M18[URS-18 CAPA] <--> M13
  M21[URS-21 Findings] --> M13
  M22[URS-22 Inspection Mgmt] --> M13
  M23[URS-23 Batch Records] <--> M13
  M27[URS-27 Reg Intelligence] <--> M13
  M28[URS-28 Training] <-- M13
  M30[URS-30 Notifications] <-- M13
  ANNEX22[Annex 22 GenAI prohibition] -.governs.-> M13
  ARCHAI[ARCH-AI-001 advisory AI] -.governs.-> M13
```

Diagram 7.1-A — Module 13 cross-module wiring. Module 13 is the convergence point for every regulated change across the platform.

### 7.2 Change-Impact Matrix (CIM)

| Module 13 capability | Affects | Direction | Trigger if modified |
|---|---|---|---|
| Lifecycle state machine | All consuming modules | Outbound | Class 1 change |
| Per-classification approval matrix | URS-04, URS-05 | Bidirectional | Class 2 change |
| Required category coverage matrix | URS-04 | Outbound | Class 2 change |
| `affected_entity_type` enum | URS-09, URS-10, URS-11, URS-12, URS-23, URS-27 | Outbound | Class 1 change |
| Effectiveness-check schedule defaults | All consuming modules | Outbound | Class 2 change |
| Critical-system definition (DEC-13-21) | All consuming modules | Outbound | Class 1 change |
| ICH Q12 EC auto-classification ruleset | URS-10, URS-27 | Outbound | Class 1 change |
| Reopen executive authority co-sign requirement | URS-05 | Outbound | Class 1 change |

### 7.3 Cross-module dependencies (consumed by Module 13)

- URS-01 — Authentication and session.
- URS-02 — RBAC permission grants (`change-control:*`).
- URS-03 — Active scope (tenant + site + product + study + region + supplier).
- URS-04 — Workflow / e-signature substrate (HITL service, Controlled Approval Modal).
- URS-05 — Authority Profile registry (`final_quality_approver`, `cab_approval_matrix_member`, `change_*` profiles).
- URS-06 — Audit trail substrate (`audit_trail`, `auth_audit_log`, `ai_requests`).
- URS-07 — Study Management.
- URS-08 — Tenant lifecycle (offboarding cascade).
- URS-09 — Site / facility / equipment.
- URS-10 — Product / specification / registration impact.
- URS-11 — Supplier qualification / SCN.
- URS-12 — Document Control / Document Review / Knowledge Libraries.
- URS-14 — Complaints (precipitate changes).
- URS-15 — OOS / OOT (precipitate changes).
- URS-16 — Deviations (precipitate changes via `related_deviation_id`).
- URS-18 — CAPA (changes implement CAPAs).
- URS-21 — Findings (precipitate changes).
- URS-22 — Inspection Management (observations precipitate changes).
- URS-23 — Batch Records (boundary).
- URS-27 — Regulatory Intelligence (commitments + submissions).
- URS-28 — Training (changes trigger training updates).
- URS-30 — Notifications.
- EU GMP Annex 22 — GenAI prohibition in critical decision paths.
- ARCH-AI-001 — Advisory AI binding.

---

## 8. AI / Automation / Human-in-the-Loop Controls

Per **EU GMP Annex 22 (Draft 2025) §critical-decision prohibition** and DEC-13-18, generative / probabilistic AI is **PROHIBITED** in Module 13 approval, classification, and closure decision paths. Static deterministic AI may be used in advisory roles only, governed by ARCH-AI-001 AC-1..AC-7.

| AI Surface | Permitted | Governance |
|---|---|---|
| AI-suggested CAB decision | NO (Annex 22 prohibition) | Not built; never built |
| AI-suggested classification | NO (Annex 22 prohibition) | Not built; deterministic rule engine for ICH Q12 EC auto-flag |
| AI-suggested closure | NO (Annex 22 prohibition) | Not built |
| AI-suggested effectiveness outcome | NO (Annex 22 prohibition) | Not built |
| Impact-assessment domain suggestion (static deterministic) | YES — advisory | ARCH-AI-001 AC-1..AC-7; visible "AI-suggested" label; no autonomous write; full audit |
| Cross-module linkage suggestion (static deterministic) | YES — advisory | ARCH-AI-001 AC-1..AC-7 |
| Implementation step template suggestion (static deterministic) | YES — advisory | ARCH-AI-001 AC-1..AC-7 |
| MIRA copilot read-only retrieval over closed change-request audit trail | YES — read-only retrieval (no write) | RAG retrieval per URS-12; logging per ARCH-AI-001 AC-5 |

All advisory AI output is visibly labelled "AI-suggested — requires human review" per ARCH-AI-001 AC-3. All advisory output is preserved in audit trail even when overridden per AC-6. No AI service is the sole path to act on a change request.

---

## 9. Reports, Dashboards, and Exports

| Report / Dashboard | Purpose | Audience |
|---|---|---|
| Change-request inventory | All change requests by classification, lifecycle, scope | QA, RA, Engineering, Manufacturing |
| Lifecycle aging dashboard | Time in each state per request | QA, change-control management |
| Approval-decision SLA dashboard | Time to CAB decision vs. SLA | QA, CAB chair |
| Effectiveness-check pass-rate dashboard | % effective vs. partial vs. ineffective by classification, by product, by site | QA, RA |
| Overdue implementation steps | Steps past planned_end without completion | Implementation leads |
| Overdue effectiveness checks | Checks past planned_check_date without sign | Verification leads |
| Conditional-approval condition-discharge queue | Open conditions and discharge status | QA |
| Critical-system change executive authority co-sign queue | Pending executive authority co-signs | Executive authority |
| Reopen audit register | Reopened change requests with reason and executive authority attribution | QA, RA, executive authority |
| Cross-module linkage status | Linkages by status (`pending` / `linkage_updated`) | All consuming module owners |
| Tenant cross-tenant change indices (platform admin only) | Aggregate Module 13 events across tenants | `platform_admin` |

Exports:

- Change-request evidence pack (zipped: full request + impact + approvals + steps + checks + conditions + linkages + closure + URS-06 audit excerpt with hash-chain proof).
- Per-classification approval-matrix configuration export.
- Audit trail export (URS-06 substrate; date-range scoped; signed export).
- Inspection-ready evidence pack (multi-request export for an inspection scope).

---

## 10. Notifications and Queues

| Event | Trigger | Recipients | Channel |
|---|---|---|---|
| Change request created | `change-control:create` | Originator confirmation; QA queue | URS-30 in-app |
| Submit to impact assessment | `submit_to_impact` | Required functional leads per matrix | URS-30 in-app + email |
| Required category coverage incomplete (reminder) | Periodic check vs. SLA | Originator + uncovered category leads | URS-30 reminder |
| Submit to CAB | `submit_to_cab` | CAB members per classification matrix | URS-30 in-app + email |
| CAB approval slot signed | `approve` / `conditional` / `reject` | Originator + remaining slots | URS-30 in-app |
| Change approved | All slots signed approved | Originator + implementation team | URS-30 in-app + email |
| Change approved with conditions | All slots approved/conditional | Originator + condition dischargers | URS-30 in-app + email |
| Change rejected | Any slot rejected | Originator + all participants | URS-30 in-app + email |
| Critical-system executive authority co-sign required | Critical change reaches CAB | Executive authority + executive office | URS-30 critical |
| Start implementation | `start_implementation` | Implementation team | URS-30 in-app |
| Implementation step due | `planned_end` reminder | Step responsible | URS-30 reminder |
| Implementation step overdue | Past `planned_end` without complete | Step responsible + change owner | URS-30 critical |
| Complete implementation | `complete_implementation` | Verification team | URS-30 in-app |
| Effectiveness check due | `planned_check_date` reminder | Verifier | URS-30 reminder |
| Effectiveness check ineffective | `outcome=ineffective` signed | Originator + QA + change owner | URS-30 critical |
| Condition discharge due | `target_discharge_date` reminder | Discharger + QA | URS-30 reminder |
| Closure attempted with prerequisite failure | Any prerequisite blocks | Closure authority + QA | URS-30 in-app |
| Change closed | `close` | All stakeholders | URS-30 in-app + email |
| Change reopened | executive authority co-sign | Originator + QA + RA + executive office | URS-30 critical |
| Change superseded | New successor created | Stakeholders | URS-30 in-app |
| Tenant offboarding cascade | URS-08 cascade | All open-request stakeholders | URS-30 in-app |

---

## 11. Error Handling and Negative Paths

### 11.1 Error envelope

All Module 13 errors return the `AppError` envelope per QS-9: `{ error: string, code: string, details?: unknown }`. No stack traces, SQL errors, table names, or internal paths in API responses.

### 11.2 Error-code catalogue

| Code | HTTP | Meaning |
|---|---|---|
| `CHANGE_CONTROL_NOT_FOUND` | 404 | Change request ID not in tenant scope |
| `CHANGE_CONTROL_INVALID_TRANSITION` | 422 | Lifecycle transition not allowed from current state |
| `CHANGE_CONTROL_AUTHORITY_REQUIRED` | 403 | Authority Profile required |
| `CHANGE_CONTROL_SCOPE_ANCHOR_REQUIRED` | 400 | At least one scope anchor required (CC-REQ-001 / BR-13-01) |
| `CHANGE_CONTROL_REQUIRED_CATEGORY_MISSING` | 422 | Required impact-assessment category coverage incomplete (CC-REQ-003 / DEC-13-04) |
| `CHANGE_CONTROL_SOD_VIOLATION_ORIGINATOR_CANNOT_APPROVE` | 403 | SoD-13-01 — originator cannot approve own request |
| `CHANGE_CONTROL_SOD_VIOLATION_ASSESSOR_CANNOT_APPROVE_OWN_CATEGORY` | 403 | SoD-13-02 |
| `CHANGE_CONTROL_SOD_VIOLATION_DOUBLE_SLOT` | 403 | SoD-13-03 — same user cannot satisfy two slots |
| `CHANGE_CONTROL_SOD_VIOLATION_VERIFIER_EQUALS_IMPLEMENTER` | 403 | SoD-13-04 |
| `CHANGE_CONTROL_SOD_VIOLATION_DISCHARGE_AUTHOR` | 403 | SoD-13-05 |
| `CHANGE_CONTROL_SOD_VIOLATION_EXECUTIVE_REPEAT` | 403 | SoD-13-06 |
| `CHANGE_CONTROL_SOD_VIOLATION_CLOSURE` | 403 | SoD-13-07 |
| `CHANGE_CONTROL_MATRIX_QUORUM_NOT_MET` | 422 | Matrix quorum minimum not satisfied |
| `CHANGE_CONTROL_ESIG_VERIFICATION_FAILED` | 422 | E-signature service-boundary verification failed (CC-REQ-005) |
| `CHANGE_CONTROL_CLOSURE_BLOCKED_STEPS_INCOMPLETE` | 422 | Closure prereq 1 fail |
| `CHANGE_CONTROL_CLOSURE_BLOCKED_INEFFECTIVE_CHECK` | 422 | Closure prereq 2 fail |
| `CHANGE_CONTROL_CLOSURE_BLOCKED_CONDITION_OPEN` | 422 | Closure prereq 3 fail |
| `CHANGE_CONTROL_CLOSURE_BLOCKED_LINKAGE_PENDING` | 422 | Closure prereq 4 fail |
| `CHANGE_CONTROL_REOPEN_EXECUTIVE_AUTHORITY_REQUIRED` | 403 | Reopen requires executive authority co-sign per DEC-13-22 |
| `CHANGE_CONTROL_CRITICAL_EXECUTIVE_AUTHORITY_REQUIRED` | 403 | Critical-system change requires executive authority slot per DEC-13-21 |
| `CHANGE_CONTROL_REGULATORY_SUBMISSION_GATE` | 422 | Major change to registered spec needs URS-27 submission per DEC-13-25 |
| `CHANGE_CONTROL_DUPLICATE_STEP_DESCRIPTION` | 400 | Implementation step uniqueness per DEC-13-10 |
| `CHANGE_CONTROL_GENAI_PROHIBITED` | 403 | Generative / probabilistic AI not permitted in this surface (Annex 22 / DEC-13-18) |
| `VALIDATION_FAILED` | 400 | Zod validation failed |
| `SCOPE_MISMATCH` | 403 | Active scope does not include this resource |

### 11.3 Negative-path catalogue

- Originator submits without scope anchor → `CHANGE_CONTROL_SCOPE_ANCHOR_REQUIRED`.
- Submit-to-CAB without required category coverage → `CHANGE_CONTROL_REQUIRED_CATEGORY_MISSING`; response identifies missing categories.
- Originator attempts CAB approval on own request → `CHANGE_CONTROL_SOD_VIOLATION_ORIGINATOR_CANNOT_APPROVE`.
- Same user signs two matrix slots → `CHANGE_CONTROL_SOD_VIOLATION_DOUBLE_SLOT`.
- Closure attempted with ineffective check → `CHANGE_CONTROL_CLOSURE_BLOCKED_INEFFECTIVE_CHECK`; response identifies failing check.
- Closure attempted with open condition → `CHANGE_CONTROL_CLOSURE_BLOCKED_CONDITION_OPEN`; response lists open conditions.
- Reopen attempted by non-executive-authority → `CHANGE_CONTROL_REOPEN_EXECUTIVE_AUTHORITY_REQUIRED`.
- Critical-system change attempted approve without executive authority slot → `CHANGE_CONTROL_CRITICAL_EXECUTIVE_AUTHORITY_REQUIRED`.
- Major spec change attempts implementing without URS-27 submission → `CHANGE_CONTROL_REGULATORY_SUBMISSION_GATE`.
- Generative AI invocation in approval/classification/closure path → `CHANGE_CONTROL_GENAI_PROHIBITED` (Annex 22).

---

## 12. Security, Privacy, and Tenant Isolation

### 12.1 Authentication dependency

All Module 13 routes require a valid URS-01 authenticated session; anonymous access is prohibited.

### 12.2 Authorisation pipeline

Three-guard hierarchy on every Module 13 mutation: RoleGuard → PermissionGuard → AuthorityGuard. Per QS-7. `requirePermission('change-control:approve')` checks RBAC; `withAuthority('final_quality_approver')` checks Authority Profile.

### 12.3 Tenant isolation

Every database operation goes through TDAL (`tdal.withTenant(tenantId, ...)`); raw `db.query` calls outside TDAL are prohibited per QS-5. Every Module 13 table has RLS enabled per QS-6.

### 12.4 Encryption

Change requests, impact items, approvals, conditions, steps, checks, linkages — all stored with platform standard at-rest encryption. TLS 1.2+ in transit.

### 12.5 Logging hygiene

No PHI / PII / passwords / API keys / raw e-signature secrets in operational logs per QS-19. Change-request content is referenced by ID only in operational logs.

### 12.6 Privacy and data residency

Module 13 records inherit the tenant's data residency configuration (US / EU / India / UK / Canada / Japan).

### 12.7 Periodic access review

Per QS-7 and URS-02 cadence: per-tenant CAB-membership and Authority Profile review every 6 months by `quality_lead` + `admin`; cross-tenant entitlement review every 12 months by `platform_admin`.

### 12.8 Periodic audit-trail review

Per QS-19 and URS-06 cadence: monthly Module 13 audit-trail sample review by `quality_lead`; quarterly tenant-wide audit-trail integrity check by `platform_admin`.

### 12.9 Security-operations alert thresholds

| Alert | Threshold |
|---|---|
| SoD violations | Any (SoD-13-01..07) |
| Authority denials on approval | >5 in 1 hour for one user |
| executive authority co-sign | Any (always alert) |
| Reopen | Any (always alert) |
| Closure prerequisite failures | >3 in 1 day for one user |
| Bulk export | >20 change requests in 1 hour for one user |
| GenAI prohibition violation attempt | Any (always critical alert) |

### 12.10 Self-modification block

Module 13 services cannot modify their own audit trail entries or configuration tables; admin-only configuration via dedicated admin routes.

### 12.11 Secure export

Evidence-pack exports are watermarked, audit-logged, and downloaded over TLS. Bulk exports require additional authority.

### 12.12 Cross-tenant confidentiality envelope

Module 13 enforces the cross-tenant envelope: tenant A cannot read tenant B's change requests under any RBAC permission; only `platform_admin` operating in `tdal.withPlatformContext()` can do cross-tenant operations, and those are exclusively read-only for audit indexing.

---

## 13. Data Integrity and ALCOA+ Controls

| ALCOA+ Principle | Module 13 Implementation |
|---|---|
| Attributable | Every change request, impact item, approval, condition, step, check, closure attestation carries `created_by` / `signed_by` (URS-01 user ID). Per QS-2. |
| Legible | Records stored in human-readable form; structured payloads in JSONB; UI renders them with full attribution. |
| Contemporaneous | Server-generated timestamps via `NOW()`; `created_at` immutable; client timestamps not trusted. Per QS-3. |
| Original | Original draft preserved on supersede; original AI advisory output preserved when overridden. Per QS-4. |
| Accurate | Schema and Zod validation at boundary per QS-8; referential integrity enforced per QS-14; matrix prevents incorrect approver. |
| Complete | All required fields enforced at validation; required category coverage enforced; closure prerequisites non-bypassable. |
| Consistent | Context model consistent across schema, persistence, filter (MUST|
| Enduring | Records preserved per retention class; audit trail append-only per QS-1; legal-hold supported. |
| Available | Tenant-scoped retrieval available to authorised users; evidence pack export available; audit export available. |
| Traceable | Hash-chained URS-06 audit; per-request audit view; cross-module reference chain; full lifecycle audit. |

---

## 14. Regulatory Mapping

### 14.1 Predicate-rule applicability matrix

| Regulatory authority | Predicate | Module 13 obligation |
|---|---|---|
| FDA | 21 CFR Part 11 §11.10(a) | Module 13 must be validated per QS-15, QS-16; URS-13-VAL-* |
| FDA | 21 CFR Part 11 §11.10(d) | Three-guard RBAC + Authority Profile |
| FDA | 21 CFR Part 11 §11.10(e) | URS-06 hash-chained audit substrate, append-only |
| FDA | 21 CFR Part 11 §11.50/§11.70/§11.100/§11.200/§11.300 | Controlled Approval Modal contract |
| FDA | 21 CFR Part 211 §211.100 (GMP procedures and records) | Change-control workflow |
| FDA | 21 CFR Part 211.100(a) (written procedures for production and process control) | Change-control governance |
| EMA | EU GMP Annex 11 §4 / §9 / §12 / §16 | Module 13 validation, audit, security, incident handling |
| EMA / PIC/S | EU GMP Annex 15 (Qualification and Validation) | Re-qualification triggers per DEC-13-11 |
| EMA / PIC/S | EU GMP Chapter 1 §1.4 (Quality Management) | Change-management element of PQS |
| Internal architectural control (forward-looking; not enacted predicate rule) | EU GMP Annex 22 (Draft 2025) §critical-decision prohibition | Annex 22 GenAI prohibition per DEC-13-18 (treated as internal forward-looking control; jurisdiction-specific legal enforceability subject to future legal assessment) |
| Internal architectural control (forward-looking; not enacted predicate rule) | EU AI Act Art. 13 — Transparency principles for advisory AI | Visible advisory labelling per ARCH-AI-001 AC-3 (treated as internal control aligned with transparency principles; jurisdiction-specific legal enforceability subject to future legal assessment) |
| MHRA | MHRA Data Integrity Guidance — ALCOA+ | Per §13 |
| Health Canada | C.02.020 — GMP records | Change-control register and retention |
| ICH | ICH Q10 — Pharmaceutical QMS | Change-management element |
| ICH | ICH Q12 — Lifecycle management / Established Conditions | Auto-classification per DEC-13-24 |
| ICH | ICH Q9 — Quality Risk Management | Risk-based assessment in impact assessment |
| ICH | ICH GCP E6(R3) — Good Clinical Practice | Clinical study change governance |
| GAMP | GAMP 5 Cat 5 — Custom application | Validation per §17 |
| FDA | FDA CSA Final Guidance (Sep 2025) | Risk-based testing approach |
| WHO | TRS 996 Annex 5 — Good data management | ALCOA+ implementation |
| India CDSCO (per applicable scope) | India Drugs and Cosmetics Act 1940 + Drugs Rules 1945 + Revised Schedule M (change governance over GMP-validated systems / processes / specifications / sites) + Schedule M-III (where distribution-change scope) + New Drugs and Clinical Trials Rules 2019 (where clinical-protocol-change or clinical-system-change scope) + Medical Devices Rules 2017 (where device / combination-product change scope) — Applicable per India tenant operation and jurisdictional regulatory assessment | Change Control register, impact assessment, approval matrix, post-implementation effectiveness verification, retention per regulatory framework; external jurisdictional legal / RA confirmation required for clause / form applicability per India change scope |

---

## 15. URS Requirements Register

### 15.1 Front-end (FE)

| ID | Requirement | Priority |
|---|---|---|
| URS-13-FE-001 | Change Control landing route at `/change-control` | MUST |
| URS-13-FE-002 | Create change request route | MUST |
| URS-13-FE-003 | Change request detail route with lifecycle / impact / approvals / implementation / verification / closure tabs | MUST |
| URS-13-FE-004 | CAB approval matrix viewer with quorum + non-duplication indicator | MUST |
| URS-13-FE-005 | Required category coverage matrix viewer | MUST |
| URS-13-FE-006 | Implementation step editor + completion sign modal | MUST |
| URS-13-FE-007 | Effectiveness check editor + sign modal | MUST |
| URS-13-FE-008 | Conditional approval condition editor + discharge modal | MUST |
| URS-13-FE-009 | Closure prerequisite checklist viewer (5 prerequisites live status) | MUST |
| URS-13-FE-010 | Cross-module linkage panel | MUST |
| URS-13-FE-011 | AI advisory banner on every advisory AI surface (ARCH-AI-001 AC-3) | MUST |
| URS-13-FE-012 | Executive authority reopen modal | MUST |
| URS-13-FE-013 | Executive authority critical-system co-sign queue | MUST |
| URS-13-FE-014 | Approval-decision SLA dashboard | MUST |
| URS-13-FE-015 | Effectiveness-check pass-rate dashboard | MUST |
| URS-13-FE-016 | Overdue implementation steps + checks dashboard | MUST |
| URS-13-FE-017 | Lifecycle aging dashboard | MUST |
| URS-13-FE-018 | Per-classification approval-matrix configuration UI (`admin`+) | MUST |
| URS-13-FE-019 | Required category coverage configuration UI (`admin`+) | MUST |
| URS-13-FE-020 | WCAG 2.1 AA across all routes | MUST |
| URS-13-FE-021 | i18n / l10n across all UI strings | MUST |
| URS-13-FE-022 | ErrorBoundary + loading/error/empty states per QS-17 | MUST |
| URS-13-FE-023 | Per-request audit trail view | MUST |
| URS-13-FE-024 | Watermarked evidence-pack export preview | MUST |
| URS-13-FE-025 | Annex 22 GenAI prohibition surface (no CAB / classification / closure AI surface offered) | MUST (negative requirement) |

### 15.2 Back-end (BE)

| ID | Requirement | Priority |
|---|---|---|
| URS-13-BE-001 | `change-control` REST surface per §6.3 | MUST |
| URS-13-BE-002 | `workflow.ts` state machine matches §6.4 | MUST |
| URS-13-BE-003 | Required category coverage check at `submit_to_cab` | MUST |
| URS-13-BE-004 | CAB matrix + quorum + non-duplication enforcement | MUST |
| URS-13-BE-005 | Service-layer SoD enforcement (SoD-13-01..07) | MUST |
| URS-13-BE-006 | E-signature service-boundary verification | MUST |
| URS-13-BE-007 | Explicit start_implementation / complete_implementation routes | MUST |
| URS-13-BE-008 | Implementation step completion e-sign route | MUST |
| URS-13-BE-009 | Effectiveness check sign route + SoD-13-04 | MUST |
| URS-13-BE-010 | Conditional approval condition routes (add + discharge with SoD-13-05) | MUST |
| URS-13-BE-011 | Closure prerequisite check route + SoD-13-07 | MUST |
| URS-13-BE-012 | Reopen route with executive authority + SoD-13-06 | MUST |
| URS-13-BE-013 | Supersede route | MUST |
| URS-13-BE-014 | Withdraw route | MUST |
| URS-13-BE-015 | Archive route | MUST |
| URS-13-BE-016 | Cross-module linkage routes | MUST |
| URS-13-BE-017 | Per-request audit trail route | MUST |
| URS-13-BE-018 | My-assignments route | MUST |
| URS-13-BE-019 | Admin matrix configuration routes | MUST |
| URS-13-BE-020 | Critical-system Executive authority slot auto-add per DEC-13-21 | MUST |
| URS-13-BE-021 | ICH Q12 EC auto-classification deterministic rule engine per DEC-13-24 | MUST |
| URS-13-BE-022 | Regulatory submission gating per DEC-13-25 | MUST |
| URS-13-BE-023 | Tenant offboarding cascade per DEC-13-23 | MUST |

### 15.3 Workflow (WF)

| ID | Requirement | Priority |
|---|---|---|
| URS-13-WF-001..014 | Per §6.4 | MUST |

### 15.4 Data (DATA)

| ID | Requirement | Priority |
|---|---|---|
| URS-13-DATA-001..012 | Per §6.2 | MUST |

### 15.5 Security (SEC)

| ID | Requirement | Priority |
|---|---|---|
| URS-13-SEC-001 | Three-guard RBAC + Authority pipeline | MUST |
| URS-13-SEC-002 | TDAL on every DB op per QS-5 | MUST |
| URS-13-SEC-003 | RLS on every Module 13 table per QS-6 | MUST |
| URS-13-SEC-004 | Cross-tenant envelope enforcement | MUST |
| URS-13-SEC-005 | Watermarked evidence-pack export | MUST |
| URS-13-SEC-006 | Bulk export authority gate | MUST |
| URS-13-SEC-007 | Self-modification block | MUST |
| URS-13-SEC-008 | Periodic CAB-membership review cadence | MUST |
| URS-13-SEC-009 | Periodic audit-trail integrity check | MUST to Module 13 indices |
| URS-13-SEC-010 | GenAI prohibition runtime block in approval/classification/closure paths | MUST |

### 15.6 Audit (AUD)

| ID | Requirement | Priority |
|---|---|---|
| URS-13-AUD-001 | Every mutation calls `auditTrailService.log()` per QS-1 | MUST|
| URS-13-AUD-002 | Lifecycle transitions logged dual-write to `change_request_state_events` + URS-06 | MUST |
| URS-13-AUD-003 | Impact items add audit | MUST |
| URS-13-AUD-004 | Implementation steps add/update audit | MUST |
| URS-13-AUD-005 | Effectiveness checks add/sign audit | MUST |
| URS-13-AUD-006 | Auth-related events to `auth_audit_log` | MUST |
| URS-13-AUD-007 | Advisory AI requests to `ai_requests` per ARCH-AI-001 AC-5 | MUST |
| URS-13-AUD-008 | Append-only audit per QS-1 | MUST |
| URS-13-AUD-009 | Per-request audit view route | MUST |
| URS-13-AUD-010 | Hash-chained URS-06 integrity validated periodically | MUST |

### 15.7 AI / HITL (AI)

| ID | Requirement | Priority |
|---|---|---|
| URS-13-AI-001 | NO LLM/GenAI in approval/classification/closure decision paths per Annex 22 | MUST (negative — runtime block + linting + design review) |
| URS-13-AI-002 | Static deterministic AI advisory in impact-assessment domain suggestion permitted | MUST |
| URS-13-AI-003 | Visible "AI-suggested" labelling per ARCH-AI-001 AC-3 | MUST |
| URS-13-AI-004 | No autonomous write per ARCH-AI-001 AC-4 | MUST |
| URS-13-AI-005 | Override capability with reason per ARCH-AI-001 AC-6 | MUST |
| URS-13-AI-006 | Full AI request audit per ARCH-AI-001 AC-5 | MUST |
| URS-13-AI-007 | Internal forward-looking AI governance evidence (EU AI Act Art. 13 transparency principles) | MUST |

### 15.8 Integration (INT)

| ID | Requirement | Priority |
|---|---|---|
| URS-13-INT-001 | URS-01 authentication consumed | MUST |
| URS-13-INT-002 | URS-02 RBAC consumed | MUST |
| URS-13-INT-003 | URS-03 active scope consumed | MUST |
| URS-13-INT-004 | URS-04 e-signature consumed | MUST |
| URS-13-INT-005 | URS-05 Authority Profile consumed (`final_quality_approver` + new profiles) | MUST |
| URS-13-INT-006 | URS-06 audit substrate consumed | MUST |
| URS-13-INT-007 | URS-07 Study scope linkage | MUST |
| URS-13-INT-008 | URS-08 tenant offboarding cascade | MUST |
| URS-13-INT-009 | URS-09 Site linkage | MUST |
| URS-13-INT-010 | URS-10 Product linkage | MUST |
| URS-13-INT-011 | URS-11 Supplier linkage | MUST |
| URS-13-INT-012 | URS-12 Document/Library linkage | MUST |
| URS-13-INT-013 | URS-14 Complaints inbound trigger | MUST |
| URS-13-INT-014 | URS-15 OOS/OOT inbound trigger | MUST |
| URS-13-INT-015 | URS-16 Deviations inbound trigger via `related_deviation_id` | MUST |
| URS-13-INT-016 | URS-18 CAPA bidirectional | MUST |
| URS-13-INT-017 | URS-21 Findings inbound trigger | MUST |
| URS-13-INT-018 | URS-22 Inspection observations inbound trigger | MUST |
| URS-13-INT-019 | URS-23 Batch Records boundary | MUST |
| URS-13-INT-020 | URS-27 Regulatory Intelligence linkage + submission gating per DEC-13-25 | MUST |
| URS-13-INT-021 | URS-28 Training-update outbound | MUST |
| URS-13-INT-022 | URS-30 Notifications wired for all events per §10 | MUST |
| URS-13-INT-023 | Internal forward-looking AI governance evidence (EU GMP Annex 22 Draft 2025) | MUST |
| URS-13-INT-024 | ARCH-AI-001 platform binding | MUST |

### 15.9 Reporting (REP)

| ID | Requirement | Priority |
|---|---|---|
| URS-13-REP-001..011 | Per §9 | MUST |

### 15.10 Notifications (NOTIF)

| ID | Requirement | Priority |
|---|---|---|
| URS-13-NOTIF-001..022 | Per §10 | MUST |

### 15.11 Validation (VAL)

| ID | Requirement | Priority |
|---|---|---|
| URS-13-VAL-001 | URS approval (this document) | Pending Founder + signatories |
| URS-13-VAL-002 | Functional Specification approved | Pending |
| URS-13-VAL-003 | IQ / OQ / PQ executed | Pending |
| URS-13-VAL-004 | Traceability matrix complete | Pending |
| URS-13-VAL-005 | Risk-based testing per FDA CSA | Pending |
| URS-13-VAL-006 | RLS enforcement verified | Pending |
| URS-13-VAL-007 | Audit trail integrity verified | Pending |
| URS-13-VAL-008 | Migration evidence gate (data migration validated) | Pending |
| URS-13-VAL-009 | Internal forward-looking AI governance evidence (EU GMP Annex 22 Draft 2025 GenAI prohibition control) | Pending |
| URS-13-VAL-010 | ARCH-AI-001 AC-1..AC-7 advisory AI compliance evidence | Pending |
| URS-13-VAL-011 | Internal forward-looking AI governance evidence (EU AI Act Art. 13 transparency principles) | Pending |
| URS-13-VAL-012 | SoD-13-01..07 enforcement evidence | Pending |
| URS-13-VAL-013 | Closure prerequisite enforcement evidence | Pending |
| URS-13-VAL-014 | Critical-system executive authority co-sign evidence | Pending |
| URS-13-VAL-015 | Reopen executive authority co-sign evidence | Pending |

---

## 16. Acceptance Criteria and Test Cases

### 16.1 Plain-language test cases

| TC | Plain-language test |
|---|---|
| TC-13-01 | Originator creates draft with classification + scope; submits to impact assessment; required functional leads add signed impact items; required category coverage satisfied; submitted to CAB; matrix-quorum-SoD all satisfied; final approval e-signed; implementation steps planned + executed + signed; verification checks executed + signed effective; closure attestation e-signed; request closed. |
| TC-13-02 | Originator attempts CAB approval on own request; rejected via SoD-13-01. |
| TC-13-03 | Same user signs two matrix slots; rejected via SoD-13-03. |
| TC-13-04 | Submit-to-CAB without required category coverage; rejected via `CHANGE_CONTROL_REQUIRED_CATEGORY_MISSING`. |
| TC-13-05 | Closure attempted with one ineffective check; rejected via `CHANGE_CONTROL_CLOSURE_BLOCKED_INEFFECTIVE_CHECK`. |
| TC-13-06 | Closure attempted with open condition; rejected via `CHANGE_CONTROL_CLOSURE_BLOCKED_CONDITION_OPEN`. |
| TC-13-07 | Critical-system change auto-adds executive authority slot per DEC-13-21; without executive authority sign, request cannot transition to approved. |
| TC-13-08 | Reopen attempted by non-executive-authority; rejected via `CHANGE_CONTROL_REOPEN_EXECUTIVE_AUTHORITY_REQUIRED`. |
| TC-13-09 | Major change to registered spec attempts implementing without URS-27 submission; rejected via `CHANGE_CONTROL_REGULATORY_SUBMISSION_GATE`. |
| TC-13-10 | Conditional approval; condition discharged with evidence and e-signature; closure proceeds. |
| TC-13-11 | Withdraw a draft request before CAB decision; transitions to `withdrawn`; preserved for audit. |
| TC-13-12 | Static deterministic AI advisory suggests impact-assessment domain; assessor accepts/overrides; advisory + decision both audited. |
| TC-13-13 | Generative AI invocation attempted in approval/classification/closure path; runtime block + `CHANGE_CONTROL_GENAI_PROHIBITED`. |
| TC-13-14 | Tenant offboarding cascade; open requests archived; closed records preserved. |
| TC-13-15 | Inspector-ready evidence pack exported with watermark + e-signature + audit hash-chain proof. |

### 16.2 Technical test cases

| TC | Test technique |
|---|---|
| TC-13-T01 | Unit test on service-layer SoD-13-01..07 enforcement; assert HTTP 403 + correct error code. |
| TC-13-T02 | Integration test on approval matrix + quorum aggregation; assert request transitions only when matrix complete. |
| TC-13-T03 | Integration test on required category coverage at submit-to-CAB. |
| TC-13-T04 | Integration test on closure 5-prerequisite check; assert each blocks correctly. |
| TC-13-T05 | Integration test on critical-system Executive authority slot auto-add. |
| TC-13-T06 | Integration test on reopen executive authority co-sign. |
| TC-13-T07 | RLS test: tenant A user cannot read tenant B change requests under any role. |
| TC-13-T08 | Audit test: every mutation produces URS-06 audit entry. |
| TC-13-T09 | E2E test (Playwright): full happy-path lifecycle. |
| TC-13-T10 | Performance test: list filter P95 latency ≤ 500ms with 10K change requests in tenant. |
| TC-13-T11 | Security test: bulk export >20 requests triggers authority gate. |
| TC-13-T12 | Tenant-isolation test: TDAL violation blocked; raw `db.query` outside TDAL detected by lint per Gate 4. |
| TC-13-T13 | Annex 22 negative test: any GenAI invocation in approval/classification/closure path blocked at runtime + lint. |
| TC-13-T14 | E-signature service-boundary verification: routes that bypass URS-04 substrate verification rejected. |

### 16.3 Acceptance criteria

| AC | Statement |
|---|---|
| AC-13-01 | Change-request register supports all launch classifications + lifecycle. |
| AC-13-02 | Required category coverage non-bypassable per CC-REQ-003. |
| AC-13-03 | CAB matrix + quorum + non-duplication enforced per CC-REQ-004. |
| AC-13-04 | SoD-13-01..07 enforced at service layer per CC-REQ-005. |
| AC-13-05 | E-signature service-boundary verification per CC-REQ-005. |
| AC-13-06 | Explicit start_implementation + complete_implementation transitions per CC-REQ-006. |
| AC-13-07 | Implementation step uniqueness per DEC-13-10. |
| AC-13-08 | Closure 5-prerequisite check non-bypassable per CC-REQ-008. |
| AC-13-09 | Reopen requires executive authority co-sign + reason per DEC-13-22. |
| AC-13-10 | Critical-system executive authority co-sign per DEC-13-21. |
| AC-13-11 | Annex 22 GenAI prohibition enforced runtime + lint + design review per DEC-13-18. |
| AC-13-12 | ARCH-AI-001 AC-1..AC-7 satisfied for advisory AI surfaces. |
| AC-13-13 | All Module 13 tables RLS-enabled per QS-6. |
| AC-13-14 | Every mutation produces audit entry per QS-1. |
| AC-13-15 | Tenant offboarding cascade preserves audit retention per DEC-13-23. |

```mermaid
sequenceDiagram
  participant Originator
  participant DraftSvc as change-control/service draft
  participant ImpactSvc as impact assessment
  participant CABSvc as CAB approval matrix
  participant ESign as URS-04 E-Sign
  participant ImplSvc as implementation
  participant VerifSvc as verification
  participant CloseSvc as closure
  participant Audit as URS-06 audit
  Originator->>DraftSvc: create draft
  DraftSvc->>Audit: log create
  Originator->>ImpactSvc: submit_to_impact
  ImpactSvc->>Audit: log transition
  Note over ImpactSvc: required category coverage check
  ImpactSvc->>CABSvc: submit_to_cab
  CABSvc->>Audit: log transition
  loop per required slot
    CABSvc->>ESign: ControlledApprovalModal
    ESign-->>CABSvc: signature record (SoD + authority verified)
    CABSvc->>Audit: log approval row
  end
  CABSvc->>ImplSvc: matrix complete → approved → start_implementation
  ImplSvc->>Audit: log steps
  ImplSvc->>VerifSvc: complete_implementation
  VerifSvc->>Audit: log effectiveness checks
  VerifSvc->>CloseSvc: verification complete
  CloseSvc->>CloseSvc: 5-prerequisite check
  CloseSvc->>ESign: closure attestation (SoD-13-07)
  ESign-->>CloseSvc: signature
  CloseSvc->>Audit: log closure with verification basis
```

Diagram 16-A — End-to-end acceptance test sequence: full happy-path lifecycle with SoD, authority, and prerequisite enforcement. Used as the canonical test fixture for AC-13-01..15.

### 16.4 Requirements-to-test traceability

| Requirement ID | Test Case ID | AC ID |
|---|---|---|
| URS-13-FE-001..025 | TC-13-T09 | AC-13-01..15 |
| URS-13-BE-001..023 | TC-13-T01..08, TC-13-T10..14 | AC-13-01..15 |
| URS-13-WF-001..014 | TC-13-T01..06 | AC-13-02..10 |
| URS-13-DATA-001..012 | TC-13-T07 | AC-13-13 |
| URS-13-SEC-001..010 | TC-13-T07, TC-13-T11..13 | AC-13-13, AC-13-11 |
| URS-13-AUD-001..010 | TC-13-T08 | AC-13-14 |
| URS-13-AI-001..007 | TC-13-T13 | AC-13-11..12 |
| URS-13-INT-001..024 | TC-13-T09 | AC-13-15 |

---

## 17. Validation and CSV/CSA Evidence Expectations

### 17.1 Supplier and service-provider qualification pack

- E-signature substrate provider qualification (URS-04).
- Hosting region qualification per tenant data residency.

### 17.2 Inspection-ready evidence index

- URS approval pack (this document + signatories).
- Functional specification per `change-control` code module.
- IQ / OQ / PQ scripts and execution evidence.
- Traceability matrix (URS → spec → code → test).
- Risk-based testing pack per FDA CSA.
- RLS enforcement evidence per QS-6.
- Audit trail integrity (hash chain) evidence per QS-1.
- Migration evidence (URS-13-VAL-008).
- Internal forward-looking AI governance evidence (EU GMP Annex 22 Draft 2025 GenAI prohibition control: runtime block test, lint rule, design-review record).
- ARCH-AI-001 AC-1..AC-7 advisory AI evidence pack.
- Internal forward-looking AI governance evidence (EU AI Act Art. 13 transparency principles).
- SoD-13-01..07 enforcement evidence (test execution + audit log samples).
- Closure prerequisite enforcement evidence.
- Critical-system executive authority co-sign procedural evidence (DEC-13-21).
- Reopen executive authority co-sign procedural evidence (DEC-13-22).
- ICH Q12 EC auto-classification ruleset evidence (DEC-13-24).
- Regulatory submission gating evidence (DEC-13-25).

---

## 18. Closed Decision and Dependency Register

### 18.1 Closed Launch Decisions Register

DEC-13-01..25 per §2.3 are all closed for launch. Each carries its rationale and the or branch evidence reference. Detailed dispositions:

| ID | Disposition |
|---|---|
| DEC-13-01..02 | Locked;/CC-002. |
| DEC-13-03..04 | Locked;. |
| DEC-13-05..06 | Locked; + CC-007. |
| DEC-13-07 | Locked; e-sig boundary verification. |
| DEC-13-08..10 | Locked;. |
| DEC-13-11 | Locked; schedule defaults. |
| DEC-13-12 | Locked; closure prerequisites (5-point). |
| DEC-13-13 | Locked; conditional approval model. |
| DEC-13-14 | Locked; list/filter/report. |
| DEC-13-15 | Locked; cross-module breadth. |
| DEC-13-16 | Locked; soft-delete + archive. |
| DEC-13-17 | Locked; audit coverage. |
| DEC-13-18 | Locked; EU GMP Annex 22 critical-decision GenAI prohibition. |
| DEC-13-19..20 | Locked; ARCH-AI-001 advisory AI binding + EU AI Act Art. 13 transparency. |
| DEC-13-21..22 | Locked; executive authority co-sign requirements. |
| DEC-13-23 | Locked; per URS-08 tenant lifecycle cascade. |
| DEC-13-24 | Locked; ICH Q12 EC auto-classification ruleset. |
| DEC-13-25 | Locked; URS-27 regulatory submission gating. |

### 18.2 Dependencies

| Dependency | Direction | Source |
|---|---|---|
| URS-01 authentication | Inbound | URS-01 module URS |
| URS-02 RBAC | Inbound | URS-02 module URS |
| URS-03 active scope | Inbound | URS-03 module URS |
| URS-04 workflow / e-signature | Inbound | URS-04 module URS |
| URS-05 Authority Profile registry | Inbound | URS-05 module URS |
| URS-06 audit substrate | Inbound | URS-06 module URS |
| URS-07 Study | Bidirectional | URS-07 module URS |
| URS-08 Tenant lifecycle | Inbound | URS-08 module URS |
| URS-09 Site | Bidirectional | URS-09 module URS |
| URS-10 Product | Bidirectional | URS-10 module URS |
| URS-11 Supplier | Bidirectional | URS-11 module URS |
| URS-12 Documents/Libraries | Bidirectional | URS-12 module URS |
| URS-14 Complaints | Inbound | URS-14 module URS |
| URS-15 OOS/OOT | Inbound | URS-15 module URS |
| URS-16 Deviations | Inbound | URS-16 module URS |
| URS-18 CAPA | Bidirectional | URS-18 module URS |
| URS-21 Findings | Inbound | URS-21 module URS |
| URS-22 Inspection Mgmt | Inbound | URS-22 module URS |
| URS-23 Batch Records | Bidirectional | URS-23 module URS |
| URS-27 Regulatory Intelligence | Bidirectional | URS-27 module URS |
| URS-28 Training | Outbound | URS-28 module URS |
| URS-30 Notifications | Outbound | URS-30 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 |

---

## 19. Completeness Checklist

| Item | Priority |
|---|---|
| Header + mapping + Code Modules Mapped + Architecture Bindings (Annex 22 + ARCH-AI-001) | ✓ |
| Plain-language primer + glossary + architectural picture | ✓ |
| Change Request lifecycle diagram | ✓ |
| Module Purpose | ✓ |
| Scope (in / out / closed launch decisions) | ✓ |
| User Roles + Authority Profiles + SoD rules + worked examples + role-permission matrix | ✓ |
| 28 end-to-end user journeys | ✓ |
| Front-end expected state (routes + components + a11y/i18n) | ✓ |
| Back-end expected state (entities + ER diagram + state machine + CAB matrix flow + closure prerequisite flow + data model + API + workflow + business rules + audit) | ✓ |
| Annex 22 + ARCH-AI-001 architecture reference section | ✓ |
| Cross-module wiring + CIM + dependencies | ✓ |
| AI / Automation / HITL controls (with Annex 22 prohibition) | ✓ |
| Reports / dashboards / exports | ✓ |
| Notifications and queues | ✓ |
| Error envelope + error-code catalogue + negative paths | ✓ |
| Security, privacy, tenant isolation | ✓ |
| ALCOA+ controls | ✓ |
| Regulatory mapping | ✓ |
| URS Requirements Register (FE / BE / WF / DATA / SEC / AUD / AI / INT / REP / NOTIF / VAL) | ✓ |
| Acceptance Criteria + Test Cases + traceability | ✓ |
| Validation evidence expectations | ✓ |
| Closed decisions + dependencies | ✓ |
| Module scoped strictly to Change Control | ✓ |
| Version 1.0 only — no internal change-history scaffolding | ✓ |

---

## 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; it becomes "Released for validation execution" only after URS-13-VAL-008 (Migration Evidence Gate) and the §17 validation evidence pack are satisfied. **No Module 13 internal open questions remain.**

- **Specification ready for engineering review?** Yes — every requirement is fully specified within this URS..CC-REQ-012.
- **Specification ready for quality validation review?** Yes — IQ/OQ/PQ + RLS evidence + audit chain integrity + Annex 22 GenAI-prohibition evidence + ARCH-AI-001 AC-1..AC-7 advisory evidence + EU AI Act Art. 13 transparency + SoD enforcement evidence + closure prerequisite evidence + executive authority co-sign procedural evidence are itemised in §17.
- **Specification ready for compliance review?** Yes — ALCOA+, 21 CFR Part 11 §11.10(a/d/e/g) §11.50/11.70/11.100/11.200/11.300, 21 CFR Part 211 §211.100, EU GMP Annex 11 §4/9/12/16, EU GMP Annex 15, EU GMP Chapter 1 §1.4, ICH Q9, ICH Q10, ICH Q12, ICH GCP E6(R3), MHRA ALCOA+, GAMP 5 Cat 5, FDA CSA Final Guidance (Sep 2025), Health Canada C.02.020, WHO TRS 996 Annex 5 — all mapped in §14. EU GMP Annex 22 (Draft 2025) and EU AI Act Art. 13 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 end-to-end journeys (§4), full requirements register (§15), evidence pack index (§17.2).
- **Specification ready for Founder approval?** Yes.
- **Blocking gaps?** None internal. Cross-module dependencies (§18.2) are owned by named companion modules. Forward dependencies (URS-14..URS-35 per canonical) documented but not blocking for launch.
- **Two-step release path:**
  1. **Approved Controlled URS — released for engineering implementation and validation planning.** Reached upon signature capture.
  2. **Released for validation execution.** Reached after URS-13-VAL-008 is satisfied and the §17 evidence pack is complete.

---

## Appendix A — Module 13 End-to-End Composite (Draft → Impact → CAB → Approved → Implement → Verify → Close)

```mermaid
flowchart TD
  A([change_originator creates draft]) --> B[DRAFT — at least one scope anchor required]
  B --> C[Edit draft]
  C --> D[Submit to impact assessment]
  D --> E[IMPACT_ASSESSMENT — required functional leads notified]
  E --> F[Each function adds signed impact item]
  F --> G{Required category coverage satisfied per DEC-13-04?}
  G -- no --> F
  G -- yes --> H[Submit to CAB]
  H --> I[CAB_REVIEW — required slots per per-classification matrix]
  I --> J[Per slot: SoD-13-01..03 + withAuthority + e-sign]
  J --> K{Decision aggregation}
  K -- any required slot rejected --> L[REJECTED terminal]
  K -- all required slots approved --> M[APPROVED]
  K -- all approved/conditional with at least one conditional --> N[APPROVED_WITH_CONDITIONS + first-class conditions]
  K -- critical-system change without executive authority slot --> O[CRITICAL_EXECUTIVE_AUTHORITY_REQUIRED block]
  M --> P[start_implementation]
  N --> P
  P --> Q[IMPLEMENTING — explicit transition CC-REQ-006]
  Q --> R[Add steps with uniqueness per DEC-13-10]
  R --> S[Each step: planned/in_progress/complete/blocked + e-sign on completion]
  S --> T{All required steps complete?}
  T -- no --> S
  T -- yes --> U[complete_implementation]
  U --> V[VERIFICATION]
  V --> W[Effectiveness checks per schedule per DEC-13-11]
  W --> X[Each check: outcome effective/partial/ineffective + e-sign + SoD-13-04]
  X --> Y{All required checks effective?}
  Y -- no --> Z[Closure blocked CHANGE_CONTROL_CLOSURE_BLOCKED_INEFFECTIVE_CHECK]
  Y -- yes --> AA{All conditions discharged + linkages updated + SoD-13-07?}
  AA -- no --> AB[Closure blocked]
  AA -- yes --> AC[change_closure_authority e-signs closure attestation]
  AC --> AD[CLOSED]
  AD --> AE{Lifecycle event}
  AE -- new request supersedes --> AF[SUPERSEDED terminal]
  AE -- post-closure issue --> AG[executive authority co-sign reopen DEC-13-22 → REOPENED → IMPACT_ASSESSMENT]
  AE -- normal end --> AH[Terminal closed]
  L --> AI[Terminal rejected — preserved for audit]
  AF --> AJ[Terminal superseded]
  H -.regulatory submission gate DEC-13-25.-> AK[Major spec change blocked from implementing without URS-27 submission record]
  AK --> P
  J -.Annex 22.-> AL[GenAI invocation in approval path: CHANGE_CONTROL_GENAI_PROHIBITED runtime block]
```

Diagram Appendix A — Module 13 End-to-End Composite. Single composite flow showing the full Change Control lifecycle: draft → impact assessment with required category coverage → CAB review with matrix-quorum-SoD enforcement → approved (with critical-system executive authority co-sign branch + regulatory submission gating branch) → implementation with step uniqueness and completion sign → verification with SoD-13-04 enforcement → closure with 5-prerequisite check → terminal states (closed, superseded, rejected, withdrawn) with reopen path requiring executive authority co-sign. Under the internal Annex 22 Draft 2025 forward-looking AI governance control (not enacted predicate rule), generative AI is prohibited in the approval, classification, and closure decision paths; ARCH-AI-001 governs advisory deterministic AI in impact-assessment domain suggestion. Binding predicate-rule obligations remain those listed in §14.

— End of Module 13 User Requirements Specification —