# Verixa — User Requirements Specification

# Module 4: Workflow / Human-in-the-Loop / Electronic Signature / Approval Authority

| Field | Value |
|---|---|
| Document ID | VRX-URS-04 |
| Version | 1.0 |
| Status | Final — ready for QA, Validation, Regulatory Affairs, Information Security, 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-04-VAL-008) and validation evidence pack are satisfied. |
| Document Type | User Requirements Specification (URS) |
| GAMP 5 Category | Category 5 — Custom Application |
| Regulatory Classification | Critical infrastructure substrate — operates the workflow template engine, the Controlled Approval Modal, the electronic-signature ceremony, and the approval-authority resolver that capture every regulated human decision across the Verixa platform. |
| Date of Issue | 2026-05-06 |
| Module Owner (Engineering) | Workflow / E-Sign Squad |
| Module Owner (Quality Validation) | CSV / CSA Lead — Workflow & E-Signature |
| Module Owner (Compliance) | Quality Assurance, Regulatory Affairs |
| Approving Authority | Founder / Chairman & MD; QA Head; Validation Head; RA Head; Information Security Head |

## Document Approval

| Role | Name | Signature | Date |
|---|---|---|---|
| Author — Platform Architecture | _____________________ | _____________________ | __________ |
| Reviewer — Engineering Lead | _____________________ | _____________________ | __________ |
| Reviewer — QA / Validation Lead | _____________________ | _____________________ | __________ |
| Reviewer — Information Security Lead | _____________________ | _____________________ | __________ |
| Reviewer — Regulatory Affairs Lead | _____________________ | _____________________ | __________ |
| Approving Authority — Founder, Chairman & MD | _____________________ | _____________________ | __________ |

## Version History

| Version | Date | Summary |
|---|---|---|
| 1.0 | 2026-05-06 | First issued user requirements specification for Module 4. |

---

## 0. Document Framing

### 0.1 Purpose of this document

This URS defines the target expected state for Verixa's Workflow / Human-in-the-Loop / Electronic Signature / Approval Authority module (Module 4). It is the binding contract between product, engineering, quality validation, regulatory affairs, information security, and the executive authority for the design, implementation, validation, release, and on-going periodic review of the workflow template engine, the workflow runtime, the Controlled Approval Modal, the electronic-signature ceremony and registry, the approval-authority resolver, the human-in-the-loop decision lifecycle and escalation engine, the adapter contract for regulated entities, and the template library import / provenance system. Compliance with this URS is mandatory.

### 0.2 Audience

- Engineering — design, implementation, code review.
- Quality Assurance / Validation — IQ / OQ / PQ test design, traceability matrix, validation reports.
- Regulatory Affairs — regulatory mapping, inspection readiness.
- Information Security — security review, penetration testing, incident response.
- Product Owners — feature definition, UX acceptance.
- Inspectors and Auditors — evidence of system intent and controls.
- Customers — confirmation of platform behaviour during qualification of Verixa as a supplier.

### 0.3 Reading conventions

- Requirements use the keywords MUST, SHOULD, and MAY as defined in IETF RFC 2119 / RFC 8174.
- Atomic requirement identifier form: `URS-04-<Domain>-<Number>`. Domain prefixes: `FE`, `BE`, `WF`, `DATA`, `SEC`, `AUD`, `ESIG`, `AI`, `INT`, `REP`, `VAL`.
- Supporting identifiers: `DEC-04-N` (closed launch decision), `DEP-04-N` (dependency), `BR-04-N` (business rule), `RG-04-N` (regulatory mapping row), `TC-PLAIN-N` (plain-language scenario), `TC-TECH-N` (technical test case), `AC-04-N` (Given/When/Then acceptance criterion), `CIM-N` (change-impact matrix row).
- Where this document does not state a fact in §18.1, the absence MUST be raised as an in-scope decision request to QA / RA / Information Security and resolved before signature; this final version has no decisions left open.

### 0.4 Inherited cross-module standards

The twelve standards defined in URS-01 §0.4 apply unchanged to Module 4 plus the inherited additions from URS-02 (Mode A admin invariant, self-modification block), URS-03 (context filter universal application, context coverage gate, active context persistence, approval-scope check at decision time, cross-context request denial), and the following module-specific additions:

13. **Controlled Approval Modal is the only regulated-decision UI.** Every regulated decision (approve, release, dispose, sign off, close, certify) MUST traverse the Controlled Approval Modal contract owned by Module 4 — `password` (re-authentication), `meaningOfSignature`, `reasonForChange`. The front end NEVER sends `ip`, `userAgent`, `timestamp`, or `performedBy` in the request body; the back end derives them from request context.
14. **Authority validated immediately before signature.** The approval-authority resolver MUST execute `validateApprovalAction` immediately before the electronic-signature row is written, and MUST execute it again from `esigService.createSignature` as defence-in-depth, so a non-HITL signing path cannot bypass the authority check.
15. **Approval-authority snapshot is per-decision and append-only.** At every regulated decision, an `approval_authority_snapshots` row is written into Module 4's hash-chained ledger capturing the actor's authority profiles, delegation evidence, scope match details, segregation-of-duties verdict, claims version at approval, and required authority keys, linked to the electronic-signature row.
16. **No generic PATCH for state transitions.** A regulated record state transition MUST be invoked through an explicit action endpoint (for example `POST /capas/:id/approve`), never through a generic `PATCH /entities/:id`. The route handler MUST carry the `withAuthority({requiredAuthorityKey, decisionType, requiresEsign})` wrapper.
17. **Workflow runtime resolves approval requirements from the active node.** When a HITL decision is created, the workflow runtime MUST look up the active node's `workflow_node_approval_requirements` row and pass the **real** required authority keys, minimum approver count, and segregation-of-duties requirement to `resolveApprovalCandidates`. Hard-coded defaults (for example a fallback to `'quality_approval'` when no node-bound requirement exists) MUST be logged and the fallback MUST be a release-time defect in the regulated entity's adapter, not a permanent runtime path.

### 0.5 Verixa URS suite — module map

This module is **URS-04** in the thirty-five-module suite. Cross-module references use the module number and short title.

| Module | Title |
|---|---|
| URS-01 | Authentication, Session Management & Access Control |
| URS-02 | Role-Based Access Control & Permissions |
| URS-03 | Context Gate & Approval Scope |
| URS-04 | Workflow / HITL / E-Signature / Approval Authority *(this document)* |
| URS-05 | Authority Profile / Approval Delegation / Segregation of Duties |
| URS-06 | Audit Trail & Data Integrity |
| URS-07 | Study Management |
| URS-08 | Tenant Management |
| URS-09 | Sites Management |
| URS-10 | Products Management |
| URS-11 | Supplier Management |
| URS-12 | Document Control & Knowledge Libraries |
| URS-13 | Regulated change governance |
| URS-14 | Complaints |
| URS-15 | Out-of-Specification / Out-of-Trend |
| URS-16 | Deviations |
| URS-17 | Root Cause Analysis |
| URS-18 | Corrective and Preventive Actions |
| URS-19 | Risk Assessment |
| URS-20 | Reviews |
| URS-21 | Findings |
| URS-22 | Inspection Management & Readiness |
| URS-23 | Batch Records & Manufacturing Execution |
| URS-24 | Stability Management |
| URS-25 | Environmental Monitoring |
| URS-26 | Annual Product Quality Review |
| URS-27 | Regulatory Intelligence & Submission Governance |
| URS-28 | Training Management & Qualification |
| URS-29 | Screen Reader / Data Capture & Extraction Governance |
| URS-30 | Notifications, Delivery Channels & Communication Governance |
| URS-31 | Document Quality Gateway |
| URS-32 | MIRA AI Chat / Command Center / Agent Orchestration |
| URS-33 | Good Manufacturing Practice — Manufacturing Operations & Controls |
| URS-34 | Good Distribution Practice — Distribution, Warehouse & Dispatch Controls |
| URS-35 | Infrastructure, Backup, Restore & Operational Resilience |

### 0.6 Glossary

#### Workflow and template terms

- **Workflow template** — a controlled, versioned definition of how a regulated record progresses from open to closed; consists of states, transitions, and per-node approval requirements.
- **Workflow template version** — an immutable snapshot of a template at a given version; once published, the version's content is read-only.
- **Workflow instance** — a runtime instantiation of a template attached to a specific regulated record; carries its own state machine that advances through transitions.
- **Workflow node** — a state in the template's state machine; carries optional approval requirements (`workflow_node_approval_requirements`).
- **Transition** — an edge between two nodes; may be self-service (the actor simply submits) or **regulated** (requires HITL gate plus electronic signature).
- **Adapter** — a code surface implementing the contract between a regulated entity (deviation, CAPA, complaint, batch, etc.) and the workflow engine; tells the engine where the record lives, what its current node is, and how to apply a transition.
- **Library template** — a vendor- or community-provided template definition imported into a tenant; carries provenance fields (source library key, source library hash, semantic version) that survive into runtime instances.
- **Template lifecycle states** — `draft`, `under_review`, `approved`, `effective`, `obsolete`. A template is editable only in `draft`; review is captured as a controlled artefact; approval is electronically signed; effective is the publishable state; obsolete preserves history.

#### Human-in-the-Loop (HITL)

- **HITL decision** — a regulated decision request opened by the workflow runtime when a regulated transition is reached; lives until decided, escalated, or expired.
- **HITL gate config** — per-node configuration that determines who is eligible to decide, the minimum number of decisions required, the segregation-of-duties rule, and the escalation policy.
- **HITL escalation** — the runtime path that reassigns the decision to an alternate authority holder when the original decider is unavailable or the SLA is exceeded.
- **Decision modes** — `single` (one signature is sufficient), `dual` (two distinct signers required), `sequential` (signers must sign in a defined order), `parallel` (any required signers may sign in any order; all must complete).
- **Final approver** — a signer designated as the decision owner; the regulated state transition commits only after the final approver signs.
- **Secondary approver** — an additional required signer (typically dual or parallel mode) named on the workflow node configuration.
- **Override authority** — an Authority Profile permitted to override the primary requirement under specified conditions; every override use is electronically signed and audited.

#### Electronic signature

- **Electronic signature** — the regulated signature recording who approved a decision, when, why, and on what content. Composed of identification code (the authenticated session) plus password (re-entered through the Controlled Approval Modal), per 21 CFR Part 11 §11.200.
- **Meaning of signature** — the statement that records what the signer is attesting to (for example "I approve closure of CAPA-2026-0044"); persisted on the signature row per §11.50.
- **Reason for change** — the human-readable rationale captured alongside the signature for audit traceability.
- **Signed content snapshot** — a serialised, hash-stable representation of the entity at the moment of signature; ensures the signature can be verified against exactly what was signed.
- **Signature/record linking** — the binding between the signature row and the action row through the electronic-signature identifier; per 21 CFR Part 11 §11.70 the link prevents copying or transferring signatures to falsify records.
- **Signature invalidation** — when the signed entity is mutated post-signature, the signature is marked invalidated; an `invalidated_at` timestamp and `SIGNATURE_INVALIDATED` event are written.
- **Multi-factor step-up** — for high-risk decisions (template approval, library import, override use, segregation-of-duties exception activation, founder-level decisions) the Controlled Approval Modal additionally requires a fresh multi-factor authentication response per URS-01 §6.7.

#### Approval authority

- **Authority Profile** (recap from URS-01 §3.3 / URS-05) — a named regulated approval right.
- **Approval-authority resolver** — the server-side service that, given a workflow node and a target record, returns the set of users currently eligible to decide (`resolveApprovalCandidates`), validates that a specific actor is eligible (`validateApprovalAction`), and writes the decision-time authority snapshot (`snapshotApprovalAuthority`).
- **Authority candidate** — a user currently eligible to decide a HITL gate, computed from active Authority Profile assignments, active delegations, and segregation-of-duties rules.
- **Segregation-of-Duties (SoD)** — rules that prevent one user from playing two conflicting roles (for example, the same user cannot author and approve the same deviation); evaluated as part of the resolver's eligibility computation.

#### Engineering and platform

- **`workflow_templates`** / **`workflow_template_versions`** — the canonical schema; versions are append-only.
- **`workflow_node_approval_requirements`** — per-node approval requirement rows; the runtime reads these to compute `requiredAuthorityKeys`, `minApprovers`, `requiresSod`, `approvalMode`, `finalApproverRequired`, `secondaryAuthorityProfileId`, `overrideAuthorityProfileId`, `esignRequired`, `sodRuleId`, `fromState`, `toState`, `entityType`, `workflowFamily`.
- **`hitl_decisions`** — the per-decision record produced by the workflow runtime.
- **`hitl_escalation_log`** — append-only escalation history per HITL decision.
- **`electronic_signatures`** — the canonical signature registry.
- **`approval_authority_snapshots`** — the hash-chained per-decision authority snapshot ledger.

If a reader is uncertain about a term not in this glossary, the term is treated as a defect in this URS and resolved before signature; no unresolved decisions are carried.

---

## 1. Module Purpose

**Plain-language primer (read before §1 if you are a non-domain engineer or a product owner).** A workflow defines the steps that take a regulated record (a deviation, a CAPA, a batch release, a CAPA closure) from open to closed. Module 4 is the engine that runs those workflows. When the workflow reaches a step that requires a human regulated decision, **Module 4 opens a "human-in-the-loop" gate** and sends the decision to whoever is authorised. When the human clicks Approve, **Module 4 brings up the Controlled Approval Modal** — the same modal everywhere — and asks the user to re-enter their password, state what they are approving (the "meaning of signature"), and give a reason. **Module 4 then writes the electronic signature**, links it to the record, captures a snapshot of the user's authority at that exact moment, and lets the workflow advance. RBAC says "you can enter this module"; Authority says "you can sign off"; Context says "but only for these scopes"; **Module 4 says "now write the signature, capture the meaning, link it to the record, and advance the workflow."** The four-layer model is shown in Diagram 0.4-A.

#### Diagram 0.4-A — Module 4 in the regulated-decision pipeline

```mermaid
flowchart LR
  A([Regulated state transition triggered]) --> B[URS-01 Auth — token + claims]
  B --> C[URS-02 RBAC — base role + permission matrix]
  C --> D[URS-03 Context — active context + scope check]
  D --> E[URS-04 Workflow runtime — node + transition + adapter]
  E --> F{HITL gate required?}
  F -- No --> G[State advances; audit row]
  F -- Yes --> H[Open HITL decision]
  H --> I[Resolver: resolveApprovalCandidates]
  I --> J[Notify candidates URS-30]
  J --> K[Candidate opens Controlled Approval Modal]
  K --> L[validateApprovalAction]
  L --> M[Re-auth + meaning + reason + MFA step-up if high risk]
  M --> N[Insert electronic_signatures row]
  N --> O[Insert approval_authority_snapshots row hash-chained]
  O --> P[Adapter applies state transition]
  P --> Q[URS-06 audit row]
```

Module 4 is the workflow template engine, the workflow runtime, the Controlled Approval Modal, the electronic-signature registry and ceremony, the approval-authority resolver, the HITL decision lifecycle and escalation engine, the adapter contract that lets every regulated entity (deviation, CAPA, complaint, batch record, document, training, etc.) plug into the workflow runtime in a uniform way, the template library import system with provenance, and the audit substrate for every regulated-decision event. It does not authenticate users (URS-01), does not gate module entry by base role (URS-02), does not constrain records by active context (URS-03), and does not own the Authority Profile catalogue (URS-05). It is the layer that **executes** regulated decisions, captures them as electronic signatures, and advances workflow state.

---

## 2. Scope

### 2.1 In scope

- The workflow template engine: `workflow_templates` and `workflow_template_versions` schemas, template lifecycle (draft → under_review → approved → effective → obsolete), versioning, and the controlled approval ceremony for new template versions.
- The workflow runtime: per-record workflow-instance state machine, transition application, node-resolution from the runtime's instance pointer, HITL gate creation when a regulated transition is reached.
- Per-node approval requirements (`workflow_node_approval_requirements`) including required authority keys, minimum approvers, segregation-of-duties requirement, approval mode (single / dual / sequential / parallel), final approver, secondary approver, override authority, electronic-signature requirement, source state, target state, entity type, workflow family.
- The HITL decision lifecycle: open → assigned → decided / escalated / expired, with `hitl_decisions` row per decision, `hitl_escalation_log` per escalation event, SLA timers, reminder schedules, and the queue model.
- The Controlled Approval Modal contract: front-end component, fields collected (`password`, `meaningOfSignature`, `reasonForChange`), forbidden client-supplied fields (`ip`, `userAgent`, `timestamp`, `performedBy`), multi-factor step-up integration for high-risk decisions, accessibility, internationalisation.
- The electronic-signature ceremony and registry: `electronic_signatures` table; signature components per 21 CFR Part 11 §11.200 (identification code + password; biometric MAY be added later as Class 1 change); meaning of signature per §11.50; signed content snapshot; signature/record linking per §11.70; signature invalidation on post-signature mutation; signature manifestation rendering in record detail views and exports.
- The approval-authority resolver: `resolveApprovalCandidates` (eligibility computation including segregation-of-duties), `validateApprovalAction` (per-decision eligibility check immediately before signature), `snapshotApprovalAuthority` (per-decision hash-chained authority snapshot).
- The adapter contract for regulated entities: deviation adapter, CAPA adapter, complaint adapter, document adapter, batch-record adapter, OOS / OOT adapter, RCA adapter, risk-assessment adapter, review adapter, finding adapter, inspection adapter, stability adapter, environmental-monitoring adapter, APQR adapter, regulatory-submission adapter, training adapter, screen-reader adapter, DQG adapter, GMP adapter, GDP adapter, equipment-qualification adapter, supplier-qualification adapter, URS-13 adapter, recall adapter; plus a documented `stub-adapter` only used during template authoring before a regulated entity is wired through its production adapter.
- Workflow template library import with provenance fields (`source_library_key`, `source_library_hash`, `source_library_semver`, `imported_by`, `imported_at`); template-approval ceremony for imported templates that requires the same controlled review and electronic signature as freshly authored templates.
- Override-authority resolution and audit, including the `AUTHORITY_OVERRIDE_USED` event and the dual-signature / extended-meaning rules for override.
- Audit substrate: workflow-template lifecycle events, workflow-instance events, HITL events, electronic-signature events, authority-snapshot events, override events, library-import events, adapter-registration events, signature-invalidation events.
- Reports: regulated-decision register, signature register, override register, escalation register, template-version coverage report, library-import register, signature-invalidation register, authority-snapshot integrity report.
- Front-end: Controlled Approval Modal, HITL inbox, workflow-template editor, workflow-template-version comparison, workflow-instance status, signature-detail viewer, override request and review.
- Cross-module wiring: every regulated module's regulated decisions traverse Module 4; URS-06 ingests audit rows; URS-30 delivers notifications; URS-35 preserves chains across restore.
- Periodic access review and audit-trail review obligations specific to Module 4 events.

### 2.2 Out of scope

- Authentication, multi-factor authentication, password policy, lockout, IP allowlist, session lifecycle, refresh-token rotation (URS-01).
- Permission matrix, role catalogue, access-governance lifecycle (URS-02).
- Active-context resolution and approval-scope check (URS-03).
- Authority Profile catalogue, scope rules, segregation-of-duties rule registry (URS-05).
- Master-data CRUD for tenants, sites, products, studies, suppliers (URS-07/08/09/10/11).
- Domain semantics for any regulated entity (every domain module owns its own state model and content rules; Module 4 owns the engine, not the domain).
- AI-driven decision-making (explicitly prohibited; AI suggestion-only paths route through MIRA / URS-32 with human acceptance required).

### 2.3 Closed launch decisions

| Identifier | Closed launch decision |
|---|---|
| DEC-04-01 | Workflow template lifecycle states are fixed at five values: `draft`, `under_review`, `approved`, `effective`, `obsolete`. The complete set of allowed transitions is: `draft → under_review`, `under_review → draft` (controlled "return for correction" path requiring a written reason and electronic signature; emits `WORKFLOW_TEMPLATE_RETURNED_FOR_CORRECTION`), `under_review → approved`, `approved → effective`, `effective → obsolete`, and `obsolete → effective` (controlled rollback only; requires Founder electronic signature plus QA + RA approval). All other transitions are forbidden. |
| DEC-04-02 | Approval modes are exactly four at launch: `single`, `dual`, `sequential`, `parallel`. Adding a mode is a Class 1 change. |
| DEC-04-03 | Per-node approval-requirement fields are exactly: `requiredAuthorityKeys[]`, `minApprovers`, `requiresSod`, `sodRuleId`, `approvalMode`, `finalApproverRequired`, `secondaryAuthorityProfileId`, `overrideAuthorityProfileId`, `esignRequired`, `fromState`, `toState`, `entityType`, `workflowFamily`. Adding a field is a Class 1 change. |
| DEC-04-04 | The Controlled Approval Modal collects exactly `password`, `meaningOfSignature`, `reasonForChange`. It NEVER sends `ip`, `userAgent`, `timestamp`, or `performedBy`. The back end derives those server-side. |
| DEC-04-05 | Electronic-signature components at launch are: identification code (the authenticated session) + password (re-entered in the Controlled Approval Modal). Biometric components are not in launch scope. Adding biometric is a Class 1 change with founder electronic signature. |
| DEC-04-06 | Multi-factor step-up is mandatory for: workflow-template approval, library import, override use, segregation-of-duties exception activation, founder-level decisions, and any high-risk action explicitly tagged on the workflow node. The launch list of high-risk actions is enumerated in §6.7.1. |
| DEC-04-07 | Hard-coded approval-requirement defaults (for example `'quality_approval'` fallback when a node has no requirement) are forbidden in production code paths. Every regulated entity's adapter MUST guarantee that node-bound requirements are in place; missing requirements MUST return `500 NODE_REQUIREMENT_MISSING` and SOC alert. |
| DEC-04-08 | Authority validation is performed twice per decision: once at HITL submission via the workflow runtime, and once again immediately before signature insertion via `esigService.createSignature` as defence-in-depth. Both calls share the same resolver implementation. |
| DEC-04-09 | The approval-authority snapshot is hash-chained per entity instance using SHA-256 with a PostgreSQL advisory lock scoped to `(tenant_id, entity_type, target_record_id)` to serialise writers for that single entity chain. A per-tenant lock is forbidden (see BR-04-16 rationale). The chain is restored intact across URS-35 backup / restore. |
| DEC-04-10 | Override use is a regulated event: it requires multi-factor step-up, an extended meaning text (≥ 80 characters), the original primary requirement archived in the snapshot, a Security Operations Centre alert, and dual-signature where the workflow node declares `override_dual_sign = true`. |
| DEC-04-11 | Library imports MUST capture provenance: source library key, source library hash (SHA-256 of canonical JSON), semantic version, imported-by user, imported-at timestamp; provenance survives into every workflow-instance record produced from the imported template. |
| DEC-04-12 | The launch adapter set covers every regulated entity in the launch URS suite (one adapter per consuming module URS-12 through URS-34 inclusive). The `stub-adapter` is permitted only during template authoring before a production adapter is wired; using `stub-adapter` in a production workflow-instance is a release blocker. |
| DEC-04-13 | Workflow-instance pointer changes (for example admin-driven repointing to a different template version) are forbidden after the first regulated decision has been signed; before the first signature, repointing requires QA electronic signature and is audited. |
| DEC-04-14 | HITL decisions follow a single canonical lifecycle: `open → assigned → decided | escalated | expired`. SLA timer values are tenant-configurable within validated bounds (default: 72 h to first acknowledgement, 5 working days to decision). Auto-escalation runs at the SLA boundary. |
| DEC-04-15 | Signature invalidation is automatic: any mutation of a signed entity's relevant fields (per its adapter's `signedContentFingerprint` definition) sets `signature.invalidated_at` and emits `SIGNATURE_INVALIDATED`. Invalidated signatures are visually marked in record detail views and excluded from "valid signature" report aggregations. |

---

## 3. User Roles and Permissions

### 3.1 Architecture

Module 4 consumes Layer 1 (base role) and Layer 2 (permission matrix) from URS-02; consumes Layer 2 (Authority Profile) plus Layer 3 (Delegation) from URS-05 through the resolver; consumes the active context and approval-scope check from URS-03. Module 4 owns three administrative surfaces: the workflow-template editor, the workflow-template library admin, and the override-request review queue. End-user surfaces are the HITL inbox, the Controlled Approval Modal, and the signature-detail viewer.

### 3.2 Role definitions

The five tenant-level base roles defined by URS-02 (admin, quality_lead, reviewer, auditor, viewer) and the two cross-tenant platform identities (platform_admin, super_admin) apply unchanged.

### 3.3 Authority Profiles consumed by Module 4

| Authority Profile (consumed) | Module 4 action gated |
|---|---|
| `tenant_admin_authority` | Read tenant workflow-template inventory; export regulated-decision register; configure HITL SLA values within validated bounds; manage the tenant override-request queue. |
| Domain-specific Authority Profiles (per URS-01 §3.3.3) | Sign at every regulated decision per the workflow node's `requiredAuthorityKeys[]`. |
| `final_quality_approver` | Final approval at workflow nodes whose requirement names this key. |
| `qp_release_authority` and jurisdictional variants | Batch-release decisions per URS-01 §3.3.3. |
| Override authority profiles (per node config) | Override use at the specified node when `override_authority_profile_id` is populated. |
| `global_quality_oversight` | Break-glass override of the entire approval requirement; emits `GLOBAL_SUPER_AUTHORITY_USED` per URS-01 / URS-03. |
| platform-only (no profile; identity check) | Edit workflow-template-engine configuration globals (e.g., approval-mode taxonomy, escalation engine configuration); platform-administrator identity required. |

### 3.4 Segregation-of-Duties rules

| SoD rule (consumed from URS-05) | Module 4 application |
|---|---|
| Author ≠ approver of same record | Resolver excludes the record's `created_by` and `last_modified_by` from approval candidates when the workflow node's `requiresSod = true`. |
| Reviewer ≠ final approver of same record | Resolver excludes prior-step reviewers from being final approver. |
| Delegator ≠ delegate on same record | Resolver excludes the delegator from approving via a delegation that is itself derived from the record. |
| Override actor ≠ originator of override request | The override-request review queue rejects same-actor override decisions. |

### 3.5 Worked examples

#### Worked example A — CAPA closure with single-approver workflow

A CAPA reaches its `pending_closure` node. The workflow node's requirement is `requiredAuthorityKeys = ['final_quality_approver']`, `approvalMode = single`, `requiresSod = true`. The resolver computes candidates: users holding `final_quality_approver` in scope for the CAPA's site / product, excluding the CAPA's `created_by` (Sarah) due to segregation of duties. Vimal is a candidate. Vimal opens the HITL inbox, picks the CAPA, opens the Controlled Approval Modal, re-authenticates, states "I approve closure of CAPA-2026-0044 having reviewed the effectiveness check", gives the reason "effectiveness verified per CAPA SOP". `validateApprovalAction` runs; `esigService.createSignature` runs; the snapshot row records Vimal's authority profile, scope match for site / product, segregation-of-duties verdict (passed; not creator), claims version. The CAPA adapter advances the state from `pending_closure` to `closed`. URS-06 audit row links the action and the signature.

#### Worked example B — Batch release with parallel dual approval (`qp_eu` + `ap_india`)

A batch is registered for both EU and India markets. The workflow node's requirement is `requiredAuthorityKeys = ['qp_eu', 'ap_india']`, `approvalMode = parallel`, `minApprovers = 2`, `finalApproverRequired = true`. The resolver returns candidates per Authority Profile. Two distinct humans sign in any order through the Controlled Approval Modal; each signature triggers `validateApprovalAction`, `esigService.createSignature`, and a snapshot row. The runtime tracks completion: only after both signatures are present does the batch adapter execute the `released` transition. The audit chain links both signatures to the same regulated record.

#### Worked example C — Override authority used when primary approver unavailable

A deviation reaches its closure node. The primary requirement is `requiredAuthorityKeys = ['final_quality_approver']`. The configured `override_authority_profile_id` is `quality_oversight_admin` and `override_dual_sign = true`. No `final_quality_approver` is reachable within the SLA. The QA Director (holds `quality_oversight_admin`) opens the override workflow. The Controlled Approval Modal demands multi-factor step-up plus extended meaning text ("Primary final_quality_approver unavailable for 7 days due to leave coverage; override approved per CC-2026-0098 to prevent batch hold"; ≥ 80 characters). A second `quality_oversight_admin` co-signs (dual-signature). Both signatures are inserted; the snapshot rows tag `override = true` with the original primary requirement archived; `AUTHORITY_OVERRIDE_USED` is emitted; the Security Operations Centre receives the alert; the deviation closes.

#### Worked example D — HITL escalation when SLA exceeded

A complaint reaches its triage decision. Initial assignee is the on-call complaints handler. The SLA is 24 hours to first acknowledgement; the handler is unavailable. The HITL decision auto-escalates per the configured rule (escalation target = `complaint_closure_approver` peer pool); a `HITL_DECISION_ESCALATED` row is appended to `hitl_escalation_log`; URS-30 sends notification; the next available holder accepts and decides. Audit captures the full escalation history.

#### Worked example E — Workflow template approval ceremony

A new workflow template for a tenant-defined process is authored by the QA Manager (state `draft`); reviewed by a peer (state `under_review`); approved by the Head of Quality (state `approved`) through the Controlled Approval Modal with multi-factor step-up; published to `effective`. Each transition is electronically signed. Library-import provenance fields are null on this freshly authored template. A subsequent edit forks a new draft version; the old version remains effective until the new version is approved and made effective; superseded versions become `obsolete` but their content is retained for historical traceability.

#### Worked example F — Adapter pattern for a new regulated module

A new module ships with its regulated entity. Engineering writes a deviation-style adapter implementing the Module 4 adapter contract: methods to read the entity's current node, list available transitions, apply a transition, and compute `signedContentFingerprint`. The adapter is registered through the platform-administrator-only adapter-registration endpoint with electronic signature. Platform validators run the adapter contract conformance test pack. From this point on, the new module's regulated decisions traverse the standard Module 4 pipeline — Controlled Approval Modal, electronic signature, snapshot, audit — without any module-specific bypass.

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

| Action (within Module 4) | viewer | reviewer | quality_lead | auditor | admin | platform_admin | super_admin | system identity | Authority Profile |
|---|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|---|
| Open HITL inbox (own decisions) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | — | — |
| Sign a regulated decision through Controlled Approval Modal | per node | per node | per node | — | per node | per node | per node | — | required Authority Profile per node |
| Read workflow-template inventory (own tenant) | — | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | — | — |
| Author / edit workflow template (draft state) | — | — | ✓ | — | ✓ | ✓ | ✓ | — | — |
| Submit template for review | — | — | ✓ + sign | — | ✓ + sign | ✓ + sign | ✓ + sign | — | `tenant_admin_authority` |
| Approve template (move to `approved`) | — | — | — | — | ✓ + sign + MFA step-up | ✓ + sign + MFA step-up | ✓ + sign + MFA step-up | — | `final_quality_approver` |
| Publish approved template (to `effective`) | — | — | — | — | ✓ + sign | ✓ + sign | ✓ + sign | — | `tenant_admin_authority` |
| Retire template (`effective → obsolete`) | — | — | — | — | ✓ + sign | ✓ + sign | ✓ + sign | — | `tenant_admin_authority` |
| Roll back `obsolete → effective` (controlled) | — | — | — | — | — | ✓ + sign + executive authority | ✓ + sign + executive authority | — | Founder + QA + RA |
| Import library template | — | — | — | — | ✓ + sign + MFA step-up | ✓ + sign + MFA step-up | ✓ + sign + MFA step-up | — | `tenant_admin_authority` |
| Register / update regulated-entity adapter | — | — | — | — | — | ✓ + sign + MFA step-up | ✓ + sign + MFA step-up | — | platform-identity |
| Submit override request | — | — | ✓ + sign | — | ✓ + sign | ✓ + sign | ✓ + sign | — | originator's Authority Profile |
| Approve override (per workflow override config) | — | — | per profile | — | per profile | per profile | per profile | — | `override_authority_profile_id` |
| Read regulated-decision register | — | — | — | ✓ | ✓ | ✓ | ✓ | — | — |
| Export regulated-decision register | — | — | — | — | ✓ + sign | ✓ + sign | ✓ + sign | — | `tenant_admin_authority` |
| Read signature invalidation register | — | — | — | ✓ | ✓ | ✓ | ✓ | — | — |
| Use `global_quality_oversight` super-authority bypass | — | — | — | — | — | — | — | — | `global_quality_oversight` (auto-expiry; SOC alert; extended meaning) |

There is **no `tenant_admin` base role** (consistent with URS-02). External identities (URS-01 §3.2.3) cannot reach Module 4's administrative surface; they participate only as scope-bound viewers with no authority-bearing capability.

#### 3.6.1 Platform-identity tenant actions — controlled support / break-glass posture

Per URS-02 §3.6.1, platform identities (`platform_admin`, `super_admin`) MAY perform tenant-scoped Module 4 actions only under a controlled support / break-glass posture: target tenant identifier, business-justification reason, support-ticket / customer-reference identifier, electronic signature, `PLATFORM_TENANT_ACCESS_USED` audit emit, Security Operations Centre alert. Use outside the envelope returns `PLATFORM_TENANT_ACCESS_DENIED`.

---

## 4. End-to-End User Journeys

### J-01 — Single-approver regulated decision (CAPA closure)

- Trigger: a CAPA reaches the `pending_closure` node.
- Steps: workflow runtime opens HITL decision; resolver computes candidates; URS-30 notifies; assignee opens HITL inbox; opens Controlled Approval Modal; back end runs `validateApprovalAction`; modal collects password, meaning, reason; back end inserts electronic-signature row, inserts snapshot row, applies CAPA adapter transition.
- Audit: `HITL_DECISION_OPENED`, `HITL_DECISION_ASSIGNED`, `ESIG_CREATED`, `APPROVAL_AUTHORITY_VALIDATED`, `APPROVAL_AUTHORITY_SNAPSHOT_WRITTEN`, `WORKFLOW_INSTANCE_TRANSITIONED`.

```mermaid
sequenceDiagram
  autonumber
  participant U as Approver
  participant FE as HITL inbox
  participant CAM as Controlled Approval Modal
  participant API as Workflow API
  participant RES as Authority Resolver
  participant ESIG as Electronic Signatures
  participant SNAP as Authority Snapshots
  participant ADP as CAPA Adapter
  participant AUD as Audit Log

  U->>FE: open HITL inbox
  U->>CAM: re-auth + meaning + reason
  CAM->>API: POST /capas/:id/approve
  API->>RES: validateApprovalAction(actor, node, record)
  alt invalid
    RES-->>API: deny
    API-->>CAM: 403 APPROVAL_AUTHORITY_DENIED
  else valid
    API->>ESIG: createSignature (server-derived metadata)
    ESIG->>RES: validateApprovalAction (defence in depth)
    RES-->>ESIG: ok
    ESIG-->>API: e_sig_id
    API->>SNAP: snapshotApprovalAuthority (hash-chained)
    API->>ADP: applyTransition(pending_closure → closed)
    API->>AUD: hash-chained events
    API-->>CAM: 200
  end
```

### J-02 — Parallel dual approval (batch release: qp_eu + ap_india)

- Trigger: dual-registered batch reaches release node.
- Steps: runtime opens HITL decision with `approvalMode=parallel`, `minApprovers=2`; both candidate pools notified; each signer follows the same Controlled Approval Modal flow; runtime tracks `signed_count`; only when both signatures are present does the batch adapter apply the `released` transition.
- Audit: two `ESIG_CREATED` rows linked to the same workflow-instance; one `WORKFLOW_INSTANCE_TRANSITIONED`.

```mermaid
sequenceDiagram
  autonumber
  participant U1 as QP-EU
  participant U2 as AP-India
  participant API as Workflow API
  participant RES as Authority Resolver
  participant ESIG as E-Signatures
  participant ADP as Batch Adapter

  U1->>API: POST /batches/:id/approve (qp_eu)
  API->>RES: validateApprovalAction
  RES-->>API: ok
  API->>ESIG: createSignature
  ESIG-->>API: e_sig_id_1
  API->>API: signed_count = 1 / 2
  U2->>API: POST /batches/:id/approve (ap_india)
  API->>RES: validateApprovalAction
  RES-->>API: ok
  API->>ESIG: createSignature
  ESIG-->>API: e_sig_id_2
  API->>API: signed_count = 2 / 2
  API->>ADP: applyTransition(pending_release → released)
```

### J-03 — Sequential approval (template approval ceremony)

- Trigger: workflow template advances `under_review → approved`.
- Steps: review captured first; final approver signs second; sequence enforced by the runtime — second signer cannot act until first is recorded.
- Audit: chain of two `ESIG_CREATED` rows in declared order.

### J-04 — HITL escalation on SLA breach

- Trigger: HITL decision in `assigned` state passes its acknowledgement SLA.
- Steps: scheduler triggers escalation; runtime appends `hitl_escalation_log` row; reassigns to escalation target pool; URS-30 notifies; new candidates can act.
- Audit: `HITL_DECISION_ESCALATED`, `HITL_DECISION_ASSIGNED` (re-assignment).

### J-05 — Override authority used

- Trigger: original requirement cannot be satisfied within SLA; override workflow invoked.
- Steps: originator submits override request; override approver(s) per `override_authority_profile_id` and `override_dual_sign` decide; Controlled Approval Modal demands MFA step-up plus extended meaning ≥ 80 characters; both signatures inserted (where dual); snapshot tagged `override=true`; SOC alert; original primary requirement archived in snapshot.
- Audit: `AUTHORITY_OVERRIDE_REQUESTED`, `AUTHORITY_OVERRIDE_APPROVED`, `AUTHORITY_OVERRIDE_USED`, `ESIG_CREATED` per signer.

### J-06 — Library template import with provenance

- Trigger: platform administrator imports a library template into a tenant.
- Steps: import endpoint validates source library hash (SHA-256 of canonical JSON); provenance fields populated; the imported template lands in `draft`; the same approval ceremony as a freshly authored template applies before it can become `effective`.
- Audit: `LIBRARY_TEMPLATE_IMPORTED` with provenance fields; subsequent `WORKFLOW_TEMPLATE_APPROVED` and `WORKFLOW_TEMPLATE_EFFECTIVE` events follow.

### J-07 — Workflow template version supersession

- Trigger: a new draft version is approved while the current effective version is still in use.
- Steps: new version moves through the lifecycle; on publication, the old version is marked `obsolete`; in-flight workflow instances continue under the version they were created against (per DEC-04-13); newly created instances use the new version.
- Audit: `WORKFLOW_TEMPLATE_OBSOLETE` for the old version; `WORKFLOW_TEMPLATE_EFFECTIVE` for the new.

### J-08 — Adapter contract compliance test on registration

- Trigger: platform administrator registers a new adapter for a regulated entity.
- Steps: registration endpoint runs the adapter contract conformance test pack synchronously; failures block registration; on success, an audit row records the registration with electronic signature and contract-test evidence reference.
- Audit: `ADAPTER_REGISTERED` or `ADAPTER_REGISTRATION_REJECTED`.

### J-09 — Signature invalidation on post-signature mutation

- Trigger: a regulated entity is mutated after signature.
- Steps: adapter computes new `signedContentFingerprint`; mismatch detected; signature flagged `invalidated_at`; `SIGNATURE_INVALIDATED` event; record detail view shows the visual marker; report aggregations for "valid signatures" exclude the invalidated row but retain the historical link.
- Audit: `SIGNATURE_INVALIDATED`.

### J-10 — Periodic access review covers Module 4 events

- Trigger: per URS-01 §12.10, quarterly review window opens.
- Steps: reviewer opens the regulated-decision register filtered to the period; verifies signatures per Authority Profile, override use, escalations, signature invalidations; signs the attestation.

### J-11 — Periodic audit-trail review covers Module 4 high-risk events

- Trigger: per URS-01 §12.11.
- Steps: high-risk Module 4 events reviewed within one business day: `AUTHORITY_OVERRIDE_USED`, `SIGNATURE_INVALIDATED` clusters, `HITL_DECISION_ESCALATED` clusters, `LIBRARY_TEMPLATE_IMPORTED`, `ADAPTER_REGISTRATION_REJECTED`.

### J-12 — Failed authority validation at signature

- Trigger: actor reaches the Controlled Approval Modal but their authority is no longer valid by the time `esigService.createSignature` runs (e.g., authority revoked between modal open and submit).
- Steps: defence-in-depth `validateApprovalAction` inside the e-signature service detects the loss; signature is not created; `ESIG_CREATION_DENIED` recorded; HITL decision remains open; SOC alert if pattern suggests targeted attack.

### J-13 — Multi-factor step-up failure during high-risk decision

- Trigger: high-risk decision (template approval / library import / override use) requires MFA step-up; user fails the step-up.
- Steps: signature not created; HITL decision remains open; counters increment; sustained failures escalate to lockout per URS-01.

### J-14 — Workflow instance pointer repointing (pre-signature only)

- Trigger: QA needs to repoint an in-flight workflow instance to a different template version because of a defect.
- Steps: pre-signature only (DEC-04-13); QA submits repointing through the controlled endpoint with reason; QA electronic signature; audit row; instance pointer updated.

### J-15 — Pre-signature delegation expiry

- Trigger: assignee's delegation expires before they decide.
- Steps: resolver re-checks at submit; delegation no longer active; `validateApprovalAction` denies; HITL decision remains open; assignee sees "Your delegation expired; the decision has been reassigned."

### J-16 — Non-HITL signing path defence-in-depth

- Trigger: a programmatic test attempts to call `esigService.createSignature` directly (bypassing HITL).
- Steps: e-signature service runs `validateApprovalAction` itself; if the actor lacks the required authority for the target record, signature is denied; this defence-in-depth prevents bypass when callers other than HITL invoke the service.

### J-17 — Stub adapter rejected in production workflow

- Trigger: a workflow template referencing `stub-adapter` is attempted to be moved to `effective`.
- Steps: lifecycle gate detects `stub-adapter`; rejects `STUB_ADAPTER_NOT_ALLOWED_IN_PRODUCTION`; template remains in `approved`.

### J-18 — Cross-context attempt during workflow

- Trigger: a regulated decision endpoint is called with a record outside the active context.
- Steps: URS-03 cross-context filter rejects with `CROSS_CONTEXT_DENIED`; HITL decision and signature creation never reached.

### J-19 — Signature manifestation in record detail view

- Trigger: user opens a regulated record's detail view.
- Steps: front end renders the signature panel showing actor, role, meaning, reason, signed-at, IP, user agent (last 200 chars normalised), MFA step-up flag where applicable, hash-chain integrity badge.

### J-20 — Approval-snapshot integrity verifier endpoint

- Trigger: auditor opens the snapshot integrity report.
- Steps: integrity verifier recomputes the hash chain across a configured window; returns start hash, end hash, row count, validation status; export available.

### J-21 — Workflow template version coverage report

- Trigger: QA generates the coverage report ahead of an inspection.
- Steps: report enumerates every regulated entity, the active template version per entity type, and lists in-flight instances by template version; flags any entity with no active template.

### J-22 — Template editor field-level validation

- Trigger: template author submits a draft with an empty `requiredAuthorityKeys[]` array on a regulated transition.
- Steps: validator rejects `REQUIRED_AUTHORITY_KEYS_EMPTY`; editor displays inline error.

### J-23 — Override request rejected by reviewer

- Trigger: an override request is opened but the reviewer judges the rationale insufficient.
- Steps: reviewer rejects with reason; `AUTHORITY_OVERRIDE_REJECTED`; original HITL decision continues to wait for the primary requirement.

### J-24 — Bulk decisions honour per-record authority

- Trigger: user selects 25 HITL decisions in the inbox and clicks Bulk-approve.
- Steps: each decision's `validateApprovalAction` runs independently; each is signed independently; failures return per-row diagnostics.

### J-25 — Sequential mode out-of-order attempt

- Trigger: a user attempts to sign a sequential-mode node out of order.
- Steps: runtime detects the predecessor signature is missing; rejects `SEQUENTIAL_OUT_OF_ORDER`; signature not created.

### J-26 — Resolver outage during HITL submission

- Trigger: the resolver is unreachable when the user submits.
- Steps: e-signature service fails closed; signature not created; HITL decision remains open; user sees "Approval temporarily unavailable; please retry"; SOC alert.

### J-27 — Periodic re-validation of workflow templates

- Trigger: per the tenant's annual periodic review (URS-01 §12.10).
- Steps: each effective template is reviewed; if no changes are needed, a re-validation electronic signature is recorded; if changes are needed, a new draft fork is started.

### J-28 — Signature export contains integrity manifest

- Trigger: administrator exports the signature register.
- Steps: export includes hash-chain start hash, end hash, row count, validation status, and electronic-signature row hashes; export itself is electronically signed.

---

## 5. Front-End Expected State

### 5.1 Navigation and information architecture

| Route | Purpose | Guards |
|---|---|---|
| `/inbox` | HITL inbox for the caller's open decisions | authenticated |
| `/inbox/:id` | HITL decision detail | authenticated |
| `/admin/workflow-templates` | Workflow-template inventory | `RoleGuard` admin tier |
| `/admin/workflow-templates/:id` | Template detail and version comparison | as above |
| `/admin/workflow-templates/:id/edit` | Template editor (draft state only) | as above |
| `/admin/workflow-library` | Library template browser and import | as above |
| `/admin/adapters` | Regulated-entity adapter registry | `RoleGuard platform_admin/super_admin` |
| `/admin/overrides` | Override-request review queue | `RoleGuard` admin tier |
| `/admin/governance/decisions` | Regulated-decision register | `RoleGuard` admin tier or `auditor` |
| `/admin/governance/signatures` | Signature register and integrity verifier | as above |

### 5.2 Screens

#### `/inbox` — HITL inbox

Columns: record reference, module, transition, candidate role required, due date, priority, action button. Filters: module, status, due window. Empty state: "No regulated decisions pending."

#### Controlled Approval Modal (component, not a route)

Fields: `password`, `meaningOfSignature` (≥ 8 chars; ≥ 80 chars for override / high-risk), `reasonForChange` (≥ 8 chars). Re-authentication on every submission. Multi-factor step-up gate where applicable. Forbidden client-supplied fields are not in the schema; back end ignores any if sent. Banner on out-of-scope or missing-context (per URS-03).

#### `/admin/workflow-templates` — inventory

Columns: name, version, lifecycle state, effective-from, effective-to, in-flight instances, last modified by, last modified at. Action menu: edit (when draft), submit for review, approve, publish, retire, fork new draft.

#### `/admin/workflow-templates/:id/edit` — editor

State diagram canvas with nodes and edges; per-node panel for approval requirements, transitions, validation rules; field-level errors inline; submit blocked while invalid.

#### `/admin/workflow-library`

Library entries with provenance metadata and integrity hashes; "Import" button opens the import flow with MFA step-up.

#### `/admin/adapters`

Adapter inventory with conformance-test status; "Register / update adapter" requires platform identity plus MFA step-up.

#### `/admin/overrides`

Open / closed override requests with originator, target, requested authority, decision, signers.

#### `/admin/governance/decisions` and `/admin/governance/signatures`

Regulated-decision register and signature register with filters, integrity badges, export.

### 5.3 Forms and field rules

| Field identifier | Label | Type | Required | Validation | Source | Editability by status | Audit | Regulatory relevance |
|---|---|---|---|---|---|---|---|---|
| `password` | Password | string (masked) | Yes | `.min(1)` | user input | every regulated submission | not logged | 21 CFR Part 11 §11.300 |
| `meaningOfSignature` | Meaning of signature | string | Yes | `.min(8).max(500)` (≥ 80 for override / high-risk) | user input | regulated submission | yes | 21 CFR Part 11 §11.50, §11.100 |
| `reasonForChange` | Reason for change | string | Yes | `.min(8).max(2000)` | user input | regulated submission | yes | 21 CFR Part 11 §11.10(e) |
| `mfaToken` | MFA step-up code | string | Yes (high-risk) | `.length(6).regex(/^\d+$/)` | user input | high-risk submission | not logged | 21 CFR Part 11 §11.10(g) |
| `templateName` | Template name | string | Yes | `.min(2).max(120)` | user input | template draft | yes | EU GMP Annex 11 §4 |
| `templateVersion` | Template version | string | Yes (server-derived) | semver-compatible | server | template publish | yes | EU GMP Annex 11 §10 |
| `nodeRequiredAuthorityKeys` | Required authority keys | string[] | Yes (regulated transitions) | each in URS-05 catalogue; non-empty per DEC-04-07 | user input | template draft | yes | EU GMP Annex 22 §7 (where applicable) / 21 CFR Part 11 §11.10(g) |
| `nodeApprovalMode` | Approval mode | enum | Yes | `single | dual | sequential | parallel` | user input | template draft | yes | 21 CFR Part 11 §11.10(g) |
| `nodeMinApprovers` | Minimum approvers | int | Yes | `1..5` | user input | template draft | yes | EU GMP Annex 11 §10 |
| `nodeRequiresSod` | SoD required | boolean | Yes | strict | user input | template draft | yes | 21 CFR Part 11 §11.10(d) |
| `nodeOverrideAuthorityProfileId` | Override Authority Profile | uuid | conditional | profile must be regulated | user input | template draft | yes | 21 CFR Part 11 §11.10(g) |
| `libraryProvenanceHash` | Library hash | string | Yes (library import) | SHA-256 of canonical JSON | client envelope | import | yes | EU GMP Annex 11 §3 |
| `librarySemver` | Library version | string | Yes (library import) | semver | client envelope | import | yes | EU GMP Annex 11 §3 |
| `overrideRationale` | Override rationale | string | Yes (override use) | `.min(80).max(4000)` | user input | override | yes | 21 CFR Part 11 §11.10(g) |
| `decisionExportRange` | Range | datetime range | Yes (export) | start ≤ end | user input | export | yes | 21 CFR Part 11 §11.10(e) |
| `decisionExportFormat` | Format | enum | Yes (export) | `csv | pdf | jsonl` | user input | export | yes | 21 CFR Part 11 §11.10(e) |

### 5.4 UI state machines

#### Workflow template lifecycle

```mermaid
stateDiagram-v2
  [*] --> draft
  draft --> under_review: submit for review (e-sign)
  under_review --> draft: return for correction (e-sign)
  under_review --> approved: approve (e-sign + MFA step-up)
  approved --> effective: publish (e-sign)
  effective --> obsolete: retire (e-sign)
  obsolete --> effective: controlled rollback (Founder + QA + RA + e-sign)
  obsolete --> [*]
  effective --> [*]: superseded by new effective version
```

#### HITL decision lifecycle

```mermaid
stateDiagram-v2
  [*] --> open: workflow runtime opens decision
  open --> assigned: candidate accepts / runtime auto-assigns
  assigned --> decided: candidate signs (e-sign)
  assigned --> escalated: SLA breach
  escalated --> assigned: re-assigned to escalation target
  assigned --> expired: hard expiry
  decided --> [*]
  expired --> [*]
```

#### Electronic signature row lifecycle

```mermaid
stateDiagram-v2
  [*] --> created: insert via createSignature
  created --> invalidated: signed entity mutated post-signature
  invalidated --> [*]
  created --> [*]
```

### 5.5 UX safety controls

- Controlled Approval Modal disables submit during async submission.
- Sequential mode visually shows the required signing order with the current step highlighted.
- Parallel mode shows progress (`signed_count / minApprovers`).
- Override request UI demands the extended-meaning text and visually flags the regulated nature.
- Signature panel shows hash-chain integrity badge per signature; if integrity verifier flags inconsistency, the panel surfaces "Integrity check failed — investigate" without exposing internal hashes.
- Stale-context banner per URS-03 disables Controlled Approval Modal submission until context is re-resolved.
- HITL inbox auto-refreshes assignee changes (escalations) so the user does not act on stale assignment.
- Multi-factor step-up failure does not surface counters to the user; it surfaces "Please retry" and silently increments lockout state per URS-01.

---

## 6. Back-End Expected State

### 6.1 Domain entities

- `workflow_templates`, `workflow_template_versions`, `workflow_template_library`, `workflow_template_imports`.
- `workflow_node_approval_requirements`, `workflow_template_approvals`.
- `workflow_instances`, `workflow_instance_pointers`, `workflow_transitions_log`.
- `hitl_decisions`, `hitl_decision_signatures` (per-slot signature linkage for dual / sequential / parallel approvals), `hitl_escalation_log`, `hitl_gate_config`.
- `electronic_signatures`, `signature_invalidations`.
- `approval_authority_snapshots` (hash-chained).
- `regulated_entity_adapters`, `adapter_registrations`.
- `override_requests`, `override_decisions`.
- `audit_log` (Module 4 governance subset; primary owner URS-06).

### 6.1.1 Diagram 6.1-A — Module 4 data model (entity-relationship overview)

```mermaid
erDiagram
  WORKFLOW_TEMPLATES ||--o{ WORKFLOW_TEMPLATE_VERSIONS : has
  WORKFLOW_TEMPLATE_VERSIONS ||--o{ WORKFLOW_NODE_APPROVAL_REQUIREMENTS : defines
  WORKFLOW_TEMPLATE_VERSIONS ||--o{ WORKFLOW_TEMPLATE_APPROVALS : approved_by
  WORKFLOW_TEMPLATE_LIBRARY ||--o{ WORKFLOW_TEMPLATE_IMPORTS : imported_into
  WORKFLOW_TEMPLATE_VERSIONS ||--o{ WORKFLOW_INSTANCES : instantiated_as
  WORKFLOW_INSTANCES ||--o{ WORKFLOW_TRANSITIONS_LOG : logs
  WORKFLOW_INSTANCES ||--o{ HITL_DECISIONS : opens
  HITL_DECISIONS ||--o{ HITL_ESCALATION_LOG : escalations
  HITL_DECISIONS ||--o{ HITL_DECISION_SIGNATURES : has_slots
  ELECTRONIC_SIGNATURES ||--|| HITL_DECISION_SIGNATURES : binds_to_slot
  ELECTRONIC_SIGNATURES ||--o{ SIGNATURE_INVALIDATIONS : invalidations
  ELECTRONIC_SIGNATURES ||--|| APPROVAL_AUTHORITY_SNAPSHOTS : per_signature
  WORKFLOW_TRANSITIONS_LOG ||--o| HITL_DECISIONS : caused_by
  REGULATED_ENTITY_ADAPTERS ||--o{ ADAPTER_REGISTRATIONS : versions
  HITL_DECISIONS ||--o{ OVERRIDE_REQUESTS : may_have
  OVERRIDE_REQUESTS ||--o{ OVERRIDE_DECISIONS : decisions
```

The `HITL_DECISIONS ||--o{ HITL_DECISION_SIGNATURES` cardinality is mandatory because Module 4 supports dual, sequential, and parallel approval modes (DEC-04-02). One HITL decision may legitimately require multiple signatures; the `hitl_decision_signatures` join table is therefore the authoritative slot-to-signature linkage. The `WORKFLOW_TRANSITIONS_LOG ||--o| HITL_DECISIONS` link is optional because non-regulated transitions advance without an HITL decision (see §6.2 `transition_type` discriminator).

#### 6.1.2 Diagram 6.1-B — Multi-signer data model (slot-to-signature linkage)

```mermaid
flowchart TD
  N["workflow_node_approval_requirements<br/>(approvalMode, minApprovers, requiredAuthorityKeys[])"]
  HD["hitl_decisions<br/>(one row per decision instance)"]
  S1["hitl_decision_signatures<br/>slot 1 (signing_order = 1)"]
  S2["hitl_decision_signatures<br/>slot 2 (signing_order = 2)"]
  Sn["hitl_decision_signatures<br/>slot n"]
  E1["electronic_signatures<br/>(signature row 1)"]
  E2["electronic_signatures<br/>(signature row 2)"]
  En["electronic_signatures<br/>(signature row n)"]
  AS1["approval_authority_snapshots<br/>(snapshot row 1, hash-chained)"]
  AS2["approval_authority_snapshots<br/>(snapshot row 2, hash-chained)"]
  ASn["approval_authority_snapshots<br/>(snapshot row n, hash-chained)"]
  WT["workflow_transitions_log<br/>(committed only after slots are satisfied)"]

  N --> HD
  HD --> S1
  HD --> S2
  HD --> Sn
  S1 --> E1
  S2 --> E2
  Sn --> En
  E1 --> AS1
  E2 --> AS2
  En --> ASn
  S1 -.-> WT
  S2 -.-> WT
  Sn -.-> WT
```

Single-mode decisions use one slot. Dual-mode decisions use two slots with distinct signers (uniqueness on `(hitl_decision_id, signer_user_id)` enforced). Sequential-mode decisions use ordered slots (`signing_order`) with strict order enforcement at runtime (BR-04-06). Parallel-mode decisions use slots that may sign in any order, but each unique slot is bound to a unique signer (BR-04-07). The workflow transition (`workflow_transitions_log`) commits only after all required slots are satisfied per the node's `minApprovers` and `finalApproverRequired` rules (BR-04-05).

### 6.2 Data model requirements

| Entity | Purpose | Key fields | Required | Unique | Tenant isolation | Versioning | Retention | Soft-delete | Audit | E-sig link |
|---|---|---|---|---|---|---|---|---|---|---|
| `workflow_templates` | Logical template | `id`, `tenant_id` (nullable for global), `name`, `workflow_family`, `entity_type`, `created_by`, `lifecycle_state` | all | unique(`tenant_id`, `name`, `entity_type`) | RLS on `tenant_id` (NULL allowed for global) | none | retain | yes (soft) | yes | yes |
| `workflow_template_versions` | Immutable version snapshot | `id`, `template_id`, `semver`, `definition_jsonb`, `created_by`, `created_at`, `lifecycle_state`, `library_provenance_jsonb` (nullable) | all | unique(`template_id`, `semver`) | RLS via template | versioned | retain | not applicable | yes | yes |
| `workflow_node_approval_requirements` | Per-node approval rules | `id`, `template_version_id`, `node_key`, `required_authority_keys`, `min_approvers`, `requires_sod`, `sod_rule_id`, `approval_mode`, `final_approver_required`, `secondary_authority_profile_id`, `override_authority_profile_id`, `override_dual_sign`, `esign_required`, `from_state`, `to_state`, `entity_type`, `workflow_family` | all required fields | unique(`template_version_id`, `node_key`) | RLS via template version | none | retain | not applicable | yes | yes |
| `workflow_template_approvals` | Approval ceremony record (one row per ceremony step; supports multi-step template approval such as J-03 sequential review + final approval) | `id`, `template_version_id`, `approval_step_key` (e.g., `peer_review`, `qa_lead_review`, `final_approval`), `approval_sequence` (integer; declared signing order), `required_authority_key`, `actor_user_id`, `decision` (`approved` / `rejected` / `returned_for_correction`), `e_sig_id`, `signed_at` | all | unique(`template_version_id`, `approval_step_key`); unique(`template_version_id`, `actor_user_id`, `approval_step_key`) | RLS via template | none | retain | not applicable | yes | yes |
| `workflow_template_library` | Library catalogue | `id`, `library_key`, `semver`, `source_hash`, `definition_jsonb`, `published_at` | all | unique(`library_key`, `semver`) | platform-context | versioned | retain | not applicable | yes | yes |
| `workflow_template_imports` | Per-import provenance | `id`, `tenant_id`, `library_key`, `source_semver`, `source_hash`, `imported_by`, `imported_at`, `e_sig_id` | all | unique(`tenant_id`, `library_key`, `imported_at`) | RLS on `tenant_id` | none | retain | not applicable | yes | yes |
| `workflow_instances` | Per-record instance | `id`, `tenant_id`, `template_version_id`, `entity_type`, `target_record_id`, `current_node_key`, `created_by`, `created_at` | all | unique(`tenant_id`, `entity_type`, `target_record_id`) | RLS on `tenant_id` | none | seven years | not applicable | yes | yes per transition |
| `workflow_transitions_log` | Per-transition row | `id`, `instance_id`, `from_node`, `to_node`, `actor_user_id`, `transition_type` (`non_regulated` / `regulated_single` / `regulated_multi`), `hitl_decision_id` (nullable; populated for regulated transitions), `e_sig_id` (nullable; populated for regulated_single; for regulated_multi the slot signatures are reachable via `hitl_decision_signatures`), `final_signature_at` (nullable; populated for regulated transitions; equals the timestamp of the slot that completed the requirement), `transitioned_at` | core fields | none | RLS via instance | append-only | seven years | not applicable | self | conditional |
| `hitl_decisions` | Per-decision record (one row per decision instance, regardless of approval mode) | `id`, `instance_id`, `node_key`, `entity_type`, `target_record_id`, `status`, `assigned_to_user_id` (nullable), `due_at`, `signed_count`, `min_approvers`, `approval_mode` (denormalised from `workflow_node_approval_requirements` for runtime efficiency), `created_at`, `decided_at` | core fields | unique active(`instance_id`, `node_key`) | RLS via instance | none | seven years | yes | yes | yes (per slot via `hitl_decision_signatures`) |
| `hitl_decision_signatures` | Per-slot signature linkage (mandatory for dual / sequential / parallel; also used in single mode with one row) | `id`, `hitl_decision_id`, `e_sig_id`, `signer_user_id`, `authority_profile_key`, `signing_order` (integer; meaningful for sequential mode), `slot_key` (e.g., `primary`, `secondary`, `final_approver`, `qp_eu`, `ap_india`), `decision` (`approved` / `rejected`), `signed_at`, `created_at` | all | unique(`hitl_decision_id`, `e_sig_id`); unique(`hitl_decision_id`, `signer_user_id`) (the same human MUST NOT satisfy two slots, regardless of mode); unique(`hitl_decision_id`, `slot_key`) | RLS via decision | none | seven years | not applicable | yes | yes |
| `hitl_escalation_log` | Per-escalation row | `id`, `hitl_decision_id`, `from_assignee`, `to_assignee_pool`, `reason`, `escalated_at` | all | none | RLS via decision | append-only | seven years | not applicable | self | not applicable |
| `hitl_gate_config` | Per-tenant SLA values | `tenant_id`, `acknowledgement_sla_hours`, `decision_sla_business_days`, `escalation_target_pool_id`, `version`, `effective_from`, `effective_to` | all | unique(`tenant_id`, `version`) | RLS on `tenant_id` | versioned | retain | not applicable | yes | yes |
| `electronic_signatures` | Signature registry | `id`, `signed_by`, `tenant_id`, `ip`, `user_agent`, `signed_at`, `meaning`, `reason`, `mfa_step_up_used`, `content_snapshot_jsonb`, `content_fingerprint`, `invalidated_at` (nullable) | all except `invalidated_at` | none | RLS on `tenant_id` | none | seven years | not applicable | yes | self |
| `signature_invalidations` | Invalidation events | `id`, `e_sig_id`, `actor_user_id` (nullable; system actor permitted), `mutation_summary`, `invalidated_at` | all | unique(`e_sig_id`, `invalidated_at`) | RLS via signature | append-only | seven years | not applicable | yes | yes |
| `approval_authority_snapshots` | Hash-chained per-decision authority snapshots | `id`, `e_sig_id`, `actor_user_id`, `tenant_id`, `entity_type`, `target_record_id`, `actor_authority_profiles_jsonb`, `delegations_jsonb`, `scope_match_jsonb`, `sod_verdict`, `claims_version_at_approval`, `required_authority_keys`, `override`, `previous_hash`, `record_hash`, `created_at` | all | unique(`record_hash`); unique(`e_sig_id`) | RLS on `tenant_id` | none | append-only with advisory-lock serialisation | twenty-five years | not applicable | self | yes |
| `regulated_entity_adapters` | Adapter registry | `id`, `entity_type`, `adapter_module`, `current_version`, `conformance_status`, `registered_by`, `registered_at` | all | unique(`entity_type`) | platform-context | versioned | retain | yes (deprecation) | yes | yes |
| `adapter_registrations` | Registration history | `id`, `adapter_id`, `version`, `conformance_test_run_id`, `e_sig_id`, `registered_at` | all | none | platform-context | append-only | retain | not applicable | self | yes |
| `override_requests` | Override request | `id`, `hitl_decision_id`, `originator_user_id`, `rationale`, `requested_at` | all | none | RLS via decision | none | seven years | yes | yes | yes (where decided) |
| `override_decisions` | Override decision (per signer) | `id`, `override_request_id`, `signer_user_id`, `e_sig_id`, `decision`, `decided_at` | all | unique(`override_request_id`, `signer_user_id`) | RLS via request | none | seven years | not applicable | yes | yes |

### 6.3 API requirements

#### 6.3.1 Workflow templates and library

| Method | Endpoint | Actor | Request | Response | Permission | Audit | Error codes |
|---|---|---|---|---|---|---|---|
| GET | `/admin/workflow-templates` | administrator / auditor | filters | `WorkflowTemplate[]` | `tenant_admin_authority` (read) | none | none |
| POST | `/admin/workflow-templates` | administrator | `Template` (electronic-signed) | `201` | `tenant_admin_authority` | `WORKFLOW_TEMPLATE_CREATED` | validation errors |
| PATCH | `/admin/workflow-templates/:id` | administrator | (only when `lifecycle_state = draft`) | `200` | `tenant_admin_authority` | `WORKFLOW_TEMPLATE_UPDATED` | `STATE_NOT_DRAFT`, validation |
| POST | `/admin/workflow-templates/:id/submit-for-review` | administrator | reason (electronic-signed) | `200` | `tenant_admin_authority` | `WORKFLOW_TEMPLATE_SUBMITTED_FOR_REVIEW` | `STATE_NOT_DRAFT` |
| POST | `/admin/workflow-templates/:id/approve` | administrator | reason (electronic-signed + MFA step-up) | `200` | `final_quality_approver` | `WORKFLOW_TEMPLATE_APPROVED` | `STATE_NOT_UNDER_REVIEW`, validation |
| POST | `/admin/workflow-templates/:id/publish` | administrator | reason (electronic-signed) | `200` | `tenant_admin_authority` | `WORKFLOW_TEMPLATE_EFFECTIVE` | `STATE_NOT_APPROVED` |
| POST | `/admin/workflow-templates/:id/retire` | administrator | reason (electronic-signed) | `200` | `tenant_admin_authority` | `WORKFLOW_TEMPLATE_OBSOLETE` | `STATE_NOT_EFFECTIVE` |
| POST | `/admin/workflow-templates/:id/rollback` | platform-administrator | reason (electronic-signed + executive authority + QA + RA) | `200` | platform admin + executive authority | `WORKFLOW_TEMPLATE_ROLLED_BACK` | `STATE_NOT_OBSOLETE` |
| POST | `/admin/workflow-templates/:id/return-for-correction` | administrator | reason (electronic-signed) | `200` | `tenant_admin_authority` (only by a reviewer who is not the author of the version under review) | `WORKFLOW_TEMPLATE_RETURNED_FOR_CORRECTION` | `STATE_NOT_UNDER_REVIEW`, `TEMPLATE_RETURN_REASON_REQUIRED`, `TEMPLATE_RETURN_BY_AUTHOR_FORBIDDEN` |
| POST | `/admin/workflow-library/import` | tenant administrator (own tenant only) | `{libraryKey, semver, sourceHash, reason}` (electronic-signed + MFA step-up) | `201` | `tenant_admin_authority` | `LIBRARY_TEMPLATE_IMPORTED` | `LIBRARY_HASH_MISMATCH`, `LIBRARY_NOT_FOUND`, `LIBRARY_VERSION_RETIRED` |
| POST | `/platform/workflow-library` | platform-administrator (global catalogue management only) | `{libraryKey, semver, definitionJson, sourceHash, publishReason}` (electronic-signed + MFA step-up) | `201` | platform admin | `LIBRARY_TEMPLATE_PUBLISHED` | `LIBRARY_VERSION_CONFLICT`, validation |
| POST | `/platform/workflow-library/:libraryKey/:semver/retire` | platform-administrator | reason (electronic-signed + MFA step-up) | `200` | platform admin | `LIBRARY_TEMPLATE_RETIRED` | `LIBRARY_NOT_FOUND` |

#### 6.3.2 HITL inbox and decisions

| Method | Endpoint | Actor | Request | Response | Permission | Audit | Error codes |
|---|---|---|---|---|---|---|---|
| GET | `/inbox` | authenticated | filters | `HitlDecision[]` | self (candidate-eligible) | none | none |
| GET | `/inbox/:id` | authenticated | none | `HitlDecisionDetail` | self | none | none |
| POST | `/<entityRoute>/:id/<action>` | authenticated | `{password, meaning, reason, mfaToken?}` | `200 / 207` | per workflow node `requiredAuthorityKeys` | `ESIG_CREATED`, `APPROVAL_AUTHORITY_VALIDATED`, `APPROVAL_AUTHORITY_SNAPSHOT_WRITTEN`, `WORKFLOW_INSTANCE_TRANSITIONED` | `APPROVAL_AUTHORITY_DENIED`, `INVALID_CURRENT_PASSWORD`, `MFA_STEP_UP_REQUIRED`, `SEQUENTIAL_OUT_OF_ORDER`, `ESIG_FAILED`, `RECORD_SCOPE_UNRESOLVED` (URS-03), `CROSS_CONTEXT_DENIED` (URS-03) |

Generic `PATCH /entities/:id` for state transition is forbidden; routes must be explicit per DEC-04 inherited standard 16.

#### 6.3.3 Override requests

| Method | Endpoint | Actor | Request | Response | Permission | Audit |
|---|---|---|---|---|---|---|
| POST | `/admin/overrides` | administrator | `{hitlDecisionId, rationale}` (electronic-signed) | `201` | originator's Authority Profile | `AUTHORITY_OVERRIDE_REQUESTED` |
| POST | `/admin/overrides/:id/approve` | administrator | reason (electronic-signed + MFA step-up + extended meaning) | `200` | `override_authority_profile_id` | `AUTHORITY_OVERRIDE_APPROVED`, `ESIG_CREATED`, `APPROVAL_AUTHORITY_SNAPSHOT_WRITTEN`, `AUTHORITY_OVERRIDE_USED` |
| POST | `/admin/overrides/:id/reject` | administrator | reason (electronic-signed) | `200` | `override_authority_profile_id` | `AUTHORITY_OVERRIDE_REJECTED` |

#### 6.3.4 Adapters

| Method | Endpoint | Actor | Request | Response | Permission | Audit |
|---|---|---|---|---|---|---|
| GET | `/admin/adapters` | platform-administrator / auditor | none | `Adapter[]` | platform admin / auditor | none |
| POST | `/admin/adapters/:entityType/register` | platform-administrator | `{module, version}` (electronic-signed + MFA step-up) | `201` | platform admin | `ADAPTER_REGISTERED` (or `ADAPTER_REGISTRATION_REJECTED` on conformance failure) |

#### 6.3.5 Reports and integrity

| Method | Endpoint | Actor | Request | Response | Permission | Audit |
|---|---|---|---|---|---|---|
| GET | `/admin/governance/decisions` | administrator / auditor | filters | `RegulatedDecision[]` | `tenant_admin_authority` / `auditor` | none |
| POST | `/admin/governance/decisions/export` | administrator | `{range, filters, format}` (electronic-signed) | signed download URL | `tenant_admin_authority` | `DECISION_REGISTER_EXPORTED` |
| GET | `/admin/governance/signatures` | administrator / auditor | filters | `Signature[]` | `tenant_admin_authority` / `auditor` | none |
| GET | `/admin/governance/signatures/integrity` | administrator / auditor | range | `IntegrityManifest` | `tenant_admin_authority` / `auditor` | none |
| POST | `/admin/governance/signatures/export` | administrator | `{range, filters, format}` (electronic-signed) | signed download URL | `tenant_admin_authority` | `SIGNATURE_REGISTER_EXPORTED` |

### 6.4 Workflow engine requirements

| Workflow | Step | Time-to-live or timer | Auto-action | Reminder |
|---|---|---|---|---|
| HITL acknowledgement SLA | open → assigned (acknowledged) | tenant-configured (default 72 h) | escalate to alternate pool; emit `HITL_DECISION_ESCALATED` | T-24 h reminder |
| HITL decision SLA | assigned → decided | tenant-configured (default 5 working days) | escalate; emit `HITL_DECISION_ESCALATED` | T-1 working-day reminder |
| HITL hard expiry | open / assigned → expired | tenant-configured (default 30 calendar days) | mark `expired`; emit `HITL_DECISION_EXPIRED` | T-3 day reminder |
| Override request SLA | requested → decided | tenant-configured (default 24 h) | escalate to next override approver | T-6 h reminder |
| Workflow template approval ceremony | submit → approved | none (no auto-action; manual ceremony) | none | none |
| Adapter conformance test | registration request | synchronous; max 5 minutes | reject if fails | none |

### 6.5 Business rules

- **BR-04-01** — Every regulated decision MUST traverse the Controlled Approval Modal contract (DEC-04-04). Generic `PATCH /entities/:id` for state transitions is forbidden.
- **BR-04-02** — `validateApprovalAction` MUST run twice per decision (HITL submit + immediately before signature insert) per DEC-04-08.
- **BR-04-03** — `esigService.createSignature` MUST refuse to insert a signature when `validateApprovalAction` denies, even when invoked outside the HITL path; this is defence-in-depth against bypass.
- **BR-04-04** — Every signature MUST produce a paired hash-chained `approval_authority_snapshots` row (atomic with the signature row in a single transaction). Failure to write the snapshot rolls back the signature.
- **BR-04-05** — A regulated state transition MUST commit only after the workflow node's full approval requirement is satisfied (single / dual / sequential / parallel + final approver where required).
- **BR-04-06** — Sequential mode MUST enforce the declared signing order at runtime; out-of-order attempts return `SEQUENTIAL_OUT_OF_ORDER`.
- **BR-04-07** — Parallel mode counts each unique signer once; the same user cannot satisfy two parallel slots.
- **BR-04-08** — Override use MUST require multi-factor step-up, extended meaning ≥ 80 characters, snapshot tagged `override = true`, original primary requirement archived in the snapshot, SOC alert.
- **BR-04-09** — A workflow node with `override_dual_sign = true` MUST require two distinct override signers; same-actor cannot satisfy both.
- **BR-04-10** — Library import MUST verify `source_hash` (SHA-256 of canonical JSON) against the platform library's published hash; mismatch returns `LIBRARY_HASH_MISMATCH`.
- **BR-04-11** — Workflow-instance pointer repointing is forbidden after the first regulated decision is signed (DEC-04-13). Pre-signature repointing requires QA electronic signature.
- **BR-04-12** — Signature invalidation MUST be triggered automatically when the adapter detects a mismatch between the persisted `content_fingerprint` and the recomputed fingerprint of the signed entity's relevant fields.
- **BR-04-13** — Hard-coded approval-requirement fallbacks (for example `'quality_approval'`) are forbidden in production code. Missing `workflow_node_approval_requirements` rows for a regulated transition MUST return `500 NODE_REQUIREMENT_MISSING` and SOC alert.
- **BR-04-14** — Stub adapter usage in a workflow whose template is `effective` is forbidden; lifecycle gate rejects with `STUB_ADAPTER_NOT_ALLOWED_IN_PRODUCTION`.
- **BR-04-15** — Audit-log write failure rolls back the originating action.
- **BR-04-16** — Hash-chained `approval_authority_snapshots` MUST use a PostgreSQL advisory lock scoped to `(tenant_id, entity_type, target_record_id)` to serialise writers for that single entity chain. A per-tenant lock is forbidden because it would serialise unrelated regulated decisions across the tenant and produce avoidable contention. Chain integrity is verified periodically and on every export.
- **BR-04-17** — High-risk decisions (template approval, library import, override use, segregation-of-duties exception activation, founder-level decisions) MUST require multi-factor step-up at the Controlled Approval Modal.
- **BR-04-18** — Authority Profile changes mid-decision (revocation between modal open and submit) are caught by the second `validateApprovalAction` call inside `esigService.createSignature` and the signature is denied with `APPROVAL_AUTHORITY_REVOKED_DURING_DECISION`.
- **BR-04-19** — The Controlled Approval Modal MUST NOT include `ip`, `userAgent`, `timestamp`, or `performedBy` in its request body. Server-side derives them.
- **BR-04-20** — The same electronic signature MUST NOT be reused to satisfy a different decision. Each signature row is keyed to exactly one decision.

### 6.6 Audit trail requirements

Module 4 governance event vocabulary (canonical launch list; every code MUST have at least one writer and one regression test; adding a code is a Class 3 change):

`WORKFLOW_TEMPLATE_CREATED`, `WORKFLOW_TEMPLATE_UPDATED`, `WORKFLOW_TEMPLATE_SUBMITTED_FOR_REVIEW`, `WORKFLOW_TEMPLATE_RETURNED_FOR_CORRECTION`, `WORKFLOW_TEMPLATE_APPROVED`, `WORKFLOW_TEMPLATE_EFFECTIVE`, `WORKFLOW_TEMPLATE_OBSOLETE`, `WORKFLOW_TEMPLATE_ROLLED_BACK`, `LIBRARY_TEMPLATE_PUBLISHED` (platform-scoped), `LIBRARY_TEMPLATE_RETIRED` (platform-scoped), `LIBRARY_TEMPLATE_IMPORTED`, `WORKFLOW_INSTANCE_STARTED`, `WORKFLOW_INSTANCE_TRANSITIONED`, `WORKFLOW_INSTANCE_REPOINTED`, `WORKFLOW_INSTANCE_COMPLETED`, `HITL_DECISION_OPENED`, `HITL_DECISION_ASSIGNED`, `HITL_DECISION_ESCALATED`, `HITL_DECISION_DECIDED`, `HITL_DECISION_EXPIRED`, `HITL_SLOT_SIGNED` (per slot in dual / sequential / parallel modes), `ESIG_CREATED`, `ESIG_FAILED`, `ESIG_CREATION_DENIED`, `SIGNATURE_INVALIDATED`, `APPROVAL_AUTHORITY_VALIDATED`, `APPROVAL_AUTHORITY_DENIED`, `APPROVAL_AUTHORITY_SNAPSHOT_WRITTEN`, `APPROVAL_AUTHORITY_REVOKED_DURING_DECISION`, `AUTHORITY_OVERRIDE_REQUESTED`, `AUTHORITY_OVERRIDE_APPROVED`, `AUTHORITY_OVERRIDE_REJECTED`, `AUTHORITY_OVERRIDE_USED`, `GLOBAL_SUPER_AUTHORITY_USED` (Module 4 owns the signature event for every break-glass; the originating event is also emitted by URS-03 per its own §6.6 — the two events are correlated through the shared `e_sig_id` and authority-snapshot `record_hash` so the signature-authority chain is reconstructable end-to-end), `ADAPTER_REGISTERED`, `ADAPTER_REGISTRATION_REJECTED`, `ADAPTER_DEPRECATED`, `NODE_REQUIREMENT_MISSING` (forensic), `STUB_ADAPTER_NOT_ALLOWED_IN_PRODUCTION` (forensic), `SYSTEM_ACTOR_NOT_ELIGIBLE_FOR_REGULATED_DECISION` (forensic), `DECISION_REGISTER_EXPORTED`, `SIGNATURE_REGISTER_EXPORTED`, `PLATFORM_TENANT_ACCESS_USED`, `PLATFORM_TENANT_ACCESS_DENIED`.

The following events are emitted by upstream modules and consumed (read-only) by Module 4 dashboards and security-operations alerting; they are NOT written by Module 4 services: `MFA_STEP_UP_REQUIRED`, `MFA_STEP_UP_FAILED` (both owned by URS-01 §6.6 — Module 4 surfaces them in §12.9 Security-operations alert thresholds and in §11.2 Error-code catalogue but does not duplicate the writer).

Audit-log write failure rolls back the originating action (BR-04-15).

```mermaid
sequenceDiagram
  autonumber
  participant API as Workflow / E-Sign API
  participant DB as Database (transaction)
  participant LOG as Audit Log + Snapshot Chain

  API->>DB: BEGIN TRANSACTION
  API->>DB: insert electronic_signatures row
  API->>DB: insert approval_authority_snapshots row (hash-chained)
  API->>DB: apply adapter transition
  API->>LOG: append audit rows
  alt log write fails
    API->>DB: ROLLBACK
    API-->>API: 500 AUDIT_TRAIL_WRITE_FAILED
  else log write succeeds
    API->>DB: COMMIT
  end
```

### 6.7 Electronic signature requirements

#### 6.7.1 Launch list of high-risk decisions requiring multi-factor step-up

Workflow-template approval, workflow-template publish, workflow-template rollback, library-template import, regulated-entity-adapter registration / update, override-authority approval, segregation-of-duties exception activation, executive authority-level decisions explicitly tagged on a workflow node, batch release at QP / AP level, recall approval, signature-register export.

#### 6.7.2 Signature components and ceremony

Identification code: the authenticated session identity (URS-01). Password: re-entered through the Controlled Approval Modal at the moment of signing. For high-risk decisions, multi-factor step-up adds a Time-based One-Time Password verification immediately before signature insertion. Signatures are linked to action rows through `e_sig_id`. The signed content snapshot is computed by the regulated entity's adapter at signature time and persisted in `electronic_signatures.content_snapshot_jsonb` plus `content_fingerprint`.

#### 6.7.3 Manifestation in record detail views

Every signed regulated record's detail view renders the signature panel showing actor name, role, Authority Profile used, meaning of signature, reason for change, signed-at timestamp, source IP, normalised user agent, MFA step-up flag, hash-chain integrity badge, and (where invalidated) the invalidation marker with timestamp.

#### 6.7.4 Signature/record linking

Every signature row carries the regulated entity's identifier; every regulated record carries the corresponding `e_sig_id` (single mode) or, for dual / sequential / parallel modes, is reachable through the `hitl_decision_signatures` slot rows that link the decision to each `electronic_signatures.id`. The `workflow_transitions_log.e_sig_id` is populated for `regulated_single` transitions and is null for `regulated_multi` transitions, where the slot signatures are reached through `hitl_decision_signatures` (see §6.2). Subsequent change to the signed entity's relevant fields invalidates **every** signature linked to the affected decision (BR-04-12) and emits `SIGNATURE_INVALIDATED` per affected signature row.

#### 6.7.5 Identity verification and accountability prerequisites

Inherited from URS-01 §6.7.1: every signer MUST have a verified identity, an acknowledged electronic-signature policy, and a recorded signature activation date before they may execute a Module 4 signature.

### 6.8 Record versioning and class-of-change governance

- Versioned: `workflow_templates` / `workflow_template_versions`, `workflow_template_library`, `hitl_gate_config`, `regulated_entity_adapters`.
- Append-only: `workflow_transitions_log`, `hitl_escalation_log`, `electronic_signatures`, `signature_invalidations`, `approval_authority_snapshots`, `adapter_registrations`, `audit_log` Module 4 subset.
- Soft-delete: `workflow_templates` (retire path), `regulated_entity_adapters` (deprecation path), `override_requests`.

---

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

### 7.1 Cross-module wiring

#### Diagram 7-A — Module 4 substrate consumed by other modules

```mermaid
graph LR
  subgraph M4 [Module 4 — Workflow / HITL / E-Sign / Approval Authority]
    WE[Workflow Engine]
    HITL[HITL Lifecycle]
    CAM[Controlled Approval Modal]
    ESIG[E-Signature Registry]
    SNAP[Authority Snapshots]
    ADP[Adapter Registry]
  end

  M1[URS-01 Auth] --> CAM
  M2[URS-02 RBAC] --> WE
  M3[URS-03 Context] --> WE
  M5[URS-05 Authority Resolver] --> WE
  WE --> M12[URS-12 Doc Control]
  WE --> M13[URS-13]
  WE --> M14[URS-14 Complaints]
  WE --> M15[URS-15 OOS]
  WE --> M16[URS-16 Deviations]
  WE --> M17[URS-17 RCA]
  WE --> M18[URS-18 CAPA]
  WE --> M19[URS-19 Risk]
  WE --> M20[URS-20 Reviews]
  WE --> M21[URS-21 Findings]
  WE --> M22[URS-22 Inspections]
  WE --> M23[URS-23 Batch Records]
  WE --> M24[URS-24 Stability]
  WE --> M25[URS-25 EM]
  WE --> M26[URS-26 APQR]
  WE --> M27[URS-27 Reg Submissions]
  WE --> M28[URS-28 Training]
  WE --> M31[URS-31 DQG]
  WE --> M33[URS-33 GMP]
  WE --> M34[URS-34 GDP]
  ESIG --> M6[URS-06 Audit]
  SNAP --> M6
  CAM --> M30[URS-30 Notifications]
  M35[URS-35 Backup] -.preserves chain.-> SNAP
```

| Source / target | Direction | Trigger | Data sent / received | Failure handling | Audit |
|---|---|---|---|---|---|
| URS-01 → URS-04 | upstream | bootstrap, re-authentication, MFA step-up | session, MFA proof | URS-01 fails closed | none here |
| URS-02 → URS-04 | upstream | bootstrap | base role, effective permissions | URS-02 fails closed | none |
| URS-03 → URS-04 | upstream | every regulated decision | active context, approval-scope check | URS-03 fails closed | scope snapshot via URS-03 |
| URS-05 → URS-04 | peer | resolver call | Authority Profile data | URS-05 fails closed | snapshot |
| URS-04 → URS-06 | downstream | every Module 4 event | hash-chained event | rollback on audit failure | event |
| URS-04 → URS-30 | downstream | HITL notification, escalation, override alert | event payload | retry per URS-30 | event |
| URS-04 → URS-12..URS-34 | peer | adapter calls | record state read / transition apply | reject on adapter contract failure | adapter event |
| URS-04 → URS-35 | peer | backup / restore | append-only chains | restore preserves chain | DR drill verifies |

### 7.2 Change-Impact Matrix

| # | Module 4 artefact | Class | Affected modules | Specific impact | Required action | Re-validation |
|---|---|---|---|---|---|---|
| CIM-01 | Approval-mode taxonomy (single / dual / sequential / parallel) | 1 | every regulated module | Adding or removing a mode changes runtime semantics | Class 1 change with founder e-sign | Full IQ + OQ + PQ |
| CIM-02 | Per-node approval-requirement fields | 1 | every regulated module | Schema change forces template re-author | Schema migration with template-version migration | IQ + OQ + PQ |
| CIM-03 | Controlled Approval Modal contract | 1 | every regulated module | Field-set change breaks every regulated submission | Update shared types; align all consumers | OQ + PQ |
| CIM-04 | Electronic-signature row schema | 1 | URS-06, URS-12, URS-22, every regulated module | Audit replay format change | Schema migration; align consumers | IQ + OQ + PQ |
| CIM-05 | Adapter contract | 1 | every consuming module | Adapter API change breaks every regulated entity | Update contract; require adapter re-registration with conformance tests | IQ + OQ + PQ per adapter |
| CIM-06 | HITL decision lifecycle | 2 | every consuming module | Lifecycle change alters timing semantics | Document; differential test report | OQ + PQ |
| CIM-07 | Authority resolver algorithm | 2 | every regulated decision | Eligibility decisions change | QA + RA + IS approval; differential test against frozen historical decision log | OQ + PQ |
| CIM-08 | Authority snapshot schema | 1 | URS-06, URS-22 | Audit replay format change | Schema migration; align consumers | IQ + OQ |
| CIM-09 | High-risk action list (multi-factor step-up) | 2 / 3 | every regulated module | Tightening adds step-up to more flows | Document; UX preview | OQ + PQ |
| CIM-10 | Override-authority dual-sign rule | 2 | every regulated module with override config | Tightening or loosening changes posture | executive authority e-sign | OQ + PQ |
| CIM-11 | Library-import provenance fields | 1 | URS-22 inspection prep | Provenance schema change | Migration | IQ + OQ |
| CIM-12 | HITL SLA defaults | 4 | URS-30 alerts | Operational | Tenant configuration | none |
| CIM-13 | Audit event vocabulary | 3 (add) / 1 (rename) | URS-06, URS-30, URS-22 | Audit replay incomplete | Update writers; align consumers | OQ + PQ |
| CIM-14 | Workflow template lifecycle states | 1 | every regulated module | Adding or removing a state changes UX and routing | Schema migration; full regression | IQ + OQ + PQ |
| CIM-15 | Stub-adapter policy | 2 | every consuming module | Tightening blocks more deployments | Document; CI gate update | OQ |

### 7.3 Change classification and re-validation triggers

| Class | Definition | Examples | Required gates | Default re-validation |
|---|---|---|---|---|
| 1 — Substrate-breaking | Schema, contract, or semantic change that can break consumers | CIM-01, 02, 03, 04, 05, 08, 11, 14 | URS-13 approval by QA, RA, Security, Platform; founder e-signature | Full IQ + OQ + PQ |
| 2 — Semantic-shift | Behaviour change without contract change | CIM-06, 07, 09, 10, 15 | URS-13 approval by QA, RA, Security; differential test report | OQ + PQ |
| 3 — Additive | Pure addition not changing existing consumer contracts | CIM-13 (add) | URS-13 approval by QA + RA | OQ |
| 4 — Configuration | Tenant-level value change | CIM-12 | Tenant-administrator electronic signature | none |

---

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

Module 4 contains no AI in its decision path. The workflow runtime is deterministic; the approval-authority resolver is deterministic; the electronic-signature ceremony is deterministic. The Human-in-the-Loop pattern is the entire point of this module: every regulated decision is captured by a human through the Controlled Approval Modal with electronic signature.

The MIRA AI agent (URS-32) MAY suggest decisions to a human reviewer (for example, a suggested CAPA closure decision). MIRA suggestions MUST be presented as advisory only. MIRA MUST never invoke `esigService.createSignature` or any regulated-decision endpoint on its own behalf; only a human user, through the Controlled Approval Modal, may create a regulated signature. Module 4 enforces this by treating every signing actor as a human user identifier; the `mira_agent@verixa.internal` system identity is rejected at `validateApprovalAction` with `SYSTEM_ACTOR_NOT_ELIGIBLE_FOR_REGULATED_DECISION`.

EU AI Act (Regulation (EU) 2024/1689) applicability: the AI Act risk classification is the consuming module's responsibility (the module that uses MIRA). Module 4 itself contains no AI and is not a high-risk AI system in the meaning of the Act; documented exclusion in §14.

For critical Good Manufacturing Practice functions (batch release, OOS / OOT classification, deviation classification, CAPA disposition), generative or probabilistic AI is prohibited per inherited governance; Module 4's decision path admits only deterministic resolver output and human-signed decisions.

---

## 9. Reports, Dashboards, and Exports

| Report | Filters | Columns | Access | Format | Audit | Retention |
|---|---|---|---|---|---|---|
| Regulated-decision register | range, tenant, user, module, decision | actor, decision, scope snapshot, e_sig_id, link | administrator / auditor | CSV / PDF / JSONL | yes (export) | seven years |
| Signature register | range, tenant, user, module, MFA step-up | full row + integrity badge | administrator / auditor | CSV / PDF / JSONL | yes | seven years |
| Override register | range, tenant, user, module, decision | full row + rationale + dual signers | administrator / auditor | CSV / PDF | yes | twenty-five years |
| HITL escalation register | range, tenant, module | full row + reasons | administrator / auditor | CSV | yes | seven years |
| Template-version coverage | tenant | per-entity-type active version + in-flight instances | administrator / auditor | CSV | yes | release-current |
| Library-import register | range, tenant | provenance, importer, signer | administrator / auditor | CSV | yes | retain history |
| Signature-invalidation register | range, tenant | invalidation events with mutation summary | administrator / auditor | CSV | yes | seven years |
| Authority-snapshot integrity report | range | start hash, end hash, row count, validation status | administrator / auditor | PDF | yes | twenty-five years |

Every export routes through the Controlled Approval Modal. Signed download URLs with fifteen-minute time-to-live. Integrity manifest accompanies every export.

---

## 10. Notifications and Queues

| Trigger | Channel | Recipient | Priority | Retry | Suppression | Audit |
|---|---|---|---|---|---|---|
| HITL decision opened | e-mail + in-app | candidate pool | normal | three | one per minute per pool | yes |
| HITL acknowledgement SLA T-24h | e-mail | assigned candidate | normal | three | one per day per decision | yes |
| HITL escalation | e-mail + SOC chat (where high-priority) | escalation pool + SOC | high | three | one per five minutes per pool | yes |
| HITL hard expiry | e-mail | originator + tenant administrator queue | high | three | one per hour per decision | yes |
| Workflow template approved | e-mail | tenant administrator queue | normal | three | one per hour | yes |
| Library template imported | e-mail + SOC chat | tenant administrator queue + SOC | high | three | one per import | yes |
| Override use | SOC chat + e-mail | SOC + QA Head + executive authority escalation | critical | five | none | yes |
| Adapter registration / rejection | e-mail | platform administrator queue | high | three | one per registration | yes |
| Signature invalidation | e-mail | original signer + tenant administrator queue | high | three | one per five minutes per signer | yes |
| Periodic access review window | e-mail | tenant administrator queue | normal | three | one per day per tenant | yes |

Queues:

- **My HITL decisions** (self).
- **My override requests** (self).
- **Pending review for templates** (administrator).
- **Pending override-decision queue** (administrator).
- **Adapter conformance pending** (platform administrator).
- **Periodic access review window** (administrator).

---

## 11. Error Handling and Negative Paths

### 11.1 Error envelope

All error responses follow the envelope: human message, machine-readable code in upper-snake-case, optional structured details, correlation identifier.

### 11.2 Error-code catalogue

| Code | HTTP | Path | UI behaviour |
|---|---|---|---|
| APPROVAL_AUTHORITY_DENIED | 403 | regulated decision | inline error in modal |
| APPROVAL_AUTHORITY_REVOKED_DURING_DECISION | 403 | regulated decision | "Your authority changed; please refresh and retry" |
| INVALID_CURRENT_PASSWORD | 401 | regulated decision | inline error |
| MFA_STEP_UP_REQUIRED | 401 | high-risk decision | open MFA step-up prompt |
| MFA_STEP_UP_FAILED | 401 | high-risk decision | "Please retry" |
| ESIG_FAILED | 422 | regulated decision | inline error in modal |
| ESIG_CREATION_DENIED | 403 | non-HITL signing path | inline error |
| SEQUENTIAL_OUT_OF_ORDER | 409 | sequential-mode regulated decision | inline error naming the prior step |
| HITL_SLOT_DUPLICATE_SIGNER | 409 | dual / parallel-mode regulated decision attempting to satisfy two slots with the same human | inline error citing the slot already signed by this user |
| NODE_REQUIREMENT_MISSING | 500 | regulated decision | toast; SOC alert; the regulated decision is blocked |
| STUB_ADAPTER_NOT_ALLOWED_IN_PRODUCTION | 409 | template publish | inline error |
| SYSTEM_ACTOR_NOT_ELIGIBLE_FOR_REGULATED_DECISION | 403 | non-human caller | back-end forensic; no UI surface |
| LIBRARY_HASH_MISMATCH | 409 | library import | inline error |
| LIBRARY_NOT_FOUND | 404 | library import | inline error |
| STATE_NOT_DRAFT | 409 | template lifecycle endpoints | inline error |
| STATE_NOT_UNDER_REVIEW | 409 | template lifecycle endpoints | inline error |
| STATE_NOT_APPROVED | 409 | template lifecycle endpoints | inline error |
| STATE_NOT_EFFECTIVE | 409 | template lifecycle endpoints | inline error |
| STATE_NOT_OBSOLETE | 409 | template lifecycle endpoints | inline error |
| ADAPTER_CONFORMANCE_FAILED | 422 | adapter registration | inline error citing failing tests |
| RECORD_SCOPE_UNRESOLVED | 500 | regulated decision (URS-03) | toast; SOC alert |
| CROSS_CONTEXT_DENIED | 403 | regulated decision (URS-03) | toast |
| AUDIT_TRAIL_WRITE_FAILED | 500 | any state-changing action | toast; the originating action did NOT commit |
| OVERRIDE_RATIONALE_TOO_SHORT | 400 | override use | inline error citing minimum length |
| OVERRIDE_DUAL_SIGN_REQUIRED | 409 | override use missing second signer | inline error |
| HITL_NOT_ASSIGNED | 403 | submit by non-assignee | inline error |
| HITL_ALREADY_DECIDED | 409 | submit on decided decision | inline error |
| TEMPLATE_VALIDATION_FAILED | 400 | template submit / approve | inline list of validation errors |
| TEMPLATE_RETURN_REASON_REQUIRED | 400 | template return-for-correction | inline error citing minimum length |
| TEMPLATE_RETURN_BY_AUTHOR_FORBIDDEN | 403 | template return-for-correction by the author of the version | inline error |
| LIBRARY_VERSION_RETIRED | 409 | tenant import of a retired library version | inline error |
| LIBRARY_VERSION_CONFLICT | 409 | platform publish of an existing `(libraryKey, semver)` | inline error |
| WORKFLOW_INSTANCE_REPOINT_FORBIDDEN | 403 | repoint after first signature | inline error |
| PLATFORM_TENANT_ACCESS_DENIED | 403 | platform identity outside support envelope | inline error; SOC alert |

### 11.3 Negative-path catalogue

| Scenario | Detection | Response | UI behaviour |
|---|---|---|---|
| Authority revoked between modal open and submit | back end (`validateApprovalAction` defence-in-depth) | `403 APPROVAL_AUTHORITY_REVOKED_DURING_DECISION` | inline error; HITL decision remains open |
| MFA step-up failed on high-risk | back end | `401 MFA_STEP_UP_FAILED` | retry prompt |
| Sequential out of order | back end | `409 SEQUENTIAL_OUT_OF_ORDER` | inline error |
| Missing node requirement | back end | `500 NODE_REQUIREMENT_MISSING` | toast; SOC alert |
| Stub adapter in production | back end | `409 STUB_ADAPTER_NOT_ALLOWED_IN_PRODUCTION` | inline error |
| MIRA agent attempts signature | back end | `403 SYSTEM_ACTOR_NOT_ELIGIBLE_FOR_REGULATED_DECISION` | not surfaced to UI; forensic |
| Library hash mismatch | back end | `409 LIBRARY_HASH_MISMATCH` | inline error |
| Adapter conformance test failure | back end (synchronous) | `422 ADAPTER_CONFORMANCE_FAILED` | inline error citing failing tests |
| Override rationale below 80 chars | back end | `400 OVERRIDE_RATIONALE_TOO_SHORT` | inline error |
| Audit-write failure mid-decision | back end | `500 AUDIT_TRAIL_WRITE_FAILED` | toast; the regulated decision did NOT commit |
| Repoint after first signature | back end | `403 WORKFLOW_INSTANCE_REPOINT_FORBIDDEN` | inline error |
| HITL submit by non-assignee | back end | `403 HITL_NOT_ASSIGNED` | inline error |
| HITL submit on already-decided | back end | `409 HITL_ALREADY_DECIDED` | inline error |
| Same-human attempts to satisfy two slots in dual / parallel mode | back end | `409 HITL_SLOT_DUPLICATE_SIGNER` | inline error citing the slot already signed by this user |
| Sequential-mode slot signed before its predecessor | back end | `409 SEQUENTIAL_OUT_OF_ORDER` | inline error naming the prior step |
| Template author attempts to return their own version for correction | back end | `403 TEMPLATE_RETURN_BY_AUTHOR_FORBIDDEN` | inline error |
| Tenant import of a retired library version | back end | `409 LIBRARY_VERSION_RETIRED` | inline error |
| Platform publish of an existing `(libraryKey, semver)` | back end | `409 LIBRARY_VERSION_CONFLICT` | inline error |
| Resolver outage (URS-03 / URS-05) | back end | `503` from upstream; defence-in-depth fail-secure | banner |

---

## 12. Security, Privacy, and Tenant Isolation

### 12.1 Authentication dependency

URS-04 is reached only through an authenticated session established by URS-01. Every regulated decision additionally requires re-authentication and (for high-risk) multi-factor step-up.

### 12.2 Authorisation pipeline

`authenticate hook → tenant hook → rbac hook → context gate hook → workflow hook → authorityCheckHook → esigService.createSignature → snapshotApprovalAuthority → adapter applyTransition`. Module 4 owns the workflow hook position and the e-signature / snapshot stages.

### 12.3 Tenant isolation

Every database operation routes through TDAL with tenant context bound. Tenant-scoped tables have RLS enabled in the same migration as creation. The library catalogue and the regulated-entity-adapter registry are global / platform-context with explicit platform-only access policies.

### 12.4 Encryption

At rest: signature content snapshots may contain regulated record content; protected by RLS plus KMS at the storage layer. In transit: TLS 1.2 or higher with HSTS preload.

### 12.5 Logging hygiene

Logs scrub passwords, MFA tokens, and any field tagged sensitive. Structured logs carry the correlation identifier on every request.

### 12.6 Privacy and data residency

Inherits tenant data-residency configuration from URS-08. Signature content snapshots respect the tenant's residency.

### 12.7 Periodic access review

Per URS-01 §12.10, the access-review window enumerates Authority Profile holders, override approvers, library importers, and adapter registrars; reviewer signs the attestation.

### 12.8 Periodic audit-trail review

Per URS-01 §12.11, high-risk Module 4 events triaged within one business day: `AUTHORITY_OVERRIDE_USED`, `SIGNATURE_INVALIDATED` clusters, `HITL_DECISION_ESCALATED` clusters, `LIBRARY_TEMPLATE_IMPORTED`, `ADAPTER_REGISTRATION_REJECTED`, `NODE_REQUIREMENT_MISSING`.

### 12.9 Security-operations alert thresholds

| Pattern | Threshold | Severity | Channel |
|---|---|---|---|
| `AUTHORITY_OVERRIDE_USED` | any single event | critical | SOC chat + executive authority escalation |
| `SIGNATURE_INVALIDATED` cluster (same record) | three events on same record per hour | high | SOC chat |
| `HITL_DECISION_ESCALATED` cluster (same tenant) | ten escalations per tenant per hour | high | SOC chat |
| `NODE_REQUIREMENT_MISSING` | any single event | critical | SOC chat + on-call page |
| `STUB_ADAPTER_NOT_ALLOWED_IN_PRODUCTION` | any single event | high | SOC chat |
| `MFA_STEP_UP_FAILED` cluster | five events per user per hour | high | SOC chat |
| `LIBRARY_TEMPLATE_IMPORTED` | any single event | informational (real-time) | SOC chat |
| `ADAPTER_REGISTRATION_REJECTED` | any single event | high | SOC chat |
| `PLATFORM_TENANT_ACCESS_USED` for Module 4 | any single event | informational (real-time) | SOC chat |
| `AUTHORITY_OVERRIDE_REJECTED` | any single event | informational (digest hourly) | SOC e-mail digest |

### 12.10 Self-modification block — scope

Inherited from URS-02 §12.10 and URS-03 §12.10: a user MUST NOT approve their own actions on the same record where the workflow node's `requiresSod = true`. The resolver enforces by excluding the record's `created_by` and `last_modified_by` from candidates.

### 12.11 Secure export

Every export routes through the Controlled Approval Modal. Signed download URLs with fifteen-minute TTL. Integrity manifest accompanies every export.

---

## 13. Data Integrity and ALCOA+ Controls

| Principle | Module 4 control | Requirement | Verification |
|---|---|---|---|
| Attributable | Every signature carries `signed_by`; every snapshot carries `actor_user_id`; system actors prohibited as regulated signer | URS-04-AUD-001 | Integration test |
| Legible | Signatures store structured JSON content snapshots; exports render in PDF and machine-readable formats | URS-04-REP-001 | Export test |
| Contemporaneous | All timestamps from server clock; client-supplied timestamps dropped | URS-04-AUD-002 | Integration test |
| Original | Append-only signatures, snapshots, transitions log, escalation log | URS-04-AUD-003 | Validation test |
| Accurate | Authority validation runs twice per decision; CHECK constraints on snapshot rows | URS-04-DATA-001 | Integration test |
| Complete | Every event in §6.6 has at least one writer; vocabulary completeness gate enforced | URS-04-AUD-004 | Validation test |
| Consistent | Hash-chained snapshots with advisory lock; per-entity chain integrity | URS-04-AUD-005 | Concurrency test |
| Enduring | Retention (seven years signatures and decisions; twenty-five years overrides and snapshots; cold archive after two years per URS-35) | URS-04-DATA-002 | Migration test |
| Available | Read paths administrator / auditor accessible; export self-service | URS-04-REP-002 | End-to-end test |

---

## 14. Regulatory Mapping

| Identifier | Control | Regulation / Guidance | Clause | Applicable | Implementation expectation |
|---|---|---|---|---|---|
| RG-04-001 | Limit access to authorised individuals | 21 CFR Part 11 | §11.10(d) | Yes | Authority resolver + Controlled Approval Modal |
| RG-04-002 | Authority checks for system functions | 21 CFR Part 11 | §11.10(g) | Yes | `validateApprovalAction` invoked twice per decision |
| RG-04-003 | Audit trail of operator actions | 21 CFR Part 11 | §11.10(e) | Yes | Hash-chained Module 4 events |
| RG-04-004 | Identity and components of electronic signature | 21 CFR Part 11 | §11.100, §11.200 | Yes | Identification code + password; MFA step-up for high-risk |
| RG-04-005 | Electronic signature components | 21 CFR Part 11 | §11.200 | Yes | Two distinct components per decision |
| RG-04-006 | Identification code and password controls | 21 CFR Part 11 | §11.300 | Yes | Inherited from URS-01 |
| RG-04-007 | Signature manifestation | 21 CFR Part 11 | §11.50 | Yes | Meaning of signature + reason persisted |
| RG-04-008 | Signature/record linking | 21 CFR Part 11 | §11.70 | Yes | `e_sig_id` linked into action row; invalidation on post-signature mutation |
| RG-04-009 | Logical access controls | EU GMP Annex 11 | §12, §12.1 | Yes | Inherited from URS-01..URS-03 |
| RG-04-010 | Validation of computerised systems | EU GMP Annex 11 | §4 | Yes | CSV / CSA pack per §17 |
| RG-04-011 | Documentation and record integrity | EU GMP Chapter 4 | applicable | Yes | Versioning + retention |
| RG-04-012 | Risk-based assurance | FDA Computer Software Assurance for Production and Quality Management System Software, Final Guidance, February 2026 | applicable | Yes | Risk classification per validation pack |
| RG-04-013 | ALCOA+ data integrity | MHRA Data Integrity Guidance (2018) | nine principles | Yes | §13 mapping |
| RG-04-014 | Records retention | EU GMP Annex 11 | §17 | Yes | Seven years signatures / twenty-five years overrides and snapshots |
| RG-04-015 | Identity-management standards | ISO/IEC 27001 | A.5.16, A.8.5 | Yes | Inherited from URS-01 |
| RG-04-016 | EU AI Act applicability | Regulation (EU) 2024/1689 | Article 3(1) | Not applicable to this module | No AI; documented exclusion |
| RG-04-017 | India regulatory framework (CDSCO; D&C Act 1940; CDSCO GCP) | Per applicability | Conditional per tenant operation | Conditional | Tenant-onboarding RA disposition under URS-08 controls |
| RG-04-018 | Notifications integrity | Internal | not applicable | Yes | URS-30 substrate |
| RG-04-019 | Library / supplier oversight | EU GMP Annex 11 | §3 | Yes | Library import provenance + adapter conformance evidence |
| RG-04-020 | Per-node `requiredAuthorityKeys[]` enforcement (authority of record) | 21 CFR Part 11 / EU GMP Annex 11 | 21 CFR §11.10(g); EU GMP Annex 11 §12 (logical access controls) | Yes | Resolver enforces node-bound authority keys; signature ceremony refuses if denied |
| RG-04-021 | AI-in-GMP forward-looking expectations (informational only; NOT part of the controlled launch baseline) | EU GMP Annex 22 (Draft 2025) — emerging expectation | applicable forward-looking | Forward-looking only — internal mapping for change-governance awareness; not invoked as an enforceable URS-04 control until Annex 22 is finalised and incorporated into the controlled regulatory baseline through URS-13 | No control text in this URS depends on Annex 22; Module 4 enforces only stable predicate rules (21 CFR Part 11 + EU GMP Annex 11) |

### 14.1 Predicate-rule applicability matrix

| Record / signature | Predicate-rule basis | Part 11 applicable? | Retention | Owner | Evidence |
|---|---|---|---|---|---|
| Electronic signature for regulated decision | 21 CFR Part 11 §11.10(d), §11.10(g), §11.50, §11.70, §11.100, §11.200 | Yes | seven years | QA / Validation | Signature row + linked snapshot + audit |
| Authority snapshot per regulated decision | Authority of record evidence | Yes | twenty-five years | QA / Information Security | Hash-chained snapshot table |
| Override request and decisions | Break-glass evidence | Yes | twenty-five years | QA / Founder | Override register + signed signatures |
| Workflow template version (lifecycle states) | Configuration baseline evidence | Yes | retain history | QA | Template version + approvals |
| Library template import provenance | Supplier-oversight evidence | Yes | retain history | QA | Import register |
| Adapter registration record | Supplier-oversight evidence | Yes | retain history | Platform / QA | Registration register |
| HITL decision row | Operational evidence | Conditional — the audit row is predicate; the row itself supports | seven years | QA | Audit export |
| HITL escalation log row | Operational evidence | Conditional | seven years | QA | Escalation register |
| Workflow transitions log row | Authority chain evidence | Yes | seven years | QA | Transitions register |
| Signature invalidation row | Forensic and integrity evidence | Yes | seven years | QA / Information Security | Invalidation register |

---

## 15. URS Requirements Register

### 15.1 Front-end (FE)

- URS-04-FE-001 — The Controlled Approval Modal MUST collect exactly `password`, `meaningOfSignature`, `reasonForChange`; MUST NOT include `ip`, `userAgent`, `timestamp`, `performedBy` in the request body. Priority MUST. Risk HIGH. Maps RG-04-004.
- URS-04-FE-002 — High-risk decisions MUST trigger the multi-factor step-up flow within the Controlled Approval Modal before signature submission. Priority MUST. Risk HIGH. Maps RG-04-004.
- URS-04-FE-003 — The HITL inbox MUST surface only decisions for which the caller is a candidate per the resolver. Priority MUST. Risk MEDIUM. Maps RG-04-002.
- URS-04-FE-004 — Sequential-mode UI MUST visually indicate the required signing order and disable submission for users not at the current step. Priority MUST. Risk HIGH. Maps RG-04-002.
- URS-04-FE-005 — Parallel-mode UI MUST show progress (`signed_count / minApprovers`) and prevent the same user from satisfying two slots. Priority MUST. Risk HIGH. Maps RG-04-002.
- URS-04-FE-006 — Override-request UI MUST require `meaningOfSignature ≥ 80` characters and visually flag the regulated nature of the action. Priority MUST. Risk HIGH. Maps RG-04-002.
- URS-04-FE-007 — Signature panel in record detail views MUST render actor, role, Authority Profile used, meaning, reason, signed-at, IP, normalised user agent, MFA step-up flag, hash-chain integrity badge, and invalidation marker where applicable. Priority MUST. Risk HIGH. Maps RG-04-007, RG-04-008.
- URS-04-FE-008 — Workflow template editor MUST validate `requiredAuthorityKeys[]` non-empty for regulated transitions and surface inline errors. Priority MUST. Risk HIGH. Maps RG-04-002.
- URS-04-FE-009 — Library template import UI MUST require multi-factor step-up and display the source library hash and semver before commit. Priority MUST. Risk HIGH. Maps RG-04-019.
- URS-04-FE-010 — Every route in §5.1 MUST be registered in the application router before release. Priority MUST. Risk LOW.

### 15.2 Back-end (BE)

- URS-04-BE-001 — The Controlled Approval Modal contract MUST be the only path for regulated decisions; generic `PATCH /entities/:id` for state transitions is forbidden. Priority MUST. Risk CRITICAL. Maps RG-04-001.
- URS-04-BE-002 — `validateApprovalAction` MUST execute twice per decision (HITL submit + immediately before signature insertion). Priority MUST. Risk CRITICAL. Maps RG-04-002.
- URS-04-BE-003 — `esigService.createSignature` MUST refuse insertion when `validateApprovalAction` denies, regardless of caller. Priority MUST. Risk CRITICAL. Maps RG-04-002.
- URS-04-BE-004 — Every signature MUST produce a hash-chained `approval_authority_snapshots` row atomic with the signature in a single transaction. Priority MUST. Risk CRITICAL. Maps RG-04-003.
- URS-04-BE-005 — Hard-coded approval-requirement defaults are forbidden in production. Missing requirements return `500 NODE_REQUIREMENT_MISSING`. Priority MUST. Risk HIGH. Maps RG-04-002.
- URS-04-BE-006 — Sequential-mode runtime MUST enforce signing order; out-of-order returns `409 SEQUENTIAL_OUT_OF_ORDER`. Priority MUST. Risk HIGH. Maps RG-04-002.
- URS-04-BE-007 — Parallel-mode runtime MUST count unique signers; same user cannot satisfy two slots. Priority MUST. Risk HIGH. Maps RG-04-002.
- URS-04-BE-008 — Override use MUST require multi-factor step-up, extended meaning ≥ 80 characters, snapshot tagged `override = true`, original requirement archived, SOC alert. Priority MUST. Risk HIGH. Maps RG-04-002.
- URS-04-BE-009 — Library import MUST verify SHA-256 hash against the platform library; mismatch returns `409 LIBRARY_HASH_MISMATCH`. Priority MUST. Risk HIGH. Maps RG-04-019.
- URS-04-BE-010 — Workflow-instance pointer repointing is forbidden post-signature. Pre-signature repointing requires QA electronic signature. Priority MUST. Risk HIGH. Maps RG-04-001.
- URS-04-BE-011 — Signature invalidation MUST be triggered automatically by adapter fingerprint mismatch. Priority MUST. Risk HIGH. Maps RG-04-008.
- URS-04-BE-012 — High-risk decision list (§6.7.1) MUST require MFA step-up. Priority MUST. Risk HIGH. Maps RG-04-004.
- URS-04-BE-013 — Audit-log write failure MUST roll back the originating action. Priority MUST. Risk CRITICAL. Maps RG-04-003.
- URS-04-BE-014 — Hash-chained snapshots MUST use a per-tenant advisory lock to serialise writers. Priority MUST. Risk HIGH. Maps RG-04-003.
- URS-04-BE-015 — System-actor identifiers (e.g., `mira-agent@verixa.internal`) MUST be rejected as regulated signers with `403 SYSTEM_ACTOR_NOT_ELIGIBLE_FOR_REGULATED_DECISION`. Priority MUST. Risk HIGH. Maps RG-04-001.
- URS-04-BE-016 — The same electronic signature row MUST NOT be reusable across decisions; uniqueness enforced at the database. Priority MUST. Risk HIGH. Maps RG-04-008.
- URS-04-BE-017 — Stub-adapter usage in workflows whose template is `effective` is forbidden; lifecycle gate enforces. Priority MUST. Risk HIGH. Maps RG-04-001.
- URS-04-BE-018 — Adapter registration MUST run the conformance test pack synchronously; failures block registration. Priority MUST. Risk HIGH. Maps RG-04-019.
- URS-04-BE-019 — Tenant-scoped Module 4 tables MUST have RLS enabled in the same migration that creates them. Global / platform-context tables (`workflow_template_library`, `regulated_entity_adapters`) MUST carry explicit platform-context access policies. Priority MUST. Risk HIGH. Maps RG-04-009.
- URS-04-BE-020 — Server-side derives `ip`, `user_agent`, `timestamp`, `signed_by`; client-supplied values dropped. Priority MUST. Risk HIGH. Maps RG-04-004.

### 15.3 Workflow (WF)

- URS-04-WF-001 — HITL decision lifecycle adheres to §5.4 `open → assigned → decided | escalated | expired`. Priority MUST. Risk HIGH.
- URS-04-WF-002 — Workflow template lifecycle adheres to §5.4 with controlled rollback path. Priority MUST. Risk HIGH.
- URS-04-WF-003 — Auto-escalation at HITL SLA boundary; emits `HITL_DECISION_ESCALATED`. Priority MUST. Risk MEDIUM.
- URS-04-WF-004 — Adapter conformance test runs synchronously on registration; max 5-minute timeout. Priority MUST. Risk MEDIUM.

### 15.4 Data (DATA)

- URS-04-DATA-001 — Every entity in §6.1 exists with the columns and constraints in §6.2; uniqueness enforced at the database level. Priority MUST. Risk HIGH.
- URS-04-DATA-002 — Append-only chains (signatures, snapshots, transitions, escalations) preserved across restore. Priority MUST. Risk HIGH.
- URS-04-DATA-003 — Soft-deleted templates / adapters / override requests remain queryable for audit / export. Priority MUST. Risk MEDIUM.

### 15.5 Security (SEC)

- URS-04-SEC-001 — All requests route through TDAL plus the appropriate hook chain. Priority MUST. Risk CRITICAL.
- URS-04-SEC-002 — Periodic access review per URS-01 §12.10 covers Module 4 events. Priority MUST. Risk HIGH.
- URS-04-SEC-003 — Periodic audit-trail review per URS-01 §12.11 covers Module 4 high-risk events. Priority MUST. Risk HIGH.
- URS-04-SEC-004 — SOC alert routing per §12.9. Priority MUST. Risk HIGH.

### 15.6 Audit (AUD)

- URS-04-AUD-001 — Every state-changing action emits an audit event with all required fields per URS-06 §6.6. Priority MUST. Risk HIGH.
- URS-04-AUD-002 — Server-derived metadata is the only source of truth for audit fields. Priority MUST. Risk HIGH.
- URS-04-AUD-003 — Audit-log write failure rolls back the originating action. Priority MUST. Risk CRITICAL.
- URS-04-AUD-004 — All event codes in §6.6 have at least one writer. Priority MUST. Risk MEDIUM.
- URS-04-AUD-005 — Hash-chain integrity verifier endpoint and CLI tool available; integrity verified on every export. Priority MUST. Risk HIGH.

### 15.7 Electronic Signature (ESIG)

- URS-04-ESIG-001 — Every regulated decision is electronically signed via the Controlled Approval Modal. Priority MUST. Risk HIGH.
- URS-04-ESIG-002 — Signature row carries server-derived `ip`, `user_agent`, `signed_at`, `signed_by`; signed content snapshot persisted. Priority MUST. Risk HIGH.
- URS-04-ESIG-003 — Signature is linked to the action row through `e_sig_id`. Priority MUST. Risk HIGH.
- URS-04-ESIG-004 — Re-authentication mandatory; multi-factor step-up mandatory for high-risk decisions per §6.7.1. Priority MUST. Risk HIGH.
- URS-04-ESIG-005 — Identity verification, signature-policy acknowledgement, and signature activation date prerequisites are inherited from URS-01 §6.7.1. Priority MUST. Risk HIGH.
- URS-04-ESIG-006 — Signature invalidation triggered on adapter fingerprint mismatch; `SIGNATURE_INVALIDATED` emitted. Priority MUST. Risk HIGH.

### 15.8 AI / HITL (AI)

- URS-04-AI-001 — No AI is invoked in any regulated-decision path. Priority MUST. Risk HIGH. Maps RG-04-016.
- URS-04-AI-002 — System actors (including `mira-agent@verixa.internal`) MUST be rejected as regulated signers. Priority MUST. Risk HIGH.

### 15.9 Integration (INT)

- URS-04-INT-001 — URS-01 supplies authenticated identity, re-authentication, and MFA step-up. Priority MUST. Risk HIGH.
- URS-04-INT-002 — URS-02 supplies effective permissions; Module 4 layers HITL on top. Priority MUST. Risk HIGH.
- URS-04-INT-003 — URS-03 supplies active context and approval-scope check at each regulated decision. Priority MUST. Risk HIGH.
- URS-04-INT-004 — URS-05 supplies Authority Profile data to the resolver. Priority MUST. Risk HIGH.
- URS-04-INT-005 — URS-06 ingests every Module 4 event and preserves hash-chain integrity. Priority MUST. Risk HIGH.
- URS-04-INT-006 — URS-30 delivers all notifications listed in §10. Priority MUST. Risk LOW.
- URS-04-INT-007 — URS-12..URS-34 (each consuming module) implement the Module 4 adapter contract. Priority MUST. Risk HIGH.
- URS-04-INT-008 — URS-35 preserves append-only chains across restore; restore drill verifies. Priority MUST. Risk HIGH.

### 15.10 Reports / Exports (REP)

- URS-04-REP-001 — All reports in §9 are implemented with documented filters, columns, formats, and access rules. Priority MUST. Risk MEDIUM.
- URS-04-REP-002 — Every export produces a self-verifying integrity manifest and is electronically signed. Priority MUST. Risk HIGH.
- URS-04-REP-003 — Export download URLs are signed and time-to-live limited (fifteen minutes). Priority MUST. Risk MEDIUM.

### 15.11 Validation Evidence (VAL)

- URS-04-VAL-001 — IQ pack verifies the schema of all migrations creating Module 4 tables; RLS enabled on every tenant-scoped table; library catalogue and adapter registry seeded. Priority MUST. Risk HIGH.
- URS-04-VAL-002 — OQ pack tests every approval-mode (single / dual / sequential / parallel), override flow, escalation flow, signature invalidation, library import, adapter registration, signature/record linking, hash-chain integrity, error-code emission. Priority MUST. Risk HIGH.
- URS-04-VAL-003 — PQ pack runs end-to-end scenarios for J-01..J-28. Priority MUST. Risk HIGH.
- URS-04-VAL-004 — Regression pack exercises every requirement in §15. Priority MUST. Risk MEDIUM.
- URS-04-VAL-005 — Traceability matrix links each requirement identifier in §15 to at least one IQ / OQ / PQ test case. Priority MUST. Risk HIGH.
- URS-04-VAL-006 — Supplier and service-provider qualification pack per §17.1 (notification provider, KMS, library publisher). Priority MUST. Risk HIGH.
- URS-04-VAL-007 — Inspection-ready evidence index per §17.2. Priority MUST. Risk HIGH.
- URS-04-VAL-008 — Migration Evidence Gate. Before Installation Qualification execution, engineering MUST provide the exact migration set proving all §6.2 entities, columns, constraints, indexes, RLS policies, append-only protections, advisory-lock setup for the snapshot chain, and adapter-registry seed. Installation Qualification MUST fail if any migration evidence is missing. Priority MUST. Risk CRITICAL.

---

## 16. Acceptance Criteria and Test Cases

### 16.1 Plain-language behaviour scenarios

#### TC-PLAIN-001 — Sarah signs a CAPA closure

Sarah opens her HITL inbox, picks the CAPA, opens the Controlled Approval Modal, re-authenticates, states what she is approving, gives a reason, and signs. The CAPA closes; the audit shows her authority profile, the scope match, the segregation-of-duties verdict, and a hash-chained snapshot.

#### TC-PLAIN-002 — Dual approval for a dual-registered batch

Two distinct authorised humans (one EU QP and one India AP) sign the batch release. The batch advances only after both signatures are in. The audit log shows both signatures linked to the same record and to a single transition.

#### TC-PLAIN-003 — Override used when primary unavailable

The QA Director uses override authority because the primary approver is unavailable. The system requires multi-factor step-up, an extended meaning of at least 80 characters, two override signers (when configured), and emits an SOC alert. The audit captures the original primary requirement and the override use.

#### TC-PLAIN-004 — Escalation when SLA exceeded

A complaint triage decision misses the 24-hour acknowledgement SLA. The system auto-escalates to the configured pool; the next available holder picks it up; the audit records the full escalation history.

#### TC-PLAIN-005 — Library template import is provenance-tracked

A platform administrator imports a vendor template into a tenant. The system verifies the source hash, records the provenance (key, semver, hash, importer), and the imported template enters draft to be approved through the same ceremony as a freshly authored template.

#### TC-PLAIN-006 — Signature invalidation when a signed document is later edited

After a CAPA is closed, someone edits the closed-state content. The system detects the fingerprint mismatch, marks the signature invalidated, displays the visual marker, and excludes the signature from "valid signature" report aggregations while preserving the historical link.

#### TC-PLAIN-007 — A user without the right authority is blocked

A user without `final_quality_approver` clicks Approve on a CAPA that requires it. The system rejects with a clear message; nothing is signed; the rejection is recorded.

#### TC-PLAIN-008 — Authority revoked between modal open and submit

The QA Manager opens the Controlled Approval Modal. Before they submit, their authority is revoked. The defence-in-depth check inside the e-signature service detects the loss; signature is not created; HITL decision remains open.

#### TC-PLAIN-009 — Sequential mode out-of-order attempt

A user attempts to sign a sequential-mode node out of order. The system rejects with a clear message naming the missing prior step; signature not created.

#### TC-PLAIN-010 — Parallel mode same-user duplicate attempt

A user who satisfied one parallel slot tries to satisfy the second. The system rejects; the same user cannot satisfy two slots.

#### TC-PLAIN-011 — Stub adapter rejected in production

A platform administrator tries to publish a workflow template that still references the stub adapter. The system rejects with a clear message; the template stays in approved.

#### TC-PLAIN-012 — Adapter conformance test gate

Engineering registers a new adapter. The conformance test pack runs synchronously. One contract test fails. The registration is rejected with a precise list of failing tests; the adapter is not registered.

#### TC-PLAIN-013 — High-risk decision requires MFA step-up

A user tries to import a library template without MFA step-up. The system demands the step-up; on failure the import is denied; on success the import proceeds.

### 16.2 Technical test cases

#### TC-TECH-001 — Single-mode regulated decision happy path

- Type: End-to-end. Linked: URS-04-BE-001..004, URS-04-FE-001.
- Steps: Open HITL inbox; submit a CAPA closure with valid Controlled Approval Modal payload. Verify HTTP 200; one signature row; one hash-chained snapshot row; one CAPA closure transition; audit chain intact.

#### TC-TECH-002 — Dual parallel mode happy path

- Type: End-to-end + Concurrency. Linked: URS-04-BE-007.
- Steps: Two authorised users sign the same batch in parallel. Verify two unique signatures; release transition fires only after both; same user cannot satisfy two slots.

#### TC-TECH-003 — Sequential mode order enforcement

- Type: Integration. Linked: URS-04-BE-006.
- Steps: Submit signer 2 before signer 1. Verify HTTP 409 `SEQUENTIAL_OUT_OF_ORDER`. Submit signer 1 first; verify pass; then signer 2; verify pass.

#### TC-TECH-004 — Override use with dual signature and MFA step-up

- Type: End-to-end. Linked: URS-04-BE-008.
- Steps: Submit override request; first override signer with MFA step-up and extended meaning; second override signer; verify both signatures, snapshot tagged override, SOC alert.

#### TC-TECH-005 — Authority revoked during decision

- Type: Integration. Linked: URS-04-BE-002, URS-04-BE-003.
- Steps: Open Controlled Approval Modal; revoke the user's authority via URS-05 admin path; submit. Verify HTTP 403 `APPROVAL_AUTHORITY_REVOKED_DURING_DECISION`; no signature.

#### TC-TECH-006 — Defence-in-depth for non-HITL signing path

- Type: Integration. Linked: URS-04-BE-003.
- Steps: Programmatically call `esigService.createSignature` directly with an actor who lacks authority. Verify denial; no signature row.

#### TC-TECH-007 — Hash-chained snapshot integrity under concurrency

- Type: Concurrency. Linked: URS-04-BE-014.
- Steps: Fire 100 parallel regulated decisions across multiple tenants. Verify hash chain unbroken per entity; no duplicate `record_hash`; advisory lock acquisition trace shows serialised writes per chain.

#### TC-TECH-008 — Audit-log write failure rollback

- Type: Chaos. Linked: URS-04-BE-013.
- Steps: Force audit log INSERT to fail mid-decision. Verify HTTP 500 `AUDIT_TRAIL_WRITE_FAILED`; no signature, no snapshot, no transition.

#### TC-TECH-009 — Stub adapter blocked in production publish

- Type: Integration. Linked: URS-04-BE-017.
- Steps: Attempt to publish a template referencing stub adapter. Verify HTTP 409 `STUB_ADAPTER_NOT_ALLOWED_IN_PRODUCTION`.

#### TC-TECH-010 — System actor blocked from regulated signature

- Type: Integration. Linked: URS-04-BE-015.
- Steps: Programmatic call as `mira-agent@verixa.internal` to a regulated decision endpoint. Verify HTTP 403 `SYSTEM_ACTOR_NOT_ELIGIBLE_FOR_REGULATED_DECISION`; no signature.

#### TC-TECH-011 — Library import with hash mismatch

- Type: Integration. Linked: URS-04-BE-009.
- Steps: Submit import with manipulated source_hash. Verify HTTP 409 `LIBRARY_HASH_MISMATCH`.

#### TC-TECH-012 — Workflow-instance pointer repoint forbidden post-signature

- Type: Integration. Linked: URS-04-BE-010.
- Steps: After first signature, attempt repoint. Verify HTTP 403 `WORKFLOW_INSTANCE_REPOINT_FORBIDDEN`.

#### TC-TECH-013 — Signature invalidation on post-signature mutation

- Type: Integration. Linked: URS-04-BE-011.
- Steps: Sign a record; mutate a fingerprint-relevant field; verify `invalidated_at` is set and `SIGNATURE_INVALIDATED` audited.

#### TC-TECH-014 — High-risk decision MFA step-up enforcement

- Type: Integration. Linked: URS-04-BE-012.
- Steps: Attempt template approval without MFA step-up; verify HTTP 401 `MFA_STEP_UP_REQUIRED`; submit step-up; verify pass.

#### TC-TECH-015 — Adapter conformance test failure

- Type: Integration. Linked: URS-04-BE-018.
- Steps: Register an adapter that fails one contract test. Verify HTTP 422 `ADAPTER_CONFORMANCE_FAILED`; no registration.

#### TC-TECH-016 — Server-derived metadata only

- Type: Integration + Penetration. Linked: URS-04-BE-020.
- Steps: Send a regulated submission with spoofed `ip`, `userAgent`, `timestamp`, `performedBy`. Verify those values are dropped server-side; signature row carries server-derived values.

#### TC-TECH-017 — Same signature row not reusable

- Type: Integration. Linked: URS-04-BE-016.
- Steps: Attempt to reuse an existing `e_sig_id` in a new decision. Verify uniqueness violation at the database; insert rejected.

#### TC-TECH-018 — HITL escalation at SLA boundary

- Type: Integration. Linked: URS-04-WF-003.
- Steps: Open HITL decision; advance clock past acknowledgement SLA; verify escalation row appended; assignment changed; URS-30 notification sent.

#### TC-TECH-019 — Workflow template approval ceremony

- Type: End-to-end. Linked: URS-04-WF-002.
- Steps: Author draft → submit-for-review → approve (with MFA step-up) → publish → retire. Verify each transition produces an electronic signature and audit row.

#### TC-TECH-020 — Performance: regulated decision throughput

- Type: Load. Linked: URS-04-BE-001..004.
- Steps: Sustain 200 RPS of regulated decisions for fifteen minutes. Verify p95 ≤ 300 ms (excluding upstream); error rate < 0.1 %.

#### TC-TECH-021 — Performance: signature integrity verifier

- Type: Load. Linked: URS-04-AUD-005.
- Steps: Verify a 1-million-row chain segment. Verify completion in ≤ 60 s; integrity status returned correctly.

#### TC-TECH-022 — Migrations idempotent and seed library + adapter registry

- Type: Migration. Linked: URS-04-VAL-001, URS-04-VAL-008.
- Steps: Apply all Module 4 migrations to a clean database; apply them again. Verify schema; RLS enabled on tenant-scoped tables; library catalogue seeded; adapter registry seeded.

#### TC-TECH-023 — Override rationale length enforcement

- Type: Integration. Linked: URS-04-FE-006.
- Steps: Submit override use with rationale < 80 chars. Verify HTTP 400 `OVERRIDE_RATIONALE_TOO_SHORT`.

#### TC-TECH-024 — Library import e-signature record

- Type: Integration. Linked: URS-04-INT-001..005.
- Steps: Import a library template. Verify provenance row + electronic signature + audit chain.

#### TC-TECH-025 — Signature manifestation render

- Type: End-to-end. Linked: URS-04-FE-007.
- Steps: Open a signed regulated record. Verify the signature panel renders all required fields including hash-chain integrity badge.

#### TC-TECH-026 — `NODE_REQUIREMENT_MISSING` blocks decision

- Type: Integration. Linked: URS-04-BE-005.
- Steps: Submit a regulated decision against a node lacking `workflow_node_approval_requirements`. Verify HTTP 500 `NODE_REQUIREMENT_MISSING`; SOC alert; no signature.

#### TC-TECH-027 — HITL submit by non-assignee

- Type: Integration. Linked: URS-04-WF-001.
- Steps: User who is not the assignee submits a decision. Verify HTTP 403 `HITL_NOT_ASSIGNED`.

#### TC-TECH-028 — Bulk decisions per-record authority

- Type: Integration. Linked: URS-04-BE-002.
- Steps: Submit 25 decisions in bulk; mix in/out of authority. Verify 207 multi-status; per-row outcome; one snapshot per success.

#### TC-TECH-029 — Adapter contract conformance test pack

- Type: Validation. Linked: URS-04-BE-018.
- Steps: For each entity-type adapter, run the contract conformance pack. Verify all pass.

#### TC-TECH-030 — Restore preserves authority-snapshot chain

- Type: DR drill. Linked: URS-04-INT-008.
- Steps: Restore a snapshot from backup. Verify hash chain validates intact.

### 16.3 Acceptance criteria summary in Given / When / Then form

#### Functional

- AC-04-FUN-01 — Given a single-mode regulated decision, When committed, Then one signature, one snapshot, and one transition row exist.
- AC-04-FUN-02 — Given dual / parallel mode, When all signers complete, Then the transition fires; same user cannot satisfy two slots.
- AC-04-FUN-03 — Given override use, When committed, Then snapshot tagged override; SOC alert; original requirement archived.

#### UI

- AC-04-UI-01 — Given high-risk decision, When submitting, Then MFA step-up is demanded.
- AC-04-UI-02 — Given a signed record, When viewed, Then signature panel renders all required fields including invalidation marker.

#### API

- AC-04-API-01 — Given non-HITL caller invokes `esigService.createSignature` for a non-eligible actor, When processed, Then signature is denied.
- AC-04-API-02 — Given library import with hash mismatch, When processed, Then HTTP 409 `LIBRARY_HASH_MISMATCH`.

#### Workflow

- AC-04-WF-01 — Given HITL SLA exceeded, When the scheduler runs, Then the decision is escalated.
- AC-04-WF-02 — Given a stub adapter referenced, When publishing the template, Then publish is rejected.

#### Permission / Authority

- AC-04-PERM-01 — Given a user without the required Authority Profile, When submitting, Then HTTP 403 `APPROVAL_AUTHORITY_DENIED`.
- AC-04-PERM-02 — Given authority revoked between modal open and submit, When submitting, Then HTTP 403 `APPROVAL_AUTHORITY_REVOKED_DURING_DECISION`.

#### Audit

- AC-04-AUD-01 — Given any state-changing Module 4 action, When the audit transaction is rolled back, Then the action is also rolled back.
- AC-04-AUD-02 — Given 100 parallel regulated decisions per entity, When the chain integrity verifier runs, Then the snapshot chain is unbroken.

#### Electronic signature

- AC-04-ESIG-01 — Given a regulated decision, When committed, Then signature row carries server-derived `ip`, `user_agent`, `signed_at`, `signed_by`.
- AC-04-ESIG-02 — Given a signed entity is mutated post-signature, Then `SIGNATURE_INVALIDATED` is emitted and the signature flagged invalidated.

#### Data integrity

- AC-04-DI-01 — Given a soft-deleted template, When auditor queries audit-export, Then the template appears in audit history.
- AC-04-DI-02 — Given concurrent regulated decisions, When committed, Then per-entity hash chain is strictly monotonic.

#### Integration

- AC-04-INT-01 — Given a regulated decision, When committed, Then URS-06 ingests the audit + snapshot rows in the same transaction.
- AC-04-INT-02 — Given URS-35 restores a database snapshot, When the integrity verifier runs, Then the audit chain validates including Module 4 events.

#### Report / export

- AC-04-REP-01 — Given an administrator exports the regulated-decision register, When the download completes, Then the manifest validates and the export is electronically signed.

#### AI / HITL

- AC-04-AI-01 — Static analysis finds zero references to large-language-model SDKs in Module 4.
- AC-04-AI-02 — System actors are rejected as regulated signers.

#### Negative paths

- AC-04-NEG-01 — Given missing node requirement, When submitting, Then HTTP 500 `NODE_REQUIREMENT_MISSING` and SOC alert.
- AC-04-NEG-02 — Given override rationale below 80 chars, When submitting, Then HTTP 400 `OVERRIDE_RATIONALE_TOO_SHORT`.

#### Performance

- AC-04-PERF-01 — Regulated decision p95 ≤ 300 ms at 200 RPS sustained (excluding upstream).
- AC-04-PERF-02 — Hash-chain integrity verifier ≤ 60 s for 1 M rows.

#### Security

- AC-04-SEC-01 — Penetration test: cross-tenant token replay returns 404 with no tenant B data.
- AC-04-SEC-02 — Penetration test: bypass attempts of `validateApprovalAction` produce `ESIG_CREATION_DENIED` rows.

#### Migration / backfill

- AC-04-MIG-01 — Module 4 migrations are idempotent.
- AC-04-MIG-02 — Applying all Module 4 migrations seeds library catalogue and adapter registry.

### 16.4 Requirements-to-test traceability

| Requirement | Plain-language | Technical | Given / When / Then |
|---|---|---|---|
| URS-04-FE-001 | TC-PLAIN-001 | TC-TECH-001, TC-TECH-016 | AC-04-ESIG-01 |
| URS-04-FE-002 | TC-PLAIN-013 | TC-TECH-014 | AC-04-UI-01 |
| URS-04-FE-003 | TC-PLAIN-001 | TC-TECH-027 | — |
| URS-04-FE-004 | TC-PLAIN-009 | TC-TECH-003 | — |
| URS-04-FE-005 | TC-PLAIN-010 | TC-TECH-002 | — |
| URS-04-FE-006 | TC-PLAIN-003 | TC-TECH-023 | AC-04-NEG-02 |
| URS-04-FE-007 | TC-PLAIN-006 | TC-TECH-025 | AC-04-UI-02 |
| URS-04-FE-008 | — | TC-TECH-022 | — |
| URS-04-FE-009 | TC-PLAIN-005, TC-PLAIN-013 | TC-TECH-014, TC-TECH-024 | — |
| URS-04-FE-010 | — | TC-TECH-022 | — |
| URS-04-BE-001 | TC-PLAIN-001 | TC-TECH-001 | AC-04-FUN-01 |
| URS-04-BE-002 | TC-PLAIN-008 | TC-TECH-005, TC-TECH-006 | AC-04-PERM-02 |
| URS-04-BE-003 | TC-PLAIN-008 | TC-TECH-006 | AC-04-API-01 |
| URS-04-BE-004 | TC-PLAIN-001 | TC-TECH-001, TC-TECH-007 | AC-04-AUD-02 |
| URS-04-BE-005 | TC-PLAIN-007 | TC-TECH-026 | AC-04-NEG-01 |
| URS-04-BE-006 | TC-PLAIN-009 | TC-TECH-003 | — |
| URS-04-BE-007 | TC-PLAIN-010 | TC-TECH-002 | AC-04-FUN-02 |
| URS-04-BE-008 | TC-PLAIN-003 | TC-TECH-004 | AC-04-FUN-03 |
| URS-04-BE-009 | TC-PLAIN-005 | TC-TECH-011 | AC-04-API-02 |
| URS-04-BE-010 | — | TC-TECH-012 | — |
| URS-04-BE-011 | TC-PLAIN-006 | TC-TECH-013 | AC-04-ESIG-02 |
| URS-04-BE-012 | TC-PLAIN-013 | TC-TECH-014 | AC-04-UI-01 |
| URS-04-BE-013 | — | TC-TECH-008 | AC-04-AUD-01 |
| URS-04-BE-014 | TC-PLAIN-002 | TC-TECH-007 | AC-04-AUD-02 |
| URS-04-BE-015 | — | TC-TECH-010 | AC-04-AI-02 |
| URS-04-BE-016 | — | TC-TECH-017 | — |
| URS-04-BE-017 | TC-PLAIN-011 | TC-TECH-009 | AC-04-WF-02 |
| URS-04-BE-018 | TC-PLAIN-012 | TC-TECH-015, TC-TECH-029 | — |
| URS-04-BE-019 | — | TC-TECH-022 | AC-04-SEC-01 |
| URS-04-BE-020 | — | TC-TECH-016 | AC-04-ESIG-01 |
| URS-04-WF-001 | TC-PLAIN-004 | TC-TECH-018, TC-TECH-027 | AC-04-WF-01 |
| URS-04-WF-002 | TC-PLAIN-005 | TC-TECH-019 | — |
| URS-04-WF-003 | TC-PLAIN-004 | TC-TECH-018 | AC-04-WF-01 |
| URS-04-WF-004 | TC-PLAIN-012 | TC-TECH-015 | — |
| URS-04-DATA-001 | — | TC-TECH-022 | — |
| URS-04-DATA-002 | — | TC-TECH-030 | AC-04-INT-02 |
| URS-04-DATA-003 | TC-PLAIN-005 | (audit retention test) | AC-04-DI-01 |
| URS-04-SEC-001 | — | TC-TECH-022 | AC-04-SEC-01 |
| URS-04-SEC-002 | — | (review test) | — |
| URS-04-SEC-003 | — | (audit-trail review test) | — |
| URS-04-SEC-004 | TC-PLAIN-003 | TC-TECH-004 | — |
| URS-04-AUD-001 | — | TC-TECH-001, TC-TECH-008 | — |
| URS-04-AUD-002 | — | TC-TECH-016 | AC-04-ESIG-01 |
| URS-04-AUD-003 | — | TC-TECH-008 | AC-04-AUD-01 |
| URS-04-AUD-004 | — | (writer presence test) | — |
| URS-04-AUD-005 | — | TC-TECH-007, TC-TECH-021 | AC-04-AUD-02, AC-04-INT-02 |
| URS-04-ESIG-001 | TC-PLAIN-001 | TC-TECH-001 | — |
| URS-04-ESIG-002 | — | TC-TECH-016 | AC-04-ESIG-01 |
| URS-04-ESIG-003 | TC-PLAIN-001 | TC-TECH-001 | — |
| URS-04-ESIG-004 | TC-PLAIN-013 | TC-TECH-014 | — |
| URS-04-ESIG-005 | — | (URS-01 prerequisite test) | — |
| URS-04-ESIG-006 | TC-PLAIN-006 | TC-TECH-013 | AC-04-ESIG-02 |
| URS-04-AI-001 | — | (static analysis) | AC-04-AI-01 |
| URS-04-AI-002 | — | TC-TECH-010 | AC-04-AI-02 |
| URS-04-INT-001 | TC-PLAIN-013 | TC-TECH-014 | — |
| URS-04-INT-002 | — | TC-TECH-001 | — |
| URS-04-INT-003 | — | TC-TECH-001 | — |
| URS-04-INT-004 | TC-PLAIN-007 | TC-TECH-005 | — |
| URS-04-INT-005 | — | TC-TECH-007 | AC-04-INT-01 |
| URS-04-INT-006 | TC-PLAIN-004 | TC-TECH-018 | — |
| URS-04-INT-007 | TC-PLAIN-012 | TC-TECH-029 | — |
| URS-04-INT-008 | — | TC-TECH-030 | AC-04-INT-02 |
| URS-04-REP-001 | — | (export test) | AC-04-REP-01 |
| URS-04-REP-002 | — | (manifest test) | AC-04-REP-01 |
| URS-04-REP-003 | — | (TTL test) | — |
| URS-04-VAL-001 | — | TC-TECH-022 | — |
| URS-04-VAL-002 | All applicable | All applicable | All applicable |
| URS-04-VAL-003 | All applicable | All applicable | All applicable |
| URS-04-VAL-004 | — | full TC-TECH suite | — |
| URS-04-VAL-005 | — | this table is the seed | — |
| URS-04-VAL-006 | — | (supplier qualification) | — |
| URS-04-VAL-007 | — | (evidence index) | — |
| URS-04-VAL-008 | — | TC-TECH-022 | AC-04-MIG-01, AC-04-MIG-02 |
| Multi-signer slot table (`hitl_decision_signatures`) — schema, uniqueness, RLS | — | TC-TECH-002, TC-TECH-003, TC-TECH-006 | AC-04-FUN-02, AC-04-DI-01 |
| Multi-signer slot table — declared signing order in sequential mode | — | TC-TECH-003 | AC-04-FUN-02 |
| Multi-signer slot table — same-human-cannot-satisfy-two-slots invariant | — | TC-TECH-002 | AC-04-FUN-02 |
| `workflow_transitions_log.transition_type` discriminator and nullability of `e_sig_id` for non-regulated transitions | — | TC-TECH-018 | AC-04-WF-01 |
| `workflow_template_approvals` multi-step (peer review + final approval) | — | TC-TECH-019 | — |
| Library import API split (tenant-scoped vs platform-scoped) | — | TC-TECH-024 | AC-04-API-02 |
| Per-entity advisory lock for hash chain | — | TC-TECH-021 | AC-04-DI-02 |
| Annex 22 forward-looking exclusion (no control text depends on RG-04-021) | — | RG-04-020 / RG-04-021 review | — |

---

## 17. Validation and CSV/CSA Evidence Expectations

| Item | Required evidence |
|---|---|
| URS traceability | Matrix linking every requirement identifier in §15 to test-case identifiers and to a regulatory-mapping row in §14 |
| Risk assessment | GAMP 5 risk register; risk-based assurance per FDA CSA |
| Configuration specification | Documented seed of `workflow_template_library` and `regulated_entity_adapters`; high-risk action list; HITL SLA defaults |
| Functional specification | Matches §6 of this document |
| Design specification | Matches §6.1–§6.4 |
| Test protocols | IQ (schema, RLS, indexes, per-entity advisory locks scoped to `(tenant_id, entity_type, target_record_id)`, `hitl_decision_signatures` uniqueness invariants, `workflow_transitions_log.transition_type` discriminator + nullable `e_sig_id` rules, `workflow_template_approvals` multi-step uniqueness, library / adapter seed); OQ per URS-04-VAL-002; PQ per URS-04-VAL-003; regression per URS-04-VAL-004 |
| Test evidence | Pass / fail records per protocol step, traced to requirement identifier |
| Defect log | Defects mapped to URS requirement identifiers; resolved before release |
| Requirements traceability matrix | Per §16.4 |
| Release approval | Electronically signed by Quality Lead, Validation Lead, Information Security Lead, Regulatory Affairs Lead, executive authority |
| Training record | Engineering, QA, validation, operations trained on Module 4 expected state |
| Periodic review | Annual review per EU GMP Annex 11 §11; trigger reviews on every significant change |
| Data migration evidence | Backfill of `electronic_signatures` and `approval_authority_snapshots` chain genesis rows |

### 17.1 Supplier and service-provider qualification pack

| Category | Required evidence |
|---|---|
| Cloud hosting provider | Inherited from URS-01 §17.1 |
| Notification provider | Inherited from URS-01 §17.1 |
| Library publisher (workflow templates) | Source-hash signing process, semver discipline, deprecation policy, right-to-audit |
| Adapter authors (each consuming module) | Conformance test pass record, version history, deprecation policy |
| Backup and restore provider | Restore drill preserving snapshot chain integrity |
| Security-operations / SIEM | Alert routing per §12.9 |

### 17.2 Inspection-ready evidence index

| Evidence item | Owner | Location / system of record | Retention | Linked requirement | Inspection use |
|---|---|---|---|---|---|
| Electronic signatures | QA | `electronic_signatures` + audit log | seven years | URS-04-ESIG-001 | demonstrate authority of record per signed action |
| Per-decision signature slot register (multi-signer model) | QA | `hitl_decision_signatures` | seven years | URS-04-BE-006, URS-04-BE-007, URS-04-WF-001 | demonstrate that dual / sequential / parallel decisions captured every required signer in the declared slot, with signing order and SoD-preserved unique-signer enforcement |
| Approval authority snapshots | QA / Information Security | `approval_authority_snapshots` (hash-chained) | twenty-five years | URS-04-AUD-005 | demonstrate authority of record per regulated decision |
| Override register | QA / Founder | override_requests + override_decisions + audit | twenty-five years | URS-04-BE-008 | demonstrate break-glass governance |
| Workflow template version history | QA | `workflow_template_versions` + approvals | retain history | URS-04-WF-002 | demonstrate template baseline |
| Library import register | QA | `workflow_template_imports` | retain history | URS-04-BE-009 | demonstrate supplier oversight on imported templates |
| Adapter registration register | Platform / QA | `adapter_registrations` | retain history | URS-04-BE-018 | demonstrate adapter conformance discipline |
| HITL escalation log | QA | `hitl_escalation_log` | seven years | URS-04-WF-003 | demonstrate operational discipline |
| Signature invalidation register | Information Security | `signature_invalidations` | seven years | URS-04-BE-011 | demonstrate forensic posture on post-signature mutations |
| Validation evidence pack (IQ / OQ / PQ) | Validation | testing system of record | retain per release | URS-04-VAL-001..008 | release approval |
| Release approval (electronically signed) | Founder, QA, RA, Validation, Information Security | document control (URS-12) | retain per release | URS-04-VAL-007 | demonstrate authority chain for release |

---

## 18. Closed Decision and Dependency Register

### 18.1 Closed Launch Decisions Register

Every closed launch decision is locked in §2.3 and summarised below. No Module 4 internal open questions remain.

| Closed decision | Spec reference |
|---|---|
| Five workflow template lifecycle states + complete allowed-transition set including controlled `under_review → draft` return for correction | DEC-04-01 |
| Four approval modes (single, dual, sequential, parallel) | DEC-04-02 |
| Per-node approval-requirement field set | DEC-04-03 |
| Controlled Approval Modal contract fields | DEC-04-04 |
| Electronic signature components (identification code + password; biometric Class 1 future) | DEC-04-05 |
| Multi-factor step-up mandatory on high-risk action list | DEC-04-06, §6.7.1 |
| No hard-coded approval-requirement defaults | DEC-04-07, BR-04-13 |
| Authority validation runs twice per decision | DEC-04-08, BR-04-02 |
| Hash-chained snapshots with per-entity advisory lock scoped to `(tenant_id, entity_type, target_record_id)` | DEC-04-09, BR-04-16 |
| Override use rules (MFA step-up, extended meaning, archived primary, SOC alert, dual-sign where configured) | DEC-04-10, BR-04-08 |
| Library import provenance fields; tenant-scoped vs platform-scoped library API split | DEC-04-11, BR-04-10, §6.3.1 |
| Launch adapter set; stub-adapter not allowed in production | DEC-04-12, BR-04-14 |
| Workflow-instance pointer immutable post-signature | DEC-04-13, BR-04-11 |
| HITL lifecycle with tenant-configurable SLA defaults; per-slot signature linkage via `hitl_decision_signatures` | DEC-04-14, §6.1.2 |
| Signature invalidation automatic on adapter fingerprint mismatch | DEC-04-15, BR-04-12 |
| Annex 22 forward-looking only — controlled URS-04 baseline depends only on 21 CFR Part 11 + EU GMP Annex 11 | RG-04-020, RG-04-021 |

### 18.2 Dependencies

| ID | Dependency | Source | Impact | Blocking? | Mitigation |
|---|---|---|---|---|---|
| DEP-04-01 | URS-01 authentication, MFA step-up, identity-verification prerequisites | URS-01 | Substrate | Blocking | none |
| DEP-04-02 | URS-02 effective permissions and matrix-version | URS-02 | Substrate | Blocking | none |
| DEP-04-03 | URS-03 active context and approval-scope check | URS-03 | Substrate | Blocking | none |
| DEP-04-04 | URS-05 Authority Profile catalogue, scope rules, delegations, segregation-of-duties rules | URS-05 | Resolver semantics | Blocking | none |
| DEP-04-05 | URS-06 universal audit substrate and retention | URS-06 | Audit ingest | Blocking | none |
| DEP-04-06 | URS-08 active-tenant gate | URS-08 | Lifecycle | Blocking | none |
| DEP-04-07 | URS-12..URS-34 adapters | every consuming module | Per-entity integration | Blocking per module | adapter conformance pack |
| DEP-04-08 | URS-30 notification delivery service | URS-30 | Notifications | Non-blocking | direct e-mail fallback |
| DEP-04-09 | URS-35 backup / restore preserves append-only chains | URS-35 | DR | Blocking for PQ | DR drill |

---

## 19. Completeness Checklist

| Item | Yes / No | Evidence |
|---|---|---|
| Controlled-document metadata complete? | Yes | front matter |
| Approval block complete? | Yes (signatures pending) | Document Approval section |
| Version history complete? | Yes | Version History |
| Glossary complete? | Yes | §0.6 |
| Scope complete? | Yes | §2 |
| Roles and permissions complete? | Yes | §3 |
| User journeys complete? | Yes | §4 (28 journeys) |
| Front-end complete? | Yes | §5 |
| Backend complete? | Yes | §6 |
| Data model complete? | Yes | §6.2 |
| APIs complete? | Yes | §6.3 |
| Workflow complete? | Yes | §6.4 |
| Business rules complete? | Yes | §6.5 |
| Audit trail complete? | Yes | §6.6, BR-04-15, URS-04-AUD-001..005 |
| Electronic signature complete? | Yes | §6.7, URS-04-ESIG-001..006 |
| AI / Human-in-the-Loop complete? | Yes (no AI; HITL is the module's core) | §8 |
| Reports complete? | Yes | §9 |
| Notifications complete? | Yes | §10 |
| Cross-module wiring complete? | Yes | §7 |
| Change-impact matrix complete? | Yes | §7.2 |
| Negative paths complete? | Yes | §11 |
| Security / privacy / tenant isolation complete? | Yes | §12 |
| ALCOA+ complete? | Yes | §13 |
| Regulatory mapping complete? | Yes | §14 |
| Predicate-rule applicability matrix complete? | Yes | §14.1 |
| Requirements register complete? | Yes | §15 |
| Acceptance tests complete? | Yes | §16 |
| Requirements-to-test traceability complete? | Yes | §16.4 |
| Validation evidence complete? | Yes | §17, §17.1, §17.2, URS-04-VAL-001..008 |
| Supplier and service-provider qualification pack complete? | Yes | §17.1 |
| Decisions and dependencies registered (no internal decisions outstanding)? | Yes | §18.1, §18.2 |
| Final quality gate answered? | Yes | §20 |

---

## 20. Final Module Output Quality Gate

**URS approval is separate from validation execution.** This document becomes "Approved Controlled URS — released for engineering implementation and validation planning" upon signature capture in the Document Approval block; it becomes "Released for validation execution" only after URS-04-VAL-008 (Migration Evidence Gate) and the §17 validation evidence pack are satisfied. **No Module 4 internal open questions remain.**

- **Specification ready for engineering review?** Yes — every MUST requirement is declarative, atomic, and testable. Front end, back end, data, application programming interface, workflow, audit, electronic signature, security, integration, and the adapter contract are covered as a single self-contained contract.
- **Specification ready for quality validation review?** Yes — Installation, Operational, and Performance Qualification scope is specified; the traceability matrix template is in §16.4; the high-risk action list in §6.7.1 is enumerated.
- **Specification ready for compliance review?** Yes — ALCOA+ table, regulatory mapping, and predicate-rule applicability matrix are populated.
- **Specification ready for inspector or client review?** Yes — every regulated assertion traces to a regulatory clause and to a test case; no internal item remains open.
- **Specification ready for Founder approval?** Yes.
- **Blocking gaps?** **None internal.** Cross-module dependencies (§18.2) are owned by their named companion modules and tracked at the program level. The Installation Qualification gate URS-04-VAL-008 and the §17 evidence pack govern only the transition to "Released for validation execution".
- **Two-step release path:**
  1. **Approved Controlled URS — released for engineering implementation and validation planning.** Reached upon signature capture. Engineering may begin implementation; validation may begin protocol authoring.
  2. **Released for validation execution.** Reached after URS-04-VAL-008 is satisfied and the §17 evidence pack is complete. Document Status updates from "Approved Controlled URS" to "Released for validation execution".

---

## Appendix A — Bootstrap and Decision Pipeline Composite

```mermaid
flowchart TD
  A([Browser opens app]) --> B[App.tsx mount]
  B --> C[useAuthInit → /auth/me URS-01]
  C --> D[useEffectivePermissions URS-02]
  D --> E[useContext URS-03]
  E --> F[App renders authenticated routes]
  F --> G[User opens HITL inbox]
  G --> H[User picks decision, opens Controlled Approval Modal]
  H --> I[Submit: password + meaning + reason + MFA step-up if high risk]
  I --> J[validateApprovalAction at runtime]
  J --> K{Allowed?}
  K -- No --> X1[403 APPROVAL_AUTHORITY_DENIED]
  K -- Yes --> L[esigService.createSignature]
  L --> M[validateApprovalAction defence in depth]
  M --> N[Insert electronic_signatures]
  N --> O["Insert approval_authority_snapshots hash-chained, advisory lock on tenant_id, entity_type, target_record_id"]
  O --> SLOT[Insert hitl_decision_signatures slot row binding signature to decision slot]
  SLOT --> COMPLETE{Slot requirement satisfied? minApprovers + finalApproverRequired + approvalMode rules}
  COMPLETE -- No --> WAIT[HITL_SLOT_SIGNED audit emitted; decision remains open for remaining slots]
  COMPLETE -- Yes --> P[Adapter applies state transition; workflow_transitions_log row written with transition_type and final_signature_at]
  P --> Q[URS-06 audit + URS-30 notifications]
  Q --> R[HTTP 200 to UI]
```

— End of Module 4 User Requirements Specification —