# Verixa — User Requirements Specification

# Module 26: Annual Product Quality Review (APQR)

| Field | Value |
|---|---|
| Document ID | VRX-URS-26 |
| Version | 1.0 |
| Status | Final — ready for QA, Validation, Regulatory Affairs, Information Security, Manufacturing Head, Site Quality Lead, Qualified Person Authority, 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-26-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 `apqr`, expected API mounts `/api/v1/apqr/*` (canonical), expected supporting modules `products`, `studies`, `context-filter`, `rbac`, `audit-log`, `authority`, `electronic_signatures`, `hitl`, `documents`, expected event-bus emission for `apqr_report_created`, `apqr_data_collection_added`, `apqr_data_collection_refreshed`, `apqr_statistical_analysis_executed`, `apqr_recommendation_added`, `apqr_recommendation_implemented`, `apqr_submitted_for_approval`, `apqr_approval_step_assigned`, `apqr_approval_step_signed`, `apqr_approval_step_rejected`, `apqr_report_recalled`, `apqr_report_approved`, `apqr_report_rejected`, `apqr_year_over_year_refreshed`, `apqr_ai_insight_proposed`, `apqr_ai_insight_accepted`, `apqr_report_locked`, `apqr_report_reopened`, expected MIRA context integration through `useMiraRecord('apqr_report', id)` mapping, expected URS-13 change-control linkage for APQR template revisions and approved-report supersession, expected URS-23 batch-record consumer for APQR period-batch evidence, expected URS-24 stability consumer for APQR shelf-life-claim evidence, expected URS-25 environmental-monitoring consumer for APQR EM trending dataset, expected URS-15 OOS/OOT consumer for APQR OOS summary, expected URS-16 deviations consumer for APQR deviation summary, expected URS-18 CAPA consumer for APQR CAPA summary and recommendation→CAPA implementation linkage, expected URS-13 change-control consumer for APQR change-control summary and recommendation→CR implementation linkage, expected URS-14 complaints consumer for APQR complaint summary, expected URS-21 findings consumer for APQR findings summary, expected URS-22 inspection consumer for APQR inspection observation summary, expected Authority Profile + HITL + e-signature integration for non-bypassable approval-step signing, report approval, report recall, report lock, and reopen, expected platform_admin / super_admin support / break-glass only paths. Implementation evidence remains subject to repository verification and validation evidence. |
| Architecture Bindings | This module is subject to **ARCH-AI-001 AI Optionality and Manual Continuity**. Verixa internally classifies this AI surface as **limited-risk under internal AI governance**, aligned with the limited-risk transparency approach in **EU AI Act (Regulation 2024/1689) Article 13**, escalating to **internal forward-looking AI governance aligned with EU AI Act Annex III concepts** where AI-generated narrative or recommendation feeds an APQR approval decision or directly creates a downstream URS-18 CAPA / URS-13 Change Request. AI-assisted APQR surfaces (AI-generated narrative summary, AI-generated trend commentary, AI-generated deviation / CAPA / change-control / complaint roll-up, AI insights field on the report header, MIRA APQR copilot, AI recommendation / downstream action linkage) are advisory only under internal AI governance. Every AI surface shall provide a fully functional manual narrative, trend commentary, roll-up, and recommendation path; APQR section drafting, data aggregation, narrative authoring, review, and approval shall be executable when AI services are disabled, degraded, or overridden by the APQR author or quality lead. **AI-generated narrative shall be visibly labeled as advisory and shall not be written to the APQR record as an AI-attributable system-of-record statement without explicit human confirmation; the final APQR sign-off shall be executed by a qualified human approver.** This module binds ARCH-AI-001 AC-1, AC-2, AC-3, AC-4, and AC-7. Verixa treats **EU GMP Annex 22 Draft 2025 §7** as an internal forward-looking architectural control (not an enacted predicate rule); under that internal control, generative AI may draft narrative and roll-up text **only** in advisory form labeled as advisory, with mandatory human acceptance recorded in `apqr_ai_insights` provenance per DEC-26-11; generative / probabilistic AI is **PROHIBITED from being the sole path to approve an APQR report, sign an approval step, or convert a recommendation into a downstream URS-18 CAPA or URS-13 Change Request**. Static deterministic AI may surface trending regressions, year-over-year comparisons, and deviation/CAPA/complaint pattern detection as advisory help. 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 Annual Product Quality Review (APQR / PQR — terminology aligned with **EU GMP Chapter 1 §1.10** Product Quality Review, **21 CFR Part 211 §211.180(e)** Annual Review of Drug Products, **ICH Q10 §3.2.1 / §3.2.4** Process Performance and Product Quality Monitoring System and Management Review, and **WHO TRS Annex 2** Product Quality Review); the APQR-report register; the APQR lifecycle state machine (`draft → data_collection → in_progress → under_review → pending_approval → approved | rejected → locked` with reopen / recall as governed transitions per DEC-26-22 + SoD-26-06); the data-collection substructure with **source-record provenance, refresh mode (manual / scheduled / on-demand), and source-system reference** (URS-23 batch records, URS-24 stability, URS-25 EM, URS-15 OOS, URS-16 deviations, URS-18 CAPA, URS-13 change control, URS-14 complaints, URS-21 findings, URS-22 inspection) per DEC-26-05; the statistical-analysis substructure with **input-dataset provenance and reproducible method metadata** per DEC-26-06; the recommendation substructure with **mandatory downstream action linkage to URS-13 CR or URS-18 CAPA where the recommendation requires implementation** per DEC-26-07; the approval substructure with **assigned-approver validation, sequencing, SoD enforcement** per DEC-26-08 and **server-attributed signature evidence (IP / user-agent derived from request context, never client-supplied)** per DEC-26-09; the year-over-year comparison substructure with **governed writer/refresh path** per DEC-26-10; the AI-insights substructure with **provenance, model attribution, mandatory human acceptance, and lock-on-acceptance** per DEC-26-11; the multi-dimensional context capture (`tenant_id` mandatory, `study_id` mandatory at report level —, `product_id` mandatory at report level via FK to URS-10 Product master with **immutable product snapshot** per DEC-26-03 —, `site_id` optional inherited from `studies`, `period_start` / `period_end` mandatory); the canonical API contract `/api/v1/apqr/*` (retained ALIGNED); the typed schema validation across every route (— `study_id` aligned to NOT NULL); the controlled report lifecycle with **terminal-state patch-bypass prevention**; the version-increment-on-update behavior per DEC-26-04; the audit-trail coverage with reason-for-change discipline on every mutation route per DEC-26-12; the post-locked record immutability across the report header and linked approvals; the controlled reopen workflow with executive authority co-sign and Qualified Person co-sign per DEC-26-22; the canonical findings-source emission to URS-21 for APQR findings per DEC-26-15; the canonical CAPA-source emission to URS-18 with `apqr_recommendation` source type per DEC-26-16 (mandatory linkage where recommendation requires CAPA per DEC-26-07); the canonical change-control linkage to URS-13 for recommendation→CR implementation per DEC-26-07; the MIRA copilot read-only context integration on APQR records, and the per-jurisdictional regulatory expectations under FDA 21 CFR Part 11, **FDA 21 CFR Part 211 §211.180(e)** Annual Review of Drug Products, FDA 21 CFR Part 211 §211.192 Production Record Review, EU GMP Annex 11, **EU GMP Chapter 1 §1.10 Product Quality Review** (primary EU predicate), EU GMP Annex 22 Draft 2025 §7 (HITL — internal forward-looking control), EU AI Act (Regulation 2024/1689) Art. 13 / Annex III (internal forward-looking control), MHRA Data Integrity Guidance (ALCOA+), GAMP 5 Cat 5, **ICH Q10 §3.2.1 / §3.2.4** Process Performance and Product Quality Monitoring System and Management Review (primary ICH predicate), ICH Q9 (Quality Risk Management), WHO TRS No. 996 Annex 2 §22 (Product Quality Review), and India CDSCO Schedule M (Revised) §17 (Product Quality Review) and Schedule M-III §3.7 (Medical Device Quality Management Review) subject to a future jurisdiction-specific legal assessment for Verixa's exact CDSCO obligations. |
| Date of Issue | 2026-05-07 |
| Module Owner (Engineering) | Quality / APQR Squad |
| Module Owner (Quality Validation) | CSV / CSA Lead — APQR |
| Module Owner (Compliance) | Quality Assurance, Manufacturing, Regulatory Affairs, Qualified Person Authority |
| Approving Authority | Founder / Chairman & MD; QA Head; Manufacturing Head; Validation Head; RA Head; Information Security Head; Qualified Person (QP) Authority; Site Quality Lead |

---

## 0. Document Framing

### 0.1 Purpose of this document

This URS defines the target expected state for Verixa's Annual Product Quality Review (APQR / PQR) module (Module 26). It is the binding contract between product, engineering, quality validation, regulatory affairs, manufacturing, the Qualified Person authority, distribution, laboratory operations, information security, and the executive authority for the design, implementation, validation, release, and on-going periodic review of the regulated APQR substrate: the canonical APQR-report register; the APQR lifecycle state machine (`draft → data_collection → in_progress → under_review → pending_approval → approved | rejected → locked` with reopen / recall as governed transitions per executive authority co-sign + Qualified Person co-sign + reason — DEC-26-22 + SoD-26-06 — that appends a new APQR iteration without mutating or erasing the prior locked evidence); the data-collection substructure with source-record provenance, refresh mode, and source-system reference per DEC-26-05; the statistical-analysis substructure with input-dataset provenance and reproducible method metadata per DEC-26-06; the recommendation substructure with mandatory downstream action linkage per DEC-26-07; the approval substructure with assigned-approver validation, sequencing, SoD enforcement, and server-attributed signature evidence per DEC-26-08 / DEC-26-09; the year-over-year comparison substructure with governed writer/refresh path per DEC-26-10; the AI-insights substructure with provenance, model attribution, mandatory human acceptance, and lock-on-acceptance per DEC-26-11; the multi-dimensional context capture (`tenant_id`, `study_id` mandatory matching migration 033 NOT NULL, `product_id` mandatory via FK to URS-10 Product master with immutable product snapshot per DEC-26-03, `period_start` / `period_end`); the canonical API contract `/api/v1/apqr/*`; the typed schema validation across every route with `study_id` alignment per DEC-26-02; the controlled report lifecycle with terminal-state patch-bypass prevention per DEC-26-04; the version-increment-on-update behavior; the audit-trail coverage with reason-for-change discipline; the post-locked record immutability; the controlled reopen / recall workflow per DEC-26-22; the canonical findings emission to URS-21 per DEC-26-15; the canonical CAPA emission to URS-18 (`apqr_recommendation` source type) for recommendation→CAPA implementation per DEC-26-16; the canonical change-control linkage to URS-13 for recommendation→CR implementation per DEC-26-07; the **read-only consumer integration with URS-23 batch records, URS-24 stability, URS-25 EM, URS-15 OOS, URS-16 deviations, URS-18 CAPA, URS-13 change control, URS-14 complaints, URS-21 findings, URS-22 inspection**; the MIRA copilot read-only context integration with **AI-generated narrative as advisory only — never the sole path to approve a report, sign an approval step, or convert a recommendation to a downstream CAPA / CR** under the internal Annex 22 §7 control; the audit trail coverage with reason-for-change discipline; and the per-jurisdictional regulatory expectations. Compliance with this URS is mandatory.

### 0.2 Audience

Engineering, QA, RA, Manufacturing, Qualified Person Authority, Distribution, Laboratory Operations, Validation, Information Security, executive authority, the platform's Implementation team, internal and external auditors, and inspectors from regulatory bodies (FDA, EMA, MHRA, Health Canada, CDSCO, PIC/S, PMDA, WHO). The plain-language primer (§0.4) and worked examples (§3.5) make Module 26 accessible to non-domain engineers, product owners, validation engineers, and quality investigators.

### 0.3 Cross-references

- **URS-01** Authentication, Session & Access Control — identity envelope for every APQR mutation
- **URS-02** RBAC & Permissions — the `apqr:*`, `apqr:report:*`, `apqr:data_collection:*`, `apqr:analysis:*`, `apqr:recommendation:*`, `apqr:approval:*`, `apqr:ai_insight:*`, `apqr:yoy:*` permission set
- **URS-03** Context Gate & Approval Scope — context-gate enforcement for APQR scope dimensions
- **URS-04** Workflow / HITL / E-Signature / Approval Authority — Controlled Approval Modal contract for approval-step signing / report approval / report recall / lock / reopen
- **URS-05** Authority Profile / Delegation / SoD — Authority Profiles consumed (`apqr_author_authority`, `apqr_review_authority`, `apqr_approver_authority`, `qualified_person_authority`, `final_quality_approver`, `executive_authority`)
- **URS-06** Audit Trail / Hash Chain / Tamper-Evident — append-only audit substrate
- **URS-07** Study Management — mandatory study-scope dimension consumed
- **URS-08** Tenant Management Lifecycle — tenant context for APQR records
- **URS-09** Site / Facility Management — site-scope inherited via `studies` parent
- **URS-10** Product / SKU / Drug Master Data — primary linkage; mandatory `product_id` FK at report level per DEC-26-03; immutable product snapshot per DEC-26-03
- **URS-11** Supplier Management — supplier-material data input where APQR includes supplier review
- **URS-12** Document Control / SOP — affected-document linkage for APQR template
- **URS-13** Change Control — primary downstream consumer for recommendation→CR implementation per DEC-26-07; APQR-template revisions
- **URS-14** Complaints — read-only data consumer for complaint summary in APQR
- **URS-15** OOS / OOT — read-only data consumer for OOS summary in APQR
- **URS-16** Deviations — read-only data consumer for deviation summary in APQR
- **URS-17** RCA — read-only data consumer for RCA summary in APQR
- **URS-18** CAPA — primary downstream consumer for recommendation→CAPA implementation per DEC-26-16; read-only data consumer for CAPA summary in APQR
- **URS-19** Risk Assessment — read-only data consumer for risk summary in APQR
- **URS-20** Reviews — periodic review consumer
- **URS-21** Findings — primary downstream consumer for APQR findings per DEC-26-15
- **URS-22** Inspection Mgmt — read-only data consumer for inspection observation summary in APQR
- **URS-23** Batch Records — primary read-only data consumer for period-batch evidence (yields, deviations, IPC trends, locked-batch counts)
- **URS-24** Stability — primary read-only data consumer for stability evidence (locked stability studies, approved shelf-life claims)
- **URS-25** Environmental Monitoring — primary read-only data consumer for EM trending datasets (`em_trend_datasets` per URS-25 DEC-25-09)
- **URS-27** Regulatory Intelligence — predicate-rule citation source for ICH Q10 / EU GMP Chapter 1 / 21 CFR §211.180(e)
- **URS-28** Training — read-only training-evidence consumer for personnel review section
- **URS-30** Notifications — notification delivery for APQR lifecycle events
- **URS-31** DQG — data-quality gate evidence for APQR-data-collection completeness
- **URS-32** MIRA AI — read-only MIRA copilot context integration on APQR records; AI-generated narrative is advisory only with mandatory human acceptance per DEC-26-11
- **URS-33** GMP Manufacturing — GMP context for manufacturing review
- **URS-34** GDP Distribution — distribution context for distribution review
- **URS-35** Infrastructure / Backup-Restore — operational continuity

### 0.4 Plain-language primer

In a regulated pharmaceutical operation, **the Annual Product Quality Review (APQR — also called PQR / Product Quality Review)** is the formal annual evaluation of every marketed product to confirm that the manufacturing process is in a state of control and that the product continues to meet its registered quality, safety, and efficacy specifications. APQR is a standalone regulatory obligation under: **EU GMP Chapter 1 §1.10** (Product Quality Review — primary EU predicate); **21 CFR Part 211 §211.180(e)** (Annual Review of Drug Products — primary FDA predicate); **ICH Q10 §3.2.1 / §3.2.4** (Process Performance and Product Quality Monitoring System and Management Review — primary ICH predicate); **WHO TRS No. 996 Annex 2 §22**; **PIC/S PE 009-17** harmonization; and **India CDSCO Schedule M (Revised) §17**. The APQR consolidates: (1) starting materials and packaging material reviews, (2) in-process control trends, (3) batch-record review (URS-23), (4) deviation summary (URS-16), (5) OOS / OOT summary (URS-15), (6) CAPA summary (URS-18), (7) change control summary (URS-13), (8) complaints summary (URS-14), (9) returns / recalls summary, (10) stability program summary (URS-24), (11) environmental monitoring trending summary (URS-25), (12) qualification / requalification status of facilities and equipment, (13) commitment status, (14) inspection observations summary (URS-22), (15) year-over-year comparison, (16) recommendations for improvement → linked to URS-13 CR / URS-18 CAPA. The APQR is reviewed and signed by Quality, Manufacturing, and the Qualified Person; the signed APQR is the system-of-record for the period. Module 26 is the target specification for this regulated workflow.

The most common mistake in regulated APQR handling is **direct status patch bypassing the controlled approval workflow**. The regulator's tell-tale at inspection is an APQR with `status = approved` and no corresponding signed approval-step records, or with the assigned approver mismatch. Module 26 enforces the pathway: terminal-state patch-bypass is prevented per DEC-26-04; approval-step signing requires the acting user to match `apqr_approvals.assigned_to` per DEC-26-08; signature evidence (IP / user-agent / timestamp) is server-attributed from request context, never client-supplied per DEC-26-09.

The second most common mistake is **AI-generated narrative being written to the APQR record as if it were a human-attributed statement**. Module 26 enforces the pathway: AI insights live in a controlled `apqr_ai_insights` substructure with full provenance (model identifier, model version, prompt-or-template version, confidence, citation snapshot) per DEC-26-11; AI-generated narrative is **advisory only** and shall not be promoted to the APQR system-of-record narrative without explicit human confirmation captured in `accepted_by` / `accepted_at` / `acceptance_e_signature_id`; no AI service finalizes APQR approval, signs an approval step, or converts a recommendation to a downstream URS-18 CAPA / URS-13 CR.

The third most common mistake is **recommendations that remain informational without controlled implementation linkage**. Module 26 enforces the pathway: recommendations that require implementation MUST link to a URS-13 Change Request or URS-18 CAPA via `recommendation_capa_id` or `recommendation_change_request_id` per DEC-26-07 / DEC-26-16; recommendation closure requires the linked downstream record to be in terminal status.

The **two-step release path** mirrors every other Module: this URS becomes "Approved Controlled URS — released for engineering implementation and validation planning" upon signature capture in the Document Approval block; it becomes "Released for validation execution" only after URS-26-VAL-008 (Migration Evidence Gate) and the §17 validation evidence pack are satisfied.

### 0.5 Conventions

Each requirement has a unique identifier. "MUST" denotes a mandatory requirement; "SHOULD" denotes a strong recommendation; "MAY" denotes an option. The document is self-contained: front end (§5), back end (§6), data model (§6.2), application programming interface (§6.3), workflow (§6.4), business rules (§6.5), audit (§6.6), security (§12), regulatory mapping (§14), test cases (§16), and validation evidence (§17) are all in this single file. Every requirement is mandatory unless explicitly marked SHOULD or MAY.

### 0.6 Glossary

| Term | Definition |
|---|---|
| APQR / PQR | Annual Product Quality Review — the formal annual evaluation of a marketed product per EU GMP Ch.1 §1.10 / 21 CFR §211.180(e) / ICH Q10 §3.2.1. |
| APQR period | The review period (typically 12 months); captured as `period_start` / `period_end` on the report header. |
| Data collection | A row in `apqr_data_collections` consolidating data from a source module (URS-23 / URS-24 / URS-25 / URS-15 / URS-16 / URS-18 / URS-13 / URS-14 / URS-21 / URS-22) for a specific section of the APQR; carries source-record provenance + refresh mode + source-system reference per DEC-26-05. |
| Statistical analysis | Computed analytical output (control charts, capability indices, trend regressions) executed against an input dataset with reproducible method metadata per DEC-26-06. |
| Recommendation | An identified improvement opportunity with optional / required downstream linkage to URS-13 CR or URS-18 CAPA per DEC-26-07. |
| Approval step | A row in `apqr_approvals` defining a sequenced assigned approver (e.g., QA Reviewer → Manufacturing Head → Qualified Person); each step requires bound e-signature with server-attributed evidence per DEC-26-09. |
| Year-over-year (YoY) | A computed comparison of current-period APQR metrics against prior-period APQR metrics; refreshed via governed writer per DEC-26-10. |
| AI insight | An advisory AI-generated observation (narrative summary, trend commentary, deviation roll-up); persisted in `apqr_ai_insights` with full provenance + mandatory human acceptance per DEC-26-11. |
| Recall / rework | A governed transition from `approved → recalled` requiring executive authority co-sign + reason; the recalled report appends a new iteration without mutating prior approved evidence. |
| Reopen | A governed transition from `locked → in_progress` requiring `executive_authority` co-sign AND `qualified_person_authority` co-sign + reason per DEC-26-22. |
| ARCH-AI-001 | Platform architecture binding requiring manual continuity for every AI surface (AC-1, AC-2, AC-3, AC-4, AC-7). |
| Annex 22 | EU GMP Annex 22 (Draft 2025) §7. Verixa treats Annex 22 §7 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, AI may draft narrative in advisory form labeled as advisory with mandatory human acceptance; AI is prohibited from being the sole path to approve an APQR report, sign an approval step, or convert a recommendation to a downstream CAPA / CR. Binding predicate-rule obligations remain those listed in §14. |
| MIRA | The platform's read-only AI copilot service; for Module 26 MIRA may propose advisory drafts via `apqr_ai_insights`; no MIRA write paths to system-of-record APQR fields without explicit human confirmation; no AI signs approval steps. |

### 0.7 Module-26 architectural picture

```mermaid
flowchart TD
 AUTH[APQR Author] --> RPT[/APQR Reports/]
 RPT --> DC[Data Collections — provenance + refresh mode]
 DC --> SRC23[URS-23 Batch Records]
 DC --> SRC24[URS-24 Stability]
 DC --> SRC25[URS-25 EM Trend Datasets]
 DC --> SRC15[URS-15 OOS]
 DC --> SRC16[URS-16 Deviations]
 DC --> SRC18[URS-18 CAPA]
 DC --> SRC13[URS-13 Change Control]
 DC --> SRC14[URS-14 Complaints]
 DC --> SRC21[URS-21 Findings]
 DC --> SRC22[URS-22 Inspection]
 RPT --> ANL[Statistical Analyses — reproducible method metadata]
 RPT --> REC[Recommendations — mandatory downstream linkage]
 REC --> DS_CR[URS-13 Change Request]
 REC --> DS_CAPA[URS-18 CAPA]
 RPT --> AI[AI Insights — provenance + human acceptance]
 RPT --> YOY[Year-over-Year — governed writer]
 RPT --> APV[Approval Steps — assigned approver + sequenced + bound e-sign]
 APV --> APR[Report Approved or Rejected]
 APR --> LOCK[Locked]
 LOCK -. governed reopen + executive + QP co-sign.-> RPT
 APR -. governed recall.-> RPT
 M21[URS-21 Findings] <-- RPT (apqr_finding events)
 M30[URS-30 Notifications] <-- RPT
 M32[URS-32 MIRA AI] <-- RPT (read-only context + advisory drafting only)
 M10[URS-10 Product Master] --> RPT (immutable snapshot)
```

The platform shall implement: a controlled APQR-report register; a data-collection substructure with source provenance + refresh mode + source-system reference per DEC-26-05; statistical-analysis substructure with input-dataset provenance + reproducible method metadata per DEC-26-06; recommendation substructure with mandatory downstream URS-13 CR or URS-18 CAPA linkage where implementation required per DEC-26-07; approval substructure with assigned-approver validation + sequencing + SoD per DEC-26-08 + server-attributed signature evidence per DEC-26-09; year-over-year comparison with governed writer/refresh per DEC-26-10; AI-insights substructure with provenance + model attribution + mandatory human acceptance per DEC-26-11; mandatory `study_id` per DEC-26-02; mandatory `product_id` FK + immutable product snapshot per DEC-26-03; canonical API contract `/api/v1/apqr/*`; typed schema validation per DEC-26-02; terminal-state patch-bypass prevention per DEC-26-04; version-increment-on-update per DEC-26-04; audit-trail coverage + reason-for-change per DEC-26-12; post-locked record immutability; governed reopen with executive + QP co-sign per DEC-26-22; governed recall per DEC-26-23; canonical findings emission to URS-21 per DEC-26-15; canonical CAPA emission to URS-18 (`apqr_recommendation` source type) per DEC-26-16; URS-13 CR linkage per DEC-26-07; read-only data consumer integration with all source modules; MIRA copilot read-only context with advisory drafting only; and per-jurisdictional regulatory expectations.

### 0.8 Locked Launch Controls

| Locked control | Authority | Rationale |
|---|---|---|
| Two-step release path: signature → engineering implementation → validation execution | DEC-26-01 / VAL-008 | Mirrors every other Module. |
| "No Module 26 internal decisions outstanding" | §11.6 | Captured in locked decisions DEC-26-01..DEC-26-23 (§3.2). |
| `platform_admin` / `super_admin` support / break-glass only | DEC-26-20 / SoD-26-07 | Operating-tenant APQR ownership is the regulated path. |
| Target implementation binding language | Module bindings | URS specifies expected implementation. |
| AI overclaim posture as **internal forward-looking governance** with **GenAI prohibition in approving / signing / converting recommendations** | Architecture Bindings | EU GMP Annex 22 Draft 2025 §7 + EU AI Act Annex III treated as internal controls. AI may draft advisory narrative; AI cannot sign or convert. |
| Enumerated error codes | §6.7 | Stable machine-readable error contract. |
| JSON multi-signature evidence as **derived snapshot** | §6.6 | The `electronic_signatures` substrate is the system of record. |
| India CDSCO §17 row | §14 | India CDSCO Schedule M (Revised) §17 PQR + Schedule M-III §3.7 captured for India operations subject to a future jurisdiction-specific legal assessment. |
| Version 1.0 posture | Header | First binding version. |
| Canonical API mount `/api/v1/apqr/*` | DEC-26-01 / APQR-001 ALIGNED | Retained. |
| Mandatory study scope alignment (`study_id` NOT NULL) | DEC-26-02 / APQR-002 | `createAPQRReportSchema` requires `study_id`; `MODULE_CONTEXT_CONFIG.apqr` declares both `study_id` and `product_id` filtering. |
| Mandatory `product_id` FK + immutable product snapshot | DEC-26-03 / APQR-003 | Replaces free-text `VARCHAR(100)` product binding with FK to URS-10 + immutable snapshot of product attributes at report creation. |
| Terminal-state patch-bypass prevention + version increment on update | DEC-26-04 / APQR-004 | `updateReport` cannot set `status` to `approved` / `rejected` / `locked`; report version increments on any material update. |
| Data-collection provenance + refresh mode + source-system reference | DEC-26-05 / APQR-005 | Replaces free-text `data_source_table`; captures `source_module`, `source_record_query_hash`, `refresh_mode` (manual / scheduled / on-demand), `last_refreshed_at`. |
| Statistical-analysis input-dataset provenance + reproducible method metadata | DEC-26-06 / APQR-006 | Captures `input_dataset_hash`, `method_name`, `method_version`, `method_parameters_json`. |
| Recommendation mandatory downstream linkage | DEC-26-07 / APQR-007 | Recommendations requiring implementation MUST link to URS-13 CR or URS-18 CAPA. |
| Approval-step assigned-approver validation + sequencing + SoD | DEC-26-08 / APQR-008 | Acting user MUST equal `apqr_approvals.assigned_to`; sequenced; preparer ≠ approver. |
| Server-attributed signature evidence | DEC-26-09 / APQR-009 | Signature IP / user-agent / timestamp derived from request context; never client-supplied. |
| Year-over-year governed writer | DEC-26-10 / APQR-010 | Generation/refresh path with `formula_version` + `generated_by` + immutable snapshot. |
| AI-insight provenance + mandatory human acceptance + lock-on-acceptance | DEC-26-11 / APQR-011 | Replaces free-text `ai_insights` field; provenance per record; advisory until human-accepted. |
| Audit-trail coverage on lifecycle transitions + recalls + signed approvals | DEC-26-12 / APQR-012 | Full audit detail for state transitions, recall, lock, reopen, signed approval ceremonies. |
| Authority/HITL/e-sign on every regulated final action | DEC-26-13 / APQR-008 / APQR-009 | Approval signing / report approval / recall / lock / reopen all carry authority + HITL + bound e-sign. |
| Frontend workflow completeness | DEC-26-14 / APQR-013 | Data-collection entry / analysis execution / recommendation management / approval-step assignment / approve-reject / recall-rework UI added. |
| Bound e-signature persistence on every regulated final action | DEC-26-13 / DEC-26-23 | Approval signing / report approval / recall / lock / reopen — all carry bound e-signature. |
| Governed reopen pattern (`locked → in_progress`) | DEC-26-22 / SoD-26-06 | Append-only iteration; executive + QP co-sign; does NOT mutate prior locked evidence. |
| Governed recall pattern (`approved → recalled → in_progress`) | DEC-26-23 | Recall as governed transition pre-lock; appends new iteration. |

---

## 1. Scope and Out-of-Scope

### 1.1 In-scope

- The canonical APQR-report register and lifecycle.
- The data-collection substructure with source provenance + refresh mode + source-system reference.
- The statistical-analysis substructure with input-dataset provenance + reproducible method metadata.
- The recommendation substructure with mandatory downstream linkage.
- The approval-step substructure with assigned-approver validation + sequencing + SoD + server-attributed signature evidence.
- The year-over-year comparison substructure with governed writer.
- The AI-insights substructure with provenance + mandatory human acceptance.
- The MIRA copilot read-only context integration (advisory drafting only).
- The findings emission to URS-21.
- The CAPA emission to URS-18.
- The change-control linkage to URS-13.
- The read-only data consumer integration with URS-23, URS-24, URS-25, URS-15, URS-16, URS-18, URS-13, URS-14, URS-21, URS-22.
- The governed reopen / recall workflow.
- The audit-trail coverage with reason-for-change discipline.
- The per-jurisdictional regulatory expectations.

### 1.2 Out-of-scope

- The CAPA register itself (URS-18) — this URS emits APQR-recommendation→CAPA events; CAPA closure is the URS-18 contract.
- The change-control register itself (URS-13) — this URS emits APQR-recommendation→CR events; CR closure is the URS-13 contract.
- The findings register itself (URS-21) — this URS emits APQR-finding events; finding lifecycle is the URS-21 contract.
- The document-control register itself (URS-12).
- The MIRA copilot service itself (URS-32).
- Direct ERP / financial integration for cost-of-quality — out of scope for v1.0.
- Automated regulatory submission of APQR (e.g., FDA Field Alert Reports auto-generation) — future-state.

---

## 2. Preconditions, Dependencies, Constraints

### 2.1 Operating preconditions

The following preconditions MUST hold for this URS to apply at validation time. Each bullet is a binding precondition; deviations require a controlled exception per URS-13 Change Control.

- The platform's authentication and session substrate (URS-01), RBAC (URS-02), context gate (URS-03), HITL / e-sign (URS-04), Authority Profile registry (URS-05), audit-trail hash-chain (URS-06), Product master (URS-10), document-control (URS-12), change-control (URS-13), source modules (URS-14, URS-15, URS-16, URS-18, URS-21, URS-22, URS-23, URS-24, URS-25), and MIRA AI (URS-32) are released and operational at validation time.
- APQR authors, reviewers, approvers, Qualified Person are trained, attributable users with documented authority.
- AI-assisted APQR surfaces are advisory only; the human approver's signed disposition is the system of record.
- The tenant operating jurisdiction(s) are configured and applicable predicate rules surface accordingly.

### 2.2 Dependencies

- URS-01.URS-25, URS-27.URS-35 platform contracts.
- The `electronic_signatures` substrate.
- The `authority` substrate.
- The `hitl` substrate.
- The `audit_trail` substrate.
- The `documents` substrate (URS-12).
- The `change_control` substrate (URS-13).
- The `capa` substrate (URS-18).
- All data-source modules (URS-14, URS-15, URS-16, URS-18, URS-21, URS-22, URS-23, URS-24, URS-25).
- The `notifications` substrate (URS-30).

### 2.3 Constraints

- The canonical API mount is `/api/v1/apqr/*`. No frontend hook may use `/api/apqr/*` (extra `/api`).
- The APQR module is study-scoped + product-scoped at report level; site-scope inherited via `studies` parent.
- AI-assisted content is advisory-only; **no AI service finalizes APQR approval, signs an approval step, or converts a recommendation to a downstream CAPA / CR**.
- Generative AI may draft advisory narrative only; mandatory human acceptance required to promote AI insight to system-of-record narrative.
- Approval-step signing requires the acting user to match `apqr_approvals.assigned_to` per DEC-26-08.
- Signature evidence is server-attributed; client-supplied signature IP / user-agent rejected.
- Released / rejected / locked states cannot be set via direct PATCH per DEC-26-04.
- Recommendations requiring implementation MUST link to URS-13 CR or URS-18 CAPA per DEC-26-07.

---

## 3. Closed Launch Decisions

### 3.1 Decision register

| Decision ID | Title | Locked decision |
|---|---|---|
| DEC-26-01 | Two-step release path | Module 26 follows the same two-step release path as every other Module. |
| DEC-26-02 | Mandatory study scope + context-filter alignment + typed schema | `study_id` is mandatory at report level (matching migration 033 NOT NULL); `MODULE_CONTEXT_CONFIG.apqr` declares both `study_id` and `product_id` filtering; `createAPQRReportSchema` no longer allows nullable `study_id`; typed schema validation across every route. |
| DEC-26-03 | Mandatory `product_id` FK + immutable product snapshot | `product_id` becomes a mandatory FK to URS-10 Product master at report level; on report creation, an immutable product snapshot is captured (`product_snapshot_json` containing product code, name, dosage form, strength, route of administration, registration status as of `period_end`). |
| DEC-26-04 | Terminal-state patch-bypass prevention + version increment on update | The generic `PATCH /apqr/reports/:id` route excludes `status` from allowed-fields; status transitions occur only through controlled lifecycle endpoints; report `version` increments on any material update with reason-for-change per DEC-26-12. |
| DEC-26-05 | Data-collection provenance + refresh mode + source-system reference | `apqr_data_collections` persists `source_module` (ENUM `batch` / `stability` / `em` / `oos` / `deviations` / `capa` / `change_control` / `complaints` / `findings` / `inspection` / `manual`), `source_record_query_hash`, `refresh_mode` (ENUM `manual` / `scheduled` / `on_demand`), `last_refreshed_at`, `last_refreshed_by`, `formula_version`; replaces free-text `data_source_table`. |
| DEC-26-06 | Statistical-analysis input-dataset provenance + reproducible method metadata | `apqr_statistical_analyses` persists `input_dataset_hash`, `input_dataset_record_count`, `method_name` (ENUM `control_chart` / `cpk_cpu_cpl` / `regression` / `descriptive` / `comparison`), `method_version`, `method_parameters_json`, `executed_by`, `executed_at`, `formula_version`. |
| DEC-26-07 | Recommendation mandatory downstream linkage | `apqr_recommendations` persists `recommendation_severity` (ENUM `informational` / `improvement` / `required`); recommendations with `severity = required` MUST link to a URS-13 Change Request via `recommendation_change_request_id` OR a URS-18 CAPA via `recommendation_capa_id` before APQR can be approved; recommendation closure requires linked downstream record in terminal status. |
| DEC-26-08 | Approval-step assigned-approver validation + sequencing + SoD | `apqr_approvals` persists `step_order`, `assigned_to`, `step_status` (`pending` / `signed` / `rejected` / `recalled`); approval-step signing requires the acting user to match `assigned_to`; preceding steps must be in `signed` status before next step opens; the report preparer (`apqr_reports.created_by`) MUST NOT be assigned as any approver (preparer ≠ approver per SoD-26-02); SoD-26-03 enforces that an approval step holder MUST NOT be assigned as a subsequent step approver unless tenant policy explicitly permits same-person multi-step. |
| DEC-26-09 | Server-attributed signature evidence | Signature IP, user-agent, and timestamp are derived from the request context (`request.ip`, `request.headers['user-agent']`, server clock); the request body MAY NOT supply `signature_ip_address` or `signature_user_agent`; client-supplied signature evidence is rejected with `APQR_SIGNATURE_EVIDENCE_CLIENT_SUPPLIED`. |
| DEC-26-10 | Year-over-year governed writer | `apqr_year_over_year` is generated via a governed writer that compares current-period APQR metrics against prior-period APQR metrics; refresh `on_demand` (authorized user) or `scheduled` (configurable); persists `formula_version`, `generated_by`, `generated_at`; YoY records are immutable snapshots. |
| DEC-26-11 | AI-insight provenance + mandatory human acceptance + lock-on-acceptance | `apqr_ai_insights` substructure replaces the free-text `ai_insights` field on the report header; per-insight columns include `insight_type`, `narrative_text`, `model_id`, `model_version`, `prompt_version`, `confidence`, `citation_snapshot_json`, `proposed_at`, `proposed_by_system`, `accepted_by` (FK nullable), `accepted_at` (nullable), `acceptance_e_signature_id` (FK nullable), `accepted_text_immutable` (TEXT nullable — locked on acceptance); AI-generated narrative is advisory until accepted; promotion to APQR system-of-record narrative requires explicit human confirmation captured in `acceptance_e_signature_id`. |
| DEC-26-12 | Audit-trail coverage on lifecycle transitions + recalls + signed approvals + reason-for-change discipline | Every mutation route emits audit-trail entries; lifecycle transitions / recall / lock / reopen / signed approvals carry full audit detail; material updates after draft require structured reason-for-change. |
| DEC-26-13 | Authority/HITL/e-sign on every regulated final action | Approval-step signing, report approval, report rejection, report recall, report lock, governed reopen all use `withAuthority(.)` + HITL + bound e-signature persisted via `electronic_signatures` substrate. |
| DEC-26-14 | Frontend workflow completeness | Frontend extends to data-collection entry, analysis execution, recommendation management with downstream-linkage UI, approval-step assignment, approve / reject ceremonies with bound e-signature UI, recall / rework UI, AI-insight provenance + acceptance UI, year-over-year refresh UI. |
| DEC-26-15 | Findings emission to URS-21 | APQR findings (e.g., review-period gaps, control-chart out-of-trend findings) emit `apqr_finding_created` to URS-21 with `apqr_finding` source type. |
| DEC-26-16 | Recommendation→CAPA emission to URS-18 | Recommendations linked to URS-18 CAPA emit `apqr_recommendation_capa_linked` event consumed by URS-18 (`apqr_recommendation` source type per URS-18 declared source set). |
| DEC-26-17 | Recommendation→Change-Request linkage to URS-13 | Recommendations linked to URS-13 Change Request emit `apqr_recommendation_cr_linked` event consumed by URS-13. |
| DEC-26-18 | Read-only data consumer integration | Module 26 consumes read-only data from URS-23 (batch records), URS-24 (stability — locked studies + approved shelf-life claims), URS-25 (`em_trend_datasets`), URS-15 (OOS), URS-16 (deviations), URS-18 (CAPA), URS-13 (change control), URS-14 (complaints), URS-21 (findings), URS-22 (inspection); consumption is read-only with provenance captured per DEC-26-05. |
| DEC-26-19 | Multi-dimensional context model | `tenant_id`, `study_id` mandatory, `product_id` mandatory FK, `period_start`, `period_end` mandatory, `site_id` optional inherited from `studies`. |
| DEC-26-20 | platform_admin / super_admin | `platform_admin` / `super_admin` are support / break-glass only paths. |
| DEC-26-21 | Reason-for-change on material updates | Captured per DEC-26-12. |
| DEC-26-22 | APQR reopen as governed transition | Report `locked → in_progress` requires `executive_authority` co-sign AND `qualified_person_authority` co-sign + documented reason; appends a new APQR iteration without mutating prior locked evidence (consistent with M14.M25 reopen pattern). |
| DEC-26-23 | APQR recall as governed transition | Report `approved → recalled → in_progress` is a governed transition pre-lock requiring `executive_authority` co-sign + reason; appends a new APQR iteration; useful for material-change recalls before the auto-lock SLA. |

### 3.2 Locked-decision rationale narrative

The decisions above define the binding launch posture for Module 26 v1.0. The most consequential locked controls are: (a) DEC-26-02 / DEC-26-03 make `study_id` mandatory, replace free-text `product_id` with a mandatory FK + immutable snapshot, and align `createAPQRReportSchema`, the typed DB layer, and `MODULE_CONTEXT_CONFIG.apqr` to the persisted schema; (b) DEC-26-04 removes `status` from the generic PATCH allowed-fields and requires controlled lifecycle endpoints; (c) DEC-26-05 replaces free-text `data_source_table` with `source_module` ENUM + `source_record_query_hash` + `refresh_mode` for data-collection provenance; (d) DEC-26-07 mandates downstream URS-13 CR or URS-18 CAPA linkage for `severity = required` recommendations; (e) DEC-26-08 / DEC-26-09 mandate assigned-approver validation + sequencing + SoD enforcement + server-attributed signature evidence on approval signing; (f) DEC-26-11 replaces the free-text `ai_insights` field with a controlled substructure requiring provenance + human acceptance + lock-on-acceptance; (g) DEC-26-22 defines reopen as a governed append-only transition consistent with the Module-14..-25 reopen pattern.

### 3.3 Closed launch decisions: cross-link to items

| Specification item ID | Specification item | Locked decision |
|---|---|---|
| APQR-001 | API contract (ALIGNED) | DEC-26-01 (retained) |
| APQR-002 | Study scope + context-filter conflict | DEC-26-02 |
| APQR-003 | Free-text product binding | DEC-26-03 |
| APQR-004 | Lifecycle bypass + version not incremented | DEC-26-04 |
| APQR-005 | Data-collection provenance missing | DEC-26-05 |
| APQR-006 | Analysis provenance missing | DEC-26-06 |
| APQR-007 | Recommendation downstream linkage missing | DEC-26-07 / DEC-26-16 / DEC-26-17 |
| APQR-008 | Assigned-approver validation + SoD missing | DEC-26-08 |
| APQR-009 | Client-supplied signature evidence | DEC-26-09 |
| APQR-010 | YoY writer missing | DEC-26-10 |
| APQR-011 | AI-insight provenance + acceptance missing | DEC-26-11 |
| APQR-012 | Audit + reason-for-change gaps | DEC-26-12 / DEC-26-21 |
| APQR-013 | Frontend workflow + test gaps | DEC-26-14 + §16 + §17 |

### 3.4 Locked-decision authority

Each locked decision is approved by the Founder / Chairman & MD on signature capture in the Document Approval block of this URS (§19). Decisions cannot be unlocked except through controlled URS revision under the URS change-control process and re-approval.

### 3.5 Worked examples

**Worked example 1 — APQR for Product P-Tabs covering 2026 calendar year.**
The QA APQR Author opens an APQR for Product P-Tabs (FK `product_id = PROD-PTabs`) for `period_start = 2026-01-01`, `period_end = 2026-12-31`; the report header captures `product_snapshot_json` with the product master state as of 2026-12-31 per DEC-26-03. The report enters `draft → data_collection`. Data-collection rows are added: `source_module = batch` referencing all locked URS-23 batch records in the period (87 batches; query hash captured); `source_module = stability` referencing all approved shelf-life claims and locked stability studies in the period; `source_module = em` referencing all `em_trend_datasets` from URS-25; `source_module = oos` (4 OOS investigations); `source_module = deviations` (12 deviations); `source_module = capa` (3 open + 8 closed CAPAs); `source_module = change_control` (5 CRs); `source_module = complaints` (6 complaints); `source_module = findings` (2 findings); `source_module = inspection` (1 FDA Form 483 from URS-22). Each data-collection row carries `refresh_mode = scheduled`, `last_refreshed_at`, `formula_version` per DEC-26-05. Statistical analyses are run: control charts on assay (input dataset hash captured), Cpk on dissolution, regression on yield, year-over-year comparison vs 2025 APQR (computed via governed YoY writer per DEC-26-10). 7 recommendations are added: 4 informational, 2 improvement, 1 required (linked to URS-18 CAPA `CAPA-2027-001` per DEC-26-07 / DEC-26-16). MIRA proposes 3 advisory AI insights: trend commentary, deviation roll-up, narrative summary; each persisted in `apqr_ai_insights` with model identifier `claude-sonnet-4`, model version, prompt version, confidence per DEC-26-11. The QA APQR Author reviews the AI insights; accepts 2 (with bound e-signature); rejects 1; only the 2 accepted insights are written to the system-of-record narrative. Report transitions `data_collection → in_progress → under_review`. The APQR Author submits for approval; approval steps are assigned: Step 1 QA Reviewer, Step 2 Manufacturing Head, Step 3 Qualified Person — preparer (the Author) is excluded from any step per SoD-26-02. Step 1 is signed by the QA Reviewer (who matches `apqr_approvals.assigned_to` per DEC-26-08); signature evidence (IP / user-agent / timestamp) is server-attributed per DEC-26-09. Step 2 opens; Manufacturing Head signs. Step 3 opens; Qualified Person signs. Report transitions `pending_approval → approved`; bound e-signature on report header captured. After 24h the report auto-locks; bound e-signature on lock per DEC-26-23.

**Worked example 2 — Recall before lock.**
On `2027-04-15` (after report `approved` but before auto-lock — actually the auto-lock SLA had 6h remaining), a material discrepancy is found in the locked URS-23 batch evidence. The Manufacturing Head initiates a recall per DEC-26-23; `executive_authority` co-sign + reason captured. Report transitions `approved → recalled → in_progress`; new APQR iteration appended; prior approved evidence NOT mutated; new iteration captures the revised analysis and re-routes through approval steps.

**Worked example 3 — Governed reopen of locked APQR.**
On `2027-08-10` an FDA inspection finding (URS-22) reveals the locked APQR may have under-reported one OOS investigation. The Manufacturing Head initiates a reopen; per DEC-26-22 + SoD-26-06, `executive_authority` co-sign AND `qualified_person_authority` co-sign + documented reason are required. On both co-signs the report transitions `locked → in_progress` and a new APQR iteration is appended; the prior locked evidence (data collections, analyses, recommendations, approvals, accepted AI insights, YoY) is NOT mutated; the new iteration captures the revised investigation and re-routes through approval steps.

**Worked example 4 — Approval-step SoD violation rejected.**
The APQR Author tries to assign themselves as the QA Reviewer step. Per DEC-26-08 + SoD-26-02, the system rejects with `APQR_PREPARER_APPROVER_SOD_VIOLATION`; the Author cannot be assigned as any approver. A different user with `apqr_approver_authority` is selected.

---

## 4. End-to-End User Journeys (28 launch journeys)

| # | Journey | Actor | Pre-condition | Path | Post-condition |
|---|---|---|---|---|---|
| 1 | Create APQR report | APQR Author | `apqr:report:create`; `study_id`, `product_id` resolved | Create report `(study_id, product_id, period_start, period_end)`; capture immutable product snapshot per DEC-26-03 | Report `draft`; product snapshot persisted; audit entry |
| 2 | Add data collection from URS-23 batch records | APQR Author | Report `draft` or `data_collection`; URS-23 read access | Add data-collection row with `source_module = batch`, `source_record_query_hash`, `refresh_mode` per DEC-26-05 | Data-collection row persisted; audit entry |
| 3 | Add data collection from URS-24 stability | APQR Author | URS-24 read access | Add data-collection row with `source_module = stability` | Data-collection row persisted |
| 4 | Add data collection from URS-25 EM trend datasets | APQR Author | URS-25 read access | Add data-collection row with `source_module = em` | Data-collection row persisted |
| 5 | Add data collections from URS-15/-16/-18/-13/-14/-21/-22 | APQR Author | Read access to source modules | Add data-collection rows with corresponding `source_module` | Data-collection rows persisted |
| 6 | Refresh data collection on demand | APQR Author | Data-collection row exists | Re-run query against source module; persist `last_refreshed_at`, `last_refreshed_by` per DEC-26-05 | Data-collection row refreshed; audit entry |
| 7 | Run statistical analysis | APQR Author | Data collections in place | Execute analysis with `method_name`, `method_version`, `method_parameters_json`, `input_dataset_hash` per DEC-26-06 | Analysis persisted with provenance; audit entry |
| 8 | Add recommendation (informational) | APQR Author | Report `in_progress` | Add recommendation `severity = informational` | Recommendation persisted |
| 9 | Add recommendation (required) with URS-18 CAPA linkage | APQR Author | Required severity; URS-18 CAPA created | Add recommendation `severity = required`; persist `recommendation_capa_id`; emit `apqr_recommendation_capa_linked` to URS-18 per DEC-26-16 | Recommendation linked to CAPA; URS-18 CAPA created with `apqr_recommendation` source type |
| 10 | Add recommendation (required) with URS-13 CR linkage | APQR Author | Required severity; URS-13 CR created | Add recommendation `severity = required`; persist `recommendation_change_request_id`; emit `apqr_recommendation_cr_linked` to URS-13 per DEC-26-17 | Recommendation linked to CR |
| 11 | Reject required recommendation without linkage | System (validation) | Required severity; no downstream link | Reject with `APQR_RECOMMENDATION_LINKAGE_REQUIRED` per DEC-26-07 | Operation rejected |
| 12 | Generate year-over-year via governed writer | System (on demand or scheduled) | Prior-period APQR exists | Compute YoY metrics; persist with `formula_version` per DEC-26-10 | YoY snapshot persisted; immutable |
| 13 | MIRA proposes AI insight | System (MIRA) | Authorized user requests | Persist insight in `apqr_ai_insights` with full provenance per DEC-26-11 | Insight `proposed`; advisory only |
| 14 | Accept AI insight | APQR Author / Quality Lead | Insight `proposed` | HITL + bound e-sign; persist `accepted_by`, `accepted_at`, `acceptance_e_signature_id`, `accepted_text_immutable` per DEC-26-11 | Insight `accepted`; locked text written to system-of-record |
| 15 | Reject AI insight | APQR Author / Quality Lead | Insight `proposed` | Mark `rejected`; capture rejection reason | Insight rejected; not promoted to system-of-record |
| 16 | Submit report for approval | APQR Author | Report `under_review`; all `severity=required` recommendations linked per DEC-26-07 | Transition `under_review → pending_approval`; create approval steps with assigned approvers per DEC-26-08 | Report `pending_approval`; approval steps in `pending` |
| 17 | Reject preparer-as-approver assignment | System (validation) | Author = approver | Reject with `APQR_PREPARER_APPROVER_SOD_VIOLATION` per SoD-26-02 / DEC-26-08 | Operation rejected |
| 18 | Sign approval step (assigned approver) | Approver (matches `assigned_to`) | Approval step `pending`; preceding steps `signed` | HITL + bound e-sign with server-attributed evidence per DEC-26-09; transition `pending → signed` | Approval step `signed`; signature evidence server-attributed; next step opens |
| 19 | Reject approval step | Approver | Approval step `pending` | Reject with reason; transition `pending → rejected` | Approval step `rejected`; report transitions `pending_approval → rejected` |
| 20 | Reject signing by non-assigned actor | System (validation) | Acting user ≠ `assigned_to` | Reject with `APQR_APPROVER_NOT_ASSIGNED` per DEC-26-08 | Operation rejected |
| 21 | Reject client-supplied signature evidence | System (validation) | Body contains `signature_ip_address` or `signature_user_agent` | Reject with `APQR_SIGNATURE_EVIDENCE_CLIENT_SUPPLIED` per DEC-26-09 | Operation rejected |
| 22 | Approve report | Final Quality Approver / Qualified Person | All approval steps `signed` | Bound e-sign on report header; transition `pending_approval → approved` | Report `approved`; bound e-signature; `apqr_report_approved` event |
| 23 | Recall approved report (governed transition) | Manufacturing Head / Executive Authority | Report `approved`; pre-lock | `executive_authority` co-sign + reason; transition `approved → recalled → in_progress`; append new iteration per DEC-26-23 | Report `in_progress`; new iteration appended; prior approved evidence NOT mutated |
| 24 | Auto-lock approved report | System (auto + bound e-sign) | Report `approved` for ≥ 24h | Transition `approved → locked` with bound e-sign per DEC-26-13 | Report `locked`; immutable; `apqr_report_locked` event |
| 25 | Reopen locked report (governed transition) | Manufacturing Head + Executive Authority + Qualified Person | Report `locked`; documented reason | Executive co-sign AND QP co-sign; transition `locked → in_progress`; append new iteration per DEC-26-22 | Report `in_progress`; new iteration appended; prior locked evidence NOT mutated; bound e-signature; `apqr_report_reopened` event |
| 26 | Direct PATCH on terminal status rejected | APQR Author (attempted) | Generic PATCH attempt setting `status = approved` | Reject with `APQR_TERMINAL_STATE_PATCH_FORBIDDEN` per DEC-26-04 | Operation rejected |
| 27 | Apply context filter on APQR query | Reader | `apqr:read`; study + product context | Query filtered by `study_id` AND `product_id` per DEC-26-02 | Context-scoped results; no invalid SQL |
| 28 | Cross-tenant `platform_admin` break-glass | platform_admin | Documented reason | Cross-tenant APQR coordination access; logged | Break-glass action logged in platform support audit per DEC-26-20 |

---

## 5. Front-end Requirements

### 5.1 APQR List

The APQR list (URS-26-FE-001) renders APQR reports with filters by study, product, period, status; uses canonical `/apqr/*` hooks per DEC-26-01.

### 5.2 APQR Detail

The APQR detail (URS-26-FE-002) renders the complete report: header (with immutable product snapshot per DEC-26-03), data collections (with source-module + refresh-mode badges per DEC-26-05), statistical analyses (with method-version badges per DEC-26-06), recommendations (with downstream-linkage badges per DEC-26-07), approval steps (with assigned-approver + sequenced badges per DEC-26-08), AI insights (with provenance + acceptance status per DEC-26-11), YoY comparison (with formula-version badge per DEC-26-10).

### 5.3 Data Collection Console

The data collection console (URS-26-FE-003) supports adding data-collection rows with source-module selection (`batch` / `stability` / `em` / `oos` / `deviations` / `capa` / `change_control` / `complaints` / `findings` / `inspection` / `manual`); query-hash capture; refresh-mode selection; manual / scheduled / on-demand refresh per DEC-26-05.

### 5.4 Analysis Execution

The analysis execution console (URS-26-FE-004) supports `method_name` selection (`control_chart` / `cpk_cpu_cpl` / `regression` / `descriptive` / `comparison`), method parameters, input-dataset-hash capture per DEC-26-06.

### 5.5 Recommendation Management

The recommendation management console (URS-26-FE-005) supports recommendation entry with `severity` selection; `severity = required` enforces downstream-linkage UI for URS-13 CR or URS-18 CAPA per DEC-26-07.

### 5.6 Approval Workflow

The approval workflow console (URS-26-FE-006) renders approval steps with sequenced ordering, assigned approvers (preparer excluded per SoD-26-02), signing ceremony with bound e-signature (server-attributed evidence per DEC-26-09), reject ceremony with reason capture.

### 5.7 AI Insight Console

The AI insight console (URS-26-FE-007) renders AI-generated insights with provenance (model, model version, prompt version, confidence, citation snapshot), accept ceremony with bound e-signature, reject ceremony with reason; advisory-only labeling per DEC-26-11 + ARCH-AI-001 AC-3.

### 5.8 Year-over-Year Console

The YoY console (URS-26-FE-008) renders YoY comparison with on-demand refresh and configurable scheduled refresh per DEC-26-10.

### 5.9 Recall / Reopen Console

The recall / reopen console (URS-26-FE-009) supports governed recall (`approved → recalled → in_progress` per DEC-26-23) and governed reopen (`locked → in_progress` per DEC-26-22) with executive + QP co-sign UI.

### 5.10 MIRA Copilot Integration

MIRA copilot (URS-26-FE-010) is read-only context on APQR records via `useMiraRecord('apqr_report', id)`. **AI-generated narrative is advisory only with mandatory human acceptance per DEC-26-11; no AI signs approval steps; no AI converts recommendations to downstream CAPA / CR.**

### 5.11 Accessibility

WCAG 2.1 AA accessible.

---

## 6. Back-end Requirements

### 6.1 Module structure

`packages/backend/src/modules/apqr/` with `plugin.ts`, `routes.ts` (typed schemas — per DEC-26-02), `service.ts` (terminal-state patch-bypass prevention; version increment on update; data-collection provenance + refresh; analysis provenance; recommendation downstream-linkage validation; assigned-approver validation; server-attributed signature evidence; YoY governed writer; AI-insight provenance + acceptance; audit-trail + reason-for-change), `schemas.ts` (aligned with migration 033 per DEC-26-02 / DEC-26-03), `events.ts` (event emission for `apqr_*` events).

### 6.2 Data model

#### 6.2.1 `apqr_reports`

`id`, `tenant_id`, `study_id` (NOT NULL FK per DEC-26-02), `product_id` (NOT NULL FK to URS-10 per DEC-26-03), `product_snapshot_json` (JSONB NOT NULL — immutable snapshot per DEC-26-03), `period_start` (DATE NOT NULL), `period_end` (DATE NOT NULL), `report_code`, `version` (INTEGER NOT NULL DEFAULT 1 — increments on material update per DEC-26-04), `status` (ENUM `draft` / `data_collection` / `in_progress` / `under_review` / `pending_approval` / `approved` / `rejected` / `recalled` / `locked`), `approved_by` (FK nullable), `approval_timestamp` (TIMESTAMPTZ nullable), `approval_e_signature_id` (FK nullable), `locked_at` (TIMESTAMPTZ nullable), `locked_by` (FK nullable), `lock_e_signature_id` (FK nullable), `recalled_at` (TIMESTAMPTZ nullable), `recalled_by` (FK nullable), `recall_executive_co_signer` (FK nullable per DEC-26-23), `recall_reason` (TEXT nullable), `reopened_at` (TIMESTAMPTZ nullable), `reopened_by` (FK nullable), `reopen_executive_co_signer` (FK nullable per DEC-26-22), `reopen_qp_co_signer` (FK nullable per DEC-26-22), `reopen_reason` (TEXT nullable), `reason_for_change` (TEXT nullable per DEC-26-21), audit columns. Note: legacy free-text `ai_insights` field removed per DEC-26-11 (replaced by normalized `apqr_ai_insights` table). Legacy client-supplied signature columns (`approval_signature_ip`, `approval_signature_ua`) deprecated; signature evidence captured in `electronic_signatures` substrate per DEC-26-09. Uniqueness `(tenant_id, study_id, product_id, period_start, period_end)`. RLS enabled.

#### 6.2.2 `apqr_data_collections`

`id`, `tenant_id`, `report_id` (FK), `section_label`, `source_module` (ENUM per DEC-26-05), `source_record_query_hash` (TEXT NOT NULL per DEC-26-05), `refresh_mode` (ENUM `manual` / `scheduled` / `on_demand`), `last_refreshed_at` (TIMESTAMPTZ), `last_refreshed_by` (FK), `formula_version` (TEXT), `aggregated_summary_json` (JSONB), audit columns.

#### 6.2.3 `apqr_statistical_analyses`

`id`, `tenant_id`, `report_id` (FK), `data_collection_id` (FK nullable), `method_name` (ENUM `control_chart` / `cpk_cpu_cpl` / `regression` / `descriptive` / `comparison`), `method_version`, `method_parameters_json` (JSONB), `input_dataset_hash` (TEXT NOT NULL per DEC-26-06), `input_dataset_record_count` (INTEGER), `output_summary_json` (JSONB), `executed_by`, `executed_at`, `formula_version`, audit columns.

#### 6.2.4 `apqr_recommendations`

`id`, `tenant_id`, `report_id` (FK), `recommendation_text`, `severity` (ENUM `informational` / `improvement` / `required` per DEC-26-07), `recommendation_capa_id` (FK to URS-18 nullable), `recommendation_change_request_id` (FK to URS-13 nullable), `linked_at` (TIMESTAMPTZ nullable), `linked_by` (FK nullable), `closure_status` (ENUM `open` / `linked` / `implemented` / `closed`), audit columns. Constraint: `severity = required` requires `recommendation_capa_id` OR `recommendation_change_request_id` to be NOT NULL before APQR can be approved per DEC-26-07.

#### 6.2.5 `apqr_approvals`

`id`, `tenant_id`, `report_id` (FK), `step_order` (INTEGER NOT NULL per DEC-26-08), `assigned_to` (FK NOT NULL), `step_status` (ENUM `pending` / `signed` / `rejected` / `recalled`), `signed_by` (FK nullable — must equal `assigned_to` on sign per DEC-26-08), `signed_at` (TIMESTAMPTZ nullable), `step_e_signature_id` (FK nullable), `signature_ip` (TEXT nullable — server-attributed per DEC-26-09), `signature_user_agent` (TEXT nullable — server-attributed per DEC-26-09), `rejection_reason` (TEXT nullable), audit columns. Constraint: `signed_by` must equal `assigned_to` when `step_status = signed`. Constraint: signature evidence is captured in `electronic_signatures` substrate; the `signature_ip` / `signature_user_agent` columns are derived snapshots for fast querying.

#### 6.2.6 `apqr_ai_insights`

`id`, `tenant_id`, `report_id` (FK), `insight_type` (ENUM `narrative_summary` / `trend_commentary` / `deviation_rollup` / `recommendation_suggestion` / `complaint_rollup` / `change_control_rollup`), `narrative_text` (TEXT — proposed text), `model_id` (TEXT NOT NULL per DEC-26-11), `model_version` (TEXT NOT NULL), `prompt_version` (TEXT NOT NULL), `confidence` (NUMERIC(3,2)), `citation_snapshot_json` (JSONB), `proposed_at` (TIMESTAMPTZ), `proposed_by_system` (TEXT — e.g., `mira_copilot`), `accepted_by` (FK nullable per DEC-26-11), `accepted_at` (TIMESTAMPTZ nullable), `acceptance_e_signature_id` (FK nullable), `accepted_text_immutable` (TEXT nullable — locked on acceptance per DEC-26-11), `rejection_reason` (TEXT nullable), `status` (ENUM `proposed` / `accepted` / `rejected`), audit columns.

#### 6.2.7 `apqr_year_over_year`

`id`, `tenant_id`, `report_id` (FK), `prior_report_id` (FK nullable), `metric_name`, `current_value`, `prior_value`, `delta`, `delta_pct`, `formula_version`, `generated_by`, `generated_at`, audit columns. Immutable snapshot per DEC-26-10.

#### 6.2.8 RLS

All Module 26 tables have RLS enabled.

### 6.3 API contract

| Route | Method | Permission | Status |
|---|---|---|---|
| `/api/v1/apqr/reports` | GET / POST | `apqr:report:read` / `apqr:report:create` | (typed schema) |
| `/api/v1/apqr/reports/:id` | GET / PATCH (status field excluded per DEC-26-04) | `apqr:report:read` / `apqr:report:update` (version increment on update per DEC-26-04) | |
| `/api/v1/apqr/reports/:id/data-collections` | GET / POST | `apqr:data_collection:read` / `apqr:data_collection:create` | (per DEC-26-05) |
| `/api/v1/apqr/reports/:id/data-collections/:dcId/refresh` | POST | `apqr:data_collection:refresh` | target route per DEC-26-05 |
| `/api/v1/apqr/reports/:id/analyses` | GET / POST | `apqr:analysis:read` / `apqr:analysis:create` | (per DEC-26-06) |
| `/api/v1/apqr/reports/:id/recommendations` | GET / POST / PATCH | `apqr:recommendation:read` / `apqr:recommendation:create` / `apqr:recommendation:update` | |
| `/api/v1/apqr/reports/:id/recommendations/:recId/link-capa` | POST | `apqr:recommendation:link_capa` (emits `apqr_recommendation_capa_linked`) | target route per DEC-26-16 |
| `/api/v1/apqr/reports/:id/recommendations/:recId/link-cr` | POST | `apqr:recommendation:link_cr` (emits `apqr_recommendation_cr_linked`) | target route per DEC-26-17 |
| `/api/v1/apqr/reports/:id/ai-insights` | GET / POST | `apqr:ai_insight:read` / `apqr:ai_insight:propose` (advisory only per DEC-26-11) | target route |
| `/api/v1/apqr/reports/:id/ai-insights/:insightId/accept` | POST | `apqr:ai_insight:accept` + HITL + bound e-sign per DEC-26-11 | target route |
| `/api/v1/apqr/reports/:id/ai-insights/:insightId/reject` | POST | `apqr:ai_insight:reject` (with reason) | target route |
| `/api/v1/apqr/reports/:id/yoy/refresh` | POST | `apqr:yoy:refresh` per DEC-26-10 | target route |
| `/api/v1/apqr/reports/:id/yoy` | GET | `apqr:yoy:read` | |
| `/api/v1/apqr/reports/:id/submit-for-approval` | POST | `apqr_author_authority` (validates all `severity=required` recommendations linked per DEC-26-07; creates approval steps per DEC-26-08) | |
| `/api/v1/apqr/reports/:id/approvals` | GET | `apqr:approval:read` | |
| `/api/v1/apqr/reports/:id/approvals/:stepId/sign` | POST | `apqr_approver_authority` + acting user = `assigned_to` per DEC-26-08 + HITL + bound e-sign with server-attributed evidence per DEC-26-09 | |
| `/api/v1/apqr/reports/:id/approvals/:stepId/reject` | POST | `apqr_approver_authority` + acting user = `assigned_to` + HITL + reason | |
| `/api/v1/apqr/reports/:id/approve` | POST | `final_quality_approver` + HITL + bound e-sign (after all approval steps signed) | target route |
| `/api/v1/apqr/reports/:id/recall` | POST | `executive_authority` co-sign + HITL + reason per DEC-26-23 | target route |
| `/api/v1/apqr/reports/:id/lock` | POST | system (auto + bound e-sign per DEC-26-13) | target route |
| `/api/v1/apqr/reports/:id/reopen` | POST | `executive_authority` co-sign AND `qualified_person_authority` co-sign + HITL + reason per DEC-26-22 | target route |

### 6.4 Workflow

#### 6.4.1 APQR lifecycle

```mermaid
stateDiagram-v2
 [*] --> draft: create
 draft --> data_collection: start data collection
 data_collection --> in_progress: data collected
 in_progress --> under_review: review
 under_review --> pending_approval: submit for approval (validates required-recommendation linkage per DEC-26-07; creates approval steps per DEC-26-08)
 pending_approval --> approved: all approval steps signed + final approval (HITL + bound e-sign)
 pending_approval --> rejected: any approval step rejected
 approved --> locked: auto-lock + bound e-sign
 approved --> recalled: governed recall (executive co-sign + reason — DEC-26-23)
 recalled --> in_progress: append new iteration
 locked --> in_progress: governed reopen (executive + QP co-sign + reason — DEC-26-22; appends new iteration)
```

#### 6.4.2 Approval-step lifecycle

```mermaid
stateDiagram-v2
 [*] --> pending: assigned (preparer ≠ approver per SoD-26-02; sequenced)
 pending --> signed: sign (acting user = assigned_to + HITL + server-attributed e-sign)
 pending --> rejected: reject (with reason)
```

#### 6.4.3 AI-insight lifecycle

```mermaid
stateDiagram-v2
 [*] --> proposed: MIRA proposes (advisory only)
 proposed --> accepted: human accept (HITL + bound e-sign + lock text)
 proposed --> rejected: human reject (with reason)
```

### 6.5 Business rules

- BR-26-01: APQR uniqueness `(tenant_id, study_id, product_id, period_start, period_end)` per DEC-26-19.
- BR-26-02: `study_id` mandatory; `product_id` mandatory FK; `product_snapshot_json` immutable per DEC-26-02 / DEC-26-03.
- BR-26-03: Direct PATCH cannot set `status` to `approved` / `rejected` / `recalled` / `locked` per DEC-26-04.
- BR-26-04: Report `version` increments on any material update per DEC-26-04.
- BR-26-05: Data-collection rows persist source-module + provenance + refresh mode + source-system reference per DEC-26-05.
- BR-26-06: Statistical analyses persist input-dataset hash + reproducible method metadata per DEC-26-06.
- BR-26-07: Recommendations with `severity = required` MUST link to URS-13 CR or URS-18 CAPA before APQR can be approved per DEC-26-07.
- BR-26-08: Approval-step signing requires acting user = `assigned_to` per DEC-26-08.
- BR-26-09: Approval steps are sequenced; preceding step must be `signed` before next step opens per DEC-26-08.
- BR-26-10: Preparer (`apqr_reports.created_by`) MUST NOT be assigned as any approver per SoD-26-02.
- BR-26-11: Signature evidence (IP / user-agent / timestamp) is server-attributed; client-supplied signature evidence rejected per DEC-26-09.
- BR-26-12: YoY records are immutable snapshots refreshed via governed writer per DEC-26-10.
- BR-26-13: AI insights live in `apqr_ai_insights` substructure with full provenance per DEC-26-11.
- BR-26-14: AI insights are advisory until human-accepted; promotion to system-of-record narrative requires bound e-signature per DEC-26-11.
- BR-26-15: Report approval requires all approval steps `signed` AND all `severity=required` recommendations linked per DEC-26-07.
- BR-26-16: Auto-lock 24h after `approved` with bound e-signature per DEC-26-13.
- BR-26-17: Recall `approved → recalled → in_progress` requires `executive_authority` co-sign + reason per DEC-26-23.
- BR-26-18: Reopen `locked → in_progress` requires `executive_authority` co-sign AND `qualified_person_authority` co-sign + reason per DEC-26-22.
- BR-26-19: APQR findings emit `apqr_finding_created` to URS-21 per DEC-26-15.
- BR-26-20: Recommendation→CAPA emits `apqr_recommendation_capa_linked` to URS-18 (`apqr_recommendation` source type) per DEC-26-16.
- BR-26-21: Recommendation→CR emits `apqr_recommendation_cr_linked` to URS-13 per DEC-26-17.
- BR-26-22: `platform_admin` / `super_admin` are support / break-glass only paths per DEC-26-20.
- BR-26-23: **AI cannot sign approval steps; AI cannot finalize APQR approval; AI cannot convert recommendations to downstream CAPA / CR**; AI may draft advisory narrative only with mandatory human acceptance per DEC-26-11.

### 6.6 Audit trail

Every Module 26 record mutation persists an audit-trail entry. Material updates after draft persist `reason_for_change` per DEC-26-21. Regulated final actions persist a bound e-signature via the `electronic_signatures` substrate; the JSON multi-signature evidence in the audit-trail `details` JSON is a derived snapshot. Append-only.

### 6.7 Error handling

| Code | HTTP | Meaning |
|---|---|---|
| `APQR_VALIDATION_FAILED` | 400 | Schema validation failure |
| `APQR_UNAUTHORIZED` | 401 | Authentication required |
| `APQR_FORBIDDEN` | 403 | RBAC denied |
| `APQR_NOT_FOUND` | 404 | Resource not found |
| `APQR_DUPLICATE_KEY` | 409 | Uniqueness violation |
| `APQR_INVALID_TRANSITION` | 422 | Lifecycle transition not permitted |
| `APQR_TERMINAL_STATE_PATCH_FORBIDDEN` | 422 | Direct PATCH attempted on terminal status per DEC-26-04 |
| `APQR_PRODUCT_FK_REQUIRED` | 422 | `product_id` not a valid FK per DEC-26-03 |
| `APQR_PRODUCT_SNAPSHOT_IMMUTABLE` | 422 | Attempt to mutate `product_snapshot_json` after creation |
| `APQR_DATA_COLLECTION_PROVENANCE_REQUIRED` | 422 | Data-collection row missing `source_module` / `source_record_query_hash` per DEC-26-05 |
| `APQR_ANALYSIS_PROVENANCE_REQUIRED` | 422 | Analysis missing `input_dataset_hash` / `method_version` per DEC-26-06 |
| `APQR_RECOMMENDATION_LINKAGE_REQUIRED` | 422 | Required recommendation not linked to URS-13 CR or URS-18 CAPA per DEC-26-07 |
| `APQR_PREPARER_APPROVER_SOD_VIOLATION` | 422 | Author = approver per SoD-26-02 |
| `APQR_APPROVER_NOT_ASSIGNED` | 422 | Acting user ≠ `assigned_to` per DEC-26-08 |
| `APQR_APPROVAL_STEP_OUT_OF_SEQUENCE` | 422 | Preceding step not `signed` per DEC-26-08 |
| `APQR_SIGNATURE_EVIDENCE_CLIENT_SUPPLIED` | 422 | Client-supplied `signature_ip_address` / `signature_user_agent` per DEC-26-09 |
| `APQR_AI_INSIGHT_NOT_ACCEPTED` | 422 | Attempt to promote AI insight to system-of-record without human acceptance per DEC-26-11 |
| `APQR_AI_CANNOT_SIGN_APPROVAL` | 422 | AI service attempted to sign an approval step per ARCH-AI-001 |
| `APQR_AUTHORITY_REQUIRED` | 422 | Authority Profile missing |
| `APQR_HITL_DECISION_REQUIRED` | 422 | HITL decision capture missing |
| `APQR_E_SIGNATURE_REQUIRED` | 422 | Bound e-signature persistence missing |
| `APQR_REOPEN_AUTHORITY_REQUIRED` | 422 | Reopen attempted without executive AND QP co-sign per DEC-26-22 |
| `APQR_RECALL_AUTHORITY_REQUIRED` | 422 | Recall attempted without executive co-sign per DEC-26-23 |
| `APQR_REASON_FOR_CHANGE_REQUIRED` | 422 | Material update after draft without reason-for-change |
| `APQR_REQUIRED_RECOMMENDATIONS_OPEN` | 422 | Approve attempted while required recommendations not linked per DEC-26-07 |
| `APQR_APPROVAL_STEPS_OPEN` | 422 | Approve attempted while approval steps not all `signed` |
| `APQR_CONTEXT_FILTER_MISMATCH` | 422 | Query against context column not present in schema |
| `APQR_INTERNAL` | 500 | Sanitized server error |

### 6.8 Configuration rules

- Auto-lock interval (default 24h) configurable per tenant.
- YoY refresh schedule (default monthly) configurable per tenant.
- Method-name enumerations and method-version registry configured at platform level per DEC-26-06.
- Source-module enumerations configured at platform level per DEC-26-05.

---

## 7. Non-functional Requirements

- NFR-26-01: List pagination (default 50, max 200).
- NFR-26-02: List p95 < 800ms (10k reports per tenant).
- NFR-26-03: Detail (with nested data collections, analyses, recommendations, approvals, AI insights, YoY) p95 < 1.5s.
- NFR-26-04: Data-collection refresh p95 < 30s (cross-module read).
- NFR-26-05: Statistical-analysis execution p95 < 60s (1M-row dataset).
- NFR-26-06: YoY refresh p95 < 30s.
- NFR-26-07: Audit-trail append p99 < 200ms.
- NFR-26-08: Concurrent APQR authors per tenant: 20.
- NFR-26-09: Storage scalability: 100k reports per tenant (multi-year retention).
- NFR-26-10: Backup / restore RPO ≤ 15 min; RTO ≤ 4 hours per URS-35.
- NFR-26-11: Bound e-signature persistence transaction p95 < 1.5s.

---

## 8. Localization

English (en-US, en-GB), Hindi (hi-IN), Marathi (mr-IN), Japanese (ja-JP) at launch.

---

## 9. Migration

### 9.1 Migration scope

Greenfield at launch.

### 9.2 Schema migration

Migration 033 baseline; target migrations (034+) reconcile `study_id` NOT NULL on `apqr_reports` (matching schema), replace `product_id VARCHAR(100)` with `product_id UUID NOT NULL FK` to URS-10 `products` per DEC-26-03, add `product_snapshot_json` per DEC-26-03, add `apqr_ai_insights` table per DEC-26-11 (and remove free-text `ai_insights` column from `apqr_reports`), add data-collection provenance columns (`source_module`, `source_record_query_hash`, `refresh_mode`, `last_refreshed_at`, `last_refreshed_by`, `formula_version`) per DEC-26-05, add analysis provenance columns (`input_dataset_hash`, `method_version`, `method_parameters_json`, `formula_version`) per DEC-26-06, add recommendation downstream-linkage columns (`recommendation_capa_id`, `recommendation_change_request_id`, `severity`) per DEC-26-07, add approval `step_order` constraint, deprecate client-supplied `approval_signature_ip` / `approval_signature_ua` columns in favor of `electronic_signatures` substrate per DEC-26-09, add YoY governed-writer columns per DEC-26-10, add reopen / recall columns per DEC-26-22 / DEC-26-23, reconcile `MODULE_CONTEXT_CONFIG.apqr` to declare both `study_id` and `product_id` filtering per DEC-26-02.

### 9.3 Migration evidence gate (URS-26-VAL-008)

(a) all migrations applied; (b) RLS verified; (c) typed schema validation verified; (d) `study_id` NOT NULL reconciliation verified; (e) `product_id` FK + immutable snapshot verified; (f) terminal-state patch-bypass prevention verified; (g) version-increment-on-update verified; (h) data-collection provenance verified; (i) analysis provenance verified; (j) recommendation downstream-linkage validation verified; (k) assigned-approver validation + sequencing + SoD verified; (l) server-attributed signature evidence verified; (m) AI-insight provenance + acceptance verified; (n) YoY governed writer verified; (o) governed reopen + recall append-only verified; (p) cross-module event emission verified (URS-13, URS-15, URS-16, URS-18, URS-21, URS-23, URS-24, URS-25); (q) audit-trail coverage on every mutation verified; (r) §17 validation evidence pack signed.

---

## 10. Decommissioning

Module 26 records subject to platform record-retention policy: retained for the longer of (a) 30 years from report lock (FDA 21 CFR §211.180) or (b) 50 years from product expiry (EU GMP). On tenant decommissioning, records exported per URS-35.

---

## 11. Decisions, Dependencies, Risks, and Error Handling
### 11.1 Closed decision posture

**No Module 26 internal decisions outstanding.** Launch decisions are captured in the locked decisions above.

### 11.2 External dependencies

- URS-10 Product master must support `product_id` FK + product attributes for snapshot per DEC-26-03.
- URS-13 change-control register must support `apqr_recommendation_cr_linked` consumer per DEC-26-17.
- URS-18 CAPA register must accept `apqr_recommendation` source type per DEC-26-16.
- URS-21 findings register must accept `apqr_finding` source type per DEC-26-15.
- URS-23 / URS-24 / URS-25 / URS-15 / URS-16 / URS-13 / URS-14 / URS-22 must support read-only data consumer integration per DEC-26-18.
- URS-32 MIRA AI must support read-only `useMiraRecord('apqr_report',.)` mapping; AI advisory drafting only with mandatory human acceptance.

### 11.3 Risks

- Risk-26-01: Cross-module data refresh latency under high tenant load. Mitigation: NFR-26-04 latency budget; refresh-mode `scheduled` for routine refresh; `on_demand` for ad hoc; query-hash-aware caching.
- Risk-26-02: AI insight acceptance rate may be high if reviewers rubber-stamp; this could bypass the spirit of advisory-only. Mitigation: acceptance-rate audit; periodic review by Validation Head + QA Head + Founder; lock-on-acceptance discipline for `accepted_text_immutable`.
- Risk-26-03: Approval-step SoD enforcement may delay small-tenant cycles. Mitigation: clear documented training; tenant-configurable same-person multi-step waiver (default disabled) with audit-flag.
- Risk-26-04: Reopen workflow gravity (executive + QP co-sign) may delay urgent post-marketing investigation. Mitigation: documented reopen SLA.

### 11.4 Out-of-scope risks tracked elsewhere

- Direct ERP / financial integration (future-state).
- Automated regulatory submission (future-state).

### 11.5 Risk owner

Module-26 risk register owned by Quality / APQR Squad with quarterly review by QA Head + Manufacturing Head + Validation Head + Qualified Person Authority.

### 11.6 Decision discipline

No Module 26 internal decisions outstanding.

### 11.7 Error Handling and Negative Paths

This section defines the controlled error envelope, the enumerated machine-code catalogue, and the negative-path response contract required for this module. The error envelope is the standard platform envelope (human message, machine code in upper-snake-case, optional structured details, correlation identifier). Errors are returned with the appropriate HTTP status; the UI surfaces inline errors at the field of cause where applicable, otherwise a controlled error toast or modal. Every error path is logged to the URS-06 audit substrate when the originating action is regulated; errors that occur before authentication are logged without `userId`. Audit-trail write failure on a state-changing action MUST cause the originating action to NOT commit (atomic write per URS-04 BR-04-15). The enumerated machine codes for this module's negative paths are defined alongside the corresponding lifecycle gates, segregation-of-duties controls, and authority-resolution outcomes throughout §6 (Back-end Requirements) and §13 (Segregation of Duties); engineering MUST surface every enumerated machine code through the standard envelope and MUST NOT swallow errors silently. Cross-module error propagation follows the §20 Cross-Module Event Contract.


---

## 12. Security

- SEC-26-01: Tenant isolation enforced at RLS on every Module 26 table.
- SEC-26-02: RBAC enforced on every route via `requirePermission(.)`.
- SEC-26-03: Authority resolution enforced on regulated final actions before HITL + e-signature.
- SEC-26-04: HITL decision capture enforced before bound e-signature persistence.
- SEC-26-05: Bound e-signature persistence via `electronic_signatures` substrate; signature evidence (IP / user-agent / timestamp) server-attributed per DEC-26-09; client-supplied signature evidence rejected.
- SEC-26-06: PII redaction in logs.
- SEC-26-07: Audit-trail integrity via URS-06 hash chain.
- SEC-26-08: AI-request provenance via `ai_requests` linked to `apqr_ai_insights`; **AI cannot sign approval steps; AI cannot finalize APQR approval; AI cannot convert recommendations to downstream CAPA / CR**; AI may draft advisory narrative only.
- SEC-26-09: `platform_admin` / `super_admin` break-glass actions logged per DEC-26-20.
- SEC-26-10: Product snapshot immutable per DEC-26-03; tampering attempts rejected.
- SEC-26-11: Context-gate filtering enforced on detail reads per DEC-26-02.

---

## 13. Segregation of Duties

| SoD ID | Constraint |
|---|---|
| SoD-26-01 | The APQR author MAY perform data-collection / analysis / recommendation entry; the APQR author MUST NOT be assigned as any approval step approver per DEC-26-08 / SoD-26-02. |
| SoD-26-02 | The report preparer (`apqr_reports.created_by`) MUST NOT be assigned as any approver. |
| SoD-26-03 | An approval-step holder MUST NOT be assigned as a subsequent step approver unless tenant policy explicitly permits same-person multi-step (default disabled; audit-flagged). |
| SoD-26-04 | The AI-insight accepter MAY be the APQR author; AI-insight acceptance is a content-curation action, not a regulated final approval. |
| SoD-26-05 | The recall co-signer (executive authority per DEC-26-23) MUST NOT be the original approval-step signer. |
| SoD-26-06 | The reopen co-signers (executive AND Qualified Person per DEC-26-22) MUST NOT be the original approval-step signers; reopen append-only semantics enforced. |
| SoD-26-07 | The `platform_admin` / `super_admin` support / break-glass action MUST NOT be a regulated production action; logged and reviewed per DEC-26-20. |

---

## 14. Regulatory Mapping

| Predicate rule | Section | Module 26 binding |
|---|---|---|
| FDA 21 CFR Part 11 | §11.10(a), §11.10(d), §11.10(e), §11.50, §11.70 | URS-26-VAL-008 + bound e-sign on every regulated final action + audit-trail on every mutation |
| **FDA 21 CFR Part 211 §211.180(e)** | Annual Review of Drug Products — primary FDA predicate | APQR period + product + reviewer + approval ceremony |
| FDA 21 CFR Part 211 §211.192 | Production record review | APQR data collection from URS-23 batch records |
| **EU GMP Chapter 1 §1.10** | Product Quality Review — primary EU predicate | APQR scope: starting materials, IPC, batch review, deviations, OOS, CAPA, change control, complaints, returns/recalls, stability, EM, qualification, commitments, recommendations |
| EU GMP Annex 11 | §1, §4, §9, §12, §16 | Risk; validation; audit trails; security; incident management |
| EU GMP Annex 22 Draft 2025 | §7 — HITL / GenAI advisory only in APQR narrative | Internal forward-looking control; AI advisory + mandatory human acceptance |
| EU AI Act (Regulation 2024/1689) | Annex III; Art. 13 transparency | Internal forward-looking control; advisory-labeling |
| MHRA Data Integrity Guidance | ALCOA+ | Audit-trail; bound e-signature; record retention |
| GAMP 5 Cat 5 | Custom-application validation lifecycle | URS-26 validation evidence pack per URS-26-VAL-008 |
| **ICH Q10 §3.2.1 / §3.2.4** | Process Performance and Product Quality Monitoring System; Management Review — primary ICH predicate | APQR as the operational substrate for Q10 §3.2.1 / §3.2.4 |
| ICH Q9 | Quality Risk Management | APQR-precipitated risk emission (where applicable) |
| WHO TRS No. 996 Annex 2 §22 | Product Quality Review | WHO PQR expectations |
| PIC/S PE 009-17 Chapter 1 | International harmonization with EU GMP Chapter 1 | Harmonized PQR for PIC/S members |
| **India CDSCO Schedule M (Revised) §17** | Product Quality Review | India operations regulatory baseline subject to a future jurisdiction-specific legal assessment |
| India CDSCO Schedule M-III | §3.7 Medical Device Quality Management Review | India medical-device PQR subject to a future jurisdiction-specific legal assessment |

---

## 15. Code Modules

| Code module | Path | Status |
|---|---|---|
| `apqr` plugin | `packages/backend/src/modules/apqr/plugin.ts` | (canonical mount retained) |
| `apqr` routes | `packages/backend/src/modules/apqr/routes.ts` | (typed schemas; route additions per §6.3; status excluded from PATCH) |
| `apqr` service | `packages/backend/src/modules/apqr/service.ts` | (terminal-state patch-bypass prevention; version increment; data-collection / analysis / recommendation / approval / signature-attribution / YoY / AI-insight provenance; assigned-approver validation; SoD enforcement) |
| `apqr` schemas | `packages/backend/src/modules/apqr/schemas.ts` | (aligned with migration 033 — study_id mandatory; client signature evidence removed) |
| `apqr` events | `packages/backend/src/modules/apqr/events.ts` | target route |
| Migration 033 | `packages/backend/src/db/migrations/033_apqr_tables.sql` | (034+ migrations add `product_id` FK + snapshot, `apqr_ai_insights` table, data-collection / analysis / recommendation provenance columns, approval sequencing constraint, server-attributed e-signature substrate linkage, YoY governed-writer columns, reopen / recall columns, context-config alignment) |
| Shared types | `packages/shared/src/types/apqr.ts` | (free-text `ai_insights` removed; AI insights via `apqr_ai_insights`; recommendations carry `severity` + downstream FK) |
| Shared schemas | `packages/shared/src/schemas/apqr.schema.ts` | (study_id mandatory; client signature evidence removed) |
| Frontend hooks | `packages/frontend/src/api/hooks/useAPQR.ts` | (canonical relative `/apqr/*`) |
| Frontend list | `packages/frontend/src/pages/APQRList.tsx` | |
| Frontend detail | `packages/frontend/src/pages/APQRDetail.tsx` | (renders nested data collections, analyses, recommendations, approvals, AI insights, YoY) |
| Frontend data-collection console | `packages/frontend/src/pages/APQRDataCollection.tsx` | target route per DEC-26-05 |
| Frontend analysis console | `packages/frontend/src/pages/APQRAnalysis.tsx` | target route per DEC-26-06 |
| Frontend recommendation console | `packages/frontend/src/pages/APQRRecommendations.tsx` | target route per DEC-26-07 |
| Frontend approval workflow | `packages/frontend/src/pages/APQRApprovalWorkflow.tsx` | target route per DEC-26-08 / DEC-26-09 |
| Frontend AI-insight console | `packages/frontend/src/pages/APQRAIInsights.tsx` | target route per DEC-26-11 |
| Frontend YoY console | `packages/frontend/src/pages/APQRYoY.tsx` | target route per DEC-26-10 |
| Frontend recall/reopen console | `packages/frontend/src/pages/APQRRecallReopen.tsx` | target route per DEC-26-22 / DEC-26-23 |
| App routing | `packages/frontend/src/App.tsx` | |

---

## 16. Test Cases

### 16.1 Unit tests

- TC-26-U-001: APQR uniqueness `(tenant_id, study_id, product_id, period_start, period_end)` rejects duplicate.
- TC-26-U-002: `study_id` null on report create rejects with `APQR_VALIDATION_FAILED`.
- TC-26-U-003: `product_id` not FK rejects with `APQR_PRODUCT_FK_REQUIRED`.
- TC-26-U-004: `product_snapshot_json` mutation after creation rejects with `APQR_PRODUCT_SNAPSHOT_IMMUTABLE`.
- TC-26-U-005: Direct PATCH setting `status = approved` rejects with `APQR_TERMINAL_STATE_PATCH_FORBIDDEN`.
- TC-26-U-006: Material update increments `version` per DEC-26-04.
- TC-26-U-007: Data-collection without `source_module` / `source_record_query_hash` rejects with `APQR_DATA_COLLECTION_PROVENANCE_REQUIRED`.
- TC-26-U-008: Analysis without `input_dataset_hash` / `method_version` rejects with `APQR_ANALYSIS_PROVENANCE_REQUIRED`.
- TC-26-U-009: Required recommendation without URS-13 CR or URS-18 CAPA linkage rejects with `APQR_RECOMMENDATION_LINKAGE_REQUIRED`.
- TC-26-U-010: Author = approver assignment rejects with `APQR_PREPARER_APPROVER_SOD_VIOLATION`.
- TC-26-U-011: Approval-step signing by non-assigned actor rejects with `APQR_APPROVER_NOT_ASSIGNED`.
- TC-26-U-012: Approval-step out-of-sequence signing rejects with `APQR_APPROVAL_STEP_OUT_OF_SEQUENCE`.
- TC-26-U-013: Client-supplied `signature_ip_address` rejects with `APQR_SIGNATURE_EVIDENCE_CLIENT_SUPPLIED`.
- TC-26-U-014: AI-insight promotion without acceptance rejects with `APQR_AI_INSIGHT_NOT_ACCEPTED`.
- TC-26-U-015: AI service signing approval step rejects with `APQR_AI_CANNOT_SIGN_APPROVAL`.
- TC-26-U-016: YoY immutable snapshot — UPDATE rejected at DB level.
- TC-26-U-017: Reopen without executive AND QP co-sign rejects with `APQR_REOPEN_AUTHORITY_REQUIRED`.
- TC-26-U-018: Recall without executive co-sign rejects with `APQR_RECALL_AUTHORITY_REQUIRED`.
- TC-26-U-019: Reopen / recall appends new iteration; prior locked / approved evidence not mutated.
- TC-26-U-020: Material update after draft without reason-for-change rejects with `APQR_REASON_FOR_CHANGE_REQUIRED`.

### 16.2 Integration tests

- TC-26-I-001: Full APQR lifecycle from `draft` to `locked` with all gates.
- TC-26-I-002: APQR for Product P-Tabs covering 2026 calendar year per Worked Example 1.
- TC-26-I-003: Recall before lock per Worked Example 2.
- TC-26-I-004: Governed reopen of locked APQR per Worked Example 3.
- TC-26-I-005: Approval-step SoD violation rejected per Worked Example 4.
- TC-26-I-006: Data-collection refresh from URS-23 / URS-24 / URS-25 / URS-15 / URS-16 / URS-18 / URS-13 / URS-14 / URS-21 / URS-22.
- TC-26-I-007: Statistical analysis with control chart + Cpk + regression methods.
- TC-26-I-008: Recommendation→URS-18 CAPA linkage emission.
- TC-26-I-009: Recommendation→URS-13 CR linkage emission.
- TC-26-I-010: AI insight propose + accept ceremony with bound e-signature; rejection ceremony.
- TC-26-I-011: YoY governed writer refresh.
- TC-26-I-012: Server-attributed signature evidence (IP / user-agent derived from request context).
- TC-26-I-013: Approval-step assigned-approver validation + sequencing.
- TC-26-I-014: APQR finding emission to URS-21.
- TC-26-I-015: Cross-tenant `platform_admin` break-glass logged per DEC-26-20.

### 16.3 End-to-end tests

- TC-26-E-001: APQR for Product P-Tabs per Worked Example 1.
- TC-26-E-002: Recall before lock per Worked Example 2.
- TC-26-E-003: Reopen of locked APQR per Worked Example 3.
- TC-26-E-004: SoD violation per Worked Example 4.
- TC-26-E-005: Concurrent APQR authors — 20 users — NFR-26-08 verification.
- TC-26-E-006: India CDSCO Schedule M §17 PQR with India predicate-rule citations.

### 16.4 Performance tests

- TC-26-P-001: List p95 latency (NFR-26-02).
- TC-26-P-002: Detail p95 latency (NFR-26-03).
- TC-26-P-003: Data-collection refresh p95 latency (NFR-26-04).
- TC-26-P-004: Statistical-analysis execution p95 latency (NFR-26-05).
- TC-26-P-005: YoY refresh p95 latency (NFR-26-06).
- TC-26-P-006: Bound e-signature p95 latency (NFR-26-11).

### 16.5 Security tests

- TC-26-S-001: Cross-tenant access rejected by RLS.
- TC-26-S-002: Missing RBAC rejected.
- TC-26-S-003: Missing Authority Profile rejected on regulated final action.
- TC-26-S-004: Missing HITL rejected.
- TC-26-S-005: Missing bound e-signature rejected.
- TC-26-S-006: SQL injection against typed-schema route rejected.
- TC-26-S-007: Audit-trail UPDATE / DELETE rejected at DB level.
- TC-26-S-008: AI service attempting approval-step sign rejected.
- TC-26-S-009: PII redaction in logs verified.
- TC-26-S-010: Client-supplied signature evidence rejected.
- TC-26-S-011: Product snapshot tampering rejected.

---

## 17. Validation Evidence

### 17.1 URS-26-VAL-001: Requirements traceability matrix

Complete RTM mapping every URS-26 requirement (DEC-26-01.DEC-26-23, BR-26-01.BR-26-23, NFR-26-01.NFR-26-11, SoD-26-01.SoD-26-07, SEC-26-01.SEC-26-11) to test cases (TC-26-U-001.TC-26-U-020, TC-26-I-001.TC-26-I-015, TC-26-E-001.TC-26-E-006, TC-26-P-001.TC-26-P-006, TC-26-S-001.TC-26-S-011) and code modules (§15).

### 17.2 URS-26-VAL-002: Design qualification (DQ)

Architecture, data model, API contract, workflow, business rules, audit trail, security, integration; signed by Validation Head, QA Head, RA Head, Manufacturing Head, Qualified Person Authority.

### 17.3 URS-26-VAL-003: Installation qualification (IQ)

Migration application + RLS verification + route mount verification + frontend hook resolution + frontend route surface verification.

### 17.4 URS-26-VAL-004: Operational qualification (OQ)

Happy-path execution of every test case with evidence captures.

### 17.5 URS-26-VAL-005: Performance qualification (PQ)

NFR-26-01.NFR-26-11 verification.

### 17.6 URS-26-VAL-006: AI/ML governance evidence

Per ARCH-AI-001: (a) MIRA read-only context integration; (b) AI advisory drafting only; (c) **AI cannot sign approval steps; AI cannot finalize APQR approval; AI cannot convert recommendations to downstream CAPA / CR** verification; (d) `apqr_ai_insights` provenance + acceptance discipline; (e) Annex 22 §7 + EU AI Act Annex III internal forward-looking control compliance evidence.

### 17.7 URS-26-VAL-007: Regulatory mapping evidence

FDA 21 CFR Part 11 + 211 (§180(e), §192), **EU GMP Chapter 1 §1.10**, EU GMP Annex 11, Annex 22 Draft 2025 §7, EU AI Act Art. 13 / Annex III, MHRA Data Integrity (ALCOA+), GAMP 5 Cat 5, **ICH Q10 §3.2.1 / §3.2.4**, ICH Q9, WHO TRS No. 996 Annex 2 §22, PIC/S PE 009-17 Chapter 1, India CDSCO Schedule M (Revised) §17 / Schedule M-III §3.7.

### 17.8 URS-26-VAL-008: Migration evidence gate

Per §9.3.

### 17.9 URS-26-VAL-009: Signature manifest

QA Head, RA Head, Validation Head, Manufacturing Head, Qualified Person Authority, Information Security Head, Site Quality Lead, Founder / Chairman & MD per §19.

### 17.10 URS-26-VAL-010: Post-launch periodic-review pack

(a) APQR metrics (reports per tenant, approval cycle time, recall rate, reopen rate); (b) AI-insight acceptance rate by reviewer; (c) audit-trail integrity; (d) reopen / recall event audit; (e) cross-tenant break-glass audit; (f) cross-module event integrity; (g) data-collection refresh latency; (h) approval-step SoD compliance; periodic review at quarterly cadence by QA Head + Manufacturing Head + Validation Head + Qualified Person Authority.

---

## 18. Document Change History

| Version | Date | Author | Change Summary |
|---|---|---|---|
| 1.0 | 2026-05-07 | Founder Doctrine — Verixa URS Cell | First issued user requirements specification for Module 26. |

---

## 19. Document Approval

| Role | Name | Signature | Date |
|---|---|---|---|
| Founder / Chairman & MD | Vimal | __________ | __________ |
| QA Head | __________ | __________ | __________ |
| RA Head | __________ | __________ | __________ |
| Validation Head | __________ | __________ | __________ |
| Manufacturing Head | __________ | __________ | __________ |
| Qualified Person Authority | __________ | __________ | __________ |
| Information Security Head | __________ | __________ | __________ |
| Site Quality Lead | __________ | __________ | __________ |

---

## 20. Cross-Module Event Contract

| Event | Emitter | Consumer | Payload key fields |
|---|---|---|---|
| `apqr_report_created` | Module 26 | URS-30 | `report_id`, `tenant_id`, `study_id`, `product_id`, `period_start`, `period_end`, `created_by` |
| `apqr_data_collection_added` | Module 26 | URS-30 | `data_collection_id`, `report_id`, `source_module`, `source_record_query_hash` |
| `apqr_data_collection_refreshed` | Module 26 | URS-30 | `data_collection_id`, `last_refreshed_at`, `last_refreshed_by` |
| `apqr_statistical_analysis_executed` | Module 26 | URS-30 | `analysis_id`, `report_id`, `method_name`, `method_version`, `input_dataset_hash`, `executed_by` |
| `apqr_recommendation_added` | Module 26 | URS-30 | `recommendation_id`, `report_id`, `severity` |
| `apqr_recommendation_capa_linked` | Module 26 | **URS-18 (CAPA — primary consumer)**, URS-30 | `recommendation_id`, `capa_id`, `linked_by`, `source_type = apqr_recommendation` |
| `apqr_recommendation_cr_linked` | Module 26 | **URS-13 (Change Control — primary consumer)**, URS-30 | `recommendation_id`, `change_request_id`, `linked_by` |
| `apqr_recommendation_implemented` | Module 26 | URS-30 | `recommendation_id`, `closure_status` |
| `apqr_submitted_for_approval` | Module 26 | URS-30 | `report_id`, `submitted_by` |
| `apqr_approval_step_assigned` | Module 26 | URS-30 | `step_id`, `report_id`, `step_order`, `assigned_to` |
| `apqr_approval_step_signed` | Module 26 | URS-30 | `step_id`, `signed_by`, `step_e_signature_id` |
| `apqr_approval_step_rejected` | Module 26 | URS-30 | `step_id`, `rejected_by`, `rejection_reason` |
| `apqr_report_approved` | Module 26 | URS-30 | `report_id`, `approved_by`, `approval_e_signature_id` |
| `apqr_report_rejected` | Module 26 | URS-30 | `report_id`, `rejected_by` |
| `apqr_report_recalled` | Module 26 | URS-30 | `report_id`, `recalled_by`, `recall_executive_co_signer`, `recall_reason` |
| `apqr_report_locked` | Module 26 | URS-30 | `report_id`, `locked_by`, `lock_e_signature_id` |
| `apqr_report_reopened` | Module 26 | URS-30, URS-21 (governed-reopen audit) | `report_id`, `reopened_by`, `executive_co_signer`, `qp_co_signer`, `reopen_reason` |
| `apqr_year_over_year_refreshed` | Module 26 | URS-30 | `yoy_id`, `report_id`, `formula_version`, `generated_by` |
| `apqr_ai_insight_proposed` | Module 26 | URS-30 | `insight_id`, `report_id`, `insight_type`, `model_id`, `model_version`, `confidence` |
| `apqr_ai_insight_accepted` | Module 26 | URS-30 | `insight_id`, `accepted_by`, `acceptance_e_signature_id` |
| `apqr_finding_created` | Module 26 | **URS-21 (Findings — primary consumer)**, URS-30 | `finding_id` (URS-21), `report_id`, `severity`, `finding_type` |

---

## 21. References

- ARCH-AI-001 — AI Optionality and Manual Continuity (binding architecture)
- VRX-SPEC-URS-026-APQR.md (Module specification)
- URS-01.URS-25, URS-27.URS-35 (cross-module contracts)
- FDA 21 CFR Part 11
- **FDA 21 CFR Part 211 §211.180(e) Annual Review of Drug Products** — primary FDA predicate
- FDA 21 CFR Part 211 §211.192
- **EU GMP Chapter 1 §1.10 Product Quality Review** — primary EU predicate
- EU GMP Annex 11
- EU GMP Annex 22 (Draft 2025) §7 — internal forward-looking control
- EU AI Act (Regulation 2024/1689) Art. 13 / Annex III — internal forward-looking control
- MHRA Data Integrity Guidance (2018) — ALCOA+
- GAMP 5 Cat 5
- **ICH Q10 §3.2.1 / §3.2.4** — primary ICH predicate
- ICH Q9
- WHO TRS No. 996 Annex 2 §22
- PIC/S PE 009-17 Chapter 1
- India CDSCO Schedule M (Revised) §17
- India CDSCO Schedule M-III §3.7

---

**END OF VRX-URS-26 — APQR — VERSION 1.0**