# Verixa — User Requirements Specification # Module 23: Batch Records & Manufacturing Execution | Field | Value | |---|---| | Document ID | VRX-URS-23 | | Version | 1.0 | | Status | Final — ready for QA, Validation, Regulatory Affairs, Information Security, Manufacturing Head, Site Quality Lead, Qualified Person (QP) 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-23-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 `batch`, expected API mounts `/api/v1/batch/*` (canonical), expected supporting modules `audit-log`, `context-filter`, `authority-check`, `electronic_signatures`, `hitl`, `documents`, `expected event-bus emission for `mbr_created`, `mbr_released_effective`, `mbr_superseded`, `batch_record_created`, `batch_record_status_changed`, `batch_step_executed`, `ipc_recorded`, `yield_recorded`, `genealogy_linked`, `release_submitted`, `qa_review_completed`, `release_approved`, `release_rejected`, `batch_record_locked`, `batch_record_reopened`, expected MIRA context integration through `useMiraRecord('batch_record', id)` and `useMiraRecord('master_batch_record', id)` mappings, expected findings-source emission consumed by URS-21 (batch deviation observations and batch quality findings), expected CAPA-source emission consumed by URS-18 (batch deviation source type per URS-18 declared source set), expected deviation-source emission consumed by URS-16 (in-process exceptions and yield deviations), expected risk-source emission consumed by URS-19 (batch-precipitated risk records), expected change-control linkage to URS-13 for MBR version changes and effective-state release, expected Authority Profile + HITL + e-signature integration through the `authority` and `hitl` subsystems for non-bypassable MBR release, batch closure, QA review, and final release, expected platform_admin / super_admin support / break-glass only paths for cross-tenant batch coordination. 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. AI-assisted batch surfaces (AI batch quality prediction, AI release recommendation, MIRA record context / MIRA batch copilot, AI deviation-to-batch impact prediction, AI yield-trend analysis) 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 batch record execution, review, disposition, and release path; batch record creation, step execution, exception handling, reviewer review, QA disposition, and release shall be executable when AI services are disabled, degraded, or overridden by the reviewer or QA releaser. **No AI service shall be the sole path to finalize batch disposition or release; the Qualified Person or delegated QA releaser with documented authority shall be the sole executor of the release signing ceremony.** This module binds ARCH-AI-001 AC-1, AC-2, AC-3, AC-4, AC-6, 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, **only static deterministic AI** is permitted in batch quality prediction; **generative AI / LLMs are PROHIBITED in critical GMP decisions**, specifically in batch-disposition decisions, batch-release decisions, OOS classification (which routes to URS-15), deviation classification (which routes to URS-16), and CAPA disposition (which routes to URS-18). Static deterministic AI may surface similar prior batches, historical yield trends, and prior-deviation patterns by product / step as advisory help; the Qualified Person's signed release ceremony 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 Master Batch Record (MBR) controlled-template register, the MBR lifecycle state machine (`draft → under_review → effective → superseded → archived` with immutable historical versions per DEC-23-06), the Batch Record (BR) execution-record register, the BR lifecycle state machine (`created → in_progress → execution_complete → under_qa_review → pending_release → released | rejected → locked` with reopen as a governed transition event from `locked → in_progress` per DEC-23-22 + SoD-23-06 that appends a new execution-iteration row and does not mutate or erase the prior locked evidence), the controlled MBR-step and MBR-parameter substructure with version-bound execution evidence, the In-Process Check (IPC) lifecycle with parameter-ownership validation per DEC-23-09, the batch-yield record lifecycle, the batch-genealogy linkage with source/target ownership validation, self-link prevention, duplicate-link prevention, and circular-traceability prevention per DEC-23-10, the release-record lifecycle with QA-review and final-release as **distinct controlled steps with distinct attributable actors** per DEC-23-13, the bound e-signature persistence on QA-review submission and final release via the `electronic_signatures` substrate per DEC-23-12, the synchronized batch-header release-disposition fields with the release-record per DEC-23-14, the multi-dimensional context capture (`tenant_id` mandatory, `site_id` mandatory at MBR and BR level —, `study_id` optional, `product_id` mandatory, `batch_id` mandatory at BR level), the canonical API contract `/api/v1/batch/*`, the typed schema validation across every route with shared-schema/migration-contract alignment, the controlled batch-record creation flow with frontend route alignment, the MBR detail read model exposing the full controlled template including steps and parameters, the controlled batch-record status transitions with terminal-state patch bypass prevention, the batch-entry MBR-step ownership validation per DEC-23-09, the genealogy validation per DEC-23-10, the release-submission completeness check per DEC-23-11, the post-locked record immutability across the batch record header and linked release record, the controlled reopen workflow with executive authority co-sign and Qualified Person co-sign per DEC-23-22, the canonical findings-source emission to URS-21 for batch quality findings per DEC-23-15, the canonical CAPA-source emission to URS-18 with `batch_deviation` source type per DEC-23-16, the canonical deviation-source emission to URS-16 for in-process exceptions and yield deviations per DEC-23-17, the canonical risk-source emission to URS-19 for batch-precipitated risk records per DEC-23-18, the change-control linkage to URS-13 for MBR effective-state release per DEC-23-19, the MIRA copilot read-only context integration on batch records, and the per-jurisdictional regulatory expectations under FDA 21 CFR Part 11, FDA 21 CFR Part 211 §211.180 (Records and Reports), §211.186 (Master Production and Control Records), §211.188 (Batch Production and Control Records), §211.192 (Production Record Review), §211.194 (Laboratory Records), §211.165 (Testing and Release for Distribution), EU GMP Annex 11, EU GMP Annex 22 Draft 2025 §7 (HITL for AI disposition; prohibition of GenAI in critical GMP decisions — 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 Q7 (GMP for APIs), ICH Q9 (Quality Risk Management), ICH Q10 §3.2.1 / §3.2.2 (Process Performance and Product Quality Monitoring), and India CDSCO Schedule M (Revised) §8 / §9 (Master Formula Records and Batch Manufacturing Records) and Schedule M-III §3 / §6 for medical device manufacture, subject to a future jurisdiction-specific legal assessment for Verixa's exact CDSCO obligations. | | Date of Issue | 2026-05-07 | | Module Owner (Engineering) | Manufacturing / Batch Squad | | Module Owner (Quality Validation) | CSV / CSA Lead — Manufacturing | | Module Owner (Compliance) | Quality Assurance, Manufacturing, Regulatory Affairs, Qualified Person Authority | | Approving Authority | Founder / Chairman & MD; QA Head; Manufacturing Head; Validation Head; RA Head; Information Security Head; Qualified Person (QP) Authority; Site Quality Lead | --- ## 0. Document Framing ### 0.1 Purpose of this document This URS defines the target expected state for Verixa's Batch Records & Manufacturing Execution module (Module 23). It is the binding contract between product, engineering, quality validation, regulatory affairs, manufacturing, the Qualified Person authority, distribution, laboratory operations, information security, and the executive authority for the design, implementation, validation, release, and on-going periodic review of the regulated batch-execution substrate: the canonical Master Batch Record (MBR) controlled-template register; the MBR lifecycle state machine (`draft → under_review → effective → superseded → archived` with immutable historical versions per DEC-23-06); the MBR-step and MBR-parameter substructure with version-bound execution evidence; the Batch Record (BR) execution-record register; the BR lifecycle state machine (`created → in_progress → execution_complete → under_qa_review → pending_release → released | rejected → locked`; reopen as a governed transition event from `locked → in_progress` per executive authority co-sign + Qualified Person co-sign + reason — DEC-23-22 + SoD-23-06 — that appends a new execution-iteration row without mutating or erasing the prior locked evidence); the In-Process Check (IPC) lifecycle with parameter-ownership validation per DEC-23-09; the batch-yield record lifecycle; the batch-genealogy linkage with source/target ownership validation, self-link prevention, duplicate-link prevention, and circular-traceability prevention per DEC-23-10; the release-record lifecycle with **QA review and final release as distinct controlled steps with distinct attributable actors** per DEC-23-13; the bound e-signature persistence on QA-review submission and final release via the `electronic_signatures` substrate per DEC-23-12; the synchronized batch-header release-disposition fields with the release-record per DEC-23-14; the multi-dimensional context capture (`tenant_id`, `site_id` mandatory —, `study_id` optional, `product_id` mandatory, `batch_id` mandatory at BR level); the canonical API contract `/api/v1/batch/*`; the typed schema validation across every route with shared-schema / migration-contract alignment; the controlled batch-record creation flow with frontend route alignment; the MBR detail read model exposing the full controlled template including steps and parameters; the controlled batch-record status transitions with terminal-state patch-bypass prevention; the batch-entry MBR-step ownership validation per DEC-23-09; the genealogy validation per DEC-23-10; the release-submission completeness check per DEC-23-11; the post-locked record immutability; the controlled reopen workflow with executive authority co-sign and Qualified Person co-sign per DEC-23-22; the canonical findings-source emission to URS-21 for batch quality findings per DEC-23-15; the canonical CAPA-source emission to URS-18 with `batch_deviation` source type per DEC-23-16; the canonical deviation-source emission to URS-16 for in-process exceptions and yield deviations per DEC-23-17; the canonical risk-source emission to URS-19 for batch-precipitated risk records per DEC-23-18; the change-control linkage to URS-13 for MBR effective-state release per DEC-23-19; the MIRA copilot read-only context integration through `useMiraRecord(.)` mappings, with no MIRA write paths and **no LLM/GenAI in critical GMP decisions** under the internal Annex 22 §7 control; the audit trail coverage with reason-for-change discipline; and the per-jurisdictional regulatory expectations. Compliance with this URS is mandatory. ### 0.2 Audience Engineering, QA, RA, Manufacturing, Qualified Person Authority, Distribution, Laboratory Operations, Validation, Information Security, executive authority, the platform's Implementation team, internal and external auditors, and inspectors from regulatory bodies (FDA, EMA, MHRA, Health Canada, CDSCO, PIC/S, PMDA). The plain-language primer (§0.4) and worked examples (§3.5) make Module 23 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 batch-record mutation - **URS-02** RBAC & Permissions — the `batch:*`, `batch:mbr:*`, `batch:execution:*`, `batch:ipc:*`, `batch:yield:*`, `batch:genealogy:*`, `batch:qa_review:*`, `batch:release:*` permission set - **URS-03** Context Gate & Approval Scope — context-gate enforcement for batch scope dimensions - **URS-04** Workflow / HITL / E-Signature / Approval Authority — Controlled Approval Modal contract for MBR release / batch closure / QA review submission / final release / release rejection / reopen - **URS-05** Authority Profile / Delegation / SoD — Authority Profiles consumed (`mbr_author_authority`, `mbr_review_authority`, `mbr_release_authority`, `batch_executor_authority`, `qa_review_authority`, `qualified_person_authority`, `final_quality_approver`, `executive_authority`, `controlled_content_approver`) - **URS-06** Audit Trail / Hash Chain / Tamper-Evident — append-only audit substrate - **URS-07** Study Management — optional study-scope dimension consumed - **URS-08** Tenant Management Lifecycle — tenant context for batch records - **URS-09** Site / Facility Management — mandatory site-scope dimension consumed at MBR and BR level - **URS-10** Product / SKU / Drug Master Data — mandatory product-scope dimension at MBR level - **URS-11** Supplier Management — material supplier linkage for batch genealogy - **URS-12** Document Control / SOP — affected-document linkage for MBR; SOP citation linkage on MBR steps - **URS-13** Change Control — MBR effective-state release linkage; MBR revision linkage per DEC-23-19 - **URS-14** Complaints — batch-related complaint trend consumer - **URS-15** OOS / OOT — laboratory-test-out-of-spec linkage to batch-record release decision - **URS-16** Deviations — primary downstream consumer for in-process exceptions and yield deviations per DEC-23-17 - **URS-17** RCA — RCA records as release-decision input where root-cause investigations are pending - **URS-18** CAPA — primary downstream consumer for batch-deviation CAPA via `batch_deviation_capa_linked` event per DEC-23-16 - **URS-19** Risk Assessment — batch-precipitated risk records per DEC-23-18; risk-status input to release decision - **URS-20** Reviews — batch-record review consumer - **URS-21** Findings — primary downstream consumer for batch quality findings per DEC-23-15 - **URS-22** Inspection Mgmt — batch-record evidence retrieval source for inspections per URS-22 BR-22-22 - **URS-24** Stability — stability-record linkage to batch-record release - **URS-25** Environmental Monitoring — EM-record linkage to batch-record context - **URS-26** APQR — periodic batch consumer - **URS-27** Regulatory Intelligence — predicate-rule citation source for MBR step regulatory references - **URS-28** Training — training-evidence consumer for batch executors - **URS-30** Notifications — notification delivery for batch lifecycle events - **URS-31** DQG — data-quality gate evidence for batch-record completeness - **URS-32** MIRA AI — read-only MIRA copilot context integration on batch records; **no LLM/GenAI in critical GMP decisions** per Annex 22 §7 internal control - **URS-33** GMP Manufacturing — primary GMP module integration - **URS-34** GDP Distribution — released-batch distribution linkage - **URS-35** Infrastructure / Backup-Restore — operational continuity ### 0.4 Plain-language primer In a regulated pharmaceutical operation, **a batch record is the documented evidence that a single batch was manufactured according to the Master Batch Record (MBR) and meets all release criteria**. The Master Batch Record is the controlled-template document defining the manufacturing process for a product (per FDA 21 CFR §211.186); the Batch Record (per FDA 21 CFR §211.188) is the executed evidence for a specific batch run, attributing every step, every in-process check (IPC), every yield observation, every deviation, and every reviewer/QA-reviewer/Qualified-Person signature. Each batch record requires structured handling under **21 CFR Part 11, 21 CFR §211.186 / §211.188 / §211.192 / §211.194 / §211.165, EU GMP Annex 11, MHRA Data Integrity Guidance, ICH Q7 (for APIs), and ICH Q10 §3.2.1 / §3.2.2 (Process Performance and Product Quality Monitoring)**: (1) author and release the MBR through controlled change control to `effective` state with `mbr_release_authority` + e-signature, (2) create a batch record bound to a single effective MBR version, (3) execute steps with attributable executors and IPC records bound to the correct MBR step / parameter, (4) record yields and material genealogy, (5) capture exceptions and emit deviation records to URS-16, (6) reviewer reviews execution evidence, (7) QA reviewer signs the QA-review record (distinct step from final release per DEC-23-13), (8) Qualified Person executes the final release signing ceremony with bound e-signature, (9) lock the batch record on release. Module 23 is the target specification for this regulated workflow. The most common mistake in regulated batch handling is **collapsing QA review and final release into one user action**. The regulator's tell-tale at inspection is a single signature representing both review and disposition. Module 23 enforces the pathway: QA review and final release are distinct controlled steps with distinct attributable actors per DEC-23-13; each carries a bound e-signature persisted via the `electronic_signatures` substrate per DEC-23-12. The second most common mistake is **bypass of release workflow via direct PATCH on batch_record.status to `released` or `rejected`**. Module 23 enforces the pathway: terminal-state patch-bypass is prevented per DEC-23-08; release transitions can only occur through the controlled QA-review and final-release ceremonies. The **AI-assistance** dimension is critical. Static deterministic AI (deterministic models — same input → same output always) may surface "similar prior batches by yield / IPC pattern", "historical OOS frequency by step", or "prior-deviation patterns by product / step" as advisory help; this is permitted under the internal Annex 22 §7 control. **Generative AI (LLMs / MIRA copilot) is PROHIBITED in batch-disposition decisions, batch-release decisions, OOS classification, deviation classification, and CAPA disposition** under the internal Annex 22 §7 + EU AI Act Annex III internal forward-looking control. MIRA copilot may read closed batch records for read-only context via `useMiraRecord('batch_record', id)` and `useMiraRecord('master_batch_record', id)` but no AI service writes to `batch_records` tables, and no AI service finalizes batch disposition or release. The Qualified Person's signed release ceremony is the system of record, attributable to the human QP. 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-23-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 | |---|---| | Master Batch Record (MBR) | The controlled-template document defining the manufacturing process for a product (per FDA 21 CFR §211.186); versioned with controlled lifecycle (`draft → under_review → effective → superseded → archived`); released to `effective` state with `mbr_release_authority` + e-signature; immutable once superseded. | | Batch Record (BR) | The executed evidence for a specific batch run (per FDA 21 CFR §211.188); attributable execution evidence bound to a single effective MBR version; lifecycle `created → in_progress → execution_complete → under_qa_review → pending_release → released | rejected → locked`. | | MBR step | A single step of the MBR controlled template; attributable execution captured in batch-record entries; version-bound; SOP citation linkage to URS-12. | | MBR parameter | A controlled in-process parameter on an MBR step; attributable IPC record bound to this parameter; version-bound. | | In-Process Check (IPC) | An in-process measurement bound to a specific MBR-parameter on a specific MBR-step within a single batch execution; per DEC-23-09 the IPC's `mbr_parameter_id` MUST belong to the batch's `mbr_id`. | | Batch yield | The batch-output yield record (theoretical / actual / percentage); recorded per batch step and at batch close. | | Batch genealogy | Material-flow linkage between batches (parent batch → child batch); per DEC-23-10 source/target ownership validated, self-link prevented, duplicate-link prevented, circular-traceability prevented. | | QA review | The first regulated final action: the QA reviewer reviews execution evidence and signs the QA-review record with bound e-signature; distinct controlled step from final release per DEC-23-13. | | Final release | The second regulated final action: the Qualified Person (QP) or delegated QA releaser executes the release signing ceremony with bound e-signature; **the only path to disposition `released` or `rejected`**. | | Qualified Person (QP) | The Qualified Person Authority Profile holder responsible for batch release per EU GMP Article 51 (or the FDA equivalent QP / Responsible Person designated under tenant policy). | | 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 execution-iteration row without mutating prior locked evidence per DEC-23-22. | | Reviewer independence | The Segregation-of-Duties enforcement that the batch executor MUST NOT be the QA reviewer; the QA reviewer MUST NOT be the final releaser unless tenant policy explicitly permits same-person QA-review-and-release with documented authority and audit-logged justification. | | ARCH-AI-001 | Platform architecture binding requiring manual continuity for every AI surface (AC-1.AC-7). | | Annex 22 | EU GMP Annex 22 (Draft 2025) §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, only static deterministic AI is permitted in batch quality prediction; generative AI / LLMs are PROHIBITED in batch-disposition decisions, batch-release decisions, OOS classification, deviation classification, and CAPA disposition. Binding predicate-rule obligations remain those listed in §14. | | MIRA | The platform's read-only AI copilot service; for Module 23 MIRA is read-only context on batch records via `useMiraRecord(.)` mappings; no MIRA write paths; no LLM/GenAI in critical GMP decisions. | ### 0.7 Module-23 architectural picture ```mermaid flowchart TD AUTH[MBR Author / Reviewer / Releaser] --> MBR[/Master Batch Records — controlled template/] MBR -- effective version --> BR[/Batch Records — executed evidence/] EX[Batch Executor] --> BR BR --> ENT[Batch Record Entries — per MBR step] BR --> IPC[In-Process Checks — per MBR parameter] BR --> YLD[Batch Yields — per step + close] BR --> GEN[Batch Genealogy — parent/child material flow] BR --> EXC[Exceptions] EXC --> M16[URS-16 Deviations] BR --> QAR[QA Review — bound e-sign + SoD-23-04] QAR --> REL[Final Release — Qualified Person bound e-sign + SoD-23-05] REL --> LOCK[Locked] LOCK -. governed reopen + executive + QP co-sign.-> BR M13[URS-13 Change Control] --> MBR (release to effective) M12[URS-12 Document Control] --> MBR (SOP citation) M27[URS-27 Regulatory Intelligence] --> MBR (predicate-rule citation) M11[URS-11 Suppliers] --> GEN (material supplier linkage) M15[URS-15 OOS] --> REL (release-decision input) M16 --> M18[URS-18 CAPA] (batch_deviation_capa_linked) M19[URS-19 Risk Assessment] <-- BR (batch-precipitated risk) M21[URS-21 Findings] <-- BR (batch quality finding) M22[URS-22 Inspection] -- evidence retrieval --> BR M24[URS-24 Stability] --> REL (stability evidence input) M25[URS-25 EM] --> BR (context input) M26[URS-26 APQR] <-- BR (periodic consumer) M30[URS-30 Notifications] <-- BR M32[URS-32 MIRA AI] <-- BR (read-only context — no GenAI in critical decisions) M33[URS-33 GMP] -- bound to --> BR M34[URS-34 GDP] <-- REL (released-batch distribution) M31[URS-31 DQG] --> BR (completeness) ``` The platform shall implement: a controlled MBR register with version-immutability after `effective` release; a batch-record register bound to a single effective MBR version with full attributable execution; IPC records bound to MBR-parameter ownership per DEC-23-09; genealogy validation per DEC-23-10; a release-record lifecycle with QA review and final release as **distinct controlled steps with distinct attributable actors** per DEC-23-13; bound e-signature persistence on QA-review submission and final release per DEC-23-12; synchronized batch-header release-disposition fields per DEC-23-14; mandatory `site_id` at MBR and BR level per DEC-23-04; mandatory `product_id` at MBR level per DEC-23-05; canonical API contract `/api/v1/batch/*` per DEC-23-01; typed schema validation across every route per DEC-23-03; controlled batch-record creation flow with frontend route alignment per DEC-23-02; MBR detail read model exposing the full controlled template per DEC-23-07; terminal-state patch-bypass prevention per DEC-23-08; batch-entry MBR-step ownership validation per DEC-23-09; release-submission completeness check per DEC-23-11; post-locked record immutability; governed reopen with executive + QP co-sign per DEC-23-22; canonical findings-source emission to URS-21 per DEC-23-15; canonical CAPA-source emission to URS-18 with `batch_deviation` source type per DEC-23-16; canonical deviation-source emission to URS-16 per DEC-23-17; canonical risk-source emission to URS-19 per DEC-23-18; change-control linkage to URS-13 for MBR effective-state release per DEC-23-19; MIRA copilot read-only context integration with no GenAI in critical GMP 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-23-01 / VAL-008 | Mirrors every other Module; URS approval is separate from validation evidence. | | "No Module 23 internal decisions outstanding" | §11.6 | Captured in locked decisions DEC-23-01..DEC-23-23 (§3.2). | | `platform_admin` / `super_admin` support / break-glass only | DEC-23-20 / SoD-23-07 | Operating-tenant batch ownership is the regulated path; cross-tenant coordination is support-only. | | Target implementation binding language | Module bindings | URS specifies expected implementation; repository evidence is verified at validation. | | AI overclaim posture as **internal forward-looking governance** with **GenAI prohibition in critical GMP decisions** | Architecture Bindings | EU GMP Annex 22 Draft 2025 §7 + EU AI Act Annex III treated as internal controls; not enacted predicate rules; jurisdiction-specific legal assessment deferred. Static deterministic AI permitted; GenAI / LLMs prohibited in batch disposition / release / OOS / deviation / CAPA decisions. | | Enumerated error codes (no overload of generic 4xx) | §6.7 | Stable machine-readable error contract for client + auditor reproducibility. | | JSON multi-signature evidence as **derived snapshot** | §6.6 | The `electronic_signatures` substrate is the system of record; audit-trail JSON column is a derived snapshot. | | India CDSCO §14 row | §14 | India CDSCO Schedule M (Revised) §8/§9 + Schedule M-III §3/§6 batch-manufacturing-record expectations captured for India operations subject to a future jurisdiction-specific legal assessment. | | Version 1.0 posture | Header | First binding version; subsequent revisions follow controlled change control. | | Canonical API mount `/api/v1/batch/*` | DEC-23-01 / BAT-DR-002 | Canonical mount; route comments aligned to canonical mount. | | Frontend route alignment for batch creation flow | DEC-23-02 / BAT-DR-003 | `/batch/new` route created and wired; CTA from `BatchList.tsx` resolves. | | `site_id` mandatory at MBR and BR level | DEC-23-04 / BAT-DR-004 / BAT-DR-005 | Schema/context-filter alignment. | | `product_id` mandatory at MBR level | DEC-23-05 / BAT-DR-005 | Master-data alignment with URS-10. | | Typed schema validation with shared-schema/migration alignment | DEC-23-03 / BAT-DR-005 | `study_id` nullability + `site_id` presence aligned across `batch.schema.ts`, migration 035, and `batch/service.ts`. | | MBR controlled-version lifecycle | DEC-23-06 / BAT-DR-006 | `draft → under_review → effective → superseded → archived`; immutable historical versions. | | MBR detail read model with full template | DEC-23-07 / BAT-DR-007 | `getMBR(.)` returns MBR + steps + parameters. | | Terminal-state patch-bypass prevention | DEC-23-08 / BAT-DR-008 | Direct PATCH cannot set `released` / `rejected` / `locked`. | | Batch-entry MBR-step ownership validation | DEC-23-09 / BAT-DR-009 | Step/parameter ownership verified before persistence. | | Genealogy validation | DEC-23-10 / BAT-DR-010 | Source/target ownership, self-link prevention, duplicate prevention, circular prevention. | | Release-submission completeness check | DEC-23-11 / BAT-DR-011 | All steps complete, all IPCs in spec or with deviation linkage, yields recorded, exceptions resolved or linked. | | Bound e-signature on QA review and final release | DEC-23-12 / BAT-DR-012 | True Part 11 e-signature record persisted via `electronic_signatures` substrate; `requiresEsign: true` on `withAuthority(.)` is necessary but insufficient. | | QA review and final release as distinct controlled steps with distinct actors | DEC-23-13 / BAT-DR-013 | SoD enforced; same-person fallback only with documented tenant policy + audit. | | Synchronized batch-header release-disposition fields | DEC-23-14 / BAT-DR-014 | `qa_reviewer_id`, `qa_review_date`, `approved_by`, `approval_date` synced from release record. | | Findings emission to URS-21 | DEC-23-15 | Batch quality findings emit `batch_quality_finding_created` to URS-21. | | CAPA emission to URS-18 | DEC-23-16 | Batch deviations emit `batch_deviation_capa_linked` with `batch_deviation` source type. | | Deviation emission to URS-16 | DEC-23-17 | In-process exceptions and yield deviations emit `batch_deviation_created` to URS-16. | | Risk emission to URS-19 | DEC-23-18 | Batch-precipitated risk records emit `batch_risk_created` to URS-19. | | Change-control linkage for MBR effective release | DEC-23-19 / BAT-DR-006 | `mbr_release_change_request_id` ties MBR `effective` release to a URS-13 change request. | | Reason-for-change requirement on material updates after draft | DEC-23-21 | Replaces silent updates on regulated records. | | Bound e-signature persistence on every regulated final action | DEC-23-12 / DEC-23-23 | MBR release / QA review / final release / batch lock / governed reopen — all carry bound e-signature. | | Governed reopen pattern (`locked → in_progress`) | DEC-23-22 / SoD-23-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 Master Batch Record (MBR) controlled-template register and lifecycle. - The MBR-step and MBR-parameter substructure. - The Batch Record (BR) execution-record register and lifecycle. - The In-Process Check (IPC) lifecycle with parameter-ownership validation. - The batch-yield record lifecycle. - The batch-genealogy linkage with full validation. - The release-record lifecycle with QA review and final release as distinct steps. - The bound e-signature persistence on every regulated final action. - The synchronized batch-header release-disposition fields. - The MIRA copilot read-only context integration (no GenAI in critical GMP 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 change-control linkage to URS-13 for MBR effective release. - The governed reopen workflow. - The audit-trail coverage with reason-for-change discipline. - The per-jurisdictional regulatory expectations. ### 1.2 Out-of-scope - The HITL decision substrate itself (URS-04). - The Authority Profile registry itself (URS-05). - The audit-trail substrate itself (URS-06). - The deviations register itself (URS-16) — this URS emits batch-deviation events; lifecycle is the URS-16 contract. - The CAPA register itself (URS-18) — this URS emits batch-deviation-CAPA-linkage events; CAPA closure is the URS-18 contract. - The findings register itself (URS-21) — this URS emits batch-quality-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 shop-floor execution interface integration (DCS / MES) — out of scope for v1.0; tracked as future-state under the GMP Manufacturing module URS-33. - Equipment / instrument calibration register integration — tracked under URS-33. --- ## 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), 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. - Batch executors, QA reviewers, and Qualified Person are trained, attributable users with documented authority. - AI-assisted batch surfaces are advisory only; the Qualified Person's signed release ceremony is the system of record. - The tenant operating jurisdiction(s) are configured and applicable predicate rules surface accordingly. ### 2.2 Dependencies - URS-01.URS-22, URS-24.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 `deviations` substrate (URS-16). - The `notifications` substrate (URS-30). ### 2.3 Constraints - The canonical API mount is `/api/v1/batch/*`. Route comments must reflect canonical mount. - The batch module is site-scoped at MBR and BR level; `site_id` is mandatory. - AI-assisted content is advisory-only; **no AI service finalizes batch disposition or release**. - Generative AI / LLMs are prohibited in batch-disposition / batch-release / OOS / deviation / CAPA disposition decision paths under the internal Annex 22 §7 + EU AI Act Annex III control. - Released / rejected / locked states cannot be set via direct PATCH. - Effective MBR versions are immutable; revisions create new version rows. --- ## 3. Closed Launch Decisions The following decisions are LOCKED for Module 23 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-23-01 | Two-step release path | Module 23 follows the same two-step release path as every other Module. | | DEC-23-02 | Frontend route alignment for batch creation | A real `/batch/new` route is created in the frontend with the controlled batch-record creation flow. | | DEC-23-03 | Typed schema validation across every route | Every batch route validates request params, query strings, and bodies through explicit typed schemas before service execution. Shared `batch.schema.ts` is aligned with migration 035. | | DEC-23-04 | `site_id` mandatory at MBR and BR level | `site_id` is added as a NOT NULL FK on `master_batch_records` and `batch_records`; `MODULE_CONTEXT_CONFIG.batch` is aligned to the persisted schema. | | DEC-23-05 | `product_id` mandatory at MBR level | `product_id` is mandatory at MBR; aligned with URS-10 master data; child batch-record `product_id` inherited and persisted. | | DEC-23-06 | MBR controlled-version lifecycle | MBR lifecycle is `draft → under_review → effective → superseded → archived`; release to `effective` requires `mbr_release_authority` + HITL + e-signature + URS-13 change-request linkage; revisions create new version rows; superseded versions are immutable. | | DEC-23-07 | MBR detail read model with full template | `getMBR(.)` returns the MBR + steps + parameters in a single read; detail page renders full controlled template. | | DEC-23-08 | Terminal-state patch-bypass prevention | The generic `PATCH /batch/:id` route cannot set `status` to `released` / `rejected` / `locked`; status transitions to terminal states occur only through controlled QA-review and final-release ceremonies. | | DEC-23-09 | Batch-entry MBR-step / MBR-parameter ownership validation | When creating a `batch_record_entry`, the `mbr_step_id` MUST belong to the batch's `mbr_id`; when creating an `ipc_check`, the `mbr_parameter_id` MUST belong to a step that belongs to the batch's `mbr_id`; ownership validated at service layer before persistence. | | DEC-23-10 | Genealogy validation | Genealogy links validated for tenant ownership (source + target same tenant), self-link prevention (source ≠ target), duplicate-link prevention `(tenant_id, parent_batch_id, child_batch_id)` unique, and circular-traceability prevention (cycle detection on add). | | DEC-23-11 | Release-submission completeness check | Release submission requires all MBR steps with `required = true` to have at least one batch-record-entry, all IPC parameters with `required = true` to have at least one IPC value (in-spec OR with deviation linkage), batch yield recorded, all exceptions either resolved or linked to a URS-16 deviation, and no open unlinked exceptions. | | DEC-23-12 | Bound e-signature on QA review and final release | True Part 11 e-signature record persisted via `electronic_signatures` substrate on QA-review submission and on final release; `requiresEsign: true` on `withAuthority(.)` alone is insufficient; the service writes `electronic_signatures`, `hitl_decisions`, and `workflow_step_signatures` evidence. | | DEC-23-13 | QA review and final release as distinct controlled steps with distinct actors | QA review and final release are split into two controlled steps. Default tenant policy: the QA reviewer MUST NOT be the final releaser; same-person QA-review-and-release is permitted only with documented tenant authority configuration and audit-logged justification. | | DEC-23-14 | Synchronized batch-header release-disposition fields | On QA-review-completed: `batch_records.qa_reviewer_id`, `qa_review_date` synced from release record; on final-release-approved: `batch_records.approved_by`, `approval_date`, `status` synced; on final-release-rejected: `batch_records.rejected_by`, `rejection_date`, `status = rejected` synced; sync occurs in the same transaction as the release-record write. | | DEC-23-15 | Batch quality findings emission to URS-21 | Batch quality findings (e.g., yield variance findings, IPC trend findings, genealogy traceability gaps) emit `batch_quality_finding_created` event to URS-21 with `inspection_observation`-equivalent source type or `batch_quality` source type; URS-21 standalone finding carries the batch-record reference and severity. | | DEC-23-16 | Batch deviations CAPA emission to URS-18 | Batch deviations escalated to CAPA emit `batch_deviation_capa_linked` event consumed by URS-18 (`batch_deviation` source type per URS-18 declared source set). | | DEC-23-17 | Batch deviations emission to URS-16 | In-process exceptions and yield deviations emit `batch_deviation_created` event consumed by URS-16; the URS-16 deviation carries the batch-record reference and IPC-record / yield-record reference. | | DEC-23-18 | Batch risk emission to URS-19 | Batch-precipitated risk records (e.g., recurring deviation patterns, supplier-material risk patterns) emit `batch_risk_created` event consumed by URS-19. | | DEC-23-19 | MBR effective-release change-control linkage | MBR transitions `under_review → effective` require linkage to a URS-13 change request via `mbr_release_change_request_id`; subsequent revisions also require change-request linkage. | | DEC-23-20 | platform_admin / super_admin | `platform_admin` / `super_admin` are support / break-glass only paths for cross-tenant batch coordination per DEC-23-20; logged with reason. | | DEC-23-21 | Reason-for-change on material updates | Material updates on batch records or MBRs after the record leaves draft require structured reason-for-change captured in audit. | | DEC-23-22 | Batch-record reopen as governed transition | Batch-record `locked → in_progress` is a governed transition requiring `executive_authority` co-sign AND `qualified_person_authority` co-sign + documented reason; appends a new execution-iteration row without mutating prior locked evidence (consistent with M14 / M16 / M17 / M18 / M19 / M20 / M21 / M22 reopen pattern but with the additional QP co-sign required for batch-record reopen given regulatory gravity). | | DEC-23-23 | Bound e-signature on MBR release / batch lock / governed reopen | Bound e-signature persistence on MBR release `under_review → effective`, on batch-record lock `released → locked` and `rejected → locked`, and on governed reopen `locked → in_progress`. | ### 3.2 Locked-decision rationale narrative The decisions above define the binding launch posture for Module 23 v1.0. The most consequential locked controls are: (a) DEC-23-04 / DEC-23-05 anchor the module at site + product mandatorily and make study_id optional, aligning `batch.schema.ts`, the typed DB layer, and the platform context filter to one canonical set; (b) DEC-23-08 removes `status` from the generic PATCH path entirely and requires controlled QA-review and final-release ceremonies (terminal-state transitions cannot bypass the lifecycle); (c) DEC-23-12 / DEC-23-13 require true Part 11 e-signature records persisted via `electronic_signatures` AND split QA review from final release as distinct controlled steps with distinct attributable actors; (d) DEC-23-14 requires synchronous update of `qa_reviewer_id` / `approved_by` / etc. inside the same transaction as the release-record write; (e) DEC-23-22 defines reopen as a governed append-only transition consistent with the Module-14 / -16 / -17 / -18 / -19 / -20 / -21 / -22 reopen pattern, with the additional Qualified Person co-sign required given the regulatory gravity of reopening a locked batch record. ### 3.3 Closed launch decisions: cross-link to items | Specification item ID | Specification item | Locked decision | |---|---|---| | BAT-DR-002 | Route comment vs canonical mount | DEC-23-01 | | BAT-DR-003 | `/batch/new` route missing | DEC-23-02 | | BAT-DR-004 | Context filter `site_id` vs schema | DEC-23-04 | | BAT-DR-005 | Migration/schema alignment requirement | DEC-23-03 / DEC-23-04 / DEC-23-05 | | BAT-DR-006 | MBR lifecycle missing | DEC-23-06 / DEC-23-19 | | BAT-DR-007 | MBR detail incomplete | DEC-23-07 | | BAT-DR-008 | Terminal-state patch bypass | DEC-23-08 | | BAT-DR-009 | Step/parameter ownership missing | DEC-23-09 | | BAT-DR-010 | Genealogy validation missing | DEC-23-10 | | BAT-DR-011 | Release submission under-controlled | DEC-23-11 | | BAT-DR-012 | E-signature not real | DEC-23-12 / DEC-23-23 | | BAT-DR-013 | QA review + release collapsed | DEC-23-13 | | BAT-DR-014 | Header sync missing | DEC-23-14 | | BAT-DR-015 | Backend 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 — Tablet batch manufacture under FDA cGMP.** The Manufacturing Head schedules a tablet batch (Product P-Tabs) for site SiteA. The MBR `MBR-PTabs-v3` is in `effective` state (released via URS-13 change request CC-2025-0042 with `mbr_release_authority` + e-signature). A batch executor creates `batch_record BR-PTabs-2026-08-12-001` bound to `MBR-PTabs-v3`; status `created`. Execution begins; status `in_progress`. For each MBR step, the executor records a `batch_record_entry` with `mbr_step_id` validated against `MBR-PTabs-v3` per DEC-23-09; for each MBR parameter, the executor records IPC values with `mbr_parameter_id` validated against the step ownership. Genealogy: an active-pharmaceutical-ingredient batch (parent `BR-API-2026-07-01-001`) is linked as parent of `BR-PTabs-2026-08-12-001`; per DEC-23-10 source/target ownership validated, self-link prevented, duplicate prevented, circular prevented. Yield recorded at end of step 8 (mixing) and at batch close. One IPC fails at step 6 (assay 98.2% vs spec 99.0–101.0%); the executor opens a deviation linked to URS-16; the deviation flows through URS-16 lifecycle and a CAPA is opened in URS-18 via `batch_deviation_capa_linked` per DEC-23-16. Status `execution_complete`. Reviewer reviews execution evidence and submits to QA; status `under_qa_review`. QA reviewer signs the QA-review record with bound e-signature per DEC-23-12; `batch_records.qa_reviewer_id` and `qa_review_date` synced per DEC-23-14; status `pending_release`. The Qualified Person reviews the QA-reviewed record and the linked URS-16 deviation + URS-18 CAPA; QP executes the final release signing ceremony with bound e-signature per DEC-23-12; `batch_records.approved_by` and `approval_date` synced per DEC-23-14; status `released`. After 24h the system automatically locks the batch record; status `locked`; bound e-signature on lock per DEC-23-23. The released batch flows to URS-34 GDP for distribution. **Worked example 2 — MBR revision through change control.** A process improvement reduces step 8 mixing time from 30 min to 25 min. The MBR author creates a revision draft `MBR-PTabs-v4` referencing `MBR-PTabs-v3` as supersedes; the revision is reviewed and a URS-13 change request CC-2026-0089 is opened. After change-control approval, `mbr_release_authority` releases `MBR-PTabs-v4` to `effective` per DEC-23-06 + DEC-23-19; `MBR-PTabs-v3` transitions to `superseded`; new batch records bind to `MBR-PTabs-v4`. In-flight batch records bound to `MBR-PTabs-v3` continue execution against v3 (the bound MBR version is immutable for an in-flight batch). **Worked example 3 — Governed reopen of a locked batch.** On `2027-02-15` a stability finding (URS-24) reveals that a previously released and locked batch `BR-PTabs-2026-08-12-001` may have an undeclared deviation. The Manufacturing Head initiates a reopen request; per DEC-23-22 + SoD-23-06, both `executive_authority` co-sign AND `qualified_person_authority` co-sign + documented reason are required. On both co-signs the batch record transitions `locked → in_progress` and a new execution-iteration row is appended; the prior locked evidence (release record, QA-review record, batch entries, IPC, yields, genealogy, exceptions) is NOT mutated or erased. The new iteration captures the additional investigation activity, which may end with a re-release (after re-QA-review and re-final-release ceremonies) or a recall. **Worked example 4 — Collapsed QA-and-release attempt rejected.** A QA reviewer attempts to submit the QA review and execute final release in a single ceremony. Per DEC-23-13 + SoD-23-04, the system rejects with `BAT_REVIEW_RELEASE_SOD_VIOLATION` unless tenant policy explicitly permits same-person QA-review-and-release with documented authority configuration; if same-person is permitted, the audit log captures the SoD-waiver justification and the action is audit-flagged for periodic review. --- ## 4. End-to-End User Journeys (28 launch journeys) | # | Journey | Actor | Pre-condition | Path | Post-condition | |---|---|---|---|---|---| | 1 | Author MBR draft | MBR Author | `batch:mbr:create`; `site_id`, `product_id` resolved | Create MBR `(site_id, product_id, version=1)` in `draft`; add steps; add parameters | MBR in `draft`; full template; audit entry | | 2 | Submit MBR for review | MBR Author | MBR `draft` complete | Transition `draft → under_review` | MBR `under_review`; audit entry | | 3 | Release MBR to effective | MBR Releaser | MBR `under_review`; URS-13 change request approved | HITL + bound e-sign; transition `under_review → effective`; supersede prior version | MBR `effective`; prior version `superseded`; audit entry; bound e-signature persisted; `mbr_released_effective` event emitted | | 4 | Revise effective MBR | MBR Author / Releaser | Effective MBR exists | New version row `draft`; on release supersedes prior version | New version `effective`; prior `superseded`; immutable historical | | 5 | Create batch record from effective MBR | Batch Executor | `batch:execution:create`; effective MBR exists | Create BR `(mbr_id, site_id, product_id, batch_id)` | BR `created`; `batch_record_created` event | | 6 | Start batch execution | Batch Executor | BR `created` | Transition `created → in_progress` | BR `in_progress`; audit entry | | 7 | Record batch-record entry | Batch Executor | BR `in_progress`; MBR step ownership valid | Add entry with validated `mbr_step_id` per DEC-23-09 | Entry persisted; audit entry; ownership invariant enforced | | 8 | Record IPC value | Batch Executor | BR `in_progress`; MBR parameter ownership valid | Add IPC with validated `mbr_parameter_id` per DEC-23-09 | IPC persisted; audit entry | | 9 | Record batch yield | Batch Executor | BR `in_progress` | Add yield record (theoretical / actual / pct) | Yield persisted; audit entry | | 10 | Add genealogy link | Batch Executor | BR `in_progress`; valid source batch | Add genealogy link per DEC-23-10 (ownership / self-link / duplicate / circular) | Link persisted; audit entry | | 11 | Open in-process exception | Batch Executor | IPC out of spec | Open exception linked to IPC; emit `batch_deviation_created` to URS-16 | Exception persisted; URS-16 deviation created; audit entry | | 12 | Escalate batch deviation to CAPA | URS-16 lifecycle | Deviation requires CAPA | Emit `batch_deviation_capa_linked` to URS-18 with `batch_deviation` source type | URS-18 CAPA created; linkage immutable | | 13 | Mark execution complete | Batch Executor | All required steps + IPCs complete | Transition `in_progress → execution_complete` | BR `execution_complete`; audit entry | | 14 | Submit batch for QA review | Reviewer | BR `execution_complete`; completeness check pass per DEC-23-11 | Transition `execution_complete → under_qa_review`; create release record `pending_review` | BR `under_qa_review`; release record `pending_review`; audit entry | | 15 | QA review with bound e-signature | QA Reviewer (SoD-distinct) | `qa_review_authority`; BR `under_qa_review` | HITL + bound e-sign per DEC-23-12; transition `under_qa_review → pending_release`; sync `batch_records.qa_reviewer_id`, `qa_review_date` per DEC-23-14 | BR `pending_release`; QA-review e-signature persisted; `qa_review_completed` event emitted | | 16 | Final release by Qualified Person | Qualified Person (SoD-distinct from QA reviewer per DEC-23-13) | `qualified_person_authority`; BR `pending_release` | HITL + bound e-sign per DEC-23-12; transition `pending_release → released`; sync `batch_records.approved_by`, `approval_date`, `status` per DEC-23-14 | BR `released`; release e-signature persisted; `release_approved` event emitted | | 17 | Final rejection by Qualified Person | Qualified Person | `qualified_person_authority`; BR `pending_release` | HITL + bound e-sign + rejection reason; transition `pending_release → rejected`; sync `batch_records.rejected_by`, `rejection_date`, `status` | BR `rejected`; release e-signature persisted; `release_rejected` event emitted | | 18 | Lock released batch | System (auto + bound e-sign) | BR `released` for ≥ 24h | Transition `released → locked` with bound e-sign per DEC-23-23 | BR `locked`; immutable; audit entry; `batch_record_locked` event emitted | | 19 | Lock rejected batch | System (auto + bound e-sign) | BR `rejected` for ≥ 24h | Transition `rejected → locked` with bound e-sign | BR `locked` (rejected disposition); immutable; audit entry | | 20 | Reject direct PATCH on terminal status | Batch Executor (attempted) | Generic PATCH attempt setting `status = released` | Reject with `BAT_TERMINAL_STATE_PATCH_FORBIDDEN` per DEC-23-08 | Operation rejected; no state change | | 21 | Reject collapsed QA-and-release | QA Reviewer (attempted) | Same-person QA review + final release without tenant SoD waiver | Reject with `BAT_REVIEW_RELEASE_SOD_VIOLATION` per DEC-23-13 | Operation rejected; SoD violation flagged | | 22 | Same-person QA-and-release with tenant SoD waiver | QA Reviewer (with documented waiver) | Tenant policy explicitly permits same-person; documented authority configuration | HITL + bound e-sign on QA-review and HITL + bound e-sign on final release with audit-logged SoD-waiver justification | Both signatures persisted; SoD-waiver audit entry; periodic review flagged | | 23 | Reopen locked batch (governed transition) | Manufacturing Head / Executive Authority + Qualified Person | BR `locked`; documented reason | Executive co-sign AND QP co-sign; transition `locked → in_progress`; append new iteration row per DEC-23-22 | BR `in_progress`; new iteration appended; prior locked evidence NOT mutated; bound e-signature on reopen; `batch_record_reopened` event emitted | | 24 | View MBR detail with full template | Reader | `batch:read` | GET MBR with steps + parameters per DEC-23-07 | Full template rendered | | 25 | Apply context filter on batch query | Reader | `batch:read`; site context active | Query filtered by `site_id` per DEC-23-04 | Site-scoped results; no invalid SQL | | 26 | Cross-tenant `platform_admin` break-glass | platform_admin | Break-glass scenario; documented reason | Cross-tenant batch coordination access; logged with reason | Break-glass action logged in platform support audit per DEC-23-20 | | 27 | Emit batch quality finding to URS-21 | System (event) | Batch quality finding triggered | Emit `batch_quality_finding_created` to URS-21 | URS-21 standalone finding created | | 28 | Emit batch-precipitated risk to URS-19 | System (event) | Batch risk pattern triggered | Emit `batch_risk_created` to URS-19 | URS-19 risk record created | --- ## 5. Front-end Requirements ### 5.1 Batch List The batch list (URS-23-FE-001) renders list of batch records with filters by status, MBR, site, product, date range; uses canonical `/batch/*` hooks; the `+ New Batch` CTA navigates to `/batch/new` (per DEC-23-02 / BAT-DR-003). ### 5.2 Batch Create Flow The batch create flow (URS-23-FE-002) renders the controlled batch-record creation form: select effective MBR, capture `site_id`, `product_id`, `batch_id`, planned quantities; validates against shared schema before submit; on submit transitions BR to `created`. ### 5.3 Batch Detail The batch detail page (URS-23-FE-003) renders the full batch record: header, status, linked MBR (with version), steps (with execution evidence), IPC records, yield records, genealogy, exceptions, QA-review record, release record. Status badges reflect controlled lifecycle. Action buttons render conditional on status and authority. ### 5.4 MBR Editor The MBR editor (URS-23-FE-004) supports MBR draft authoring with full step + parameter editor; release flow with HITL + e-signature gates linked to URS-13 change-request selection. ### 5.5 MBR Detail with Full Template The MBR detail view (URS-23-FE-005) renders full MBR template including steps and parameters per DEC-23-07. ### 5.6 IPC Recording The IPC recording form (URS-23-FE-006) supports IPC value entry against MBR parameters; client validates parameter ownership before submit; server re-validates per DEC-23-09. ### 5.7 Genealogy Editor The genealogy editor (URS-23-FE-007) supports parent/child batch linkage with client-side cycle prevention; server-side validation per DEC-23-10. ### 5.8 QA Review Console The QA review console (URS-23-FE-008) renders the QA-review-pending list and QA-review form; bound e-signature ceremony per DEC-23-12. ### 5.9 Final Release Console The final release console (URS-23-FE-009) renders the pending-release list and the Qualified Person release ceremony; bound e-signature per DEC-23-12; SoD-distinct from QA reviewer per DEC-23-13. ### 5.10 MIRA Copilot Integration MIRA copilot (URS-23-FE-010) is read-only context on batch records via `useMiraRecord('batch_record', id)` and `useMiraRecord('master_batch_record', id)`. **No MIRA write paths to batch tables; no LLM/GenAI in critical GMP decisions.** MIRA may surface advisory information (similar prior batches, historical IPC trends) labeled as advisory. ### 5.11 Accessibility WCAG 2.1 AA accessible: keyboard-navigable, screen-reader compatible, high-contrast theme support, focus indicators, semantic landmark structure. --- ## 6. Back-end Requirements ### 6.1 Module structure `packages/backend/src/modules/batch/` with `plugin.ts`, `routes.ts` (typed schemas — per DEC-23-03), `service.ts` (ownership validation + completeness check + true e-signature integration + header sync), `schemas.ts` (aligned with migration 035 per DEC-23-03 / DEC-23-04 / DEC-23-05), `events.ts` (event emission for `mbr_*`, `batch_record_*`, `batch_step_*`, `ipc_*`, `yield_*`, `genealogy_*`, `release_*`, `qa_review_*`, `batch_record_locked`, `batch_record_reopened`, `batch_quality_finding_created`, `batch_deviation_created`, `batch_deviation_capa_linked`, `batch_risk_created`). ### 6.2 Data model #### 6.2.1 `master_batch_records` Required columns include `id`, `tenant_id`, `site_id` (NOT NULL FK per DEC-23-04), `product_id` (NOT NULL FK per DEC-23-05), `study_id` (FK nullable per DEC-23-03), `mbr_code`, `title`, `version` (INTEGER NOT NULL), `effective_from`, `effective_to`, `supersedes_mbr_id` (self-FK nullable), `mbr_release_change_request_id` (FK to URS-13 per DEC-23-19), `approved_by`, `approved_at`, `e_signature_id` (FK), `status` (ENUM `draft` / `under_review` / `effective` / `superseded` / `archived` per DEC-23-06), `created_by`, `created_at`, `updated_by`, `updated_at`. Uniqueness `(tenant_id, site_id, product_id, mbr_code, version)`. RLS enabled. #### 6.2.2 `mbr_steps` `id`, `tenant_id`, `mbr_id` (FK), `step_order` (INTEGER), `step_text` (TEXT), `sop_citation_id` (FK to URS-12 documents nullable), `regulatory_citation_id` (FK to URS-27 nullable), `required` (BOOLEAN), audit columns. Immutable on `effective` MBRs. #### 6.2.3 `mbr_parameters` `id`, `tenant_id`, `mbr_step_id` (FK), `parameter_name`, `parameter_unit`, `spec_low`, `spec_high`, `required` (BOOLEAN), audit columns. Immutable on `effective` MBRs. #### 6.2.4 `batch_records` `id`, `tenant_id`, `site_id` (NOT NULL FK per DEC-23-04), `product_id` (NOT NULL FK), `study_id` (FK nullable), `mbr_id` (NOT NULL FK to effective MBR at time of create), `batch_id` (TEXT NOT NULL — tenant-scoped batch identifier), `planned_quantity`, `actual_quantity`, `status` (ENUM `created` / `in_progress` / `execution_complete` / `under_qa_review` / `pending_release` / `released` / `rejected` / `locked`), `qa_reviewer_id` (FK nullable — synced per DEC-23-14), `qa_review_date` (TIMESTAMPTZ nullable), `qa_review_e_signature_id` (FK nullable), `approved_by` (FK nullable — synced per DEC-23-14), `approval_date` (TIMESTAMPTZ nullable), `release_e_signature_id` (FK nullable), `rejected_by` (FK nullable), `rejection_date` (TIMESTAMPTZ nullable), `rejection_reason` (TEXT nullable), `locked_at` (TIMESTAMPTZ nullable), `locked_by` (FK nullable), `lock_e_signature_id` (FK nullable), `reopened_at` (TIMESTAMPTZ nullable), `reopened_by` (FK nullable), `reopen_executive_co_signer` (FK nullable per DEC-23-22), `reopen_qp_co_signer` (FK nullable per DEC-23-22), `reopen_reason` (TEXT nullable), `reason_for_change` (TEXT nullable per DEC-23-21), audit columns. #### 6.2.5 `batch_record_entries` `id`, `tenant_id`, `batch_record_id` (FK), `mbr_step_id` (FK — ownership validated per DEC-23-09), `executor_id` (FK), `execution_timestamp`, `entry_text`, audit columns. #### 6.2.6 `ipc_checks` `id`, `tenant_id`, `batch_record_id` (FK), `mbr_parameter_id` (FK — ownership validated per DEC-23-09), `executor_id`, `value_numeric`, `value_text`, `value_unit`, `in_spec` (BOOLEAN), `deviation_id` (FK nullable to URS-16 deviation), audit columns. #### 6.2.7 `batch_yields` `id`, `tenant_id`, `batch_record_id`, `step_label`, `theoretical`, `actual`, `percentage`, `recorded_by`, `recorded_at`, audit columns. #### 6.2.8 `batch_genealogy` `id`, `tenant_id`, `parent_batch_id` (FK), `child_batch_id` (FK), `relationship_type`, audit columns. Constraint: `parent_batch_id != child_batch_id` (DEC-23-10 self-link prevention); UNIQUE `(tenant_id, parent_batch_id, child_batch_id)` (DEC-23-10 duplicate prevention); cycle detection at insert (DEC-23-10 circular prevention). #### 6.2.9 `batch_releases` `id`, `tenant_id`, `batch_record_id` (FK), `release_state` (ENUM `pending_review` / `under_qa_review` / `qa_reviewed` / `pending_release` / `released` / `rejected`), `qa_reviewer_id`, `qa_review_at`, `qa_review_e_signature_id` (FK to `electronic_signatures` per DEC-23-12), `qa_review_hitl_decision_id` (FK), `released_by`, `released_at`, `release_e_signature_id` (FK to `electronic_signatures`), `release_hitl_decision_id` (FK), `rejected_by`, `rejected_at`, `rejection_reason`, audit columns. #### 6.2.10 `batch_exceptions` `id`, `tenant_id`, `batch_record_id`, `exception_text`, `linked_deviation_id` (FK to URS-16 deviation nullable), `resolution_status` (ENUM `open` / `linked` / `resolved`), audit columns. #### 6.2.11 RLS All Module 23 tables have RLS enabled. ### 6.3 API contract | Route | Method | Permission | Status | |---|---|---|---| | `/api/v1/batch/mbrs` | GET / POST | `batch:mbr:read` / `batch:mbr:create` | (typed schema) | | `/api/v1/batch/mbrs/:id` | GET (returns MBR + steps + parameters per DEC-23-07) / PATCH | `batch:mbr:read` / `batch:mbr:update` (draft only) | | | `/api/v1/batch/mbrs/:id/release` | POST | `mbr_release_authority` + HITL + bound e-sign + URS-13 change-request linkage | target route per DEC-23-06 / DEC-23-19 | | `/api/v1/batch/mbrs/:id/steps` | GET / POST | `batch:mbr:steps` | (draft only) | | `/api/v1/batch/mbrs/:id/steps/:stepId/parameters` | GET / POST | `batch:mbr:parameters` | (draft only) | | `/api/v1/batch/records` | GET / POST | `batch:read` / `batch:execution:create` | | | `/api/v1/batch/records/:id` | GET / PATCH (status field excluded from PATCH per DEC-23-08) | `batch:read` / `batch:execution:update` | | | `/api/v1/batch/records/:id/start` | POST | `batch_executor_authority` | target route | | `/api/v1/batch/records/:id/entries` | GET / POST | `batch:execution:entry` (ownership validated per DEC-23-09) | | | `/api/v1/batch/records/:id/ipc` | GET / POST | `batch:ipc` (ownership validated per DEC-23-09) | | | `/api/v1/batch/records/:id/yields` | GET / POST | `batch:yield` | | | `/api/v1/batch/records/:id/genealogy` | GET / POST | `batch:genealogy` (validation per DEC-23-10) | | | `/api/v1/batch/records/:id/exceptions` | GET / POST | `batch:exception` | target route | | `/api/v1/batch/records/:id/complete-execution` | POST | `batch_executor_authority` | target route | | `/api/v1/batch/records/:id/submit-for-qa-review` | POST | `batch_executor_authority` (completeness check per DEC-23-11) | target route per DEC-23-11 | | `/api/v1/batch/records/:id/qa-review` | POST | `qa_review_authority` + HITL + bound e-sign per DEC-23-12 (SoD-distinct from final-release per DEC-23-13) | target route per DEC-23-12 / DEC-23-13 | | `/api/v1/batch/records/:id/final-release` | POST | `qualified_person_authority` + HITL + bound e-sign per DEC-23-12 (SoD-distinct from QA reviewer per DEC-23-13) | target route per DEC-23-12 / DEC-23-13 | | `/api/v1/batch/records/:id/final-reject` | POST | `qualified_person_authority` + HITL + bound e-sign + rejection reason | target route | | `/api/v1/batch/records/:id/lock` | POST | system (auto + bound e-sign per DEC-23-23) | target route | | `/api/v1/batch/records/:id/reopen` | POST | `executive_authority` co-sign AND `qualified_person_authority` co-sign + HITL + reason per DEC-23-22 | target route per DEC-23-22 | ### 6.4 Workflow #### 6.4.1 MBR lifecycle ```mermaid stateDiagram-v2 [*] --> draft: create draft --> under_review: submit for review under_review --> effective: release (mbr_release_authority + HITL + e-sign + URS-13 CR) effective --> superseded: revise (new version) superseded --> archived: archive ``` #### 6.4.2 BR lifecycle ```mermaid stateDiagram-v2 [*] --> created: create from effective MBR created --> in_progress: start in_progress --> execution_complete: complete execution execution_complete --> under_qa_review: submit for QA review (completeness check) under_qa_review --> pending_release: QA review (qa_review_authority + HITL + bound e-sign + sync header) pending_release --> released: final release (qualified_person_authority + HITL + bound e-sign + sync header) pending_release --> rejected: final reject (qualified_person_authority + HITL + bound e-sign + reason) released --> locked: auto-lock + bound e-sign rejected --> locked: auto-lock + bound e-sign locked --> in_progress: governed reopen (executive co-sign + QP co-sign + reason — DEC-23-22 + SoD-23-06; appends new iteration) ``` ### 6.5 Business rules - BR-23-01: MBR uniqueness `(tenant_id, site_id, product_id, mbr_code, version)` per DEC-23-04 / DEC-23-05. - BR-23-02: MBR effective release requires `mbr_release_authority` + HITL + bound e-signature + URS-13 change-request linkage per DEC-23-06 / DEC-23-19. - BR-23-03: Effective MBR versions are immutable; revisions create new version rows. - BR-23-04: Batch-record creation MUST bind to an `effective` MBR; the bound MBR version is immutable for the batch. - BR-23-05: `site_id` mandatory at MBR and BR level per DEC-23-04. - BR-23-06: `product_id` mandatory at MBR level per DEC-23-05. - BR-23-07: Batch-record-entry `mbr_step_id` MUST belong to the batch's `mbr_id` per DEC-23-09. - BR-23-08: IPC `mbr_parameter_id` MUST belong to a step that belongs to the batch's `mbr_id` per DEC-23-09. - BR-23-09: Genealogy validated per DEC-23-10 (ownership / self-link / duplicate / circular). - BR-23-10: Submit-for-QA-review requires completeness check per DEC-23-11. - BR-23-11: QA review and final release are distinct controlled steps per DEC-23-13; default SoD-distinct actors; same-person waiver requires documented tenant policy. - BR-23-12: Bound e-signature persisted via `electronic_signatures` substrate on QA review and final release per DEC-23-12. - BR-23-13: Batch-header release-disposition fields synced from release record in same transaction per DEC-23-14. - BR-23-14: Direct PATCH cannot set `status` to `released` / `rejected` / `locked` per DEC-23-08. - BR-23-15: Auto-lock 24h after `released` or `rejected` with bound e-signature per DEC-23-23. - BR-23-16: Governed reopen `locked → in_progress` requires `executive_authority` co-sign AND `qualified_person_authority` co-sign + reason per DEC-23-22; appends new iteration; prior locked evidence not mutated. - BR-23-17: In-process exceptions and yield deviations emit `batch_deviation_created` to URS-16 per DEC-23-17. - BR-23-18: Batch deviations escalated to CAPA emit `batch_deviation_capa_linked` to URS-18 (`batch_deviation` source type) per DEC-23-16. - BR-23-19: Batch quality findings emit `batch_quality_finding_created` to URS-21 per DEC-23-15. - BR-23-20: Batch-precipitated risk records emit `batch_risk_created` to URS-19 per DEC-23-18. - BR-23-21: Reason-for-change required on material updates after draft per DEC-23-21. - BR-23-22: `platform_admin` / `super_admin` are support / break-glass only paths per DEC-23-20. - BR-23-23: **No LLM/GenAI in critical GMP decisions** under internal Annex 22 §7 + EU AI Act Annex III control; static deterministic AI permitted as advisory. ### 6.6 Audit trail Every Module 23 record mutation persists an audit-trail entry via `auditTrailService.log(.)`. Material updates after draft persist `reason_for_change` per DEC-23-21. Regulated final actions (MBR release, QA review submission, final release approval, final release rejection, batch lock, governed reopen) 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. The audit trail is append-only. ### 6.7 Error handling | Code | HTTP | Meaning | |---|---|---| | `BAT_VALIDATION_FAILED` | 400 | Schema validation failure | | `BAT_UNAUTHORIZED` | 401 | Authentication required | | `BAT_FORBIDDEN` | 403 | RBAC denied | | `BAT_NOT_FOUND` | 404 | Resource not found | | `BAT_DUPLICATE_KEY` | 409 | Uniqueness violation | | `BAT_INVALID_TRANSITION` | 422 | Lifecycle transition not permitted | | `BAT_TERMINAL_STATE_PATCH_FORBIDDEN` | 422 | Direct PATCH attempted on terminal status per DEC-23-08 | | `BAT_STEP_OWNERSHIP_VIOLATION` | 422 | `mbr_step_id` does not belong to batch's `mbr_id` per DEC-23-09 | | `BAT_PARAMETER_OWNERSHIP_VIOLATION` | 422 | `mbr_parameter_id` does not belong to batch's MBR ownership chain per DEC-23-09 | | `BAT_GENEALOGY_SELF_LINK` | 422 | Source = target | | `BAT_GENEALOGY_DUPLICATE` | 422 | Duplicate (parent, child) pair | | `BAT_GENEALOGY_CIRCULAR` | 422 | Circular traceability detected | | `BAT_COMPLETENESS_FAILED` | 422 | Submit-for-QA-review completeness check failed per DEC-23-11 | | `BAT_AUTHORITY_REQUIRED` | 422 | Authority Profile missing | | `BAT_HITL_DECISION_REQUIRED` | 422 | HITL decision capture missing | | `BAT_E_SIGNATURE_REQUIRED` | 422 | Bound e-signature persistence missing | | `BAT_REVIEW_RELEASE_SOD_VIOLATION` | 422 | Same-person QA-review-and-release without tenant SoD waiver per DEC-23-13 | | `BAT_REOPEN_AUTHORITY_REQUIRED` | 422 | Reopen attempted without executive AND QP co-sign per DEC-23-22 | | `BAT_MBR_NOT_EFFECTIVE` | 422 | Batch-record creation against non-effective MBR | | `BAT_MBR_CHANGE_REQUEST_REQUIRED` | 422 | MBR effective release without URS-13 change-request linkage per DEC-23-19 | | `BAT_REASON_FOR_CHANGE_REQUIRED` | 422 | Material update after draft without reason-for-change per DEC-23-21 | | `BAT_CONTEXT_FILTER_MISMATCH` | 422 | Query against context column not present in schema | | `BAT_INTERNAL` | 500 | Sanitized server error | ### 6.8 Configuration rules - Auto-lock interval (default 24h) configurable per tenant with platform-admin approval. - Same-person QA-review-and-release waiver (default disabled) configurable per tenant with documented authority configuration; audit-flagged. - Completeness-check policy (which MBR steps / parameters are `required`) defined on the MBR template. --- ## 7. Non-functional Requirements - NFR-23-01: List endpoint pagination (default 50, max 200). - NFR-23-02: List p95 < 800ms under typical tenant load (100k batch records; 10M batch entries). - NFR-23-03: MBR detail (with steps + parameters) p95 < 500ms. - NFR-23-04: Completeness check p95 < 2s. - NFR-23-05: Audit-trail append p99 < 200ms. - NFR-23-06: Concurrent batch executors per tenant: 100. - NFR-23-07: Storage scalability: 1M batch records per tenant; 100M batch entries per tenant. - NFR-23-08: Backup / restore RPO ≤ 15 min; RTO ≤ 4 hours per URS-35. - NFR-23-09: 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 for UI labels. Batch-record content stored in user-input language. --- ## 9. Migration ### 9.1 Migration scope Greenfield at launch. Pilot tenants importing legacy MBRs / batch records subject to URS-23-VAL-008 migration evidence gate. ### 9.2 Schema migration Migration 035 baseline; target migrations (036+ as needed) add `site_id` NOT NULL on `master_batch_records` and `batch_records`, add `product_id` NOT NULL on `master_batch_records`, add `mbr_release_change_request_id` FK, add bound e-signature FK columns on `master_batch_records`, `batch_records`, `batch_releases`, replace narrow uniqueness with `(tenant_id, site_id, product_id, mbr_code, version)`, add genealogy constraints (self-link prevention, uniqueness, cycle detection trigger), reconcile `MODULE_CONTEXT_CONFIG.batch` with persisted schema, exclude `status` from generic PATCH allowed-fields per DEC-23-08. ### 9.3 Migration evidence gate (URS-23-VAL-008) (a) all migrations applied; (b) RLS verified; (c) typed schema validation verified; (d) ownership validation verified for entries + IPC; (e) genealogy validation verified; (f) completeness check verified; (g) bound e-signature persistence verified for QA review + final release + lock + reopen; (h) header sync verified; (i) terminal-state patch-bypass prevention verified; (j) governed reopen append-only verified; (k) findings / CAPA / deviation / risk event emission verified; (l) MBR effective-release URS-13 linkage verified; (m) audit-trail coverage verified; (n) reason-for-change discipline verified; (o) §17 validation evidence pack signed. --- ## 10. Decommissioning Module 23 records subject to platform record-retention policy: retained for the longer of (a) 30 years from batch lock (FDA 21 CFR §211.180) or (b) 50 years from product expiry (EU GMP). On tenant decommissioning, records exported to tenant's controlled archive per URS-35. --- ## 11. Decisions, Dependencies, Risks, and Error Handling ### 11.1 Closed decision posture **No Module 23 internal decisions outstanding.** Launch decisions are captured in the locked decisions above. ### 11.2 External dependencies - URS-13 change-control register must support `mbr_release_change_request_id` linkage per DEC-23-19. - URS-16 deviations register must accept `batch_deviation` source type and `batch_record_id` reference per DEC-23-17. - URS-18 CAPA register must accept `batch_deviation` source type per URS-18 declared source set per DEC-23-16. - URS-21 findings register must accept `batch_quality` source type per DEC-23-15. - URS-19 risk-assessment register must accept `batch_record_id` reference per DEC-23-18. - URS-32 MIRA AI must support read-only `useMiraRecord('batch_record',.)` and `useMiraRecord('master_batch_record',.)` mappings; **no GenAI in critical GMP decisions**. ### 11.3 Risks - Risk-23-01: SoD-waiver for same-person QA-review-and-release may be over-used by small tenants. Mitigation: audit-flag every waiver use; periodic review by Validation Head + QA Head + Founder. - Risk-23-02: Cycle-detection on genealogy may degrade at very deep traceability chains. Mitigation: NFR-23-02 latency budget; depth-bound cycle detection with explicit error if depth exceeded. - Risk-23-03: Auto-lock 24h after release may surprise users expecting longer correction window. Mitigation: tenant-configurable interval; clear UX countdown. - Risk-23-04: Reopen workflow gravity (executive + QP co-sign) may be perceived as friction. Mitigation: documented training; reopen UX language reinforcing regulatory gravity. ### 11.4 Out-of-scope risks tracked elsewhere - Direct shop-floor DCS / MES integration (URS-33 future-state). - Equipment / instrument calibration register (URS-33). ### 11.5 Risk owner Module-23 risk register owned by Manufacturing / Batch Squad with quarterly review by QA Head + Manufacturing Head + Validation Head + Qualified Person Authority. ### 11.6 Decision discipline No Module 23 internal decisions outstanding. New decisions captured via URS-13 Change Control register. ### 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-23-01: Tenant isolation enforced at RLS on every Module 23 table. - SEC-23-02: RBAC enforced on every route via `requirePermission(.)` before service execution. - SEC-23-03: Authority resolution enforced on regulated final actions before HITL + e-signature. - SEC-23-04: HITL decision capture enforced before bound e-signature persistence. - SEC-23-05: Bound e-signature persistence via `electronic_signatures` substrate; signature binding includes user identity, action, resource ID, action timestamp, and signature hash. - SEC-23-06: PII redaction in logs; full content remains in record fields. - SEC-23-07: Audit-trail integrity via URS-06 hash chain. - SEC-23-08: AI-request provenance via `ai_requests`; **no LLM/GenAI in critical GMP decisions**; static deterministic AI permitted as advisory. - SEC-23-09: `platform_admin` / `super_admin` break-glass actions logged with reason and reviewed in platform support audit per DEC-23-20. - SEC-23-10: Same-person QA-review-and-release SoD waiver audit-flagged for periodic review. --- ## 13. Segregation of Duties | SoD ID | Constraint | |---|---| | SoD-23-01 | The MBR releaser MUST NOT be the MBR author when tenant policy requires content-author/releaser separation. | | SoD-23-02 | The batch executor MAY be the batch creator (operational continuity); the batch executor MUST NOT be the QA reviewer. | | SoD-23-03 | The MBR-step / MBR-parameter ownership invariant MUST be enforced at service layer per DEC-23-09. | | SoD-23-04 | The QA reviewer MUST NOT be the batch executor. | | SoD-23-05 | The Qualified Person (final releaser) MUST NOT be the QA reviewer per default tenant policy; same-person QA-review-and-release waiver permitted only with documented tenant policy + audit-logged justification per DEC-23-13. | | SoD-23-06 | The reopen co-signers (executive AND Qualified Person per DEC-23-22) MUST NOT be the original release-and-lock signers; reopen append-only semantics enforced. | | SoD-23-07 | The `platform_admin` / `super_admin` support / break-glass action MUST NOT be a regulated production action; break-glass logged and reviewed per DEC-23-20. | --- ## 14. Regulatory Mapping | Predicate rule | Section | Module 23 binding | |---|---|---| | FDA 21 CFR Part 11 | §11.10(a) Validation; §11.10(d) Authority checks; §11.10(e) Audit trails; §11.50 / §11.70 Signature manifestation | URS-23-VAL-008 + bound e-sign on every regulated final action + audit-trail on every mutation | | FDA 21 CFR Part 211 | §211.180 Records retention; §211.186 Master Production and Control Records; §211.188 Batch Production and Control Records; §211.192 Production record review; §211.194 Laboratory records; §211.165 Testing and Release for Distribution | MBR + BR + QA review + final release ceremonies | | EU GMP Annex 11 | §1, §4, §9, §12, §16 | Risk; validation; audit trails; security; incident management | | EU GMP Article 51 / Qualified Person | EU Directive 2001/83/EC | Qualified Person batch-release ceremony per DEC-23-13 | | EU GMP Annex 22 Draft 2025 | §7 — HITL / GenAI prohibition in critical GMP decisions | Internal forward-looking control; static deterministic AI only; GenAI prohibited in batch-disposition / release / OOS / deviation / CAPA | | EU AI Act (Regulation 2024/1689) | Annex III + Art. 13 transparency | Adopted as internal forward-looking AI governance; advisory-labeling for transparency on AI-assisted batch quality prediction | | MHRA Data Integrity Guidance | ALCOA+ | Audit-trail; bound e-signature; record retention | | GAMP 5 Cat 5 | Custom-application validation lifecycle | URS-23 validation evidence pack per URS-23-VAL-008 | | ICH Q7 | GMP for APIs | API batch records under same lifecycle | | ICH Q9 | Quality Risk Management | Batch-precipitated risk emission to URS-19 | | ICH Q10 | §3.2.1 Process Performance and Product Quality Monitoring; §3.2.2 CAPA | Batch metrics consumed by URS-26 APQR; CAPA emission to URS-18 | | India CDSCO Schedule M (Revised) | §8 / §9 — Master Formula Records and Batch Manufacturing Records | India operations regulatory baseline subject to a future jurisdiction-specific legal assessment | | India CDSCO Schedule M-III | §3 / §6 — Medical Device Manufacture | India medical-device operations subject to a future jurisdiction-specific legal assessment | --- ## 15. Code Modules | Code module | Path | Status | |---|---|---| | `batch` plugin | `packages/backend/src/modules/batch/plugin.ts` | (canonical mount) | | `batch` routes | `packages/backend/src/modules/batch/routes.ts` | (typed schemas; route additions per §6.3; route comments aligned) | | `batch` service | `packages/backend/src/modules/batch/service.ts` | (ownership validation; completeness check; true e-signature integration; header sync; SoD enforcement; reopen append-only; event emission) | | `batch` schemas | `packages/backend/src/modules/batch/schemas.ts` | (aligned with migration 035) | | `batch` events | `packages/backend/src/modules/batch/events.ts` | target route | | Migration 035 | `packages/backend/src/db/migrations/035_batch_records.sql` | (036+ migrations add `site_id`, `product_id`, change-request linkage, e-signature FKs, genealogy constraints, MODULE_CONTEXT_CONFIG alignment) | | Shared types | `packages/shared/src/types/batch.ts` | | | Shared schemas | `packages/shared/src/schemas/batch.schema.ts` | (alignment per DEC-23-03) | | Frontend hooks | `packages/frontend/src/api/hooks/useBatch.ts` | | | Frontend list | `packages/frontend/src/pages/BatchList.tsx` | (CTA points to real `/batch/new`) | | Frontend create flow | `packages/frontend/src/pages/BatchCreate.tsx` | target route per DEC-23-02 | | Frontend detail | `packages/frontend/src/pages/BatchDetail.tsx` | | | Frontend MBR editor | `packages/frontend/src/pages/MBREditor.tsx` | target route | | Frontend MBR detail | `packages/frontend/src/pages/MBRDetail.tsx` | target route per DEC-23-07 | | Frontend QA review console | `packages/frontend/src/pages/QAReviewConsole.tsx` | target route per DEC-23-12 / DEC-23-13 | | Frontend final release console | `packages/frontend/src/pages/FinalReleaseConsole.tsx` | target route per DEC-23-12 / DEC-23-13 | | App routing | `packages/frontend/src/App.tsx` | (`/batch/new`, `/mbr/*`, console routes) | --- ## 16. Test Cases ### 16.1 Unit tests - TC-23-U-001: MBR uniqueness `(tenant_id, site_id, product_id, mbr_code, version)` rejects duplicate. - TC-23-U-002: MBR effective release without URS-13 change-request linkage rejects with `BAT_MBR_CHANGE_REQUEST_REQUIRED`. - TC-23-U-003: Effective MBR step / parameter edit rejects with `BAT_INVALID_TRANSITION`. - TC-23-U-004: Batch-record creation against non-effective MBR rejects with `BAT_MBR_NOT_EFFECTIVE`. - TC-23-U-005: Batch entry with `mbr_step_id` not in batch's `mbr_id` rejects with `BAT_STEP_OWNERSHIP_VIOLATION`. - TC-23-U-006: IPC with `mbr_parameter_id` not in batch's MBR ownership chain rejects with `BAT_PARAMETER_OWNERSHIP_VIOLATION`. - TC-23-U-007: Genealogy self-link rejects with `BAT_GENEALOGY_SELF_LINK`. - TC-23-U-008: Genealogy duplicate rejects with `BAT_GENEALOGY_DUPLICATE`. - TC-23-U-009: Genealogy circular rejects with `BAT_GENEALOGY_CIRCULAR`. - TC-23-U-010: Submit-for-QA-review with incomplete steps rejects with `BAT_COMPLETENESS_FAILED`. - TC-23-U-011: Direct PATCH setting `status = released` rejects with `BAT_TERMINAL_STATE_PATCH_FORBIDDEN`. - TC-23-U-012: QA review without bound e-signature rejects with `BAT_E_SIGNATURE_REQUIRED`. - TC-23-U-013: Same-person QA-review-and-release without tenant waiver rejects with `BAT_REVIEW_RELEASE_SOD_VIOLATION`. - TC-23-U-014: Final release without `qualified_person_authority` rejects with `BAT_AUTHORITY_REQUIRED`. - TC-23-U-015: Header sync verified — `qa_reviewer_id`, `qa_review_date` populated on QA review; `approved_by`, `approval_date`, `status` populated on final release. - TC-23-U-016: Reopen without executive AND QP co-sign rejects with `BAT_REOPEN_AUTHORITY_REQUIRED`. - TC-23-U-017: Reopen appends new iteration; prior locked evidence not mutated. - TC-23-U-018: Material update after draft without reason-for-change rejects with `BAT_REASON_FOR_CHANGE_REQUIRED`. - TC-23-U-019: Context-filter query against `site_id` works correctly post-target-migration. - TC-23-U-020: Auto-lock 24h after `released` persists bound e-signature. ### 16.2 Integration tests - TC-23-I-001: Full MBR draft → effective lifecycle with HITL + e-signature + URS-13 CR linkage. - TC-23-I-002: Full BR lifecycle from `created` to `locked` with all gates. - TC-23-I-003: BR with in-process exception emitting `batch_deviation_created` to URS-16; CAPA emission to URS-18. - TC-23-I-004: Batch quality finding emission to URS-21. - TC-23-I-005: Batch-precipitated risk emission to URS-19. - TC-23-I-006: Genealogy linkage with full validation. - TC-23-I-007: Same-person QA-review-and-release with tenant SoD waiver — both signatures persisted; SoD-waiver audit entry. - TC-23-I-008: Governed reopen `locked → in_progress` with executive + QP co-sign. - TC-23-I-009: MBR detail GET returns full template including steps + parameters per DEC-23-07. - TC-23-I-010: Frontend `BatchList.tsx` `+ New Batch` CTA navigates to `/batch/new` and creates BR. - TC-23-I-011: Header sync inside same transaction as release-record write. - TC-23-I-012: Cross-module event consumption (URS-13, URS-16, URS-18, URS-19, URS-21). - TC-23-I-013: MIRA copilot read-only context on batch records; no MIRA write paths. - TC-23-I-014: AI advisory surfaces (similar prior batches) labeled as advisory; static deterministic AI only; no GenAI in critical decisions. - TC-23-I-015: Cross-tenant `platform_admin` break-glass logged. ### 16.3 End-to-end tests - TC-23-E-001: Tablet batch manufacture under FDA cGMP per Worked Example 1. - TC-23-E-002: MBR revision through change control per Worked Example 2. - TC-23-E-003: Governed reopen of locked batch per Worked Example 3. - TC-23-E-004: Collapsed QA-and-release attempt rejected per Worked Example 4. - TC-23-E-005: Concurrent batch executors — 100 concurrent users — NFR-23-06 verification. - TC-23-E-006: API batch under ICH Q7 with API-specific MBR steps. - TC-23-E-007: India CDSCO Schedule M batch with India-specific predicate-rule citations. ### 16.4 Performance tests - TC-23-P-001: List p95 latency (NFR-23-02). - TC-23-P-002: MBR detail p95 latency (NFR-23-03). - TC-23-P-003: Completeness check p95 latency (NFR-23-04). - TC-23-P-004: Audit-trail append p99 latency (NFR-23-05). - TC-23-P-005: Bound e-signature persistence p95 latency (NFR-23-09). ### 16.5 Security tests - TC-23-S-001: Cross-tenant access rejected by RLS. - TC-23-S-002: Missing RBAC rejected. - TC-23-S-003: Missing Authority Profile rejected on regulated final action. - TC-23-S-004: Missing HITL rejected. - TC-23-S-005: Missing bound e-signature rejected. - TC-23-S-006: SQL injection against typed-schema route rejected. - TC-23-S-007: Audit-trail UPDATE / DELETE rejected at DB level. - TC-23-S-008: GenAI write to critical GMP decision path rejected. - TC-23-S-009: PII redaction in logs verified. - TC-23-S-010: Direct PATCH on terminal status rejected. --- ## 17. Validation Evidence ### 17.1 URS-23-VAL-001: Requirements traceability matrix Complete RTM mapping every URS-23 requirement (DEC-23-01.DEC-23-23, BR-23-01.BR-23-23, NFR-23-01.NFR-23-09, SoD-23-01.SoD-23-07, SEC-23-01.SEC-23-10) to test cases (TC-23-U-001.TC-23-U-020, TC-23-I-001.TC-23-I-015, TC-23-E-001.TC-23-E-007, TC-23-P-001.TC-23-P-005, TC-23-S-001.TC-23-S-010) and code modules (§15). ### 17.2 URS-23-VAL-002: Design qualification (DQ) Architecture, data model, API contract, workflow, business rules, audit trail, security, integration; signed by Validation Head, QA Head, RA Head, Manufacturing Head, Qualified Person Authority. ### 17.3 URS-23-VAL-003: Installation qualification (IQ) Migration application + RLS verification + route mount verification + frontend hook resolution. ### 17.4 URS-23-VAL-004: Operational qualification (OQ) Happy-path execution of every test case (TC-23-U-001.TC-23-S-010) with evidence captures. ### 17.5 URS-23-VAL-005: Performance qualification (PQ) NFR-23-01.NFR-23-09 verification under typical and peak tenant load. ### 17.6 URS-23-VAL-006: AI/ML governance evidence Per ARCH-AI-001: (a) MIRA read-only context integration; (b) static-deterministic-AI advisory surfaces; (c) **GenAI/LLM prohibition in critical GMP decisions** verification — no LLM call from batch-disposition / release / OOS / deviation / CAPA paths; (d) Annex 22 §7 + EU AI Act Annex III internal forward-looking control compliance evidence. ### 17.7 URS-23-VAL-007: Regulatory mapping evidence FDA 21 CFR Part 11 + 211 (§186, §188, §192, §194, §165), EU GMP Annex 11, EU GMP Article 51 (QP), Annex 22 Draft 2025 §7, EU AI Act Art. 13 / Annex III, MHRA Data Integrity (ALCOA+), GAMP 5 Cat 5, ICH Q7, ICH Q9, ICH Q10 §3.2.1 / §3.2.2, India CDSCO Schedule M / M-III. ### 17.8 URS-23-VAL-008: Migration evidence gate Per §9.3. ### 17.9 URS-23-VAL-009: Signature manifest QA Head, RA Head, Validation Head, Manufacturing Head, Qualified Person Authority, Information Security Head, Site Quality Lead, Founder / Chairman & MD per §19. ### 17.10 URS-23-VAL-010: Post-launch periodic-review pack (a) batch metrics (batches per tenant, release rate, rejection rate, lock rate); (b) AI-quality (advisory acceptance / rejection rate); (c) audit-trail integrity; (d) reopen-event audit (executive + QP co-sign); (e) SoD-waiver audit; (f) cross-tenant break-glass audit; (g) cross-module event integrity (URS-13, URS-16, URS-18, URS-19, URS-21); periodic review at quarterly cadence by QA Head + Manufacturing Head + Validation Head + Qualified Person Authority. --- ## 18. Document Change History | Version | Date | Author | Change Summary | |---|---|---|---| | 1.0 | 2026-05-07 | Founder Doctrine — Verixa URS Cell | First issued user requirements specification for Module 23. | --- ## 19. Document Approval | Role | Name | Signature | Date | |---|---|---|---| | Founder / Chairman & MD | Vimal | __________ | __________ | | QA Head | __________ | __________ | __________ | | RA Head | __________ | __________ | __________ | | Validation Head | __________ | __________ | __________ | | Manufacturing Head | __________ | __________ | __________ | | Qualified Person Authority | __________ | __________ | __________ | | Information Security Head | __________ | __________ | __________ | | Site Quality Lead | __________ | __________ | __________ | --- ## 20. Cross-Module Event Contract | Event | Emitter | Consumer | Payload key fields | |---|---|---|---| | `mbr_created` | Module 23 | URS-30 | `mbr_id`, `tenant_id`, `site_id`, `product_id`, `version` | | `mbr_released_effective` | Module 23 | URS-30, URS-13 (audit) | `mbr_id`, `change_request_id`, `released_by`, `e_signature_id` | | `mbr_superseded` | Module 23 | URS-30 | `prior_mbr_id`, `new_mbr_id` | | `batch_record_created` | Module 23 | URS-30 | `batch_record_id`, `tenant_id`, `site_id`, `product_id`, `mbr_id`, `batch_id`, `created_by` | | `batch_record_status_changed` | Module 23 | URS-30 | `batch_record_id`, `from_status`, `to_status`, `changed_by`, `reason_for_change` | | `batch_step_executed` | Module 23 | URS-30 | `batch_record_id`, `mbr_step_id`, `executor_id`, `execution_timestamp` | | `ipc_recorded` | Module 23 | URS-30 | `batch_record_id`, `mbr_parameter_id`, `value_numeric`, `in_spec` | | `yield_recorded` | Module 23 | URS-30 | `batch_record_id`, `step_label`, `theoretical`, `actual`, `percentage` | | `genealogy_linked` | Module 23 | URS-30 | `parent_batch_id`, `child_batch_id`, `relationship_type` | | `release_submitted` | Module 23 | URS-30 | `batch_record_id`, `submitted_by` | | `qa_review_completed` | Module 23 | URS-30 | `batch_record_id`, `qa_reviewer_id`, `qa_review_e_signature_id` | | `release_approved` | Module 23 | URS-30, URS-34 (GDP distribution) | `batch_record_id`, `approved_by`, `release_e_signature_id` | | `release_rejected` | Module 23 | URS-30 | `batch_record_id`, `rejected_by`, `rejection_reason`, `release_e_signature_id` | | `batch_record_locked` | Module 23 | URS-30 | `batch_record_id`, `locked_by`, `lock_e_signature_id` | | `batch_record_reopened` | Module 23 | URS-30, URS-21 (governed-reopen audit) | `batch_record_id`, `reopened_by`, `executive_co_signer`, `qp_co_signer`, `reopen_reason` | | `batch_deviation_created` | Module 23 | **URS-16 (Deviations — primary consumer)**, URS-30 | `batch_record_id`, `ipc_check_id` or `yield_id`, `severity`, `deviation_id` (URS-16) | | `batch_deviation_capa_linked` | Module 23 | **URS-18 (CAPA — primary consumer)**, URS-30 | `batch_record_id`, `deviation_id`, `capa_id`, `linked_by`, `source_type = batch_deviation` | | `batch_quality_finding_created` | Module 23 | **URS-21 (Findings — primary consumer)**, URS-30 | `batch_record_id`, `finding_id` (URS-21), `severity`, `finding_type` | | `batch_risk_created` | Module 23 | **URS-19 (Risk — primary consumer)**, URS-30 | `batch_record_id`, `risk_id` (URS-19), `risk_pattern_type` | --- ## 21. References - ARCH-AI-001 — AI Optionality and Manual Continuity (binding architecture) - VRX-SPEC-URS-023-Batch-Records-and-Manufacturing-Execution.md (Module specification) - URS-01.URS-22, URS-24.URS-35 (cross-module contracts) - FDA 21 CFR Part 11 - FDA 21 CFR Part 211 §211.180 / §211.186 / §211.188 / §211.192 / §211.194 / §211.165 - EU GMP Annex 11 (Computerised Systems) - EU GMP Article 51 / Qualified Person (Directive 2001/83/EC) - 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 Q7 (GMP for APIs) - ICH Q9 (Quality Risk Management) - ICH Q10 §3.2.1 / §3.2.2 (Process Performance and Product Quality Monitoring; CAPA) - India CDSCO Schedule M (Revised) §8 / §9 - India CDSCO Schedule M-III §3 / §6 - India D&C Act 1940 / Drugs Rules 1945 --- **END OF VRX-URS-23 — BATCH RECORDS & MANUFACTURING EXECUTION — VERSION 1.0**