# Verixa — User Requirements Specification # Module 24: Stability Management | Field | Value | |---|---| | Document ID | VRX-URS-24 | | Version | 1.0 | | Status | Final — ready for QA, Validation, Regulatory Affairs, Information Security, Manufacturing Head, Laboratory 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-24-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 `stability`, expected API mounts `/api/v1/stability/*` (canonical), expected supporting modules `products`, `studies`, `oos-oot`, `regulatory`, `context-filter`, `rbac`, `audit-log`, `electronic_signatures`, `hitl`, `documents`, expected event-bus emission for `stability_protocol_created`, `stability_protocol_released_effective`, `stability_protocol_superseded`, `stability_study_created`, `stability_study_status_changed`, `stability_sample_added`, `stability_time_point_added`, `stability_result_recorded`, `stability_oos_oot_linked`, `stability_report_generated`, `stability_report_approved`, `shelf_life_claim_approved`, `stability_commitment_created`, `stability_commitment_status_changed`, `stability_study_locked`, `stability_study_reopened`, expected MIRA context integration through `useMiraRecord('stability_protocol', id)`, `useMiraRecord('stability_study', id)`, and `useMiraRecord('stability_report', id)` mappings, expected OOS/OOT-source emission consumed by URS-15 (`stability_result` source type), expected findings-source emission consumed by URS-21 (`stability_finding` source type), expected CAPA-source emission consumed by URS-18 (`stability_failure` source type), expected deviation-source emission consumed by URS-16 (stability protocol deviation), expected risk-source emission consumed by URS-19 (stability-precipitated risk), expected change-control linkage to URS-13 for protocol effective release and shelf-life-claim revisions, expected regulatory-intelligence integration with URS-27 for ICH Q1A(R2) / ICH Q1E predicate citations, expected batch-record release-decision input consumer (URS-23) for stability data, expected APQR consumer (URS-26) for periodic stability summary, expected Authority Profile + HITL + e-signature integration for non-bypassable protocol release, report approval, shelf-life claim approval, and study lock, 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 **high-risk under internal AI governance**, aligned with the high-risk classification approach in **EU AI Act (Regulation 2024/1689) Annex III**, unless a jurisdiction-specific legal assessment determines otherwise — escalated under Annex III when the trend conclusion feeds an OOS classification (URS-15) or stability-failure disposition. AI-assisted stability surfaces (AI trend analysis, AI shelf-life prediction, AI degradation-pattern detection, AI OOS/OOT predictive alerting, MIRA stability copilot) are advisory only under internal AI governance aligned with EU AI Act Article 13 transparency principles. Every AI surface shall provide a fully functional manual trending, regression, and disposition path; stability study setup, timepoint result recording, review, trend analysis, and disposition shall be executable when AI services are disabled, degraded, or overridden by the stability reviewer. **No AI service shall be the sole path to declare a stability OOS, extend shelf-life, approve a stability report, or close a stability study; a qualified human stability reviewer shall sign the disposition.** This module binds ARCH-AI-001 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 / probabilistic AI is **PROHIBITED** in stability OOS classification, shelf-life disposition, stability report approval, and study closure decision paths. Static deterministic AI may surface stability trend regressions (Arrhenius / linear / log), historical degradation patterns by formulation/storage, and prior-protocol patterns by product as advisory help; the human stability reviewer's signed disposition is the system of record. Jurisdiction-specific legal enforceability of Annex 22 and the EU AI Act remains subject to a future jurisdiction-specific legal assessment. | | Regulatory Classification | Critical infrastructure substrate — operates the canonical Stability Protocol controlled-template register, the protocol lifecycle state machine (`draft → under_review → effective → superseded → archived`; immutable historical versions per DEC-24-06), the Stability Study execution-record register, the study lifecycle state machine (`draft → enrolled → in_progress → results_complete → under_review → reported → claim_approved → closed → locked`; reopen as a governed transition event from `locked → in_progress` per DEC-24-22 + SoD-24-06), the storage-condition substructure with versioned ICH Q1A(R2) condition templates, the sample registry with sample-condition ownership validation per DEC-24-09, the time-point registry with study-bound ownership, the result-capture lifecycle with sample/time-point coherence validation and duplicate-result prevention per DEC-24-09, the OOS/OOT-linkage emission to URS-15 with mandatory linkage for out-of-spec stability results per DEC-24-08, the stability-report lifecycle (`draft → under_review → approved`) with bound e-signature per DEC-24-10, the shelf-life-claim lifecycle with **preliminary computed shelf-life vs approved shelf-life claim** distinction per DEC-24-09, the stability-commitment registry with full attributable substrate per DEC-24-11, the multi-dimensional context capture (`tenant_id` mandatory, `product_id` mandatory, `study_id` mandatory or explicitly null per approved policy, `site_id` mandatory at study level — STB-DM-005), the canonical API contract `/api/v1/stability/*`, the typed schema validation across every route with shared-schema/migration-contract alignment, the controlled frontend route surface with explicit page coverage for `/stability/protocols/:id` and `/stability/studies/:id`, the context-gate filtering on detail reads `getProtocol(.)` and `getStudy(.)` and the table-aware context-filter alignment, the controlled protocol effective-release with `protocol_release_authority` + HITL + bound e-signature + URS-13 change-request linkage per DEC-24-06, the report-approval and shelf-life-claim-approval gates with bound e-signature per DEC-24-10, the LIMS-import provenance preservation per DEC-24-13, the audit-trail coverage with reason-for-change discipline on `updateCondition`, `updateSample`, `updateCommitment`, and all mutable records per DEC-24-12, the post-locked record immutability across the study header and linked report, the controlled reopen workflow with executive authority co-sign and Qualified Person co-sign per DEC-24-22, the canonical findings-source emission to URS-21 for stability findings per DEC-24-15, the canonical CAPA-source emission to URS-18 with `stability_failure` source type per DEC-24-16, the canonical deviation-source emission to URS-16 for stability protocol deviations per DEC-24-17, the canonical risk-source emission to URS-19 for stability-precipitated risk records per DEC-24-18, the change-control linkage to URS-13 for protocol effective-state release and shelf-life-claim revisions per DEC-24-19, the URS-23 batch-record release-decision input integration for stability data, the URS-26 APQR periodic-stability-summary integration, the MIRA copilot read-only context integration on stability records, and the per-jurisdictional regulatory expectations under FDA 21 CFR Part 11, FDA 21 CFR Part 211 §211.166 (Stability Testing), §211.137 (Expiration Dating), EU GMP Annex 11, EU GMP Annex 22 Draft 2025 §7 (HITL for AI-assisted trending / shelf-life prediction — 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 Q1A(R2) (Stability Testing of New Drug Substances and Products), ICH Q1B (Photostability), ICH Q1C (New Dosage Forms), ICH Q1D (Bracketing and Matrixing), ICH Q1E (Evaluation of Stability Data), ICH Q5C (Biotech), WHO Technical Report Series Annex 10 (Stability Testing for Hot/Humid Climates — Zone IVb relevant for India operations), and India CDSCO Schedule M (Revised) §16 / Schedule Y / NDCT 2019 §27 stability expectations subject to a future jurisdiction-specific legal assessment for Verixa's exact CDSCO obligations. | | Date of Issue | 2026-05-07 | | Module Owner (Engineering) | Quality / Stability Squad | | Module Owner (Quality Validation) | CSV / CSA Lead — Stability | | Module Owner (Compliance) | Quality Assurance, Regulatory Affairs, Manufacturing, Laboratory Operations, Qualified Person Authority | | Approving Authority | Founder / Chairman & MD; QA Head; Manufacturing Head; Laboratory 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 Stability Management module (Module 24). It is the binding contract between product, engineering, quality validation, regulatory affairs, manufacturing, the Qualified Person authority, laboratory operations, distribution, information security, and the executive authority for the design, implementation, validation, release, and on-going periodic review of the regulated stability-management substrate: the canonical Stability Protocol controlled-template register; the protocol lifecycle state machine (`draft → under_review → effective → superseded → archived`; immutable historical versions per DEC-24-06); the Stability Study execution-record register; the study lifecycle state machine (`draft → enrolled → in_progress → results_complete → under_review → reported → claim_approved → closed → locked`; reopen as a governed transition event from `locked → in_progress` per executive authority co-sign + Qualified Person co-sign + reason — DEC-24-22 + SoD-24-06 — that appends a new investigation iteration without mutating or erasing the prior locked evidence); the storage-condition substructure with versioned ICH Q1A(R2) condition templates; the sample registry with sample-condition ownership validation per DEC-24-09; the time-point registry with study-bound ownership; the result-capture lifecycle with sample/time-point coherence validation and duplicate-result prevention per DEC-24-09; the OOS/OOT-linkage emission to URS-15 with mandatory linkage for out-of-spec stability results per DEC-24-08; the stability-report lifecycle (`draft → under_review → approved`) with bound e-signature per DEC-24-10; the shelf-life-claim lifecycle distinguishing **preliminary computed shelf-life (advisory)** vs **approved shelf-life claim (system-of-record after Qualified Person + RA co-sign)** per DEC-24-09; the stability-commitment registry with full attributable substrate per DEC-24-11; the multi-dimensional context capture (`tenant_id`, `product_id`, `study_id`, `site_id`); the canonical API contract `/api/v1/stability/*`; the typed schema validation across every route with shared-schema/migration-contract alignment; the controlled frontend route surface; the context-gate filtering on detail reads with table-aware filter alignment; the controlled protocol effective-release with `protocol_release_authority` + HITL + bound e-signature + URS-13 change-request linkage per DEC-24-06; the report-approval and shelf-life-claim-approval gates with bound e-signature per DEC-24-10; the LIMS-import provenance preservation per DEC-24-13; the audit-trail coverage with reason-for-change discipline on every mutable record per DEC-24-12; the post-locked record immutability; the controlled reopen workflow with executive authority co-sign and Qualified Person co-sign per DEC-24-22; the canonical findings-source emission to URS-21 per DEC-24-15; the canonical CAPA-source emission to URS-18 with `stability_failure` source type per DEC-24-16; the canonical deviation-source emission to URS-16 per DEC-24-17; the canonical risk-source emission to URS-19 per DEC-24-18; the change-control linkage to URS-13 for protocol effective-state release and shelf-life-claim revisions per DEC-24-19; the URS-23 batch-record release-decision input integration; the URS-26 APQR periodic-stability-summary integration; the MIRA copilot read-only context integration with **no GenAI in stability OOS / shelf-life / report-approval / closure decision paths** 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, Laboratory Operations, Distribution, Validation, Information Security, executive authority, the platform's Implementation team, internal and external auditors, and inspectors from regulatory bodies (FDA, EMA, MHRA, Health Canada, CDSCO, PIC/S, PMDA). The plain-language primer (§0.4) and worked examples (§3.5) make Module 24 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 stability mutation - **URS-02** RBAC & Permissions — the `stability:*`, `stability:protocol:*`, `stability:study:*`, `stability:result:*`, `stability:report:*`, `stability:claim:*`, `stability:commitment:*` permission set - **URS-03** Context Gate & Approval Scope — context-gate enforcement for stability scope dimensions - **URS-04** Workflow / HITL / E-Signature / Approval Authority — Controlled Approval Modal contract for protocol release / report approval / shelf-life claim approval / commitment closure / study lock / reopen - **URS-05** Authority Profile / Delegation / SoD — Authority Profiles consumed (`protocol_author_authority`, `protocol_review_authority`, `protocol_release_authority`, `stability_reviewer_authority`, `stability_report_approver_authority`, `shelf_life_claim_authority`, `qualified_person_authority`, `final_quality_approver`, `executive_authority`, `controlled_content_approver`, `regulatory_affairs_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 stability records - **URS-09** Site / Facility Management — mandatory site-scope dimension consumed at study level - **URS-10** Product / SKU / Drug Master Data — mandatory product-scope dimension consumed at protocol and study level - **URS-11** Supplier Management — supplier-material linkage where stability follows supplier change - **URS-12** Document Control / SOP — affected-document linkage; SOP citation linkage on stability protocols; ICH Q1A(R2) reference document - **URS-13** Change Control — protocol effective-state release linkage; shelf-life-claim revision linkage per DEC-24-19 - **URS-14** Complaints — complaint-trend linkage to stability investigation - **URS-15** OOS / OOT — primary downstream consumer for stability OOS results per DEC-24-08 - **URS-16** Deviations — primary downstream consumer for stability protocol deviations per DEC-24-17 - **URS-17** RCA — RCA records for stability-failure root-cause analysis - **URS-18** CAPA — primary downstream consumer for stability-failure CAPA via `stability_failure` source type per DEC-24-16 - **URS-19** Risk Assessment — stability-precipitated risk records per DEC-24-18 - **URS-20** Reviews — stability-report review consumer - **URS-21** Findings — primary downstream consumer for stability findings per DEC-24-15 - **URS-22** Inspection Mgmt — stability-record evidence retrieval source for inspections - **URS-23** Batch Records — batch-record release-decision input consumer for stability data - **URS-25** Environmental Monitoring — chamber EM linkage to stability conditions - **URS-26** APQR — primary periodic stability summary consumer - **URS-27** Regulatory Intelligence — predicate-rule citation source for ICH Q1A(R2) / ICH Q1E - **URS-28** Training — training-evidence consumer for stability reviewers - **URS-30** Notifications — notification delivery for stability lifecycle events - **URS-31** DQG — data-quality gate evidence for stability-record completeness - **URS-32** MIRA AI — read-only MIRA copilot context integration on stability records; **no LLM/GenAI in critical stability decisions** per Annex 22 §7 internal control - **URS-33** GMP Manufacturing — GMP-stability program integration - **URS-34** GDP Distribution — released-batch shelf-life claim consumer - **URS-35** Infrastructure / Backup-Restore — operational continuity ### 0.4 Plain-language primer In a regulated pharmaceutical operation, **a stability program is the structured testing of drug products and substances over time under defined storage conditions to establish or confirm shelf-life, retest period, and labeled storage conditions** (per FDA 21 CFR §211.166, §211.137, ICH Q1A(R2), ICH Q1B, ICH Q1C, ICH Q1D, ICH Q1E, ICH Q5C, WHO TRS Annex 10 for Zone IVb). The Stability Protocol (per ICH Q1A(R2)) is the controlled-template document defining the storage conditions (e.g., long-term 25°C/60% RH, intermediate 30°C/65% RH, accelerated 40°C/75% RH; for tropical Zone IVb 30°C/75% RH long-term), the time points (typically 0, 3, 6, 9, 12, 18, 24, 36, 48, 60 months), the analytical tests at each time point, and the acceptance criteria. The Stability Study is the executed evidence for a specific protocol applied to one or more batches; results are captured at each time point per sample per condition; out-of-spec stability results MUST link to URS-15 OOS/OOT for controlled investigation; the stability report consolidates the data and the regression analysis; the shelf-life claim is the system-of-record approved labeled shelf-life. Each stability program requires structured handling under **21 CFR Part 11, 21 CFR §211.166 / §211.137, EU GMP Annex 11, MHRA Data Integrity Guidance, and ICH Q1A(R2) / Q1E**: (1) author and release the protocol through controlled change control to `effective` state with `protocol_release_authority` + e-signature, (2) create a stability study bound to a single effective protocol version, (3) enroll samples by condition / time point / batch, (4) capture results with attributable analyst / instrument / LIMS-import provenance, (5) link out-of-spec results to URS-15 OOS/OOT, (6) generate the stability report with regression analysis, (7) approve the report through `stability_report_approver_authority` + e-signature, (8) approve the shelf-life claim through `shelf_life_claim_authority` (typically Qualified Person + RA) + e-signature, (9) close and lock the study. Module 24 is the target specification for this regulated workflow. The most common mistake in regulated stability handling is **claiming a final shelf-life from a heuristic computation without controlled approval**. The regulator's tell-tale at inspection is a `calculateShelfLife` endpoint output presented as a labeled shelf-life claim. Module 24 enforces the pathway: the heuristic / regression computation is **preliminary and advisory only** per DEC-24-09; the **approved shelf-life claim** is the system-of-record only after `shelf_life_claim_authority` (typically Qualified Person + Regulatory Affairs) co-sign the claim with bound e-signature; the claim version is linked to a URS-13 change request per DEC-24-19. The second most common mistake is **out-of-spec stability results without linkage to URS-15 OOS/OOT investigation**. Module 24 enforces the pathway: out-of-spec results MUST emit `stability_oos_oot_linked` event consumed by URS-15 per DEC-24-08; the URS-15 OOS investigation lifecycle is the system-of-record for the OOS disposition; stability report cannot be approved while linked OOS investigations are open in URS-15. The **AI-assistance** dimension is critical. Static deterministic AI (deterministic regression — Arrhenius, linear, log) may surface "stability trend regression candidates" or "historical degradation patterns by formulation / storage condition" or "prior protocol patterns by product" as advisory help; this is permitted under the internal Annex 22 §7 control. **Generative AI (LLMs / MIRA copilot) is PROHIBITED in stability OOS classification, shelf-life disposition, stability report approval, and study closure decision paths** under the internal Annex 22 §7 + EU AI Act Annex III internal forward-looking control. MIRA copilot may read closed stability protocols / studies / reports for read-only context via `useMiraRecord(.)` mappings but no AI service writes to `stability_*` tables, and no AI service finalizes shelf-life or report disposition. The qualified human stability reviewer's signed disposition is the system of record. 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-24-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 | |---|---| | Stability Protocol | The controlled-template document defining storage conditions, time points, analytical tests, and acceptance criteria for a stability study (per ICH Q1A(R2)); versioned with controlled lifecycle (`draft → under_review → effective → superseded → archived`); released to `effective` with `protocol_release_authority` + e-signature; immutable once superseded. | | Stability Study | The executed evidence for a specific stability protocol applied to one or more batches; lifecycle `draft → enrolled → in_progress → results_complete → under_review → reported → claim_approved → closed → locked`. | | Storage condition | A controlled storage condition row under a stability protocol (e.g., `25°C/60% RH long-term`, `40°C/75% RH accelerated`); versioned with the protocol; aligned with ICH Q1A(R2) climatic zones. | | Time point | A scheduled measurement timepoint under a stability study (typically 0, 3, 6, 9, 12, 18, 24, 36, 48, 60 months); study-bound. | | Sample | A registered stability sample under a study; sample-condition ownership validated per DEC-24-09. | | Result | A captured analytical result for one sample at one time point for one analytical test; sample/time-point coherence validated; duplicate-result prevented per DEC-24-09; out-of-spec results emit `stability_oos_oot_linked` to URS-15 per DEC-24-08. | | Stability report | The consolidated stability report for a study; lifecycle `draft → under_review → approved` per DEC-24-10; approved with bound e-signature. | | Preliminary computed shelf-life | Advisory output from regression analysis; **NOT** the system-of-record shelf-life; per DEC-24-09 cannot be presented as a labeled claim. | | Approved shelf-life claim | The system-of-record labeled shelf-life claim approved by `shelf_life_claim_authority` (typically Qualified Person + Regulatory Affairs) with bound e-signature + URS-13 change-request linkage per DEC-24-19. | | Stability commitment | A post-approval stability commitment record (e.g., commitment to ongoing stability or to additional stability arms) tracked through closure with full attributable substrate per DEC-24-11. | | Reopen | A governed transition event from `locked → in_progress` requiring `executive_authority` co-sign AND `qualified_person_authority` co-sign + documented reason; appends a new investigation iteration without mutating prior locked evidence per DEC-24-22. | | ARCH-AI-001 | Platform architecture binding requiring manual continuity for every AI surface (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, generative / probabilistic AI is prohibited in stability OOS classification, shelf-life disposition, report approval, and study closure decision paths. Binding predicate-rule obligations remain those listed in §14. | | MIRA | The platform's read-only AI copilot service; for Module 24 MIRA is read-only context on stability records via `useMiraRecord(.)` mappings; no MIRA write paths; no LLM/GenAI in critical stability decisions. | ### 0.7 Module-24 architectural picture ```mermaid flowchart TD AUTH[Protocol Author / Reviewer / Releaser] --> PROT[/Stability Protocols — controlled template/] PROT -- effective version --> STD[/Stability Studies — executed evidence/] EX[Stability Analyst / Lab Operator] --> STD STD --> SMP[Samples — sample-condition ownership validated] STD --> TP[Time Points — study-bound] STD --> RES[Results — sample/time-point coherence + duplicate prevention] RES --> OOS[Out-of-spec results emit stability_oos_oot_linked to URS-15] STD --> EXC[Protocol Deviations] EXC --> M16[URS-16 Deviations] STD --> RPT[Stability Report — bound e-sign approval] RPT --> CLAIM[Shelf-life Claim — Qualified Person + RA bound e-sign + URS-13 CR linkage] CLAIM --> LOCK[Study Locked] LOCK -. governed reopen + executive + QP co-sign.-> STD M13[URS-13 Change Control] --> PROT (release to effective); --> CLAIM (claim revision) M12[URS-12 Document Control] --> PROT (SOP citation) M27[URS-27 Regulatory Intelligence] --> PROT (ICH Q1A(R2)/Q1E predicate citation) M15[URS-15 OOS] <-- RES (stability_oos_oot_linked) M16 --> M18[URS-18 CAPA] (stability_failure source type) M17[URS-17 RCA] <-- RPT (root-cause investigation) M19[URS-19 Risk Assessment] <-- STD (stability-precipitated risk) M21[URS-21 Findings] <-- STD (stability finding) M22[URS-22 Inspection] -- evidence retrieval --> STD M23[URS-23 Batch Records] <-- CLAIM (release-decision input) M25[URS-25 EM] --> STD (chamber EM context) M26[URS-26 APQR] <-- STD (periodic stability summary) M30[URS-30 Notifications] <-- STD M32[URS-32 MIRA AI] <-- STD (read-only context — no GenAI in critical decisions) M34[URS-34 GDP] <-- CLAIM (released-batch shelf-life claim) M31[URS-31 DQG] --> STD (completeness) ``` The platform shall implement: a controlled stability-protocol register with version-immutability after `effective` release; a stability-study register bound to a single effective protocol version with full attributable execution; sample-condition ownership validation per DEC-24-09; time-point study-bound ownership per DEC-24-09; result-capture with sample/time-point coherence validation and duplicate-result prevention per DEC-24-09; mandatory OOS/OOT linkage to URS-15 for out-of-spec results per DEC-24-08; stability-report lifecycle with bound e-signature approval per DEC-24-10; **distinction between preliminary computed shelf-life (advisory) and approved shelf-life claim (system-of-record)** per DEC-24-09; commitment registry with full attributable substrate per DEC-24-11; mandatory `product_id` at protocol level per DEC-24-04; mandatory `study_id` per DEC-24-04 alignment; mandatory `site_id` at study level per DEC-24-04; canonical API contract `/api/v1/stability/*` per DEC-24-01; typed schema validation per DEC-24-03; controlled frontend route surface per DEC-24-02; context-gate filtering on detail reads per DEC-24-05; protocol effective-release with HITL + bound e-signature + URS-13 CR linkage per DEC-24-06; LIMS-import provenance preservation per DEC-24-13; audit-trail coverage with reason-for-change on every mutable record per DEC-24-12; post-locked record immutability; governed reopen with executive + QP co-sign per DEC-24-22; canonical findings / CAPA / deviation / risk emission per DEC-24-15.18; URS-13 change-control linkage for protocol release and shelf-life claim revisions per DEC-24-19; URS-23 batch-record release-decision input integration; URS-26 APQR periodic-stability-summary integration; MIRA copilot read-only context with no GenAI in critical stability decisions; and per-jurisdictional regulatory expectations. ### 0.8 Locked Launch Controls | Locked control | Authority | Rationale | |---|---|---| | Two-step release path: signature → engineering implementation → validation execution | DEC-24-01 / VAL-008 | Mirrors every other Module. | | "No Module 24 internal decisions outstanding" | §11.6 | Captured in locked decisions DEC-24-01..DEC-24-23 (§3.2). | | `platform_admin` / `super_admin` support / break-glass only | DEC-24-20 / SoD-24-07 | Operating-tenant stability 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 stability OOS / shelf-life / report-approval / closure decisions** | Architecture Bindings | EU GMP Annex 22 Draft 2025 §7 + EU AI Act Annex III treated as internal controls. Static deterministic AI (regression) permitted; GenAI / LLMs prohibited in critical stability disposition. | | 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 §16 row | §14 | India CDSCO Schedule M (Revised) §16 + Schedule Y + NDCT 2019 §27 + WHO TRS Annex 10 (Zone IVb) for India operations subject to a future jurisdiction-specific legal assessment. | | Version 1.0 posture | Header | First binding version. | | Canonical API mount `/api/v1/stability/*` | DEC-24-01 / STB-DM-002 | Frontend hooks use canonical relative `/stability/*`. | | Frontend route surface alignment | DEC-24-02 / STB-DM-003 | `/stability/protocols/:id` and `/stability/studies/:id` routes added; `BatchList`-style CTA targets resolve. | | Schema/migration/types alignment (`study_id` nullability) | DEC-24-04 / STB-DM-004 | `study_id` mandatory per migration; shared schema aligned; service no longer passes nullable `study_id` to NOT NULL columns. | | Context-gate filtering on detail reads + table-aware filter alignment | DEC-24-05 / STB-DM-005 | `getProtocol` and `getStudy` apply context gate; `MODULE_CONTEXT_CONFIG.stability` aligned with persisted schema; non-existent column references removed. | | Protocol controlled-version lifecycle | DEC-24-06 / STB-DM-006 | `draft → under_review → effective → superseded → archived`; release to effective requires `protocol_release_authority` + HITL + e-sign + URS-13 CR; revisions create new version rows; supersession workflow added. | | Parent-child integrity validation | DEC-24-09 / STB-DM-007 | `addSample` validates `condition_id` belongs to study's protocol; `recordResult` validates sample/time-point coherence; duplicate-result prevention. | | Mandatory OOS/OOT linkage for out-of-spec stability results | DEC-24-08 / STB-DM-008 | Out-of-spec results emit `stability_oos_oot_linked` event consumed by URS-15; reclassification to `oos` not sufficient. | | Preliminary computed shelf-life vs approved shelf-life claim distinction | DEC-24-09 / STB-DM-009 | Heuristic / regression output is advisory; approved claim is system-of-record after Qualified Person + RA co-sign + URS-13 CR linkage. | | Stability report and shelf-life claim authority + HITL + bound e-sign gates | DEC-24-10 / STB-DM-010 | `withAuthority` integrated for report approval; bound e-sign persisted via `electronic_signatures` substrate. | | Commitment governance with full attributable substrate | DEC-24-11 / STB-DM-011 | `created_by` / `updated_by` / `closed_by` / `e_signature_id` added to `stability_commitments`. | | Audit-trail coverage on all mutable records + reason-for-change | DEC-24-12 / STB-DM-012 | `updateCondition`, `updateSample`, `updateCommitment` emit audit; reason-for-change required on material updates after draft. | | LIMS-import provenance preservation + import controls | DEC-24-13 / STB-DM-013 | LIMS-import route added; `lims_import_id`, `lims_source`, `lims_import_hash`, `import_reconciliation_status` persisted. | | Backend route/service/integration test coverage | §16 / STB-DM-014 | Comprehensive backend test pack added. | | Bound e-signature persistence on every regulated final action | DEC-24-12 / DEC-24-23 | Protocol release / report approval / claim approval / commitment closure / study lock / governed reopen — all carry bound e-signature. | | Governed reopen pattern (`locked → in_progress`) | DEC-24-22 / SoD-24-06 | Append-only iteration; executive + QP co-sign; does NOT mutate prior locked evidence. | --- ## 1. Scope and Out-of-Scope ### 1.1 In-scope - The canonical Stability Protocol controlled-template register and lifecycle. - The Stability Study execution-record register and lifecycle. - The storage-condition substructure with versioned ICH Q1A(R2) condition templates. - The sample registry with sample-condition ownership validation. - The time-point registry. - The result-capture lifecycle with sample/time-point coherence validation, duplicate-result prevention, and out-of-spec OOS/OOT linkage. - The stability-report lifecycle with bound e-signature approval. - The shelf-life-claim distinction (preliminary computed advisory vs approved system-of-record). - The stability-commitment registry with full attributable substrate. - The LIMS-import provenance preservation and import controls. - The MIRA copilot read-only context integration (no GenAI in critical stability decisions). - The findings emission to URS-21. - The CAPA emission to URS-18. - The deviation emission to URS-16. - The risk emission to URS-19. - The OOS/OOT emission to URS-15. - The change-control linkage to URS-13 for protocol effective release and shelf-life claim revisions. - The URS-23 batch-record release-decision input integration. - The URS-26 APQR periodic-stability-summary integration. - The governed reopen workflow. - The audit-trail coverage with reason-for-change discipline. - The per-jurisdictional regulatory expectations. ### 1.2 Out-of-scope - The OOS/OOT register itself (URS-15) — this URS emits OOS/OOT linkage events; lifecycle is the URS-15 contract. - The deviations register itself (URS-16) — this URS emits stability deviation events; lifecycle is the URS-16 contract. - The CAPA register itself (URS-18) — this URS emits stability_failure CAPA events; CAPA closure is the URS-18 contract. - The findings register itself (URS-21) — this URS emits stability finding events; finding lifecycle is the URS-21 contract. - The change-control register itself (URS-13). - The document-control register itself (URS-12). - The MIRA copilot service itself (URS-32). - Direct chamber DCS / SCADA integration — out of scope for v1.0; tracked under URS-25 EM. - Equipment / chamber qualification register — tracked under URS-33 GMP. - Direct LIMS API integration with specific LIMS vendors — generic LIMS-import provenance pattern in scope; vendor-specific connectors are 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), document-control (URS-12), change-control (URS-13), OOS/OOT (URS-15), deviations (URS-16), CAPA (URS-18), findings (URS-21), risk assessment (URS-19), and MIRA AI (URS-32) are released and operational at validation time. - Stability analysts, reviewers, report approvers, shelf-life claim authority (Qualified Person + RA) are trained, attributable users with documented authority. - AI-assisted stability surfaces are advisory only; the human stability reviewer'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-23, URS-25.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 `oos_oot` substrate (URS-15). - The `notifications` substrate (URS-30). ### 2.3 Constraints - The canonical API mount is `/api/v1/stability/*`. No frontend hook may use `/api/stability/*` (extra `/api`). - The stability module is product-scoped at protocol level; site-scoped at study level; study-scope optional or mandatory per approved policy. - AI-assisted content is advisory-only; **no AI service finalizes stability OOS classification, shelf-life disposition, report approval, or study closure**. - Generative AI / LLMs are prohibited in stability OOS / shelf-life / report-approval / closure decision paths under the internal Annex 22 §7 + EU AI Act Annex III control. - Effective protocol versions are immutable; revisions create new version rows. - Out-of-spec stability results MUST emit OOS/OOT linkage to URS-15. - Final shelf-life claim is system-of-record only after Qualified Person + RA co-sign + URS-13 change-request linkage. --- ## 3. Closed Launch Decisions The following decisions are LOCKED for Module 24 v1.0. Each decision is the binding executive authority decision for the current launch and are locked and define the binding launch posture. ### 3.1 Decision register | Decision ID | Title | Locked decision | |---|---|---| | DEC-24-01 | Two-step release path | Module 24 follows the same two-step release path as every other Module. | | DEC-24-02 | Frontend route surface alignment | Frontend routes `/stability/protocols/:id` and `/stability/studies/:id` are added; list-page CTAs resolve to real pages. | | DEC-24-03 | Typed schema validation across every route | Every stability route validates request params, query strings, and bodies through explicit typed schemas before service execution; shared `stability.schema.ts` aligned with migration 036 (/ STB-DM-004). | | DEC-24-04 | Mandatory context dimensions alignment | `study_id` is mandatory at protocol, study, and commitment level (matching migration 036 NOT NULL); `product_id` is mandatory at protocol level; `site_id` is mandatory at study level. | | DEC-24-05 | Context-gate filtering on detail reads + table-aware filter alignment | `getProtocol(.)` and `getStudy(.)` apply context-gate filtering; `MODULE_CONTEXT_CONFIG.stability` aligned with persisted schema; service applies context filters only to tables that actually carry the referenced columns; detail reads enforce context-gate as well as list reads. | | DEC-24-06 | Protocol controlled-version lifecycle | Protocol lifecycle is `draft → under_review → effective → superseded → archived`; release to `effective` requires `protocol_release_authority` + HITL + bound e-signature + URS-13 change-request linkage per DEC-24-19; revisions create new version rows; superseded versions are immutable. | | DEC-24-07 | Stability-study lifecycle | Study lifecycle is `draft → enrolled → in_progress → results_complete → under_review → reported → claim_approved → closed → locked`; reopen `locked → in_progress` is governed transition per DEC-24-22. | | DEC-24-08 | Mandatory OOS/OOT linkage for out-of-spec stability results | Out-of-spec stability results MUST emit `stability_oos_oot_linked` event consumed by URS-15 (`stability_result` source type per URS-15 declared source set); the URS-15 OOS investigation is the system-of-record for OOS disposition; stability report cannot be approved while linked OOS investigations are open in URS-15. | | DEC-24-09 | Parent-child integrity + duplicate-result prevention + preliminary vs approved shelf-life | (a) `addSample(.)` validates `condition_id` belongs to the study's protocol; (b) `recordResult(.)` validates sample/time-point coherence (sample's study == time-point's study) and prevents duplicate result rows for `(sample_id, time_point_id, test_id)`; (c) `calculateShelfLife(.)` returns advisory **preliminary computed shelf-life**; the approved shelf-life claim is system-of-record only after `shelf_life_claim_authority` (typically Qualified Person + Regulatory Affairs) co-sign + bound e-signature + URS-13 CR linkage per DEC-24-19 (/ STB-DM-009). | | DEC-24-10 | Stability report and shelf-life claim authority + HITL + bound e-sign gates | Stability report lifecycle is `draft → under_review → approved`; report approval requires `stability_report_approver_authority` + HITL + bound e-signature; shelf-life claim approval requires `shelf_life_claim_authority` (typically Qualified Person + Regulatory Affairs co-sign) + HITL + bound e-signature + URS-13 CR linkage; bound e-signature persisted via `electronic_signatures` substrate. | | DEC-24-11 | Commitment governance with full attributable substrate | `stability_commitments` carries `created_by`, `updated_by`, `closed_by`, `closed_at`, `e_signature_id`, `linked_capa_id` (where applicable); commitment lifecycle is `open → in_progress → completed → verified → closed`; verification requires SoD-distinct verifier; closure requires bound e-signature. | | DEC-24-12 | Audit-trail coverage on all mutable records + reason-for-change discipline | `updateCondition`, `updateSample`, `updateCommitment`, `updateProtocol`, `updateStudy` and every other mutation route emit audit-trail entries; material updates after the record leaves draft require structured reason-for-change captured in audit. | | DEC-24-13 | LIMS-import provenance preservation + import controls | `stability_results` persists `lims_import_id`, `lims_source`, `lims_import_hash`, `import_reconciliation_status`, `imported_by`, `imported_at`; LIMS-import route validates payload, deduplicates by `lims_import_hash`, and creates reconciliation records for failed imports. | | DEC-24-14 | Multi-dimensional context model | `tenant_id`, `product_id`, `study_id`, `site_id` mandatory or optional per DEC-24-04 alignment; child records inherit and persist parent context. | | DEC-24-15 | Findings emission to URS-21 | Stability findings (e.g., trend findings, regression-fit findings, protocol-deviation findings) emit `stability_finding_created` event to URS-21 with `stability_finding` source type. | | DEC-24-16 | CAPA emission to URS-18 | Stability failures escalated to CAPA emit `stability_failure_capa_linked` event consumed by URS-18 (`stability_failure` source type per URS-18 declared source set). | | DEC-24-17 | Deviation emission to URS-16 | Stability protocol deviations emit `stability_deviation_created` event consumed by URS-16. | | DEC-24-18 | Risk emission to URS-19 | Stability-precipitated risk records (e.g., recurring trend patterns, supplier-material stability risk patterns) emit `stability_risk_created` event consumed by URS-19. | | DEC-24-19 | URS-13 change-control linkage | Protocol `under_review → effective` and shelf-life-claim revisions require URS-13 change-request linkage via `protocol_release_change_request_id` and `claim_revision_change_request_id`. | | DEC-24-20 | platform_admin / super_admin | `platform_admin` / `super_admin` are support / break-glass only paths. | | DEC-24-21 | Reason-for-change on material updates | Captured per DEC-24-12. | | DEC-24-22 | Stability-study reopen as governed transition | Study `locked → in_progress` requires `executive_authority` co-sign AND `qualified_person_authority` co-sign + documented reason; appends new investigation iteration without mutating prior locked evidence (consistent with M14.M23 reopen pattern with the additional QP co-sign required for stability gravity). | | DEC-24-23 | Bound e-signature on every regulated final action | Protocol release, report approval, shelf-life claim approval, commitment closure, study lock, governed reopen — all carry bound e-signature persisted via `electronic_signatures` substrate. | ### 3.2 Locked-decision rationale narrative The decisions above define the binding launch posture for Module 24 v1.0. The most consequential locked controls are: (a) DEC-24-04 makes `study_id` mandatory, aligning `stability.schema.ts` and the typed DB layer to migration 036; (b) DEC-24-05 reconciles the `MODULE_CONTEXT_CONFIG.stability` filter config with the persisted schema and adds context-gate enforcement on detail reads; (c) DEC-24-06 adds controlled protocol-version lifecycle with HITL + e-signature + URS-13 CR linkage; (d) DEC-24-08 mandates OOS/OOT linkage emission to URS-15 for every out-of-spec stability result; (e) DEC-24-09 **explicitly distinguishes the preliminary computed shelf-life (advisory) from the approved shelf-life claim (system-of-record after QP + RA co-sign + URS-13 CR linkage)**; (f) DEC-24-10 requires `withAuthority` + HITL + bound e-signature persisted via `electronic_signatures` on report and claim approval; (g) DEC-24-22 defines reopen as a governed append-only transition consistent with the Module-14..-23 reopen pattern, with the additional Qualified Person co-sign required given stability disposition gravity. ### 3.3 Closed launch decisions: cross-link to items | Specification item ID | Specification item | Locked decision | |---|---|---| | STB-DM-001 | Module exists without prior URS | DEC-24-01.DEC-24-23 (this URS) | | STB-DM-002 | API contract standardization | DEC-24-01 / DEC-24-03 | | STB-DM-003 | Frontend route surface broken | DEC-24-02 | | STB-DM-004 | Migration/schema/type alignment requirement | DEC-24-03 / DEC-24-04 | | STB-DM-005 | Context filter design defect | DEC-24-05 | | STB-DM-006 | Protocol lifecycle missing | DEC-24-06 / DEC-24-19 | | STB-DM-007 | Parent-child integrity missing | DEC-24-09 | | STB-DM-008 | OOS linkage missing | DEC-24-08 | | STB-DM-009 | Shelf-life calculation insufficient | DEC-24-09 / DEC-24-19 | | STB-DM-010 | Report approval missing | DEC-24-10 | | STB-DM-011 | Commitment governance thin | DEC-24-11 | | STB-DM-012 | Audit + reason-for-change gaps | DEC-24-12 / DEC-24-21 | | STB-DM-013 | LIMS provenance gap | DEC-24-13 | | STB-DM-014 | Test evidence missing | §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 — ICH Q1A(R2) zone IVa stability program for a tablet product.** The Quality Head authors stability protocol `STAB-PROT-PTabs-v3` for Product P-Tabs covering ICH Q1A(R2) zone IVa: long-term `30°C/65% RH` over 36 months (time points 0/3/6/9/12/18/24/36), accelerated `40°C/75% RH` over 6 months (time points 0/3/6), with analytical tests at each time point (Assay, RS impurities, Dissolution, Water content, Microbial). The protocol is reviewed by Validation and RA; a URS-13 change request CC-2026-0042 is opened. After change-control approval, `protocol_release_authority` releases `STAB-PROT-PTabs-v3` to `effective` with HITL + bound e-signature per DEC-24-06. A stability study `STAB-STD-PTabs-2026-08-Batch001` is created bound to `STAB-PROT-PTabs-v3`; samples are registered against each `condition_id` (validated to belong to the protocol per DEC-24-09); time points 0/3/6/9/12/18/24/36 (long-term) and 0/3/6 (accelerated) are added; samples are placed in chambers (URS-25 EM context). At the 6-month time point, a result for Assay is captured at 98.4% (spec 95.0–105.0%) — in spec; another result for RS impurity 0.18% (spec ≤0.20%) — in spec. At the 12-month time point, RS impurity is 0.23% — out of spec; the system requires OOS/OOT linkage and emits `stability_oos_oot_linked` to URS-15 per DEC-24-08; URS-15 OOS investigation is opened and proceeds through the URS-15 lifecycle. At month 36, all results compiled; preliminary computed shelf-life shows fail-curve crossing at ~30 months for one parameter (advisory only per DEC-24-09). Report drafted; goes through `under_review → approved` with `stability_report_approver_authority` + HITL + bound e-signature per DEC-24-10. Shelf-life claim of 24 months is proposed; URS-13 change request CC-2026-0288 is opened; `shelf_life_claim_authority` (Qualified Person + RA co-sign) approves the 24-month claim with bound e-signature per DEC-24-19. Study transitions `claim_approved → closed`; auto-locks 24h later with bound e-signature per DEC-24-23. **Worked example 2 — India Zone IVb stability program with WHO TRS Annex 10.** The same product P-Tabs is registered for India market; per WHO TRS Annex 10 the long-term condition is `30°C/75% RH` (Zone IVb); a separate stability protocol version `STAB-PROT-PTabs-v4-IN` is created and released through change control. Study runs in parallel; results captured at India-specific conditions; CDSCO-aligned shelf-life claim approved. **Worked example 3 — Out-of-spec stability result triggering OOS-CAPA chain.** At month 18 of the long-term study, dissolution drops below spec. System emits `stability_oos_oot_linked` to URS-15; URS-15 OOS investigation finds root-cause attributable to a supplier API change; URS-17 RCA performed; URS-18 CAPA opened with `stability_failure` source type per DEC-24-16; URS-19 risk record created per DEC-24-18. The stability report cannot be approved while the linked URS-15 OOS investigation is open per DEC-24-08; once URS-15 closes the OOS, the stability report can be approved with the OOS conclusion appended. **Worked example 4 — Governed reopen of a locked stability study.** On `2027-04-15` post-marketing surveillance reveals a complaint pattern (URS-14) potentially attributable to a stability concern on a previously closed and locked study. The Manufacturing Head initiates a reopen; per DEC-24-22 + SoD-24-06, both `executive_authority` co-sign AND `qualified_person_authority` co-sign + documented reason are required. On both co-signs the study transitions `locked → in_progress` and a new investigation iteration is appended; the prior locked evidence (results, report, claim, commitments) is NOT mutated; the new iteration captures the additional investigation activity, which may end with a re-report and re-claim cycle. --- ## 4. End-to-End User Journeys (28 launch journeys) | # | Journey | Actor | Pre-condition | Path | Post-condition | |---|---|---|---|---|---| | 1 | Author stability protocol draft | Protocol Author | `stability:protocol:create`; `product_id` resolved | Create protocol `(product_id, study_id, version=1)` with conditions and time points | Protocol `draft`; audit entry | | 2 | Submit protocol for review | Protocol Author | Protocol `draft` complete | Transition `draft → under_review` | Protocol `under_review`; audit entry | | 3 | Release protocol to effective | Protocol Releaser | Protocol `under_review`; URS-13 CR approved | HITL + bound e-sign + URS-13 CR linkage; transition `under_review → effective`; supersede prior version | Protocol `effective`; prior `superseded`; bound e-signature; `stability_protocol_released_effective` event | | 4 | Revise effective protocol | Protocol Author / Releaser | Effective protocol exists | New version row `draft`; on release supersedes prior | New version `effective`; prior `superseded`; immutable historical | | 5 | Create stability study from effective protocol | Stability Reviewer | `stability:study:create`; effective protocol exists | Create study `(protocol_id, site_id, product_id, study_id, batch_id)` | Study `draft`; audit entry | | 6 | Enroll study | Stability Reviewer | Study `draft` | Add samples (sample-condition ownership validated per DEC-24-09); add time points (study-bound) | Study `enrolled`; audit entry | | 7 | Start study | Stability Reviewer | Study `enrolled` | Transition `enrolled → in_progress` | Study `in_progress`; audit entry | | 8 | Record stability result (in spec) | Lab Operator | Study `in_progress`; sample/time-point coherence valid | `recordResult` with validated sample/time-point/test; in-spec | Result persisted; duplicate prevention enforced; audit entry | | 9 | Record stability result (out of spec) | Lab Operator | Out-of-spec value | `recordResult`; emit `stability_oos_oot_linked` to URS-15 per DEC-24-08 | Result persisted; URS-15 OOS investigation opened; report-approval blocked while URS-15 open | | 10 | LIMS-import results | LIMS Importer (system) | LIMS payload valid | `recordResult` via LIMS-import route; persist `lims_import_id`, `lims_source`, `lims_import_hash`, `import_reconciliation_status` per DEC-24-13 | Results persisted with provenance; deduplicated by `lims_import_hash` | | 11 | Mark results complete | Stability Reviewer | All scheduled time points captured or rationale | Transition `in_progress → results_complete` | Study `results_complete`; audit entry | | 12 | Submit study for review | Stability Reviewer | `results_complete` | Transition to `under_review` | Study `under_review`; audit entry | | 13 | Generate stability report | Stability Reviewer | Study `under_review` | Generate report draft | Report `draft`; audit entry | | 14 | Review report | Stability Reviewer | Report `draft` | Transition `draft → under_review` | Report `under_review`; audit entry | | 15 | Approve stability report (bound e-sign) | Stability Report Approver | Report `under_review`; no open URS-15 OOS investigation per DEC-24-08 | HITL + bound e-sign per DEC-24-10; transition `under_review → approved`; sync study `reported` | Report `approved`; bound e-signature; `stability_report_approved` event | | 16 | Compute preliminary shelf-life (advisory) | Stability Reviewer | Approved report | Run regression (Arrhenius / linear / log) — advisory only per DEC-24-09 | Preliminary computed shelf-life rendered; not system-of-record | | 17 | Approve shelf-life claim (Qualified Person + RA co-sign) | Qualified Person + RA | Approved report; URS-13 CR | HITL + bound e-sign + URS-13 CR linkage per DEC-24-10 / DEC-24-19; transition study `reported → claim_approved` | Approved shelf-life claim is system-of-record; bound e-signature; `shelf_life_claim_approved` event; URS-23 batch-record consumer notified; URS-34 GDP notified | | 18 | Close study | Final Quality Approver | Study `claim_approved`; commitments tracked | Transition `claim_approved → closed`; bound e-sign | Study `closed`; audit entry | | 19 | Auto-lock study | System (auto + bound e-sign) | Study `closed` for ≥ 24h | Transition `closed → locked` with bound e-sign per DEC-24-23 | Study `locked`; immutable; `stability_study_locked` event | | 20 | Reopen locked study (governed transition) | Manufacturing Head + Executive Authority + Qualified Person | Study `locked`; documented reason | Executive co-sign AND QP co-sign; transition `locked → in_progress`; append new iteration row per DEC-24-22 | Study `in_progress`; new iteration appended; prior locked evidence NOT mutated; bound e-signature; `stability_study_reopened` event | | 21 | Create post-approval stability commitment | Stability Reviewer | `stability:commitment:create` | Create commitment `open` with full attributable substrate per DEC-24-11 | Commitment `open`; audit entry | | 22 | Verify commitment | Commitment Verifier (SoD-distinct) | Commitment `completed` | Verify with structured outcome + evidence + bound e-sign | Commitment `verified`; audit entry | | 23 | Close commitment | Commitment Verifier | Commitment `verified` | Close with bound e-sign | Commitment `closed`; audit entry | | 24 | Emit stability finding to URS-21 | System (event) | Stability finding triggered | Emit `stability_finding_created` to URS-21 | URS-21 standalone finding created | | 25 | Emit stability deviation to URS-16 | System (event) | Protocol deviation captured | Emit `stability_deviation_created` to URS-16 | URS-16 deviation created | | 26 | Emit stability-precipitated risk to URS-19 | System (event) | Risk pattern triggered | Emit `stability_risk_created` to URS-19 | URS-19 risk record created | | 27 | Apply context filter on stability query | Reader | `stability:read`; product/site context active | Query filtered per DEC-24-05 | Context-scoped results; no invalid SQL | | 28 | Cross-tenant `platform_admin` break-glass | platform_admin | Documented reason | Cross-tenant stability coordination access; logged | Break-glass action logged in platform support audit per DEC-24-20 | --- ## 5. Front-end Requirements ### 5.1 Stability List The stability list (URS-24-FE-001) renders studies, protocols, and commitments with filters by status, product, site, study, condition zone, date range; uses canonical `/stability/*` hooks per DEC-24-01. ### 5.2 Stability Protocol Detail The protocol detail (URS-24-FE-002) renders the controlled protocol template including conditions, time points, analytical tests, regulatory citations (ICH Q1A(R2) / ICH Q1E / WHO TRS Annex 10) per DEC-24-05 with context-gate filtering; new route `/stability/protocols/:id` per DEC-24-02. ### 5.3 Stability Study Detail The study detail (URS-24-FE-003) renders one study with protocol (with version), conditions, samples, time points, results (with in-spec / OOS badges), shelf-life output (clearly labeled as **preliminary advisory** per DEC-24-09), report status, claim status, commitments; new route `/stability/studies/:id` per DEC-24-02. ### 5.4 Protocol Editor The protocol editor (URS-24-FE-004) supports protocol draft authoring with full condition + time-point + test editor; release flow with HITL + e-signature gates linked to URS-13 change-request selection. ### 5.5 Result Capture Form The result capture form (URS-24-FE-005) supports result entry with sample/time-point/test selection (server validates coherence per DEC-24-09); duplicate-result prevention; out-of-spec results trigger OOS/OOT linkage modal with mandatory URS-15 record creation per DEC-24-08. ### 5.6 LIMS Import Console The LIMS import console (URS-24-FE-006) supports LIMS-payload upload with provenance preservation per DEC-24-13; reconciliation surface for failed imports. ### 5.7 Stability Report Console The report console (URS-24-FE-007) renders report draft, review, and approval ceremonies with bound e-signature per DEC-24-10. ### 5.8 Shelf-Life Claim Approval Console The shelf-life claim approval console (URS-24-FE-008) renders the **clearly distinguished preliminary computed shelf-life (advisory)** vs **proposed shelf-life claim (for approval)**; Qualified Person + RA co-sign ceremony with bound e-signature + URS-13 CR linkage per DEC-24-10 / DEC-24-19. ### 5.9 Commitment Tracker The commitment tracker (URS-24-FE-009) supports commitment lifecycle `open → in_progress → completed → verified → closed` with SoD-distinct verifier and bound e-signature on closure. ### 5.10 MIRA Copilot Integration MIRA copilot (URS-24-FE-010) is read-only context on stability records via `useMiraRecord('stability_protocol', id)`, `useMiraRecord('stability_study', id)`, `useMiraRecord('stability_report', id)`. **No MIRA write paths to stability tables; no LLM/GenAI in critical stability decisions.** MIRA may surface advisory information (similar prior protocols, historical degradation patterns) labeled as advisory. ### 5.11 Accessibility WCAG 2.1 AA accessible. --- ## 6. Back-end Requirements ### 6.1 Module structure `packages/backend/src/modules/stability/` with `plugin.ts`, `routes.ts` (typed schemas — per DEC-24-03), `service.ts` (parent-child validation; OOS/OOT linkage; shelf-life claim approval; LIMS-import provenance; audit-trail coverage; reason-for-change discipline), `schemas.ts` (aligned with migration 036 per DEC-24-04), `events.ts` (event emission for `stability_protocol_*`, `stability_study_*`, `stability_result_*`, `stability_oos_oot_linked`, `stability_report_*`, `shelf_life_claim_approved`, `stability_commitment_*`, `stability_study_locked`, `stability_study_reopened`, `stability_finding_created`, `stability_deviation_created`, `stability_failure_capa_linked`, `stability_risk_created`). ### 6.2 Data model #### 6.2.1 `stability_protocols` `id`, `tenant_id`, `product_id` (NOT NULL FK per DEC-24-04), `study_id` (NOT NULL FK per DEC-24-04), `protocol_code`, `title`, `protocol_version` (INTEGER NOT NULL), `effective_from`, `effective_to`, `supersedes_protocol_id` (self-FK nullable), `protocol_release_change_request_id` (FK to URS-13 per DEC-24-19), `regulatory_zone` (ENUM `ich_zone_i` / `ich_zone_ii` / `ich_zone_iii` / `ich_zone_iva` / `ich_zone_ivb`), `approved_by`, `approved_at`, `e_signature_id` (FK), `status` (ENUM `draft` / `under_review` / `effective` / `superseded` / `archived`), audit columns. Uniqueness `(tenant_id, product_id, protocol_code, protocol_version)`. RLS enabled. #### 6.2.2 `stability_conditions` `id`, `tenant_id`, `protocol_id` (FK), `condition_label`, `temperature_c`, `humidity_pct`, `condition_type` (ENUM `long_term` / `intermediate` / `accelerated` / `photostability` / `freeze_thaw`), `time_points_months` (INTEGER[]), audit columns. Immutable on `effective` protocols. #### 6.2.3 `stability_studies` `id`, `tenant_id`, `protocol_id` (NOT NULL FK to effective protocol), `product_id` (NOT NULL FK), `study_id` (FK), `site_id` (NOT NULL FK per DEC-24-04), `batch_id` (TEXT or FK to URS-23 batch_records), `study_code`, `start_date`, `expected_end_date`, `actual_end_date`, `status` (ENUM `draft` / `enrolled` / `in_progress` / `results_complete` / `under_review` / `reported` / `claim_approved` / `closed` / `locked`), `closed_at`, `closed_by`, `closed_e_signature_id`, `locked_at`, `locked_by`, `lock_e_signature_id`, `reopened_at`, `reopened_by`, `reopen_executive_co_signer`, `reopen_qp_co_signer`, `reopen_reason`, audit columns. #### 6.2.4 `stability_samples` `id`, `tenant_id`, `study_id` (FK), `condition_id` (FK — ownership validated per DEC-24-09 belongs to study's protocol), `sample_label`, `placement_date`, `placed_by`, audit columns. #### 6.2.5 `stability_time_points` `id`, `tenant_id`, `study_id` (FK), `time_point_months` (INTEGER), `scheduled_date`, audit columns. #### 6.2.6 `stability_results` `id`, `tenant_id`, `sample_id` (FK), `time_point_id` (FK — coherence with sample's study validated per DEC-24-09), `test_id` (FK to analytical test catalog), `result_value_numeric`, `result_value_text`, `result_unit`, `spec_low`, `spec_high`, `in_spec` (BOOLEAN), `oos_oot_id` (FK to URS-15 nullable — populated for out-of-spec per DEC-24-08), `lims_import_id` (TEXT nullable), `lims_source` (TEXT nullable), `lims_import_hash` (TEXT nullable), `import_reconciliation_status` (ENUM `imported` / `reconciled` / `failed` / `manual` nullable), `imported_by` (FK nullable), `imported_at` (TIMESTAMPTZ nullable), `recorded_by`, `recorded_date`, audit columns. Uniqueness on `(sample_id, time_point_id, test_id)` per DEC-24-09 (duplicate-result prevention). #### 6.2.7 `stability_reports` `id`, `tenant_id`, `study_id` (FK), `report_version`, `report_text`, `regression_summary` (JSONB), `preliminary_computed_shelf_life_months` (INTEGER nullable — advisory only per DEC-24-09), `status` (ENUM `draft` / `under_review` / `approved`), `approved_by`, `approved_at`, `approval_e_signature_id` (FK), audit columns. #### 6.2.8 `stability_shelf_life_claims` `id`, `tenant_id`, `study_id` (FK), `report_id` (FK), `claimed_shelf_life_months` (INTEGER NOT NULL), `claim_revision_change_request_id` (FK to URS-13 per DEC-24-19), `qp_approved_by`, `qp_approved_at`, `qp_e_signature_id` (FK), `ra_approved_by`, `ra_approved_at`, `ra_e_signature_id` (FK), `claim_status` (ENUM `proposed` / `approved` / `superseded`), `effective_from`, audit columns. #### 6.2.9 `stability_commitments` `id`, `tenant_id`, `study_id` (FK), `commitment_text`, `commitment_type` (ENUM `ongoing_stability` / `additional_arm` / `post_approval`), `due_date`, `assigned_to`, `created_by`, `updated_by`, `verified_by` (FK nullable — SoD-distinct), `verified_at`, `verifier_e_signature_id`, `closed_by`, `closed_at`, `closed_e_signature_id`, `linked_capa_id` (FK to URS-18 nullable), `status` (ENUM `open` / `in_progress` / `completed` / `verified` / `closed`), audit columns. #### 6.2.10 RLS All Module 24 tables have RLS enabled. ### 6.3 API contract | Route | Method | Permission | Status | |---|---|---|---| | `/api/v1/stability/protocols` | GET / POST | `stability:protocol:read` / `stability:protocol:create` | (typed schema) | | `/api/v1/stability/protocols/:id` | GET (with context-gate filtering per DEC-24-05) / PATCH (draft only) | `stability:protocol:read` / `stability:protocol:update` | | | `/api/v1/stability/protocols/:id/release` | POST | `protocol_release_authority` + HITL + bound e-sign + URS-13 CR linkage | target route per DEC-24-06 / DEC-24-19 | | `/api/v1/stability/protocols/:id/conditions` | GET / POST | `stability:protocol:conditions` | (draft only) | | `/api/v1/stability/protocols/:id/conditions/:conditionId` | PATCH | `stability:protocol:conditions` | (draft only; audit entry per DEC-24-12) | | `/api/v1/stability/studies` | GET / POST | `stability:read` / `stability:study:create` | | | `/api/v1/stability/studies/:id` | GET (with context-gate filtering per DEC-24-05) / PATCH | `stability:read` / `stability:study:update` | | | `/api/v1/stability/studies/:id/samples` | GET / POST | `stability:study:samples` (ownership validated per DEC-24-09) | | | `/api/v1/stability/studies/:id/samples/:sampleId` | PATCH | `stability:study:samples` | (audit entry per DEC-24-12) | | `/api/v1/stability/studies/:id/time-points` | GET / POST | `stability:study:time_points` | | | `/api/v1/stability/studies/:id/results` | GET / POST | `stability:result:read` / `stability:result:create` (sample/time-point coherence + duplicate prevention per DEC-24-09; OOS/OOT linkage per DEC-24-08) | | | `/api/v1/stability/studies/:id/results/import-lims` | POST | `stability:result:lims_import` (provenance preservation per DEC-24-13) | target route | | `/api/v1/stability/studies/:id/reports` | GET / POST | `stability:report:read` / `stability:report:create` | | | `/api/v1/stability/reports/:id/approve` | POST | `stability_report_approver_authority` + HITL + bound e-sign per DEC-24-10 | target route | | `/api/v1/stability/studies/:id/preliminary-shelf-life` | GET | `stability:read` (advisory only per DEC-24-09) | (preliminary advisory only) | | `/api/v1/stability/studies/:id/shelf-life-claims` | GET / POST | `stability:claim:read` / `stability:claim:propose` | target route | | `/api/v1/stability/shelf-life-claims/:id/approve` | POST | `shelf_life_claim_authority` (Qualified Person + RA co-sign) + HITL + bound e-sign + URS-13 CR linkage per DEC-24-10 / DEC-24-19 | target route | | `/api/v1/stability/studies/:id/close` | POST | `final_quality_approver` + HITL + bound e-sign | target route | | `/api/v1/stability/studies/:id/lock` | POST | system (auto + bound e-sign per DEC-24-23) | target route | | `/api/v1/stability/studies/:id/reopen` | POST | `executive_authority` co-sign AND `qualified_person_authority` co-sign + HITL + reason per DEC-24-22 | target route | | `/api/v1/stability/commitments` | GET / POST | `stability:commitment:read` / `stability:commitment:create` | | | `/api/v1/stability/commitments/:id` | PATCH | `stability:commitment:update` | (audit entry per DEC-24-12) | | `/api/v1/stability/commitments/:id/verify` | POST | `commitment_verification_authority` (SoD-distinct) + HITL + bound e-sign | target route | | `/api/v1/stability/commitments/:id/close` | POST | `commitment_verification_authority` + HITL + bound e-sign | target route | ### 6.4 Workflow #### 6.4.1 Protocol lifecycle ```mermaid stateDiagram-v2 [*] --> draft: create draft --> under_review: submit for review under_review --> effective: release (protocol_release_authority + HITL + e-sign + URS-13 CR) effective --> superseded: revise (new version) superseded --> archived: archive ``` #### 6.4.2 Study lifecycle ```mermaid stateDiagram-v2 [*] --> draft: create draft --> enrolled: enroll samples + time points enrolled --> in_progress: start in_progress --> results_complete: results captured results_complete --> under_review: submit for review under_review --> reported: report approved reported --> claim_approved: shelf-life claim approved (QP + RA + URS-13 CR) claim_approved --> closed: close (final_quality_approver + e-sign) closed --> locked: auto-lock + bound e-sign locked --> in_progress: governed reopen (executive + QP co-sign + reason — DEC-24-22 + SoD-24-06) ``` #### 6.4.3 Report lifecycle ```mermaid stateDiagram-v2 [*] --> draft: generate draft --> under_review: submit for review under_review --> approved: approve (stability_report_approver_authority + HITL + e-sign; URS-15 OOS terminal check) ``` #### 6.4.4 Shelf-life claim lifecycle ```mermaid stateDiagram-v2 [*] --> proposed: propose proposed --> approved: approve (shelf_life_claim_authority QP + RA co-sign + HITL + e-sign + URS-13 CR linkage) approved --> superseded: revise (new claim — URS-13 CR) ``` #### 6.4.5 Commitment lifecycle ```mermaid stateDiagram-v2 [*] --> open: create open --> in_progress: start in_progress --> completed: complete completed --> verified: verify (SoD-distinct verifier + HITL + e-sign) verified --> closed: close (HITL + e-sign) ``` ### 6.5 Business rules - BR-24-01: Protocol uniqueness `(tenant_id, product_id, protocol_code, protocol_version)` per DEC-24-04. - BR-24-02: Protocol effective release requires `protocol_release_authority` + HITL + bound e-sign + URS-13 CR linkage per DEC-24-06 / DEC-24-19. - BR-24-03: Effective protocol versions are immutable; revisions create new version rows. - BR-24-04: Stability-study creation MUST bind to an `effective` protocol. - BR-24-05: `product_id` mandatory at protocol level; `study_id` mandatory at protocol/study/commitment level; `site_id` mandatory at study level per DEC-24-04. - BR-24-06: Sample `condition_id` MUST belong to the study's protocol per DEC-24-09. - BR-24-07: Result sample/time-point coherence enforced per DEC-24-09. - BR-24-08: Duplicate result prevention `(sample_id, time_point_id, test_id)` per DEC-24-09. - BR-24-09: Out-of-spec results MUST emit `stability_oos_oot_linked` to URS-15 per DEC-24-08. - BR-24-10: Stability report cannot be approved while linked URS-15 OOS investigations are open per DEC-24-08. - BR-24-11: Preliminary computed shelf-life is advisory only; approved shelf-life claim is system-of-record only after Qualified Person + RA co-sign + URS-13 CR linkage per DEC-24-09 / DEC-24-19. - BR-24-12: Bound e-signature on protocol release / report approval / shelf-life claim approval / study close / study lock / commitment verification / commitment closure / governed reopen per DEC-24-23. - BR-24-13: LIMS-import preserves provenance per DEC-24-13. - BR-24-14: `updateCondition`, `updateSample`, `updateCommitment`, and every other mutation route emit audit-trail entries per DEC-24-12. - BR-24-15: Reason-for-change required on material updates after draft per DEC-24-21. - BR-24-16: Auto-lock 24h after `closed` with bound e-signature per DEC-24-23. - BR-24-17: Governed reopen `locked → in_progress` requires `executive_authority` co-sign AND `qualified_person_authority` co-sign + reason per DEC-24-22. - BR-24-18: Stability findings emit `stability_finding_created` to URS-21 per DEC-24-15. - BR-24-19: Stability failures escalated to CAPA emit `stability_failure_capa_linked` to URS-18 per DEC-24-16. - BR-24-20: Stability protocol deviations emit `stability_deviation_created` to URS-16 per DEC-24-17. - BR-24-21: Stability-precipitated risks emit `stability_risk_created` to URS-19 per DEC-24-18. - BR-24-22: `platform_admin` / `super_admin` are support / break-glass only paths per DEC-24-20. - BR-24-23: **No LLM/GenAI in stability OOS / shelf-life / report-approval / closure decision paths**; static deterministic AI permitted as advisory. ### 6.6 Audit trail Every Module 24 record mutation persists an audit-trail entry via `auditTrailService.log(.)`. Material updates after draft persist `reason_for_change` per DEC-24-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 | |---|---|---| | `STB_VALIDATION_FAILED` | 400 | Schema validation failure | | `STB_UNAUTHORIZED` | 401 | Authentication required | | `STB_FORBIDDEN` | 403 | RBAC denied | | `STB_NOT_FOUND` | 404 | Resource not found | | `STB_DUPLICATE_KEY` | 409 | Uniqueness violation | | `STB_INVALID_TRANSITION` | 422 | Lifecycle transition not permitted | | `STB_PROTOCOL_NOT_EFFECTIVE` | 422 | Study creation against non-effective protocol | | `STB_PROTOCOL_CHANGE_REQUEST_REQUIRED` | 422 | Protocol release without URS-13 CR linkage | | `STB_CONDITION_OWNERSHIP_VIOLATION` | 422 | Sample's `condition_id` does not belong to study's protocol per DEC-24-09 | | `STB_RESULT_COHERENCE_VIOLATION` | 422 | Result sample/time-point coherence violation | | `STB_RESULT_DUPLICATE` | 422 | Duplicate `(sample_id, time_point_id, test_id)` | | `STB_OOS_OOT_LINKAGE_REQUIRED` | 422 | Out-of-spec result without URS-15 linkage | | `STB_REPORT_OOS_OPEN` | 422 | Report approval attempted while linked URS-15 OOS open | | `STB_PRELIMINARY_NOT_CLAIM` | 422 | Attempt to use preliminary computed shelf-life as system-of-record claim per DEC-24-09 | | `STB_CLAIM_CHANGE_REQUEST_REQUIRED` | 422 | Shelf-life claim approval without URS-13 CR | | `STB_AUTHORITY_REQUIRED` | 422 | Authority Profile missing | | `STB_HITL_DECISION_REQUIRED` | 422 | HITL decision capture missing | | `STB_E_SIGNATURE_REQUIRED` | 422 | Bound e-signature persistence missing | | `STB_REOPEN_AUTHORITY_REQUIRED` | 422 | Reopen attempted without executive + QP co-sign per DEC-24-22 | | `STB_REASON_FOR_CHANGE_REQUIRED` | 422 | Material update after draft without reason-for-change | | `STB_LIMS_IMPORT_HASH_DUPLICATE` | 409 | Duplicate LIMS import (`lims_import_hash`) | | `STB_CONTEXT_FILTER_MISMATCH` | 422 | Query against context column not present in schema | | `STB_INTERNAL` | 500 | Sanitized server error | ### 6.8 Configuration rules - ICH zone enumerations (`ich_zone_i` / `ich_zone_ii` / `ich_zone_iii` / `ich_zone_iva` / `ich_zone_ivb`) configured at platform level aligned with ICH Q1A(R2) and WHO TRS Annex 10. - Auto-lock interval (default 24h) configurable per tenant. - Same-person QP-and-RA waiver — NOT permitted for shelf-life claim approval (always SoD-distinct co-sign per DEC-24-10). --- ## 7. Non-functional Requirements - NFR-24-01: List pagination (default 50, max 200). - NFR-24-02: List p95 < 800ms (50k studies, 5M results). - NFR-24-03: Protocol detail (with conditions + time-points) p95 < 500ms. - NFR-24-04: Result-capture p95 < 600ms including OOS/OOT linkage emission. - NFR-24-05: LIMS-import batch p95 < 30s for 1000-row payload. - NFR-24-06: Audit-trail append p99 < 200ms. - NFR-24-07: Concurrent stability analysts per tenant: 50. - NFR-24-08: Storage scalability: 100k studies per tenant; 50M results per tenant. - NFR-24-09: Backup / restore RPO ≤ 15 min; RTO ≤ 4 hours per URS-35. - NFR-24-10: 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 036 baseline; target migrations (037+) add `protocol_release_change_request_id` FK, add `claim_revision_change_request_id` FK, add bound e-signature FK columns on `stability_protocols`, `stability_studies`, `stability_reports`, `stability_shelf_life_claims`, `stability_commitments`, add `stability_shelf_life_claims` table per DEC-24-09 / DEC-24-19, add LIMS-import provenance columns per DEC-24-13, add reopen columns on `stability_studies`, reconcile `MODULE_CONTEXT_CONFIG.stability` with persisted schema, add uniqueness on `(sample_id, time_point_id, test_id)` per DEC-24-09, add commitment attributable substrate per DEC-24-11. ### 9.3 Migration evidence gate (URS-24-VAL-008) (a) all migrations applied; (b) RLS verified; (c) typed schema validation verified; (d) parent-child integrity verified for samples/time points/results; (e) duplicate-result prevention verified; (f) OOS/OOT linkage emission verified; (g) preliminary-vs-approved shelf-life distinction verified; (h) bound e-signature persistence verified for protocol release / report approval / claim approval / study lock / reopen / commitment closure; (i) LIMS-import provenance verified; (j) governed reopen append-only verified; (k) cross-module event emission verified (URS-13, URS-15, URS-16, URS-18, URS-19, URS-21, URS-23, URS-26); (l) context-gate filtering on detail reads verified; (m) audit-trail coverage on every mutation verified; (n) §17 validation evidence pack signed. --- ## 10. Decommissioning Module 24 records subject to platform record-retention policy: retained for the longer of (a) 30 years from study 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 24 internal decisions outstanding.** Launch decisions are captured in the locked decisions above. ### 11.2 External dependencies - URS-13 change-control register must support `protocol_release_change_request_id` and `claim_revision_change_request_id` linkage per DEC-24-19. - URS-15 OOS/OOT register must accept `stability_result` source type and `stability_result_id` reference per DEC-24-08. - URS-16 deviations register must accept `stability_deviation` source type per DEC-24-17. - URS-18 CAPA register must accept `stability_failure` source type per DEC-24-16. - URS-21 findings register must accept `stability_finding` source type per DEC-24-15. - URS-19 risk-assessment register must accept `stability_risk` source type per DEC-24-18. - URS-23 batch-record release must consume `shelf_life_claim_approved` event for batch-record release-decision input. - URS-26 APQR must consume `stability_study_locked` and approved shelf-life claims. - URS-32 MIRA AI must support read-only `useMiraRecord('stability_protocol',.)`, `useMiraRecord('stability_study',.)`, `useMiraRecord('stability_report',.)` mappings; **no GenAI in critical stability decisions**. ### 11.3 Risks - Risk-24-01: ICH Q1A(R2) regression methodology validation — risk that the regression algorithm choice (Arrhenius / linear / log) varies by product. Mitigation: regression-method explicitly captured per study; reviewer can override; static deterministic AI permitted as advisory. - Risk-24-02: WHO TRS Annex 10 Zone IVb operations may differ from ICH Q1A(R2) Zone IVa. Mitigation: explicit zone capture on protocol; both zones supported with zone-specific condition templates. - Risk-24-03: LIMS-import provenance gaps if vendor does not provide `lims_import_hash`. Mitigation: server computes hash if vendor doesn't provide; reconciliation surface for failed imports. - Risk-24-04: Reopen workflow gravity (executive + QP co-sign) may delay urgent post-marketing investigation. Mitigation: documented reopen SLA; clear UX language. ### 11.4 Out-of-scope risks tracked elsewhere - Direct chamber DCS / SCADA integration (URS-25 EM future-state). - Vendor-specific LIMS API connectors (future-state). - Equipment / chamber qualification (URS-33 GMP). ### 11.5 Risk owner Module-24 risk register owned by Quality / Stability Squad with quarterly review by QA Head + Manufacturing Head + Validation Head + Qualified Person Authority + Laboratory Head. ### 11.6 Decision discipline No Module 24 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-24-01: Tenant isolation enforced at RLS on every Module 24 table. - SEC-24-02: RBAC enforced on every route via `requirePermission(.)`. - SEC-24-03: Authority resolution enforced on regulated final actions before HITL + e-signature. - SEC-24-04: HITL decision capture enforced before bound e-signature persistence. - SEC-24-05: Bound e-signature persistence via `electronic_signatures` substrate. - SEC-24-06: PII redaction in logs. - SEC-24-07: Audit-trail integrity via URS-06 hash chain. - SEC-24-08: AI-request provenance via `ai_requests`; **no LLM/GenAI in critical stability decisions**; static deterministic AI permitted as advisory. - SEC-24-09: `platform_admin` / `super_admin` break-glass actions logged per DEC-24-20. - SEC-24-10: LIMS-import payload integrity via `lims_import_hash`. - SEC-24-11: Context-gate filtering enforced on detail reads per DEC-24-05. --- ## 13. Segregation of Duties | SoD ID | Constraint | |---|---| | SoD-24-01 | The protocol releaser MUST NOT be the protocol author when tenant policy requires content-author/releaser separation. | | SoD-24-02 | The result recorder MAY be the same as result reviewer for in-spec results; the OOS investigator MUST NOT be the original result recorder per URS-15 SoD. | | SoD-24-03 | The stability report approver MUST NOT be the stability report drafter. | | SoD-24-04 | The shelf-life claim approval requires Qualified Person AND Regulatory Affairs co-sign (always SoD-distinct co-sign per DEC-24-10); same-person waiver NOT permitted. | | SoD-24-05 | The commitment verifier MUST NOT be the commitment performer; the commitment closer MUST NOT be the commitment performer. | | SoD-24-06 | The reopen co-signers (executive AND Qualified Person per DEC-24-22) MUST NOT be the original close-and-lock signers; reopen append-only semantics enforced. | | SoD-24-07 | The `platform_admin` / `super_admin` support / break-glass action MUST NOT be a regulated production action; logged and reviewed per DEC-24-20. | --- ## 14. Regulatory Mapping | Predicate rule | Section | Module 24 binding | |---|---|---| | FDA 21 CFR Part 11 | §11.10(a), §11.10(d), §11.10(e), §11.50, §11.70 | URS-24-VAL-008 + bound e-sign on every regulated final action + audit-trail on every mutation | | FDA 21 CFR Part 211 | §211.166 Stability testing; §211.137 Expiration dating; §211.180 Records retention | Stability protocol + study + report + shelf-life claim + record retention | | 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 prohibition in critical stability decisions | Internal forward-looking control; static deterministic AI only; GenAI prohibited in stability OOS / shelf-life / report-approval / closure | | EU AI Act (Regulation 2024/1689) | Annex III + Art. 13 transparency | Adopted as internal forward-looking AI governance; advisory-labeling; jurisdiction-specific legal assessment deferred | | MHRA Data Integrity Guidance | ALCOA+ | Audit-trail; bound e-signature; record retention | | GAMP 5 Cat 5 | Custom-application validation lifecycle | URS-24 validation evidence pack per URS-24-VAL-008 | | ICH Q1A(R2) | Stability Testing of New Drug Substances and Products | Long-term + intermediate + accelerated conditions; ICH zone classification | | ICH Q1B | Photostability | Photostability conditions | | ICH Q1C | New Dosage Forms | New-dosage-form stability protocol | | ICH Q1D | Bracketing and Matrixing | Bracketing/matrixing study designs | | ICH Q1E | Evaluation of Stability Data | Regression / extrapolation methodology | | ICH Q5C | Biotech | Biotech stability program | | WHO TRS No. 953 Annex 2 | Stability testing of pharmaceutical products | Long-term zones | | WHO TRS No. 1010 Annex 10 | Stability testing for hot/humid climates | Zone IVb (relevant for India operations) | | India CDSCO Schedule M (Revised) | §16 — Stability Testing | India operations regulatory baseline subject to a future jurisdiction-specific legal assessment | | India CDSCO Schedule Y / NDCT 2019 | §27 — Stability data for new drug | India new-drug application stability subject to a future jurisdiction-specific legal assessment | --- ## 15. Code Modules | Code module | Path | Status | |---|---|---| | `stability` plugin | `packages/backend/src/modules/stability/plugin.ts` | (canonical mount) | | `stability` routes | `packages/backend/src/modules/stability/routes.ts` | (typed schemas; route additions per §6.3) | | `stability` service | `packages/backend/src/modules/stability/service.ts` | (parent-child validation; OOS/OOT linkage; preliminary-vs-approved shelf-life distinction; bound e-signature integration; LIMS-import provenance; audit-trail + reason-for-change) | | `stability` schemas | `packages/backend/src/modules/stability/schemas.ts` | (aligned with migration 036) | | `stability` events | `packages/backend/src/modules/stability/events.ts` | target route | | Migration 036 | `packages/backend/src/db/migrations/036_stability.sql` | (037+ migrations add e-signature FKs, claim table, LIMS provenance, reopen columns, context-config alignment) | | Shared types | `packages/shared/src/types/stability.ts` | | | Shared schemas | `packages/shared/src/schemas/stability.schema.ts` | | | Frontend hooks | `packages/frontend/src/api/hooks/useStability.ts` | (canonical relative `/stability/*`) | | Frontend list | `packages/frontend/src/pages/StabilityList.tsx` | | | Frontend study detail | `packages/frontend/src/pages/StabilityDetail.tsx` | | | Frontend protocol detail | `packages/frontend/src/pages/StabilityProtocolDetail.tsx` | target route per DEC-24-02 | | Frontend protocol editor | `packages/frontend/src/pages/StabilityProtocolEditor.tsx` | target route | | Frontend result capture | `packages/frontend/src/pages/StabilityResultCapture.tsx` | target route | | Frontend LIMS import | `packages/frontend/src/pages/StabilityLimsImport.tsx` | target route | | Frontend report console | `packages/frontend/src/pages/StabilityReportConsole.tsx` | target route per DEC-24-10 | | Frontend shelf-life claim console | `packages/frontend/src/pages/StabilityShelfLifeClaimConsole.tsx` | target route per DEC-24-10 / DEC-24-19 | | Frontend commitment tracker | `packages/frontend/src/pages/StabilityCommitmentTracker.tsx` | target route per DEC-24-11 | | App routing | `packages/frontend/src/App.tsx` | (`/stability/protocols/:id`, `/stability/studies/:id`) | --- ## 16. Test Cases ### 16.1 Unit tests - TC-24-U-001: Protocol uniqueness `(tenant_id, product_id, protocol_code, protocol_version)` rejects duplicate. - TC-24-U-002: Protocol effective release without URS-13 CR rejects with `STB_PROTOCOL_CHANGE_REQUEST_REQUIRED`. - TC-24-U-003: Effective protocol condition / time-point edit rejects with `STB_INVALID_TRANSITION`. - TC-24-U-004: Study creation against non-effective protocol rejects with `STB_PROTOCOL_NOT_EFFECTIVE`. - TC-24-U-005: Sample with `condition_id` not in study's protocol rejects with `STB_CONDITION_OWNERSHIP_VIOLATION`. - TC-24-U-006: Result with sample/time-point coherence violation rejects with `STB_RESULT_COHERENCE_VIOLATION`. - TC-24-U-007: Duplicate result `(sample_id, time_point_id, test_id)` rejects with `STB_RESULT_DUPLICATE`. - TC-24-U-008: Out-of-spec result without URS-15 linkage rejects with `STB_OOS_OOT_LINKAGE_REQUIRED`. - TC-24-U-009: Report approval while linked URS-15 OOS open rejects with `STB_REPORT_OOS_OPEN`. - TC-24-U-010: Preliminary computed shelf-life cannot be promoted to claim without QP+RA + URS-13 CR rejects with `STB_PRELIMINARY_NOT_CLAIM`. - TC-24-U-011: Shelf-life claim approval without URS-13 CR rejects with `STB_CLAIM_CHANGE_REQUEST_REQUIRED`. - TC-24-U-012: Same-person QP-and-RA shelf-life claim approval rejects (always SoD-distinct per DEC-24-10). - TC-24-U-013: LIMS-import duplicate hash rejects with `STB_LIMS_IMPORT_HASH_DUPLICATE`. - TC-24-U-014: Reopen without executive AND QP co-sign rejects with `STB_REOPEN_AUTHORITY_REQUIRED`. - TC-24-U-015: Reopen appends new iteration; prior locked evidence not mutated. - TC-24-U-016: Material update after draft without reason-for-change rejects with `STB_REASON_FOR_CHANGE_REQUIRED`. - TC-24-U-017: Detail read `getProtocol(.)` and `getStudy(.)` apply context-gate filtering per DEC-24-05. - TC-24-U-018: `MODULE_CONTEXT_CONFIG.stability` aligned — query against non-existent column rejects with `STB_CONTEXT_FILTER_MISMATCH`. - TC-24-U-019: `updateCondition`, `updateSample`, `updateCommitment` emit audit-trail entries per DEC-24-12. - TC-24-U-020: Auto-lock 24h after `closed` persists bound e-signature per DEC-24-23. ### 16.2 Integration tests - TC-24-I-001: Full protocol draft → effective lifecycle with HITL + e-signature + URS-13 CR linkage. - TC-24-I-002: Full study lifecycle from `draft` to `locked` with all gates. - TC-24-I-003: ICH Q1A(R2) Zone IVa stability program per Worked Example 1. - TC-24-I-004: WHO TRS Annex 10 Zone IVb stability program per Worked Example 2. - TC-24-I-005: Out-of-spec result triggering URS-15 OOS → URS-17 RCA → URS-18 CAPA chain per Worked Example 3. - TC-24-I-006: Stability finding emission to URS-21. - TC-24-I-007: Stability protocol deviation emission to URS-16. - TC-24-I-008: Stability-precipitated risk emission to URS-19. - TC-24-I-009: Approved shelf-life claim consumed by URS-23 batch-record release-decision; URS-34 GDP notified. - TC-24-I-010: URS-26 APQR consumes locked stability study and approved claim. - TC-24-I-011: LIMS-import with full provenance preservation per DEC-24-13. - TC-24-I-012: Governed reopen `locked → in_progress` with executive + QP co-sign per Worked Example 4. - TC-24-I-013: MIRA copilot read-only context on stability records; no MIRA write paths; no GenAI in critical decisions. - TC-24-I-014: Cross-tenant `platform_admin` break-glass logged per DEC-24-20. - TC-24-I-015: Frontend list-page navigation to `/stability/protocols/:id` and `/stability/studies/:id` resolves per DEC-24-02. ### 16.3 End-to-end tests - TC-24-E-001: ICH Q1A(R2) Zone IVa stability for tablet product per Worked Example 1. - TC-24-E-002: WHO TRS Annex 10 Zone IVb stability per Worked Example 2. - TC-24-E-003: Out-of-spec stability triggering OOS-CAPA chain per Worked Example 3. - TC-24-E-004: Governed reopen of locked stability study per Worked Example 4. - TC-24-E-005: Concurrent stability analysts — 50 concurrent users — NFR-24-07 verification. - TC-24-E-006: India CDSCO Schedule M / Schedule Y stability with India predicate-rule citations. ### 16.4 Performance tests - TC-24-P-001: List p95 latency (NFR-24-02). - TC-24-P-002: Protocol detail p95 latency (NFR-24-03). - TC-24-P-003: Result-capture p95 latency (NFR-24-04). - TC-24-P-004: LIMS-import p95 latency (NFR-24-05). - TC-24-P-005: Bound e-signature p95 latency (NFR-24-10). ### 16.5 Security tests - TC-24-S-001: Cross-tenant access rejected by RLS. - TC-24-S-002: Missing RBAC rejected. - TC-24-S-003: Missing Authority Profile rejected on regulated final action. - TC-24-S-004: Missing HITL rejected. - TC-24-S-005: Missing bound e-signature rejected. - TC-24-S-006: SQL injection against typed-schema route rejected. - TC-24-S-007: Audit-trail UPDATE / DELETE rejected at DB level. - TC-24-S-008: GenAI write to critical stability decision path rejected. - TC-24-S-009: PII redaction in logs verified. - TC-24-S-010: Context-gate filtering on detail reads enforced. --- ## 17. Validation Evidence ### 17.1 URS-24-VAL-001: Requirements traceability matrix Complete RTM mapping every URS-24 requirement (DEC-24-01.DEC-24-23, BR-24-01.BR-24-23, NFR-24-01.NFR-24-10, SoD-24-01.SoD-24-07, SEC-24-01.SEC-24-11) to test cases (TC-24-U-001.TC-24-U-020, TC-24-I-001.TC-24-I-015, TC-24-E-001.TC-24-E-006, TC-24-P-001.TC-24-P-005, TC-24-S-001.TC-24-S-010) and code modules (§15). ### 17.2 URS-24-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, Laboratory Head, Qualified Person Authority. ### 17.3 URS-24-VAL-003: Installation qualification (IQ) Migration application + RLS verification + route mount verification + frontend hook resolution + frontend route surface verification. ### 17.4 URS-24-VAL-004: Operational qualification (OQ) Happy-path execution of every test case with evidence captures. ### 17.5 URS-24-VAL-005: Performance qualification (PQ) NFR-24-01.NFR-24-10 verification. ### 17.6 URS-24-VAL-006: AI/ML governance evidence Per ARCH-AI-001: (a) MIRA read-only context integration; (b) static-deterministic-AI advisory surfaces (regression); (c) **GenAI/LLM prohibition in stability OOS / shelf-life / report-approval / closure decisions** verification — no LLM call from critical paths; (d) Annex 22 §7 + EU AI Act Annex III internal forward-looking control compliance evidence. ### 17.7 URS-24-VAL-007: Regulatory mapping evidence FDA 21 CFR Part 11 + 211 (§166, §137, §180), 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 Q1A(R2), Q1B, Q1C, Q1D, Q1E, Q5C, WHO TRS Annex 10, India CDSCO Schedule M / Schedule Y / NDCT 2019. ### 17.8 URS-24-VAL-008: Migration evidence gate Per §9.3. ### 17.9 URS-24-VAL-009: Signature manifest QA Head, RA Head, Validation Head, Manufacturing Head, Laboratory Head, Qualified Person Authority, Information Security Head, Site Quality Lead, Founder / Chairman & MD per §19. ### 17.10 URS-24-VAL-010: Post-launch periodic-review pack (a) stability metrics; (b) AI-quality (advisory acceptance rate); (c) audit-trail integrity; (d) reopen-event audit; (e) cross-tenant break-glass audit; (f) cross-module event integrity; (g) LIMS-import reconciliation summary; (h) ICH zone distribution; periodic review at quarterly cadence by QA Head + Manufacturing Head + Validation Head + Qualified Person Authority + Laboratory Head. --- ## 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 24. | --- ## 19. Document Approval | Role | Name | Signature | Date | |---|---|---|---| | Founder / Chairman & MD | Vimal | __________ | __________ | | QA Head | __________ | __________ | __________ | | RA Head | __________ | __________ | __________ | | Validation Head | __________ | __________ | __________ | | Manufacturing Head | __________ | __________ | __________ | | Laboratory Head | __________ | __________ | __________ | | Qualified Person Authority | __________ | __________ | __________ | | Information Security Head | __________ | __________ | __________ | | Site Quality Lead | __________ | __________ | __________ | --- ## 20. Cross-Module Event Contract | Event | Emitter | Consumer | Payload key fields | |---|---|---|---| | `stability_protocol_created` | Module 24 | URS-30 | `protocol_id`, `tenant_id`, `product_id`, `protocol_version` | | `stability_protocol_released_effective` | Module 24 | URS-30, URS-13 (audit) | `protocol_id`, `change_request_id`, `released_by`, `e_signature_id` | | `stability_protocol_superseded` | Module 24 | URS-30 | `prior_protocol_id`, `new_protocol_id` | | `stability_study_created` | Module 24 | URS-30 | `study_id`, `tenant_id`, `protocol_id`, `site_id`, `product_id`, `batch_id`, `created_by` | | `stability_study_status_changed` | Module 24 | URS-30 | `study_id`, `from_status`, `to_status`, `changed_by`, `reason_for_change` | | `stability_sample_added` | Module 24 | URS-30 | `study_id`, `sample_id`, `condition_id`, `placed_by` | | `stability_time_point_added` | Module 24 | URS-30 | `study_id`, `time_point_id`, `time_point_months`, `scheduled_date` | | `stability_result_recorded` | Module 24 | URS-30 | `result_id`, `sample_id`, `time_point_id`, `test_id`, `in_spec`, `recorded_by` | | `stability_oos_oot_linked` | Module 24 | **URS-15 (OOS — primary consumer)**, URS-30 | `result_id`, `oos_oot_id` (URS-15), `severity`, `source_type = stability_result` | | `stability_report_generated` | Module 24 | URS-30 | `report_id`, `study_id`, `generated_by` | | `stability_report_approved` | Module 24 | URS-30, URS-26 (APQR) | `report_id`, `approved_by`, `e_signature_id` | | `shelf_life_claim_approved` | Module 24 | **URS-23 (Batch Records — primary consumer for release-decision input)**, URS-30, URS-34 (GDP), URS-26 (APQR), URS-13 (audit) | `claim_id`, `claimed_shelf_life_months`, `qp_approved_by`, `ra_approved_by`, `change_request_id`, `qp_e_signature_id`, `ra_e_signature_id` | | `stability_commitment_created` | Module 24 | URS-30 | `commitment_id`, `study_id`, `commitment_type`, `due_date`, `created_by` | | `stability_commitment_status_changed` | Module 24 | URS-30, URS-18 (where linked CAPA) | `commitment_id`, `from_status`, `to_status`, `changed_by` | | `stability_study_locked` | Module 24 | URS-30, URS-26 (APQR) | `study_id`, `locked_by`, `lock_e_signature_id` | | `stability_study_reopened` | Module 24 | URS-30, URS-21 (governed-reopen audit) | `study_id`, `reopened_by`, `executive_co_signer`, `qp_co_signer`, `reopen_reason` | | `stability_finding_created` | Module 24 | **URS-21 (Findings — primary consumer)**, URS-30 | `study_id`, `finding_id` (URS-21), `severity`, `finding_type` | | `stability_deviation_created` | Module 24 | **URS-16 (Deviations — primary consumer)**, URS-30 | `study_id`, `deviation_id` (URS-16), `severity` | | `stability_failure_capa_linked` | Module 24 | **URS-18 (CAPA — primary consumer)**, URS-30 | `study_id`, `capa_id`, `linked_by`, `source_type = stability_failure` | | `stability_risk_created` | Module 24 | **URS-19 (Risk — primary consumer)**, URS-30 | `study_id`, `risk_id` (URS-19), `risk_pattern_type` | --- ## 21. References - ARCH-AI-001 — AI Optionality and Manual Continuity (binding architecture) - VRX-SPEC-URS-024-Stability-Management.md (Module specification) - URS-01.URS-23, URS-25.URS-35 (cross-module contracts) - FDA 21 CFR Part 11 - FDA 21 CFR Part 211 §211.166 / §211.137 / §211.180 - EU GMP Annex 11 (Computerised Systems) - 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 — Custom-application validation lifecycle - ICH Q1A(R2) — Stability Testing of New Drug Substances and Products - ICH Q1B — Photostability - ICH Q1C — New Dosage Forms - ICH Q1D — Bracketing and Matrixing - ICH Q1E — Evaluation of Stability Data - ICH Q5C — Biotech Stability - WHO TRS No. 953 Annex 2 - WHO TRS No. 1010 Annex 10 — Zone IVb Hot/Humid Climates - India CDSCO Schedule M (Revised) §16 - India CDSCO Schedule Y / NDCT 2019 §27 --- **END OF VRX-URS-24 — STABILITY MANAGEMENT — VERSION 1.0**