# Verixa — User Requirements Specification # Module 5: Authority Profile / Approval Delegation / Segregation of Duties | Field | Value | |---|---| | Document ID | VRX-URS-05 | | 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-05-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 Authority Profile catalogue, the user-to-Authority assignment register, the Approval Delegation overlay, the Segregation-of-Duties rule registry and exception register, and the resolver functions (`resolveApprovalCandidates`, `validateApprovalAction`, `snapshotApprovalAuthority`, `evaluateSoD`) that gate every regulated decision in the platform. Module 5 is the authority-of-record substrate. | | Date of Issue | 2026-05-06 | | Module Owner (Engineering) | Authority / Resolver Squad | | Module Owner (Quality Validation) | CSV / CSA Lead — Authority of Record | | Module Owner (Compliance) | Quality Assurance, Regulatory Affairs, Information Security | | 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 5. | --- ## 0. Document Framing ### 0.1 Purpose of this document This URS defines the target expected state for Verixa's Authority Profile / Approval Delegation / Segregation of Duties module (Module 5). 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 authority-of-record substrate that gates every regulated decision in the platform: the Authority Profile catalogue (Tier 1 global, Tier 2 tenant-defined), the user-to-Authority assignment register, the Approval Delegation overlay (time-bound transfer of authority), the Segregation-of-Duties rule registry and exception register, and the four resolver functions (`resolveApprovalCandidates`, `validateApprovalAction`, `snapshotApprovalAuthority`, `evaluateSoD`). Compliance with this URS is mandatory. ### 0.2 Audience Engineering, QA, Validation, Regulatory Affairs, Information Security, executive authority, the platform's customer-facing Implementation team, internal and external auditors, and inspectors from regulatory bodies including the United States Food and Drug Administration, the European Medicines Agency / national competent authorities, the Medicines and Healthcare products Regulatory Agency, Health Canada, the Central Drugs Standard Control Organisation of India, and Pharmaceutical Inspection Co-operation Scheme members. The plain-language primer (§0.5) and worked examples (§3.5) make Module 5 accessible to non-domain engineers, product owners, and validation engineers who have not previously specified authority-of-record systems for regulated GxP platforms. ### 0.3 How to read this document Each requirement has a unique identifier. "MUST" denotes a mandatory requirement; "SHOULD" denotes a strong recommendation; "MAY" denotes an option. The document is self-contained: front end (§5), back end (§6), data model (§6.2), application programming interface (§6.3), workflow (§6.4), business rules (§6.5), audit (§6.6), security (§12), regulatory mapping (§14), test cases (§16), and validation evidence (§17) are all in this single file. ### 0.4 Plain-language primer for non-domain readers Every regulated decision in a Verixa-controlled pharmaceutical-quality system requires evidence that the human who made the decision had the **authority of record** to make it at the moment they made it. "Authority of record" is the regulator's term for the formal, documented permission to make a binding quality or compliance decision. Authority of record has four overlapping requirements: **Eligibility** — does this user hold an Authority Profile that grants them the right to take this action? An Authority Profile is a named bundle of authority — for example `final_quality_approver`, `qp_eu` (EU Qualified Person), `ap_india` (India Authorised Person), `complaint_closure_approver`. Module 5 owns the catalogue and the user-to-profile assignment register. **Scope match** — does the user's Authority Profile cover the specific record they are deciding on? An assignment may be limited to specific sites, products, studies, suppliers, or jurisdictions. For example, a `qp_eu` whose scope is Site A and Product Family Alpha may not release a batch from Site B. **Segregation of Duties (SoD)** — is the user prevented by a SoD rule from making this decision? A SoD rule excludes specific user-to-record relationships — the most common is "the author of a record cannot be the approver of the same record." Module 5 owns the SoD rule registry and the exception register. **Delegation overlay** — has someone else's authority been temporarily delegated to this user, with effective dates, scope, and acknowledgement? Delegation does not transfer the original authority — it grants the delegate the right to act on behalf of the delegator within a defined window. Module 5 owns the delegation register. The four pieces are computed by **the resolver**, the engine implemented by Module 5 and consumed by Module 4 (and indirectly by Modules 12-34, every regulated module, through Module 4's adapter contract). The resolver answers four questions for every regulated decision: who is eligible to act on this record, can this specific user act right now, what is the snapshot of their authority at the moment they signed, and does any SoD rule apply. The resolver is invoked twice per decision (once at HITL submission, once again immediately before signature insertion) per Module 4 DEC-04-08, as a defence-in-depth control against authority change between modal open and submit. Module 5 is the brain that Module 4's signature ceremony asks for permission. If the resolver denies, the signature ceremony refuses to insert the signature row and the regulated decision does not commit. **Authority Profiles are not roles.** Roles (URS-02) say what surfaces of the application a user can read or use; Authority Profiles say what regulated decisions they may sign. A user may hold the `quality_lead` base role and also hold one or more Authority Profiles such as `final_quality_approver` for two specific products. Roles and Authority Profiles compose: roles gate the surface, Authority Profiles gate the decision. Module 4 enforces both before allowing a regulated state transition. ### 0.5 Authority composition diagram (decision-time evaluation) ```mermaid flowchart TD A([Regulated decision arrives]) --> B[Module 4 opens HITL decision] B --> C[resolveApprovalCandidates URS-05] C --> D{Step 1 — eligibility} D --> E[Step 2 — scope match URS-03 active scope vs assignment scope] E --> F[Step 3 — segregation of duties evaluateSoD] F --> G[Step 4 — delegation overlay applied if any] G --> H[Resolver returns candidate list] H --> I[Module 4 invokes validateApprovalAction at signature time] I --> J{Allowed?} J -- No --> K[403 APPROVAL_AUTHORITY_DENIED] J -- Yes --> L[Module 4 inserts electronic_signatures] L --> M[Module 5 snapshotApprovalAuthority hash-chained] M --> N[Module 4 adapter applies state transition] N --> O[URS-06 audit + URS-30 notifications] ``` Diagram 0.5-A — How Module 5's four-step authority computation feeds Module 4's signature ceremony. Module 4 calls Module 5's resolver at the start of every regulated decision and again immediately before signature insertion (defence-in-depth per DEC-04-08). ### 0.6 Glossary of key terms used in this document | Term | Definition | |---|---| | Authority Profile | A named bundle of authority that grants a user the right to sign specific classes of regulated decisions. Tier 1 profiles are defined globally by Verixa; Tier 2 profiles are tenant-defined. | | Authority Profile assignment | The record that binds a user to an Authority Profile within a specific scope and effective-date window, with electronic signature, audit, and a defined revocation path. | | Authority of record | The regulator's term for the formal, documented permission to take a binding quality or compliance decision at the moment it is taken. Module 5 produces the evidence. | | Delegation | A time-bound, scope-bound, acknowledged transfer of the right to act on behalf of a delegator. Delegation does not transfer the underlying Authority Profile assignment. | | Delegation overlay | The runtime computation that, for a given user-and-decision, identifies whether an active delegation makes the user eligible to act despite not directly holding the Authority Profile. | | Eligibility | The first step of the resolver: does the user (directly or through delegation overlay) hold an Authority Profile that names a `requiredAuthorityKey` for this decision's workflow node? | | Override authority | A specific Authority Profile used as the break-glass authority for another profile's gate, configured per workflow node by Module 4. Override use requires multi-factor step-up, extended meaning, and SOC alert (URS-04 §6.7.1). | | Periodic access review | An annual (or more frequent) review of every active Authority Profile assignment, attested by a designated reviewer with electronic signature. Inactive holders are flagged for revocation. | | Resolver | The four runtime functions implemented by Module 5: `resolveApprovalCandidates`, `validateApprovalAction`, `evaluateSoD`, `snapshotApprovalAuthority`. | | Scope dimension | The dimension along which an Authority Profile assignment may be scoped: site, product, product-family, study, supplier, jurisdiction, business-unit. The launch set is enumerated in §6.2. | | Scope match | The second step of the resolver: does the user's Authority Profile assignment scope intersect with the active scope (URS-03) of the record under decision? | | Segregation of Duties (SoD) | The third step of the resolver: does any SoD rule (Tier 1 fixed launch set + Tier 2 tenant-defined) exclude this user from this decision (e.g., author cannot be approver)? | | SoD exception | A documented, dual-signed, time-bound exception to a SoD rule. Required when a tenant cannot otherwise complete a decision (e.g., small-tenant single-author scenarios). | | Snapshot | The hash-chained, append-only record of the resolver's verdict at the exact moment of signature insertion: the user's Authority Profiles, delegation overlays, scope match, SoD verdict, claims version, and a backward link to the previous snapshot in the per-entity chain. | | Tier 1 profile | A globally defined Authority Profile maintained in the platform catalogue (e.g., `final_quality_approver`, `qp_eu`). Tier 1 changes are platform-administrator-controlled and are a Class 1 change. | | Tier 2 profile | A tenant-defined Authority Profile created by tenant administrators for tenant-specific business processes (e.g., `tenant_specific_research_approver`). Tier 2 changes are tenant-administrator-controlled with electronic signature. | ### 0.7 Module 5 architectural picture ```mermaid graph LR subgraph M5 [Module 5 — Authority of Record Substrate] CAT[Authority Profile Catalogue] ASN[Assignments Register] DEL[Delegation Overlay] SOD[SoD Rule Registry + Exception Register] RES[Resolver: candidates / validate / evaluateSoD / snapshot] end M1[URS-01 Auth] --> RES M2[URS-02 RBAC] --> RES M3[URS-03 Context] --> RES RES --> M4[URS-04 Workflow / E-Sign / HITL] RES --> M6[URS-06 Audit substrate] M4 --> M12[URS-12..URS-34 Regulated modules] CAT -.platform admin.-> CAT ASN -.tenant admin.-> ASN ``` Diagram 0.7-A — Module 5 sits between the access-control modules (URS-01 / URS-02 / URS-03) and the workflow / signature substrate (URS-04). Module 5 is consumed by Module 4 for every regulated decision and by URS-06 for evidence persistence. Module 5 itself is administered through (a) the platform-administrator surface for the Tier 1 catalogue and (b) the tenant-administrator surface for Tier 2 profiles, assignments, delegations, and SoD configuration. --- ## 1. Module Purpose Module 5 establishes the authority-of-record substrate for Verixa. It owns the Authority Profile catalogue (Tier 1 global, Tier 2 tenant-defined), the user-to-Authority assignment register with scope binding and effective dates, the Approval Delegation overlay, the Segregation-of-Duties rule registry and exception register, and the four resolver functions that gate every regulated decision in the platform. Module 5 produces the inspection-ready evidence — the hash-chained per-decision authority snapshot — that demonstrates to regulators that the user who signed a regulated decision held the authority of record at the moment they signed. The module is consumed by Module 4 (workflow, HITL, electronic signature) for every regulated decision, by Module 3 (context, approval scope) for scope intersection computation, by Module 6 (audit substrate) for evidence persistence, and indirectly by every regulated module URS-12 through URS-34 through Module 4's adapter contract. Module 5 is the brain that Module 4 asks for permission. If Module 5 denies, the regulated decision does not commit. --- ## 2. Scope ### 2.1 In scope - The Authority Profile catalogue: Tier 1 globally defined profiles (e.g., `final_quality_approver`, `qp_eu`, `ap_india`, `qa_release_us`, `qa_release_uk`, `qa_release_ca`, `qp_release_authority`, `tenant_admin_authority`, `complaint_closure_approver`, `deviation_closure_approver`, `capa_closure_approver`, `oos_disposition_approver`, `class1_change_approver`, `recall_decision_authority`, `validation_approver`, `risk_assessment_approver`, `document_approver`, `training_approver`, `supplier_qualification_approver`, `inspection_finding_approver`, `quality_oversight_admin`, `regulatory_oversight_admin`, `global_quality_oversight`); Tier 2 tenant-defined profiles created through the tenant-administrator surface. - The Authority Profile schema: immutable per-version field set including `key`, `tier`, `name`, `description`, `scope_dimensions`, `required_base_roles`, `required_permissions`, `qualification_requirements_jsonb`, `delegation_eligible`, `override_eligible`, `published_at`, `published_by`, `e_sig_id`. - Scope dimensions launch set (canonical authority scope dimension registry, shared with URS-03 §6.4.1): `site`, `product`, `product_family`, `study`, `supplier`, `jurisdiction`, `business_unit`, `module`, `entity_type`, `workflow_type`. `tenant_wide` and `global_super_authority` are flags, not dimensions. Adding a dimension or flag is a Class 1 change. Module 5 is the canonical owner of this registry; URS-03's Record Scope Resolver consumes it. - The user-to-Authority assignment register: per-tenant record of which user holds which Authority Profile within which scope, with effective-from / effective-to dates, electronic signature, qualification-evidence linkage, and revocation lifecycle. - The Approval Delegation overlay: time-bound, scope-bound, acknowledged transfer of the right to act on behalf of a delegator, with a maximum duration of 30 calendar days (tenant-configurable within validated bounds), explicit acknowledgement by the delegate, no re-delegation (chain depth = 1), revocation lifecycle, and audit. - The Segregation-of-Duties rule registry: Tier 1 fixed launch set (author ≠ approver, reviewer ≠ final approver, delegator ≠ delegate, creator ≠ effectiveness verifier) plus Tier 2 tenant-defined SoD rules. - The SoD exception register: dual-signed, time-bound, scope-bound exceptions to SoD rules with extended meaning text, executive authority oversight signal, and audit. - The four resolver functions: `resolveApprovalCandidates(decisionContext)`, `validateApprovalAction(actorUserId, decisionContext)`, `evaluateSoD(actorUserId, recordId, ruleSet)`, `snapshotApprovalAuthority(actorUserId, eSigId, decisionContext)`. - Hash-chained `approval_authority_snapshots` (the chain itself is owned by Module 4's `electronic_signatures`-paired write; Module 5 produces the snapshot content and is the source of truth for the resolver verdict captured in each row). - Periodic access review: annual review (tenant-configurable within validated bounds; minimum every twelve months) of every active assignment with attested electronic signature; inactive-holder auto-flag (no signing use within six months) for revocation review. - Qualification-evidence linkage: every Authority Profile assignment MAY require linked training records, certifications, or professional licences (e.g., a `qp_eu` assignment requires linked QP licence number and EU member-state registration); the qualification register itself is owned by URS-28 (Training Management & Qualification); Module 5 stores the linkage and refuses an assignment whose linked qualification is missing or expired. - Authority Profile version history: every catalogue change (Tier 1 platform-side, Tier 2 tenant-side) creates an immutable version row with hash; assignments are pinned to the catalogue version at assignment time. - Front-end: Authority Profile catalogue browser (read-only for tenants; managed for platform), assignment management surface, delegation request / acknowledge / revoke surface, SoD configuration surface, SoD exception request / approve surface, periodic-access-review reviewer surface, the actor's "My authority" self-view. - Back-end: catalogue service, assignment service, delegation service, SoD service, exception service, resolver service. - Reports: Authority Profile inventory, assignment register, delegation register (active and historical), SoD exception register, periodic-access-review attestation register, inactive-holder report, snapshot integrity report. - Cross-module wiring: Module 4 consumes the resolver for every regulated decision; URS-06 ingests audit and snapshot rows; URS-28 owns the qualification register (training records, certifications, professional licences); URS-30 delivers notifications; URS-35 preserves the chain across restore. ### 2.2 Out of scope - Authentication, multi-factor authentication, password policy, session lifecycle (URS-01). - Permission matrix and base role catalogue (URS-02). - Active context and approval-scope check (URS-03). - Workflow templates, the workflow runtime, the Controlled Approval Modal, the e-signature ceremony, the slot-to-signature linkage (URS-04). - The audit-substrate hash-chain implementation (URS-06 owns the substrate; Module 5 owns the resolver verdict captured per row). - Master data CRUD for tenants, sites, products, studies, suppliers (URS-07/08/09/10/11). - The qualification register itself (URS-28 owns training records, certifications, professional licences; Module 5 stores the linkage). - Domain-specific decision semantics for any regulated entity (every domain module owns its own state model and content rules; Module 5 owns the authority-of-record substrate, 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-05-01 | Authority Profile architecture is two-tier: Tier 1 globally defined by Verixa (managed only by platform-administrator with electronic signature plus multi-factor step-up) and Tier 2 tenant-defined (managed by tenant-administrator holding `tenant_admin_authority` with electronic signature). Adding a tier is a Class 1 change. | | DEC-05-02 | The Authority Profile schema fields are exactly: `key` (immutable), `tier`, `name`, `description`, `scope_dimensions`, `required_base_roles`, `required_permissions`, `qualification_requirements_jsonb`, `delegation_eligible`, `override_eligible`, `effective_from`, `effective_to`, `published_at`, `published_by`, `e_sig_id`, `version`, `record_hash`, `previous_hash`. Adding a field is a Class 1 change. | | DEC-05-03 | Module 5 owns the canonical **authority scope dimension registry** that is consumed by URS-03 (active scope), URS-04 (workflow templates), and every regulated module URS-12..34. Launch dimensions are exactly: `site`, `product`, `product_family`, `study`, `supplier`, `jurisdiction`, `business_unit`, `module`, `entity_type`, `workflow_type`. The registry is reconciled with URS-03 §6.4.1 Record Scope Resolver — both modules use the same canonical set. `tenant_wide` and `global_super_authority` are **flags**, not normal scope dimensions: `tenant_wide` denotes that the assignment / profile is unrestricted across the listed dimensions for the tenant; `global_super_authority` denotes a platform-wide break-glass posture that bypasses the dimension-by-dimension intersection (subject to audit, SOC alert, and Founder oversight per URS-03). Adding a dimension or flag is a Class 1 change. | | DEC-05-04 | Every Authority Profile assignment MUST be created through the Controlled Approval Modal (URS-04 contract) with electronic signature, MUST bind a scope (one or more scope-dimension values per the profile's `scope_dimensions`), MUST have explicit `effective_from`, MAY have `effective_to` (null = indefinite, capped by periodic access review), and MUST link any required qualification evidence per the profile's `qualification_requirements_jsonb`. | | DEC-05-05 | Authority Profile assignment revocation MUST be (a) explicit (not implicit by deactivation of the user's account; account deactivation triggers automatic revocation of all assignments per URS-01 §6.7), (b) electronically signed, (c) audited, and (d) cascading — all active delegations rooted in the revoked assignment are immediately revoked. Already-signed approvals remain valid; only future approvals are blocked. | | DEC-05-06 | Approval Delegation maximum duration is 30 calendar days at launch (tenants may configure shorter intervals; tenants may not extend beyond the default without controlled regulatory justification and approved change control within validated bounds; not configurable upward). The delegate MUST explicitly acknowledge the delegation through the Controlled Approval Modal before the delegation becomes effective. Delegation chain depth is 1 — a delegate MAY NOT re-delegate. | | DEC-05-07 | Tier 1 profiles MUST individually flag `delegation_eligible` (boolean). Profiles flagged `delegation_eligible = false` at launch include: `global_quality_oversight`, `platform_super_authority`. All other Tier 1 profiles default to `delegation_eligible = true` unless explicitly marked otherwise in §3.3.2. Tier 2 profiles default to `delegation_eligible = true` and MAY be marked `delegation_eligible = false` by the tenant administrator. | | DEC-05-08 | The Tier 1 Segregation-of-Duties rule launch set is exactly: `AUTHOR_NEQ_APPROVER` (the user who created or last modified a record cannot approve it), `REVIEWER_NEQ_FINAL_APPROVER` (a prior-step reviewer cannot be the final approver of the same record), `DELEGATOR_NEQ_DELEGATE` (a delegator cannot approve through a delegation derived from their own authority on the same record), `CREATOR_NEQ_EFFECTIVENESS_VERIFIER` (the user who created a CAPA cannot also verify its effectiveness), `SAME_USER_TWO_PARALLEL_SLOTS_FORBIDDEN` (parallel-mode and dual-mode decisions cannot be satisfied by the same human across two slots — enforced at the URS-04 `hitl_decision_signatures` constraint and re-asserted by the resolver). Adding a Tier 1 rule is a Class 1 change. | | DEC-05-09 | SoD exceptions are dual-signed (the requesting administrator + an independent approver from a tenant-configured SoD-exception authority pool — typically a senior QA leader or the tenant's SoD-exception authority); meaning text MUST be ≥ 100 characters; effective-window MUST be ≤ 14 calendar days; Founder is notified for every exception within one business day; SOC alert is emitted; URS-06 audit captures full chain. | | DEC-05-10 | The resolver computes outputs in this strict order. **Delegation is an eligibility source, not a post-SoD overlay.** (1) Eligibility — enumerate users with active direct assignment whose profile.key is in `requiredAuthorityKeys`. (1b) Eligibility (via delegation) — enumerate users with an active acknowledged delegation referencing `requiredAuthorityKeys`. The union of (1) and (1b) is the eligibility candidate pool, with each candidate carrying the path tag (`direct` or `via_delegation`). (2) Scope match — for each candidate, compute the intersection between the relevant assignment scope (direct assignment scope for direct candidates; delegated scope for delegation candidates) and the active scope from URS-03. (3) SoD evaluation — apply Tier 1 fixed launch set + active Tier 2 rules + active SoD exceptions for the tenant. (4) Qualification re-check — call URS-28 to re-verify each linked qualification evidence is in force. (5) Snapshot composition — if the winning path used delegation, the snapshot tags `via_delegation = true` and records the delegation row identifier; if SoD was excepted, the snapshot records the exception identifier. Override applicability is a Module 4 concern computed against the node's `override_authority_profile_id`; Module 5 only resolves whether the actor holds the override profile. | | DEC-05-11 | Authority Profile catalogue versions are immutable. Every change to a Tier 1 profile creates a new version row with a new `record_hash` and `previous_hash`; existing assignments remain pinned to the version they were assigned under (catalogue-version pinning). New assignments use the current effective version. Migration of existing assignments to a new version requires explicit re-assignment with electronic signature. | | DEC-05-12 | Periodic access review runs annually at minimum (tenants may configure shorter intervals (e.g., quarterly); tenants may not extend beyond the default without controlled regulatory justification and approved change control, not upward beyond 12 months). The review enumerates every active assignment, every active delegation, every active SoD exception. The reviewer is a designated independent attestor (typically QA leadership or Information Security leadership; NEVER the assignment / delegation / exception holder themselves; reviewer cannot be the requester or approver of the row under review). Reviewer signs an attestation through the Controlled Approval Modal. **At the review-window boundary, every unreviewed row auto-expires** with the appropriate audit event: unreviewed assignments emit `ASSIGNMENT_AUTO_EXPIRED_NO_REVIEW`; unreviewed delegations emit `DELEGATION_AUTO_EXPIRED_NO_REVIEW`; unreviewed SoD exceptions emit `SOD_EXCEPTION_AUTO_EXPIRED_NO_REVIEW`. No active delegation or SoD exception is permitted to remain active past the review-window close without an explicit attestation; the auto-expiry is a fail-safe control to prevent unattested authority continuing across review periods. | | DEC-05-13 | An assignment whose holder has not used it (no signing event, no resolver `via=direct` candidate selection in the past six months) is flagged in the inactive-holder report. The flag is informational and does NOT auto-revoke; revocation requires explicit administrator action. Flag thresholds are tenants may configure shorter intervals; tenants may not extend beyond the default without controlled regulatory justification and approved change control (e.g., to 90 days for high-risk profiles). | | DEC-05-14 | Delegation revocation does NOT invalidate already-signed approvals signed under the delegation. Already-committed regulated decisions remain valid evidence. Revocation only blocks future approvals. The same rule applies to assignment revocation, profile retirement, and SoD-exception revocation. | | DEC-05-15 | Catalogue-version pinning: every Authority Profile assignment row stores `catalogue_version_id` referencing the catalogue version that was effective at assignment time. Resolver evaluation uses the pinned version for that assignment unless the assignment is explicitly migrated to a new version. This guarantees that a Tier 1 catalogue change does not retroactively alter the authority of already-signed decisions. | | DEC-05-16 | Qualification-evidence linkage: profiles whose `qualification_requirements_jsonb` is non-empty (e.g., `qp_eu`, `ap_india`, `qa_release_us`) MUST have linked qualification evidence (training record, certification, professional licence) at assignment time, sourced from URS-28 (Training Management & Qualification). Assignment is refused if linked evidence is missing, expired, or not yet in force. Resolver re-checks linked evidence at every `validateApprovalAction` call; expired evidence between assignment and decision time returns `QUALIFICATION_EVIDENCE_EXPIRED`. | | DEC-05-17 | The hash-chained snapshot row produced by `snapshotApprovalAuthority` is created atomic with the `electronic_signatures` row and the `approval_authority_snapshots` row write (one transaction; rollback on any failure) per URS-04 BR-04-04 and URS-04 BR-04-16. Module 5 owns the snapshot content; Module 4 + URS-06 own the chain integrity write path. | --- ## 3. User Roles and Permissions ### 3.1 Architecture Module 5 consumes Layer 1 (base role) and Layer 2 (permission matrix) from URS-02; consumes the active context from URS-03; and is consumed itself by URS-04 (workflow / signature ceremony) and URS-06 (audit substrate). Module 5 owns three administrative surfaces: (a) the platform-administrator surface for the Tier 1 catalogue, (b) the tenant-administrator surface for Tier 2 profiles, assignments, delegations, SoD configuration, and exception management, and (c) the periodic-access-review reviewer surface. Every authenticated user has a self-view at "My authority" showing their own active assignments, delegations granted to them or by them, and resolver self-test outputs. ### 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. External identities (URS-01 §3.2.3) MAY hold Authority Profiles only in viewer-equivalent capacities — i.e., they cannot hold any Authority Profile that names an `esignRequired` workflow node action. The resolver refuses to return external identities as candidates for any decision whose node requires electronic signature. ### 3.3 Authority Profile catalogue (Tier 1 launch set) #### 3.3.1 Core platform Authority Profiles | Authority Profile key | Description | Scope dimensions | Required base role | Delegation eligible | Override eligible | Qualification | |---|---|---|---|---|---|---| | `tenant_admin_authority` | Tenant-level administrative authority for Module 4 / Module 5 / Module 7 administrative actions. | none (tenant-wide) | `admin` | yes | no | none | | `platform_super_authority` | Platform-level super authority for cross-tenant support / break-glass. | global | platform identity | no | no | platform-admin onboarding | #### 3.3.2 Quality and operational Authority Profiles | Authority Profile key | Description | Scope dimensions | Required base role | Delegation eligible | Override eligible | Qualification | |---|---|---|---|---|---|---| | `final_quality_approver` | Final-step approval at quality gates (CAPA closure, deviation closure, complaint closure, OOS disposition). | site, product, product_family | `quality_lead` or higher | yes | yes | linked QA leadership credential (URS-28) | | `quality_lead_authority` | Non-final quality decisions (review, recommendation, intermediate gates). | site, product, product_family | `quality_lead` or higher | yes | no | none | | `quality_oversight_admin` | Quality break-glass override authority for `final_quality_approver` gates when primary approver unavailable. | tenant-wide or scoped | `admin` | no | yes | linked senior QA leadership credential | | `regulatory_oversight_admin` | Regulatory break-glass override authority for regulatory submission and recall decisions. | tenant-wide | `admin` | no | yes | linked RA leadership credential | | `global_quality_oversight` | Platform break-glass super-authority across all quality gates; auto-expiring; SOC alert; extended meaning. | global | `admin` | **no** | yes | linked Founder-level approval per URS-01 | | `complaint_closure_approver` | Complaint closure decision. | site, product | `quality_lead` or higher | yes | no | none | | `deviation_closure_approver` | Deviation closure decision. | site, product | `quality_lead` or higher | yes | no | none | | `capa_closure_approver` | CAPA closure decision. | site, product | `quality_lead` or higher | yes | no | none | | `capa_effectiveness_verifier` | CAPA effectiveness verification (subject to `CREATOR_NEQ_EFFECTIVENESS_VERIFIER` SoD). | site, product | `quality_lead` or higher | yes | no | none | | `oos_disposition_approver` | Out-of-Specification investigation disposition. | site, product | `quality_lead` or higher | yes | no | none | | `class1_change_approver` | Approval of URS-13 records. | site, product, product_family | `quality_lead` or higher | yes | no | none | | `recall_decision_authority` | Product recall decision (Class I / II / III). | jurisdiction, product | `admin` | no | yes | linked RA + QA leadership credential | | `validation_approver` | Validation pack approval (IQ / OQ / PQ / CSV). | site, product | `quality_lead` or higher | yes | no | linked validation-lead credential | | `risk_assessment_approver` | Quality risk-assessment approval. | site, product | `quality_lead` or higher | yes | no | none | | `document_approver` | Controlled-document approval (SOPs, work instructions, policies; URS-12). | site, business_unit | `quality_lead` or higher | yes | no | none | | `training_approver` | Training-record approval and competency confirmation. | site, business_unit | `quality_lead` or higher | yes | no | none | | `supplier_qualification_approver` | Supplier qualification and re-qualification. | supplier | `quality_lead` or higher | yes | no | none | | `inspection_finding_approver` | Inspection finding closure (regulatory inspection or audit). | site, jurisdiction | `quality_lead` or higher | yes | no | none | #### 3.3.3 Jurisdictional batch-release Authority Profiles | Authority Profile key | Description | Scope dimensions | Required base role | Delegation eligible | Override eligible | Qualification | |---|---|---|---|---|---|---| | `qp_eu` | EU Qualified Person (Directive 2001/83/EC Article 51). | site, product_family, jurisdiction (EU member state) | `quality_lead` or higher | yes (only to another `qp_eu` holder) | yes (within `qp_release_authority` family) | linked QP licence number + EU member-state registration; linked Annex 16 batch-certification training | | `ap_india` | India Authorised Person (Schedule M; Drugs and Cosmetics Act 1940; Schedule M revised 2023). | site, product, jurisdiction (India) | `quality_lead` or higher | yes (only to another `ap_india` holder) | yes (within `qp_release_authority` family) | linked CDSCO registration + Schedule M training | | `qa_release_us` | US QA release authority (21 CFR Part 211; ICH Q7 for API). | site, product | `quality_lead` or higher | yes | yes (within `qp_release_authority` family) | linked QA-leadership credential | | `qa_release_uk` | UK QA release authority (post-Brexit MHRA equivalence). | site, product, jurisdiction (UK) | `quality_lead` or higher | yes (only to another `qa_release_uk` holder) | yes | linked MHRA-recognised QP / QA credential | | `qa_release_ca` | Canada QA release authority (Health Canada DEL holder). | site, product, jurisdiction (CA) | `quality_lead` or higher | yes (only to another `qa_release_ca` holder) | yes | linked Health Canada DEL holder credential | | `qp_release_authority` | Generic batch-release authority (resolver-equivalent family that includes the jurisdictional variants above). | site, product, jurisdiction | `quality_lead` or higher | yes (only within the same jurisdictional variant) | yes | per jurisdictional variant | Tenants operating across jurisdictions (e.g., a multi-national contract manufacturer) MUST hold the appropriate jurisdictional variant per market. Cross-jurisdictional delegation is forbidden — a `qp_eu` holder cannot delegate to an `ap_india` holder, even at the same tenant. Delegation is constrained to "same key only" except where Tier 1 §3.3 explicitly permits family delegation. ### 3.4 Tier 2 (tenant-defined) Authority Profiles Tenant administrators holding `tenant_admin_authority` MAY create Tier 2 Authority Profiles for tenant-specific business processes that do not map to the Tier 1 catalogue. Tier 2 profiles MUST NOT use any reserved Tier 1 key (uniqueness enforced at catalogue level). Tier 2 profiles MUST specify the same field set as Tier 1 (DEC-05-02). Tier 2 profile creation is electronically signed and audited. Tier 2 profiles MAY be referenced in tenant-defined workflow templates (URS-04). Tier 2 profiles MAY NOT be delegated cross-tenant. Tier 2 profile retirement is electronically signed; pinned assignments referencing the retired version remain valid until explicitly revoked or migrated. ### 3.5 Worked examples #### Worked example A — Assigning `final_quality_approver` to a quality lead Sarah is the QA Lead for Site A and Product Family Alpha at TenantCo. The tenant administrator opens the assignment surface, selects Sarah, picks `final_quality_approver`, binds the scope `{site: A, product_family: Alpha}`, sets `effective_from = today`, leaves `effective_to = null` (indefinite, capped by annual review), confirms her linked QA leadership credential is in force, and submits through the Controlled Approval Modal. Sarah is now eligible to sign final-step quality gates for any record whose active scope intersects `{site: A, product_family: Alpha}`. The catalogue-version pin records the current Tier 1 catalogue version. URS-06 captures `AUTHORITY_PROFILE_ASSIGNED`. #### Worked example B — Authority Profile catalogue does not retroactively change history A Tier 1 change is published: `final_quality_approver` now requires linked qualification of "QA leadership credential plus Annex 16 awareness training." Sarah's existing assignment is pinned to the prior catalogue version, so it remains valid for already-issued decisions. For new decisions, Module 5 evaluates her assignment against the pinned version unless the tenant explicitly migrates her to the new version. Migration requires re-assignment with electronic signature and re-confirmation of qualifications. #### Worked example C — Delegation for planned absence Sarah is on annual leave for two weeks. She delegates her `final_quality_approver` authority for Site A and Product Family Alpha to her peer QA Lead, Priya, for the duration of her leave. The delegation is created through the Controlled Approval Modal with effective dates within the 30-calendar-day cap, scope inherited from Sarah's assignment, and linked rationale ("planned annual leave 2026-05-15 to 2026-05-29"). Priya receives the notification and acknowledges the delegation through the Controlled Approval Modal. From the acknowledgement timestamp until the effective-to, Priya is returned by the resolver as a candidate for `final_quality_approver` decisions in Sarah's scope. Snapshots produced under Priya's signature tag `via_delegation = true` and record the delegation row identifier. Sarah's own assignment continues unchanged. After Priya's first signed decision, the workflow transitions and the audit trail captures `AUTHORITY_DELEGATED_USED`. #### Worked example D — Override use when primary unavailable and SoD blocks delegation A deviation reaches its closure node at 23:00 on a Friday. The primary requirement is `requiredAuthorityKeys = ['final_quality_approver']`. Sarah is the only `final_quality_approver` for Site A / Product Family Alpha, but Sarah is also the deviation's `last_modified_by` (she investigated it), so the SoD rule `AUTHOR_NEQ_APPROVER` excludes her. She has not delegated to anyone. The deviation has a 24-hour SLA and is approaching breach. The configured `override_authority_profile_id` for this node is `quality_oversight_admin`, with `override_dual_sign = true`. The QA Director (holds `quality_oversight_admin`) opens the override workflow per URS-04. The Controlled Approval Modal demands multi-factor step-up plus extended meaning ("Primary `final_quality_approver` Sarah Williams excluded by AUTHOR_NEQ_APPROVER; deviation DEV-2026-0145 approaches 24h SLA; override approved per URS-13 record CC-2026-0098 to prevent batch hold"; ≥ 80 characters). A second `quality_oversight_admin` co-signs. Module 5 returns the override candidates to Module 4; Module 4 inserts both signatures with snapshots tagged `override = true` and `original_primary_requirement_archived = ['final_quality_approver']`. The deviation closes. Module 5 does NOT bypass the original SoD — the override is the documented exception path, and the snapshot preserves the full audit chain for the inspector. #### Worked example E — Resolver outage failsafe Module 5's resolver depends on Module 3's active context resolver and on URS-28's qualification register. If URS-28 is unreachable at decision time (e.g., a transient outage), `validateApprovalAction` returns `QUALIFICATION_EVIDENCE_UNAVAILABLE` (HTTP 503) and the signature ceremony refuses to insert the signature row. The decision remains open; the user retries when the upstream is restored. The resolver fails secure — never proceeds with a stale or unverified qualification. #### Worked example F — Tier 2 tenant-defined profile A specialty pharmaceutical contract research organisation needs an Authority Profile for "Phase I clinical-trial protocol amendment approval" specific to their internal SOP that does not map to a Tier 1 profile. The tenant administrator creates Tier 2 profile `phase_one_protocol_amendment_approver` with scope dimensions `{study, jurisdiction}`, required base role `quality_lead`, delegation eligible, no override eligibility. The profile is published with electronic signature; the tenant's Phase I workflow template (URS-04) references the new profile in its node `requiredAuthorityKeys[]`. The profile is private to the tenant; it does not appear in any other tenant's catalogue and cannot be cross-delegated. #### Worked example G — Periodic access review The annual review window opens. The tenant administrator launches the review through the periodic-access-review surface. The system enumerates 47 active assignments, 3 active delegations, and 1 active SoD exception. The reviewer (an independent QA Director who does not hold any of the assignments under review) goes through each row and confirms or rejects continuation. Each confirmation is one electronic signature; rejections produce a revocation cascade. After 21 days, three assignments remain unreviewed; at the review-window boundary they auto-expire and emit `ASSIGNMENT_AUTO_EXPIRED_NO_REVIEW`. The attestation pack is exported as the inspection-ready evidence for the year. #### Worked example H — SoD exception for small tenant single-author scenario A small tenant has only one quality lead. The platform's `AUTHOR_NEQ_APPROVER` SoD rule blocks them from completing any deviation closure where they were also the investigator. The tenant administrator requests a SoD exception for `AUTHOR_NEQ_APPROVER` scoped to deviation closures, citing "single-quality-lead operational constraint pending hire of second QA lead Q3 2026"; ≥ 100 characters meaning. A second tenant administrator (independent SoD-exception authority) co-signs. Effective window: 14 calendar days. Executive authority receives a notification within one business day. SOC alert is emitted. URS-06 captures the full chain. After the exception expires, the rule re-applies and the tenant must use a different solution (delegation, override, or hire). Exceptions cannot be renewed back-to-back without a Founder-level review. ### 3.6 Role-permission matrix (Module 5 administrative surface only) | Action (within Module 5) | viewer | reviewer | quality_lead | auditor | admin | platform_admin | super_admin | Authority Profile | |---|:-:|:-:|:-:|:-:|:-:|:-:|:-:|---| | Read Authority Profile catalogue (own tenant) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | — | | Create Tier 1 catalogue version | — | — | — | — | — | ✓ + sign + MFA | ✓ + sign + MFA | platform-identity | | Retire Tier 1 catalogue version | — | — | — | — | — | ✓ + sign + MFA | ✓ + sign + MFA | platform-identity | | Create Tier 2 profile (own tenant) | — | — | — | — | ✓ + sign | ✓ + sign | ✓ + sign | `tenant_admin_authority` | | Retire Tier 2 profile | — | — | — | — | ✓ + sign | ✓ + sign | ✓ + sign | `tenant_admin_authority` | | Read assignment register (own tenant) | — | — | — | ✓ | ✓ | ✓ | ✓ | `tenant_admin_authority` / `auditor` | | Create assignment | — | — | — | — | ✓ + sign | ✓ + sign | ✓ + sign | `tenant_admin_authority` | | Revoke assignment | — | — | — | — | ✓ + sign | ✓ + sign | ✓ + sign | `tenant_admin_authority` | | Migrate assignment to new catalogue version | — | — | — | — | ✓ + sign | ✓ + sign | ✓ + sign | `tenant_admin_authority` | | Create delegation (delegating own authority) | per profile | per profile | per profile | — | per profile | — | — | the delegator's own Authority Profile | | Acknowledge delegation (as delegate) | per profile | per profile | per profile | — | per profile | — | — | recipient profile required | | Revoke own delegation | per profile | per profile | per profile | — | per profile | — | — | the delegator's own Authority Profile | | Force-revoke any delegation (admin) | — | — | — | — | ✓ + sign | ✓ + sign | ✓ + sign | `tenant_admin_authority` | | Read SoD rule registry | — | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | — | | Create / edit Tier 2 SoD rule | — | — | — | — | ✓ + sign | ✓ + sign | ✓ + sign | `tenant_admin_authority` | | Request SoD exception | — | — | ✓ + sign | — | ✓ + sign | ✓ + sign | ✓ + sign | originator's profile | | Approve SoD exception | — | — | — | — | ✓ + sign + MFA | ✓ + sign + MFA | ✓ + sign + MFA | independent SoD-exception authority | | Read snapshot integrity manifest | — | — | — | ✓ | ✓ | ✓ | ✓ | — | | Run periodic-access-review attestation | — | — | — | — | ✓ + sign | ✓ + sign | ✓ + sign | independent of held assignments | | View "My authority" self-view | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | self | | Resolve candidates (read API) | — | — | — | ✓ | ✓ | ✓ | ✓ | back-end consumed by URS-04 | | Validate approval action | — | — | — | — | back-end | back-end | back-end | back-end consumed by URS-04 | | Snapshot approval authority | — | — | — | — | back-end | back-end | back-end | back-end consumed by URS-04 | External identities (URS-01 §3.2.3) cannot reach Module 5's administrative surface; they participate only as scope-bound viewers and cannot hold any Authority Profile that gates an `esignRequired` decision. #### 3.6.1 Platform-identity tenant actions — controlled support / break-glass posture Per URS-02 §3.6.1 / URS-04 §3.6.1, platform identities (`platform_admin`, `super_admin`) MAY perform tenant-scoped Module 5 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 — Platform administrator publishes a new Tier 1 catalogue version - Trigger: A regulatory update introduces a new required qualification component for `qa_release_us`. - Steps: platform administrator opens the Tier 1 catalogue surface; drafts a new version with the updated `qualification_requirements_jsonb`; submits for review; second platform administrator approves through the Controlled Approval Modal with multi-factor step-up; the version is published and effective; a backward link to the previous version is recorded; existing assignments remain pinned to the prior version until tenants explicitly migrate. - Audit: `AUTHORITY_PROFILE_VERSION_DRAFTED`, `AUTHORITY_PROFILE_VERSION_APPROVED`, `AUTHORITY_PROFILE_VERSION_PUBLISHED`. ```mermaid sequenceDiagram autonumber participant PA1 as Platform Admin (drafter) participant PA2 as Platform Admin (approver) participant FE as Catalogue UI participant API as Catalogue API participant CAT as authority_profile_versions participant AUD as Audit Log PA1->>FE: open catalogue surface PA1->>API: POST /platform/authority-profiles draft API->>CAT: insert version row (status=draft) API->>AUD: AUTHORITY_PROFILE_VERSION_DRAFTED PA1->>API: POST /platform/authority-profiles/:key/submit-for-review PA2->>API: POST /platform/authority-profiles/:key/approve (e-sign + MFA) API->>CAT: status=approved + record_hash + previous_hash API->>AUD: AUTHORITY_PROFILE_VERSION_APPROVED PA2->>API: POST /platform/authority-profiles/:key/publish (e-sign + MFA) API->>CAT: status=effective API->>AUD: AUTHORITY_PROFILE_VERSION_PUBLISHED ``` ### J-02 — Tenant administrator creates a Tier 2 Authority Profile - Trigger: A tenant needs a profile for an internal-only review process. - Steps: tenant administrator opens the catalogue surface; creates a Tier 2 profile with name, description, scope dimensions, required base role, qualification requirements, delegation eligibility; submits through the Controlled Approval Modal with electronic signature; profile is effective immediately for the tenant. - Audit: `TIER_2_PROFILE_CREATED`. ### J-03 — Tenant administrator assigns an Authority Profile to a user - Trigger: A user is qualified and ready to take on a quality-gate authority. - Steps: administrator opens assignment surface; selects user; picks profile; binds scope; sets effective dates; system checks linked qualification evidence in URS-28; if missing or expired, refuses; on success, opens Controlled Approval Modal; administrator signs; assignment is created with catalogue-version pin; URS-30 notifies the user; audit emitted. - Audit: `AUTHORITY_PROFILE_ASSIGNED`. ### J-04 — User views their "My authority" self-view - Trigger: User wants to confirm what they may sign. - Steps: user opens self-view; system runs `resolveSelfAuthority`; lists active assignments with scope, effective dates, qualification evidence status; lists active delegations granted to or by this user; lists pending periodic-review attestations they owe. - Audit: read-only; `AUTHORITY_SELF_VIEW_OPENED` for forensics. ### J-05 — Delegation lifecycle (request → acknowledge → use → revoke) - Trigger: Delegator anticipates absence. - Steps: delegator opens delegation surface; picks profile and scope (must be subset of delegator's own); sets effective dates within 30-day cap; provides reason; signs through the Controlled Approval Modal; system creates delegation in `pending_acknowledgement` status; URS-30 notifies delegate; delegate opens acknowledgement surface; signs through the Controlled Approval Modal; delegation becomes `active`; resolver returns delegate as candidate from acknowledgement timestamp; on first use, snapshot tags `via_delegation = true`; delegator may revoke at any time; revocation cascades — delegate immediately stops being a candidate. - Audit: `DELEGATION_CREATED`, `DELEGATION_ACKNOWLEDGED`, `DELEGATION_ACTIVE`, `DELEGATION_USED`, `DELEGATION_REVOKED` or `DELEGATION_EXPIRED`. ```mermaid stateDiagram-v2 [*] --> pending_acknowledgement : delegator signs pending_acknowledgement --> active : delegate acknowledges within window pending_acknowledgement --> expired_unacknowledged : window passes without acknowledgement active --> revoked : delegator or admin revokes active --> expired : effective_to passes active --> used : first decision signed under delegation (annotation, not state) used --> revoked used --> expired revoked --> [*] expired --> [*] expired_unacknowledged --> [*] ``` ### J-06 — SoD rule applies and blocks an attempted approval - Trigger: Author attempts to approve their own deviation. - Steps: user opens HITL inbox; opens the decision; URS-04 invokes the resolver; `evaluateSoD` returns `denied` with rule `AUTHOR_NEQ_APPROVER`; URS-04 hides the decision from the user's HITL inbox in the first place; if the user reaches the decision through a deep link, the Controlled Approval Modal returns `403 APPROVAL_AUTHORITY_DENIED` with reason `SOD_RULE_VIOLATION`. - Audit: `APPROVAL_AUTHORITY_DENIED` with `sod_rule = AUTHOR_NEQ_APPROVER`. ### J-07 — SoD exception request, approval, use - Trigger: Single-author tenant cannot complete a decision without exception. - Steps: requesting administrator opens SoD-exception request surface; selects rule, scope (specific entity-type or specific record), effective window (≤ 14 days), provides ≥ 100-char meaning text; signs through the Controlled Approval Modal; URS-30 notifies the SoD-exception authority pool; an independent administrator opens the review surface; signs the approval through the Controlled Approval Modal with multi-factor step-up; SOC alert emitted; Founder notification queued; exception is effective; resolver re-evaluates in scope and treats the exception as the documented exception path; on use, snapshot tags `sod_exception_id`; on expiry, rule re-applies. - Audit: `SOD_EXCEPTION_REQUESTED`, `SOD_EXCEPTION_APPROVED`, `SOD_EXCEPTION_USED`, `SOD_EXCEPTION_EXPIRED`. ### J-08 — Periodic access review - Trigger: Annual review window opens (URS-30 schedules the window). - Steps: tenant administrator opens periodic-access-review surface; system enumerates active assignments, delegations, exceptions; reviewer (independent of holders) goes row by row, confirms or rejects continuation; each confirmation is one electronic signature through the Controlled Approval Modal; rejections cascade to revocation; at window close, unreviewed rows auto-expire; the attestation pack is electronically signed and exported as inspection-ready evidence. - Audit: `PERIODIC_REVIEW_OPENED`, `PERIODIC_REVIEW_ROW_CONFIRMED`, `PERIODIC_REVIEW_ROW_REJECTED`, `ASSIGNMENT_AUTO_EXPIRED_NO_REVIEW`, `PERIODIC_REVIEW_CLOSED`. ### J-09 — Inactive holder flag and review - Trigger: Holder has not used a profile assignment for six months. - Steps: scheduled job flags the assignment in the inactive-holder report; tenant administrator opens the report; reviews the case; either revokes (electronically signed) or annotates "active in upcoming production cycle"; flag clears after annotation or revocation. - Audit: `INACTIVE_HOLDER_FLAGGED`, `INACTIVE_HOLDER_ANNOTATED`, `ASSIGNMENT_REVOKED` if revoked. ### J-10 — Catalogue migration of an existing assignment - Trigger: Tier 1 catalogue published a new version with stricter qualification requirements; tenant decides to migrate Sarah's assignment. - Steps: administrator opens assignment surface; selects Sarah's pinned `final_quality_approver` assignment; selects "migrate to current version"; system checks linked qualification evidence against new requirements; if compliant, opens Controlled Approval Modal; administrator signs; new assignment row replaces the old (the old is closed with `effective_to = now` and reason `migrated`; a new row is opened pinned to the new catalogue version); audit captures the chain. - Audit: `ASSIGNMENT_MIGRATED`. ### J-11 — Override use through Module 4 (cross-module) - Trigger: Primary approver unavailable as in Worked Example D. - Steps: per URS-04 J-12 (override request and use); Module 5's resolver returns the override authority's candidates and snapshots the override use with `override = true` tag and `original_primary_requirement_archived` populated. - Audit: per URS-04 vocabulary plus Module 5's `OVERRIDE_AUTHORITY_RESOLVED`. ### J-12 — Resolver self-test - Trigger: User reports "I can't approve this decision." - Steps: user opens self-test from "My authority"; selects the decision; system runs `resolveApprovalCandidates` in dry-run mode; returns the four-step computation with intermediate verdicts (eligibility, scope match, SoD verdict, delegation overlay); user sees exactly which step failed and why; no signature, no commit. - Audit: `RESOLVER_SELF_TEST_RUN`. ### J-13 — Cross-tenant break-glass by platform identity - Trigger: Customer-support escalation requires platform-administrator action against a tenant assignment. - Steps: platform administrator opens the controlled-support surface; selects the target tenant; provides a business-justification reason and customer-reference identifier; signs through the Controlled Approval Modal; emits `PLATFORM_TENANT_ACCESS_USED`; SOC alert emitted; performs the assignment / revocation / migration action with electronic signature; the action carries the same audit chain as a tenant-administrator action plus the platform-access markers. - Audit: `PLATFORM_TENANT_ACCESS_USED`, plus the per-action audit codes. ### J-14 — Qualification evidence expires between assignment and decision - Trigger: Sarah's QA leadership credential expires; she attempts to sign a `final_quality_approver` decision. - Steps: at decision time, `validateApprovalAction` re-checks linked qualification evidence in URS-28; finds it expired; returns `QUALIFICATION_EVIDENCE_EXPIRED`; signature ceremony refuses; URS-30 notifies the assignment holder and the tenant administrator; the assignment remains in place until administrator action. - Audit: `APPROVAL_AUTHORITY_DENIED` with reason `QUALIFICATION_EVIDENCE_EXPIRED`. ### J-15 — Delegation chain depth violation - Trigger: A delegate attempts to re-delegate. - Steps: delegate opens delegation surface; system detects the user is currently a delegate of an active delegation for the requested profile; returns `DELEGATION_CHAIN_DEPTH_EXCEEDED`; UI explains delegation chain depth = 1 per DEC-05-06; no commit. - Audit: `DELEGATION_CHAIN_DEPTH_EXCEEDED` (forensic). ### J-16 — Cross-jurisdictional delegation forbidden - Trigger: A `qp_eu` holder attempts to delegate to an `ap_india` holder. - Steps: delegator opens delegation surface; system detects the proposed delegate does not hold a same-key Authority Profile (constraint per §3.3.3); returns `DELEGATION_KEY_MISMATCH`; UI explains the cross-jurisdictional constraint; no commit. - Audit: `DELEGATION_KEY_MISMATCH` (forensic). ### J-17 — Tier 1 retirement with active assignments still pinned - Trigger: Platform retires a deprecated Tier 1 profile. - Steps: platform administrator opens catalogue; selects profile; selects "retire"; signs with multi-factor step-up; the profile's status becomes `retired`; existing pinned assignments remain valid until their effective_to (or until the next periodic access review where the reviewer must explicitly migrate or revoke); new assignments to a retired profile are forbidden; tenants are notified; URS-30 alerts. - Audit: `AUTHORITY_PROFILE_RETIRED`. ### J-18 — Resolver outage - Trigger: URS-28 (qualification register) is unreachable. - Steps: at decision time, `validateApprovalAction` cannot verify linked qualification evidence; returns `QUALIFICATION_EVIDENCE_UNAVAILABLE` (HTTP 503); signature ceremony refuses; URS-04 surfaces the banner; the decision remains open; on retry after restoration, normal flow resumes. - Audit: `RESOLVER_DEPENDENCY_UNAVAILABLE` (forensic). ### J-19 — Same-user-two-slots block at runtime - Trigger: A user holding two relevant Authority Profiles attempts to sign two parallel slots in URS-04 dual-mode. - Steps: per URS-04 BR-04-07 / URS-05 DEC-05-08 SAME_USER_TWO_PARALLEL_SLOTS_FORBIDDEN; the resolver excludes the user from candidates for the second slot once the first slot is signed; if the user reaches the modal through a stale candidate list, `validateApprovalAction` re-checks at signature time and refuses with `HITL_SLOT_DUPLICATE_SIGNER` (URS-04 error code). - Audit: `APPROVAL_AUTHORITY_DENIED` with reason `SOD_SAME_USER_TWO_SLOTS`. ### J-20 — Founder-level decision routing through resolver - Trigger: A founder-level workflow node names `requiredAuthorityKeys = ['founder_level_authority']`. - Steps: resolver enumerates the (typically very small) set of candidates holding that profile; standard scope, SoD, delegation, qualification flow; multi-factor step-up required at signature time per URS-04 §6.7.1; snapshot tags `founder_level = true`. - Audit: standard authority chain. ### J-21 — Auditor read of snapshot integrity manifest - Trigger: Inspector requests proof of the authority chain for a specific regulated decision. - Steps: auditor opens the snapshot integrity surface; enters the regulated record identifier; system returns the full hash-chain from genesis to current for that entity, with each `e_sig_id`, the `actor_user_id`, the resolver verdict, the catalogue version pinned, the delegation overlay (if any), the SoD verdict, and the linked qualification evidence; auditor exports the manifest with electronic signature. - Audit: `SNAPSHOT_INTEGRITY_EXPORTED`. ### J-22 — Tier 2 SoD rule defined by tenant - Trigger: Tenant has an internal SOP that prohibits the supplier-qualification approver from also being the supplier-onboarding requester. - Steps: administrator opens SoD configuration; creates Tier 2 rule `SUPPLIER_REQUESTER_NEQ_QUALIFICATION_APPROVER` with rule definition; signs; rule is effective; resolver applies the rule across tenant-scope decisions in the supplier-qualification family. - Audit: `TIER_2_SOD_RULE_CREATED`. ### J-23 — Founder-level oversight for SoD exception cluster - Trigger: Three SoD exceptions in same week at the same tenant. - Steps: monitoring detects the cluster; URS-30 escalates to Founder; Executive authority reviews the cases and the underlying single-author / capacity issue; Founder decides to require the tenant to engage a contracted second QA reviewer or to move to a controlled-stop posture; decisions are recorded against the tenant onboarding file (URS-08). - Audit: `SOD_EXCEPTION_CLUSTER_DETECTED`, `FOUNDER_REVIEW_LOGGED` (Module 8 forensic). ### J-24 — Resolver dry-run for workflow-template authoring - Trigger: Workflow template author wants to verify their `requiredAuthorityKeys[]` configuration is sensible. - Steps: author opens template editor (URS-04); for each regulated node, requests "preview candidates" (resolver dry-run with sample record context); resolver returns the candidate count and a high-level verdict (e.g., "12 candidates eligible at Site A; 3 excluded by SoD; 1 active delegation overlay"); author iterates the configuration; no signature, no commit. - Audit: `RESOLVER_PREVIEW_RUN`. ### J-25 — Controlled support: platform administrator force-revokes a delegation - Trigger: Customer-support ticket reports an unrecognised delegation creating an audit risk. - Steps: platform administrator under controlled-support posture opens delegation register for the target tenant; verifies the case; force-revokes the delegation with electronic signature plus business-justification reason plus customer-reference identifier; emits `PLATFORM_TENANT_ACCESS_USED` plus `DELEGATION_FORCE_REVOKED`; SOC alert emitted; tenant administrator notified. - Audit: `PLATFORM_TENANT_ACCESS_USED`, `DELEGATION_FORCE_REVOKED`. ### J-26 — Periodic-review reviewer cannot review their own assignments - Trigger: A QA Director attempts to attest their own assignment during periodic review. - Steps: review surface refuses the row with `REVIEWER_CANNOT_REVIEW_OWN_ASSIGNMENT`; the reviewer sees the explicit message; the row is rerouted to a different attestor in the SoD-exception authority pool; on close, the attestation pack records the rerouting. - Audit: `PERIODIC_REVIEW_ROW_REROUTED`. ### J-27 — Profile retirement cascades to delegation - Trigger: A Tier 1 profile is retired; an active delegation references it. - Steps: retirement workflow detects active delegations; warns the platform administrator with the count and tenant breakdown; on confirm, all active delegations referencing the profile are revoked with reason `profile_retired`; URS-30 notifies the delegators and delegates; affected open decisions are flagged; tenant administrator decides per case. - Audit: `AUTHORITY_PROFILE_RETIRED`, multiple `DELEGATION_REVOKED` with reason `profile_retired`. ### J-28 — User account deactivation cascades to assignments and delegations - Trigger: A user account is deactivated by URS-01. - Steps: URS-01 emits `USER_ACCOUNT_DEACTIVATED`; Module 5 listens; revokes all active assignments with reason `account_deactivated`; revokes all active delegations the user is delegator of with reason `delegator_deactivated`; revokes all active delegations the user is delegate of with reason `delegate_deactivated`; URS-30 notifies tenant administrators; pending HITL decisions assigned to the user are reassigned per URS-04 escalation rules. - Audit: cascade `ASSIGNMENT_REVOKED` and `DELEGATION_REVOKED` with appropriate reasons. --- ## 5. Front-End Expected State ### 5.1 Routes (registered in the application router) | Route | Surface | Role / Authority gate | Notes | |---|---|---|---| | `/admin/authority/catalogue` | Authority Profile catalogue browser (read-only for tenant administrators) | `tenant_admin_authority` (read) | tenants see Tier 1 + their own Tier 2 | | `/admin/authority/catalogue/tier2` | Tier 2 management surface (own tenant) | `tenant_admin_authority` (write) | create / edit / retire Tier 2 | | `/admin/authority/assignments` | Assignment register and management | `tenant_admin_authority` | list / create / revoke / migrate | | `/admin/authority/assignments/:userId` | Per-user assignment detail | `tenant_admin_authority` | drill-down | | `/admin/authority/delegations` | Delegation register | `tenant_admin_authority` | list active and historical | | `/authority/delegations/new` | Delegate own authority (any holder of a delegation-eligible profile) | per profile | self-service | | `/authority/delegations/inbox` | Delegations awaiting acknowledgement (delegate side) | recipient | acknowledge or decline | | `/admin/authority/sod` | SoD rule registry (Tier 1 read; Tier 2 manage) | `tenant_admin_authority` | list / create Tier 2 | | `/admin/authority/sod/exceptions` | SoD exception register and management | `tenant_admin_authority` | request / approve / list | | `/admin/authority/periodic-review` | Periodic-access-review reviewer surface | `tenant_admin_authority` (independent of held assignments) | annual attestation | | `/authority/me` | "My authority" self-view | self | self-service; resolver dry-run; delegation status | | `/admin/authority/integrity` | Snapshot integrity manifest viewer | `tenant_admin_authority` / `auditor` | hash-chain verification | | `/platform/authority/catalogue` | Platform-only Tier 1 catalogue management | platform identity | draft / approve / publish / retire | ### 5.2 Component requirements - **Authority Profile catalogue browser** — table with filter chips (tier, status, scope dimension); each profile row shows key, name, description, scope dimensions, required base role, qualification requirements summary, delegation eligibility, override eligibility, current effective version, count of active tenant assignments. Click-through opens version history with hash-chain visualisation. - **Tier 2 management surface** — form-driven create / edit; field validation per DEC-05-02; conflict-check with Tier 1 keys; submission opens the Controlled Approval Modal contract per URS-04 DEC-04-04. - **Assignment register and management** — paginated table with filters (user, profile, scope, status); create flow is a stepper: user selection → profile selection → scope binding (the surface enumerates scope dimensions per the profile and pulls eligible scope values from URS-08/09/10/11) → effective dates → qualification-evidence verification (URS-28 inline check) → review → Controlled Approval Modal. - **Delegation creation surface** — only delegation-eligible profiles appear; scope picker is constrained to be a subset of the delegator's own scope; effective-to capped at 30 days from effective-from (or tenant-configured-lower); reason field required ≥ 40 chars; submission opens the Controlled Approval Modal. - **Delegation acknowledgement inbox** — list of pending delegations to the user; acknowledge or decline action; Controlled Approval Modal on acknowledge. - **SoD configuration** — Tier 1 rules read-only; Tier 2 rules editable with rule-builder UI (rule type, scope binding, effective dates). - **SoD exception management** — request flow demands ≥ 100-char meaning, effective window ≤ 14 days, scope; approval flow requires independent administrator with multi-factor step-up; clear visual distinction of pending / active / expired exceptions with a "live exposure" indicator. - **Periodic-access-review reviewer surface** — wizard-like row-by-row attestation; each row: profile + assignment scope + holder + qualification status + last-used timestamp + reviewer decision (continue / revoke / migrate); progress indicator; final review-attestation export. - **"My authority" self-view** — sections: assignments, delegations to me, delegations by me, qualifications, periodic-review actions owed, resolver self-test; clear "what I can sign right now" summary. - **Snapshot integrity manifest viewer** — input: regulated record identifier; output: hash-chain table with verification badges (green / red); export with electronic signature. - **Resolver self-test** — inline tool inside "My authority" and inside template editor preview; dry-run computes four-step verdict and explains failures plainly. ### 5.3 Accessibility and internationalisation - WCAG 2.1 Level AA across every Module 5 surface. - Authority Profile names and descriptions translated; keys remain canonical English (immutable identifiers). - Date / time displayed in user time zone; stored UTC; ISO 8601. --- ## 6. Back-End Expected State ### 6.1 Domain entities - `authority_profile_catalogue` — registry of profile keys (Tier 1 + Tier 2). - `authority_profile_versions` — immutable per-version row; pinned by assignments. - `authority_profile_assignments` — user-to-profile binding within scope and effective-date window. - `authority_profile_delegations` — time-bound, scope-bound, acknowledged transfer. - `sod_rules` — Tier 1 + Tier 2 SoD rule registry. - `sod_rule_versions` — immutable per-version row. - `sod_exceptions` — dual-signed time-bound exceptions to SoD rules. - `qualification_evidence_links` — pointer rows linking assignments to qualification evidence in URS-28. - `periodic_access_reviews` — per-window review header. - `periodic_access_review_rows` — per-attestation row. - `inactive_holder_flags` — informational flags from the scheduled job. - `resolver_audit_log` — high-volume forensic log of `resolveApprovalCandidates` and `validateApprovalAction` calls (PII-stripped; consumed by URS-06 audit substrate as a forensic feed). ### 6.1.1 Diagram 6.1-A — Module 5 entity-relationship overview ```mermaid erDiagram AUTHORITY_PROFILE_CATALOGUE ||--o{ AUTHORITY_PROFILE_VERSIONS : has AUTHORITY_PROFILE_VERSIONS ||--o{ AUTHORITY_PROFILE_ASSIGNMENTS : pinned_to AUTHORITY_PROFILE_ASSIGNMENTS ||--o{ AUTHORITY_PROFILE_DELEGATIONS : may_be_delegated AUTHORITY_PROFILE_ASSIGNMENTS ||--o{ QUALIFICATION_EVIDENCE_LINKS : requires SOD_RULES ||--o{ SOD_RULE_VERSIONS : has SOD_RULE_VERSIONS ||--o{ SOD_EXCEPTIONS : excepted_by PERIODIC_ACCESS_REVIEWS ||--o{ PERIODIC_ACCESS_REVIEW_ROWS : contains AUTHORITY_PROFILE_ASSIGNMENTS ||--o{ PERIODIC_ACCESS_REVIEW_ROWS : reviewed_in AUTHORITY_PROFILE_ASSIGNMENTS ||--o{ INACTIVE_HOLDER_FLAGS : may_be_flagged_in AUTHORITY_PROFILE_ASSIGNMENTS ||--o{ APPROVAL_AUTHORITY_SNAPSHOTS : referenced_by AUTHORITY_PROFILE_DELEGATIONS ||--o{ APPROVAL_AUTHORITY_SNAPSHOTS : referenced_by_when_used SOD_EXCEPTIONS ||--o{ APPROVAL_AUTHORITY_SNAPSHOTS : referenced_by_when_used ``` The `APPROVAL_AUTHORITY_SNAPSHOTS` table is owned by URS-04 / URS-06 (write path); Module 5 contributes the snapshot content (assignments, delegations, scope match, SoD verdict, qualification evidence linkage) through the `snapshotApprovalAuthority` resolver function. ### 6.1.2 Diagram 6.1-B — Resolver pipeline with intermediate verdicts ```mermaid flowchart TD IN[decisionContext: tenantId, recordId, entityType, requiredAuthorityKeys, fromState, toState, workflowFamily] --> P0[Module 3 active scope resolved] P0 --> P1[Step 1 eligibility direct: enumerate users with active direct assignment whose profile.key in requiredAuthorityKeys] P0 --> P1B[Step 1b eligibility via delegation: enumerate users with active acknowledged delegation referencing requiredAuthorityKeys] P1 --> P_UNION[Union eligibility candidate pool with path tag direct or via_delegation] P1B --> P_UNION P_UNION --> P2[Step 2 scope match: relevant scope = direct assignment scope or delegated scope; intersect with activeScope] P2 --> P3[Step 3 segregation of duties: apply Tier 1 + Tier 2 SoD rules] P3 --> P3B{SoD exception covers the case?} P3B -- yes --> P4 P3B -- no, all rules pass --> P4 P3B -- no, rule blocks --> X1[Excluded with reason] P4[Step 4 qualification: re-check linked qualification evidence URS-28 for the holder of record actor or delegate] --> P4B{Evidence in force?} P4B -- no --> X2[Excluded with reason QUALIFICATION_EVIDENCE_EXPIRED] P4B -- yes --> P5[Step 5 snapshot composition: tag via_delegation if path was delegation; tag sod_exception_id if SoD was excepted; tag override if URS-04 override path] P5 --> OUT[Candidate list with verdict trail] ``` ### 6.1.3 Diagram 6.1-C — Snapshot composition produced by `snapshotApprovalAuthority` ```mermaid flowchart LR S[snapshotApprovalAuthority decisionContext, actor, eSigId] --> A[actor.assignments_jsonb] S --> D[delegation_overlay_jsonb if used] S --> SC[scope_match_jsonb intersection from URS-03] S --> SD[sod_verdict passed/excepted/overridden] S --> Q[qualification_evidence_jsonb at decision time] S --> CV[catalogue_version_pinned] S --> CL[claims_version_at_approval] S --> RH[record_hash + previous_hash] S --> OV[override flags if URS-04 override path used] A --> R[Snapshot row composed] D --> R SC --> R SD --> R Q --> R CV --> R CL --> R RH --> R OV --> R R --> URS04[Written atomically with electronic_signatures via URS-04 BR-04-04] ``` ### 6.2 Data model requirements | Entity | Purpose | Key fields | Required | Unique | Tenant isolation | Versioning | Retention | Soft-delete | Audit | E-sig link | |---|---|---|---|---|---|---|---|---|---|---| | `authority_profile_catalogue` | Logical key registry | `id`, `key`, `tier` (1 or 2), `tenant_id` (NULL for Tier 1), `status` (`active` / `retired`), `created_by`, `created_at` | all | partial unique: `unique(key) WHERE tenant_id IS NULL` (Tier 1 keys are globally unique); `unique(tenant_id, key) WHERE tenant_id IS NOT NULL` (Tier 2 keys are unique per tenant; the same Tier 2 key MAY be used by different tenants). Tier 2 creation MUST also refuse any key that exists as an active Tier 1 key (`KEY_CONFLICT_TIER_1` per BR-05-21) — enforced via CHECK / trigger because the partial indexes alone do not block this. | RLS on `tenant_id` (NULL allowed for Tier 1) | none | retain | yes (retire path) | yes | yes | | `authority_profile_versions` | Per-version snapshot. Immutable from `effective` lifecycle state onward; rows in earlier states (`draft`, `under_review`) are mutable until submitted / approved. | `id`, `catalogue_id`, `version` (integer; monotonic), `lifecycle_state` (enum: `draft` / `under_review` / `approved` / `effective` / `retired`), `name`, `description`, `scope_dimensions` (jsonb), `required_base_roles` (jsonb), `required_permissions` (jsonb), `qualification_requirements_jsonb`, `delegation_eligible`, `override_eligible`, `effective_from` (set on `effective` transition), `effective_to` (nullable), `submitted_for_review_at` (nullable), `submitted_by` (nullable), `submitted_e_sig_id` (nullable), `approved_at` (nullable), `approved_by` (nullable), `approved_e_sig_id` (nullable), `published_at` (nullable until `effective`), `published_by` (nullable until `effective`), `published_e_sig_id` (nullable until `effective`), `retired_at` (nullable), `retired_by` (nullable), `retired_e_sig_id` (nullable), `previous_hash` (nullable for genesis), `record_hash` (computed and locked on `approved` transition) | required per-state: id, catalogue_id, version, lifecycle_state always; submitted_* required from `under_review`; approved_* required from `approved`; published_* required from `effective`; retired_* required from `retired` | unique(`catalogue_id`, `version`); unique(`record_hash`) where `record_hash IS NOT NULL` | RLS via catalogue | versioned | retain | not applicable | yes | yes (per stage) | | `authority_profile_assignments` | User-to-profile binding | `id`, `tenant_id`, `user_id`, `catalogue_id`, `catalogue_version_id` (pinned), `scope_jsonb`, `effective_from`, `effective_to` (nullable), `assigned_by`, `assigned_at`, `assigned_e_sig_id`, `revoked_at` (nullable), `revoked_by` (nullable), `revocation_reason`, `revocation_e_sig_id` (nullable), `migrated_to_assignment_id` (nullable; for catalogue migration linkage) | core required | unique active (`tenant_id`, `user_id`, `catalogue_id`, `scope_hash`) | RLS on `tenant_id` | none | seven years post-revocation | yes (revoke path) | yes | yes | | `authority_profile_delegations` | Time-bound delegation | `id`, `tenant_id`, `delegator_user_id`, `delegate_user_id`, `delegator_assignment_id` (FK), `catalogue_id`, `scope_jsonb` (subset of delegator's scope), `effective_from`, `effective_to` (mandatory; ≤ 30 days from effective_from at launch), `reason`, `status` (`pending_acknowledgement` / `active` / `revoked` / `expired` / `expired_unacknowledged`), `delegated_at`, `delegated_e_sig_id`, `acknowledged_at` (nullable), `acknowledged_e_sig_id` (nullable), `revoked_at` (nullable), `revoked_by` (nullable), `revocation_reason`, `revocation_e_sig_id` (nullable) | core required | unique active(`tenant_id`, `delegate_user_id`, `catalogue_id`, `scope_hash`) | RLS on `tenant_id` | none | seven years post-expiry | not applicable | yes | yes | | `sod_rules` | Logical SoD rule registry | `id`, `tenant_id` (NULL for Tier 1), `rule_key`, `tier` (1 or 2), `status` (`active` / `retired`), `created_by`, `created_at` | all | partial unique: `unique(rule_key) WHERE tenant_id IS NULL` (Tier 1 rule keys are globally unique); `unique(tenant_id, rule_key) WHERE tenant_id IS NOT NULL` (Tier 2 rule keys are unique per tenant). Tier 2 creation MUST also refuse any rule_key that exists as an active Tier 1 rule_key — enforced via CHECK / trigger. | RLS on `tenant_id` (NULL for Tier 1) | none | retain | yes | yes | yes | | `sod_rule_versions` | Immutable per-version | `id`, `sod_rule_id`, `version`, `description`, `rule_definition_jsonb`, `effective_from`, `effective_to` (nullable), `published_at`, `published_by`, `e_sig_id`, `previous_hash`, `record_hash` | all required | unique(`sod_rule_id`, `version`); unique(`record_hash`) | RLS via rule | versioned | retain | not applicable | yes | yes | | `sod_exceptions` | Dual-signed exception (state machine: `pending` → `active` → `revoked`/`expired`/`auto_expired_no_review`) | `id`, `tenant_id`, `sod_rule_id`, `scope_jsonb`, `effective_from`, `effective_to` (mandatory; ≤ 14 days), `meaning_text` (≥ 100 chars), `requesting_user_id`, `requested_e_sig_id`, `requested_at`, `approving_user_id` (nullable until `active`), `approving_e_sig_id` (nullable until `active`), `approved_at` (nullable until `active`), `status` (`pending` / `active` / `revoked` / `expired` / `auto_expired_no_review`), `founder_notified_at` (nullable until `active`), `soc_alerted_at` (nullable until `active`), `revoked_at` (nullable), `revoked_by` (nullable), `revocation_reason` (nullable), `revocation_e_sig_id` (nullable) | required per-state: requesting_*, requested_at always; approving_*, approved_at, founder_notified_at, soc_alerted_at required from `active`; revoked_* required from `revoked` | unique active(`tenant_id`, `sod_rule_id`, `scope_hash`, `effective_from`) | RLS on `tenant_id` | none | seven years post-expiry | not applicable | yes | yes (per stage) | | `qualification_evidence_links` | Linkage to URS-28 evidence | `id`, `assignment_id`, `qualification_record_id` (URS-28 FK), `qualification_type` (e.g., `qp_licence`, `qa_leadership_credential`, `cdsco_registration`), `linked_at`, `linked_by` | all | unique(`assignment_id`, `qualification_record_id`) | RLS via assignment | none | seven years | not applicable | yes | yes (linked via assignment) | | `periodic_access_reviews` | Per-window header | `id`, `tenant_id`, `window_start`, `window_end`, `status` (`open` / `closed` / `auto_closed_unreviewed`), `opened_by`, `closed_by` (nullable), `closed_at` (nullable), `attestation_export_e_sig_id` (nullable) | core required | unique active(`tenant_id`, `window_start`) | RLS on `tenant_id` | none | seven years | not applicable | yes | yes | | `periodic_access_review_rows` | Per-attestation row (state machine: `pending` → `decided` / `auto_expired`) | `id`, `review_id`, `subject_type` (`assignment` / `delegation` / `exception`), `subject_id`, `status` (`pending` / `decided` / `auto_expired`), `reviewer_user_id` (nullable until decided), `decision` (nullable until decided; values: `continue` / `revoke` / `migrate` / `auto_expired`), `decided_at` (nullable), `decided_e_sig_id` (nullable), `rerouted_from_reviewer_user_id` (nullable; populated when row was rerouted from a reviewer who held the assignment), `notes` (nullable) | required per-state: id, review_id, subject_type, subject_id, status always; reviewer_*, decision, decided_*, decided_e_sig_id required from `decided` | unique(`review_id`, `subject_type`, `subject_id`) | RLS via review | none | seven years | not applicable | yes | yes (per row when decided) | | `inactive_holder_flags` | Informational | `id`, `tenant_id`, `assignment_id`, `flagged_at`, `last_used_at` (nullable), `cleared_at` (nullable), `cleared_reason` | all | unique active(`tenant_id`, `assignment_id`) | RLS on `tenant_id` | none | retain | not applicable | yes | not applicable | | `resolver_audit_log` | Forensic resolver call log | `id`, `tenant_id`, `caller_module` (`urs04` / `urs05_self_test` / `urs04_template_preview`), `decision_context_hash`, `actor_user_id`, `verdict`, `verdict_reasons_jsonb`, `latency_ms`, `called_at` | all | none | RLS on `tenant_id` | append-only | thirteen months hot; archive per URS-35 | not applicable | self | conditional | ### 6.2.1 Scope JSONB shape `scope_jsonb` is keyed by scope dimension drawn from the canonical authority scope dimension registry (DEC-05-03): `site`, `product`, `product_family`, `study`, `supplier`, `jurisdiction`, `business_unit`, `module`, `entity_type`, `workflow_type`. Each value is either an array of identifiers, a wildcard `*` (subject to §12.13 wildcard-restriction policy below), or a structured constraint. Two boolean flags MAY also be set: `tenant_wide: true` (assignment unrestricted across the listed dimensions for the tenant) and `global_super_authority: true` (platform-wide break-glass posture; subject to URS-03 super-authority controls and SOC alert). Examples: ```json { "site": ["site-A-uuid", "site-B-uuid"], "product_family": ["alpha-uuid"] } { "site": "*", "jurisdiction": ["EU"] } { "supplier": ["supplier-X-uuid"] } { "module": ["urs-13"], "entity_type": ["deviation"], "workflow_type": ["deviation_closure"] } { "tenant_wide": true, "module": ["urs-12"] } ``` Wildcard scope (`*`) is forbidden by default for jurisdictional batch-release profiles (`qp_eu`, `ap_india`, `qa_release_us`, `qa_release_uk`, `qa_release_ca`, `qp_release_authority`) and for `global_quality_oversight` and `recall_decision_authority`. Wildcard MAY be permitted only through tenant validation evidence and explicit QA + RA electronic signature recorded in the assignment ceremony; the assignment surface refuses wildcard for these profiles unless the WILDCARD_SCOPE_QA_RA_APPROVED flag is set on the request envelope and the dual-signed approval evidence is linked. `scope_hash` is the SHA-256 of the canonicalised JSON (sorted keys, deterministic ordering of array values; flags treated as distinct keys) and is used for uniqueness and cache keying. ### 6.3 API requirements #### 6.3.1 Authority Profile catalogue (Tier 1 platform-scoped) | Method | Endpoint | Actor | Request | Response | Permission | Audit | Error codes | |---|---|---|---|---|---|---|---| | GET | `/platform/authority-profiles` | platform identity | filters | `AuthorityProfileVersion[]` | platform identity | none | none | | POST | `/platform/authority-profiles` | platform identity | profile fields (electronic-signed + MFA) | `201` | platform identity | `AUTHORITY_PROFILE_VERSION_DRAFTED` | validation | | POST | `/platform/authority-profiles/:key/submit-for-review` | platform identity | reason (electronic-signed) | `200` | platform identity | `AUTHORITY_PROFILE_VERSION_SUBMITTED_FOR_REVIEW` | `STATE_NOT_DRAFT` | | POST | `/platform/authority-profiles/:key/approve` | platform identity (different user) | reason (electronic-signed + MFA) | `200` | platform identity | `AUTHORITY_PROFILE_VERSION_APPROVED` | `STATE_NOT_UNDER_REVIEW`, `APPROVER_IS_AUTHOR` | | POST | `/platform/authority-profiles/:key/publish` | platform identity | reason (electronic-signed + MFA) | `200` | platform identity | `AUTHORITY_PROFILE_VERSION_PUBLISHED` | `STATE_NOT_APPROVED` | | POST | `/platform/authority-profiles/:key/retire` | platform identity | reason (electronic-signed + MFA) | `200` | platform identity | `AUTHORITY_PROFILE_RETIRED` | `STATE_NOT_PUBLISHED` | | GET | `/platform/authority-profiles/:key/versions` | platform identity | none | version history with hash chain | platform identity | none | none | #### 6.3.2 Authority Profile catalogue (Tier 2 tenant-scoped) | Method | Endpoint | Actor | Request | Response | Permission | Audit | Error codes | |---|---|---|---|---|---|---|---| | GET | `/admin/authority-profiles` | administrator / auditor | filters | Tier 1 + own Tier 2 | `tenant_admin_authority` (read) | none | none | | POST | `/admin/authority-profiles/tier2` | administrator | profile fields (electronic-signed) | `201` | `tenant_admin_authority` | `TIER_2_PROFILE_CREATED` | `KEY_CONFLICT_TIER_1`, validation | | POST | `/admin/authority-profiles/tier2/:key/retire` | administrator | reason (electronic-signed) | `200` | `tenant_admin_authority` | `TIER_2_PROFILE_RETIRED` | `STATE_NOT_ACTIVE` | #### 6.3.3 Assignments | Method | Endpoint | Actor | Request | Response | Permission | Audit | Error codes | |---|---|---|---|---|---|---|---| | GET | `/admin/authority/assignments` | administrator / auditor | filters | `Assignment[]` | `tenant_admin_authority` (read) | none | none | | GET | `/admin/authority/assignments/:userId` | administrator / auditor | none | per-user detail | `tenant_admin_authority` (read) | none | none | | POST | `/admin/authority/assignments` | administrator | `{userId, catalogueId, scope, effectiveFrom, effectiveTo, qualificationEvidenceIds}` (electronic-signed) | `201` | `tenant_admin_authority` | `AUTHORITY_PROFILE_ASSIGNED` | `QUALIFICATION_EVIDENCE_MISSING`, `QUALIFICATION_EVIDENCE_EXPIRED`, `SCOPE_DIMENSION_NOT_PERMITTED`, validation | | POST | `/admin/authority/assignments/:id/revoke` | administrator | reason (electronic-signed) | `200` | `tenant_admin_authority` | `ASSIGNMENT_REVOKED` | validation | | POST | `/admin/authority/assignments/:id/migrate` | administrator | `{targetVersionId, reason}` (electronic-signed) | `200` | `tenant_admin_authority` | `ASSIGNMENT_MIGRATED` | `QUALIFICATION_EVIDENCE_MISSING`, `TARGET_VERSION_NOT_EFFECTIVE` | | GET | `/authority/me` | authenticated | none | `MyAuthorityView` | self | `AUTHORITY_SELF_VIEW_OPENED` | none | #### 6.3.4 Delegations | Method | Endpoint | Actor | Request | Response | Permission | Audit | Error codes | |---|---|---|---|---|---|---|---| | GET | `/admin/authority/delegations` | administrator / auditor | filters | `Delegation[]` | `tenant_admin_authority` (read) | none | none | | POST | `/authority/delegations` | any holder of a delegation-eligible profile | `{delegateUserId, catalogueId, scope, effectiveFrom, effectiveTo, reason}` (electronic-signed) | `201` | the delegator's own Authority Profile | `DELEGATION_CREATED` | `DELEGATION_NOT_ELIGIBLE`, `DELEGATION_KEY_MISMATCH`, `DELEGATION_CHAIN_DEPTH_EXCEEDED`, `DELEGATION_SCOPE_EXCEEDS_DELEGATOR`, `DELEGATION_DURATION_EXCEEDS_CAP`, validation | | POST | `/authority/delegations/:id/acknowledge` | delegate | `{decision: 'acknowledge'}` (electronic-signed) | `200` | recipient | `DELEGATION_ACKNOWLEDGED` | `STATE_NOT_PENDING`, `DELEGATE_DOES_NOT_HOLD_REQUIRED_BASE_ROLE` | | POST | `/authority/delegations/:id/decline` | delegate | reason (electronic-signed) | `200` | recipient | `DELEGATION_DECLINED` | `STATE_NOT_PENDING` | | POST | `/authority/delegations/:id/revoke` | delegator OR administrator | reason (electronic-signed) | `200` | the delegator's profile or `tenant_admin_authority` | `DELEGATION_REVOKED` (or `DELEGATION_FORCE_REVOKED` for admin force-revoke) | `STATE_NOT_ACTIVE` | | GET | `/authority/delegations/inbox` | authenticated | none | pending delegations awaiting acknowledgement | self | none | none | #### 6.3.5 SoD rules and exceptions | Method | Endpoint | Actor | Request | Response | Permission | Audit | Error codes | |---|---|---|---|---|---|---|---| | GET | `/admin/authority/sod` | administrator / reviewer / auditor | filters | rules with version history | `tenant_admin_authority` (read) | none | none | | POST | `/admin/authority/sod/tier2` | administrator | `{ruleKey, ruleDefinition, scope, effectiveFrom, effectiveTo}` (electronic-signed) | `201` | `tenant_admin_authority` | `TIER_2_SOD_RULE_CREATED` | `KEY_CONFLICT_TIER_1`, validation | | POST | `/admin/authority/sod/tier2/:id/retire` | administrator | reason (electronic-signed) | `200` | `tenant_admin_authority` | `TIER_2_SOD_RULE_RETIRED` | `STATE_NOT_ACTIVE` | | GET | `/admin/authority/sod/exceptions` | administrator / auditor | filters | `SoDException[]` | `tenant_admin_authority` (read) | none | none | | POST | `/admin/authority/sod/exceptions` | quality_lead or administrator | `{sodRuleId, scope, effectiveFrom, effectiveTo, meaningText}` (electronic-signed) | `201` | originator's profile | `SOD_EXCEPTION_REQUESTED` | `EXCEPTION_DURATION_EXCEEDS_CAP`, `MEANING_TEXT_TOO_SHORT` | | POST | `/admin/authority/sod/exceptions/:id/approve` | independent administrator from SoD-exception authority pool | reason (electronic-signed + MFA) | `200` | independent SoD-exception authority | `SOD_EXCEPTION_APPROVED` | `APPROVER_IS_REQUESTER`, `STATE_NOT_PENDING` | | POST | `/admin/authority/sod/exceptions/:id/revoke` | administrator | reason (electronic-signed) | `200` | `tenant_admin_authority` | `SOD_EXCEPTION_REVOKED` | `STATE_NOT_ACTIVE` | #### 6.3.6 Periodic access review | Method | Endpoint | Actor | Request | Response | Permission | Audit | Error codes | |---|---|---|---|---|---|---|---| | POST | `/admin/authority/periodic-review/open` | administrator | `{windowStart, windowEnd}` (electronic-signed) | `201` | `tenant_admin_authority` | `PERIODIC_REVIEW_OPENED` | `WINDOW_OVERLAP`, validation | | GET | `/admin/authority/periodic-review/:id/rows` | reviewer | filters | `ReviewRow[]` | `tenant_admin_authority` (independent of held assignments) | none | none | | POST | `/admin/authority/periodic-review/:id/rows/:rowId/decide` | reviewer | `{decision, notes}` (electronic-signed) | `200` | reviewer | `PERIODIC_REVIEW_ROW_CONFIRMED` or `PERIODIC_REVIEW_ROW_REJECTED` | `REVIEWER_CANNOT_REVIEW_OWN_ASSIGNMENT`, `STATE_NOT_OPEN` | | POST | `/admin/authority/periodic-review/:id/close` | administrator | `{exportFormat}` (electronic-signed) | signed download URL | `tenant_admin_authority` | `PERIODIC_REVIEW_CLOSED`, `PERIODIC_REVIEW_ATTESTATION_EXPORTED` | `UNRESOLVED_ROWS_AT_CLOSE` | | GET | `/admin/authority/inactive-holders` | administrator / auditor | filters | `InactiveHolderFlag[]` | `tenant_admin_authority` (read) | none | none | | POST | `/admin/authority/inactive-holders/:id/annotate` | administrator | reason (electronic-signed) | `200` | `tenant_admin_authority` | `INACTIVE_HOLDER_ANNOTATED` | validation | #### 6.3.7 Resolver (back-end consumed by URS-04) | Method | Endpoint | Actor | Request | Response | Permission | Audit | |---|---|---|---|---|---|---| | POST | `/internal/resolver/candidates` | URS-04 service | `decisionContext` | `Candidate[]` with verdict trail | back-end-only | `RESOLVER_CANDIDATES_RUN` (forensic) | | POST | `/internal/resolver/validate` | URS-04 service | `{actorUserId, decisionContext}` | `{allowed, reasons[]}` | back-end-only | `APPROVAL_AUTHORITY_VALIDATED` (or `APPROVAL_AUTHORITY_DENIED`) | | POST | `/internal/resolver/snapshot` | URS-04 service | `{actorUserId, eSigId, decisionContext}` | snapshot row written | back-end-only | `APPROVAL_AUTHORITY_SNAPSHOT_WRITTEN` | | POST | `/internal/resolver/preview` | URS-04 template editor (preview-only) | `decisionContextSpec` | candidate count + sample verdicts | back-end-only | `RESOLVER_PREVIEW_RUN` (forensic) | | POST | `/authority/me/self-test` | authenticated user | `decisionContext` | dry-run verdict trail | self | `RESOLVER_SELF_TEST_RUN` | #### 6.3.8 Snapshot integrity (read-only audit / inspection surface) | Method | Endpoint | Actor | Request | Response | Permission | Audit | |---|---|---|---|---|---|---| | GET | `/admin/authority/integrity/:entityType/:targetRecordId` | administrator / auditor | none | per-entity hash chain manifest | `tenant_admin_authority` / `auditor` | none | | POST | `/admin/authority/integrity/:entityType/:targetRecordId/export` | administrator | `{format}` (electronic-signed) | signed download URL | `tenant_admin_authority` | `SNAPSHOT_INTEGRITY_EXPORTED` | ### 6.4 Resolver semantics #### 6.4.1 `resolveApprovalCandidates(decisionContext)` algorithm Input: `{tenantId, requiredAuthorityKeys[], activeScope, recordId, entityType, recordCreatedBy, recordLastModifiedBy, fromState, toState, workflowFamily, prevSlotSigners[]}`. Delegation is an **eligibility source**, not a post-SoD overlay. Steps: 1. **Eligibility (direct)** — query `authority_profile_assignments` where `tenant_id = :tenantId` AND `catalogue.key IN :requiredAuthorityKeys` AND `effective_from ≤ now()` AND (`effective_to IS NULL` OR `effective_to > now()`) AND `revoked_at IS NULL`. Tag each candidate `path = 'direct'`, `relevant_scope = assignment.scope`, `holder_user_id = assignment.user_id`. 1b. **Eligibility (via delegation)** — query `authority_profile_delegations` where `tenant_id = :tenantId` AND `catalogue.key IN :requiredAuthorityKeys` AND `status = 'active'` AND `effective_from ≤ now()` AND `effective_to > now()` AND `acknowledged_at IS NOT NULL`. Tag each candidate `path = 'via_delegation'`, `relevant_scope = delegation.scope`, `holder_user_id = delegation.delegate_user_id`, `delegation_id = delegation.id`. The eligibility candidate pool is the union of (1) and (1b), keyed by `holder_user_id`. If a user appears in both, the direct path takes precedence (snapshot will record `path = 'direct'`). 2. **Scope match** — for each candidate, compute `intersect(candidate.relevant_scope, activeScope)` per the dimension-by-dimension intersection rules in URS-03 §6.4.1; retain candidates whose intersection is non-empty (or where the relevant scope carries a permitted wildcard for the dimension per §6.2.1 wildcard policy, or `tenant_wide: true` for the listed dimensions, or `global_super_authority: true` subject to URS-03 super-authority controls). 3. **SoD evaluation** — for each candidate, run `evaluateSoD(candidate.holder_user_id, decisionContext)` against the active SoD rule set (Tier 1 fixed launch set + active Tier 2 rules for the tenant) and the active SoD-exception register: - `AUTHOR_NEQ_APPROVER` — exclude `recordCreatedBy` and `recordLastModifiedBy`. - `REVIEWER_NEQ_FINAL_APPROVER` — exclude users who signed any prior step in this workflow instance. - `DELEGATOR_NEQ_DELEGATE` — exclude any candidate whose delegation's `delegator_user_id` is the same user the SoD context excludes for the record (e.g., delegation cannot be used to bypass `AUTHOR_NEQ_APPROVER`). - `CREATOR_NEQ_EFFECTIVENESS_VERIFIER` — for CAPA effectiveness gates, exclude `recordCreatedBy`. - `SAME_USER_TWO_PARALLEL_SLOTS_FORBIDDEN` — exclude users in `prevSlotSigners[]`. - Tier 2 rules — apply each rule's `rule_definition_jsonb` predicate. - SoD exceptions — if an active exception covers the rule and scope, mark `verdict = 'excepted'` with the exception identifier; the candidate remains in the pool. 4. **Qualification re-check** — call URS-28 to re-verify each linked qualification evidence for the `holder_user_id` of record (the delegate, where path is via_delegation; the direct holder otherwise) is in force at `now()`. Excluded if missing or expired. The delegate's qualifications MUST satisfy the profile-level requirements at this step regardless of the delegator's qualifications, per BR-05-24. 5. **Snapshot composition tags** — for each surviving candidate, attach the verdict trail with: `path` (direct / via_delegation), `delegation_id` (if applicable), `sod_verdict` (passed / excepted), `sod_exception_id` (if applicable), `relevant_scope`, `qualification_evidence_at_decision_time`, `catalogue_version_pinned`, `claims_version`. Override flags are attached at URS-04 override-path resolution and not in this step. 6. Return the candidate list with the five-step verdict trail per candidate (for forensic use and dry-run / self-test rendering). #### 6.4.2 `validateApprovalAction(actorUserId, decisionContext)` algorithm Run the same algorithm scoped to a single user; return `{allowed: boolean, reasons[]: string[], verdictTrail: jsonb, viaDelegation: bool, delegationId?: uuid, sodExceptionId?: uuid}`. Used by URS-04 at HITL submit and again immediately before signature insertion (defence-in-depth per URS-04 DEC-04-08). The two calls share this same implementation. #### 6.4.3 `snapshotApprovalAuthority(actorUserId, eSigId, decisionContext)` algorithm Compose the snapshot from the verdict trail produced by `validateApprovalAction`; include `actor.assignments_jsonb`, `delegation_overlay_jsonb`, `scope_match_jsonb`, `sod_verdict`, `qualification_evidence_jsonb`, `catalogue_version_pinned`, `claims_version_at_approval`, `override flag where applicable`, `record_hash` and `previous_hash` per the URS-04 hash-chain contract scoped to `(tenant_id, entity_type, target_record_id)`. Write through URS-04 transaction with the electronic-signature row. #### 6.4.4 `evaluateSoD(actorUserId, decisionContext)` algorithm Independent helper used by the resolver and by the front-end self-test. Returns per-rule verdicts. ### 6.5 Business rules - **BR-05-01** — Module 5 is the sole authority on the catalogue, assignment, delegation, SoD, and resolver semantics for the platform. URS-04 MUST consume the resolver and MUST NOT replicate authority logic. - **BR-05-02** — Catalogue versions are immutable; published versions MUST NOT be edited. Changes produce a new version row pinned forward. - **BR-05-03** — Assignments MUST be pinned to the catalogue version effective at assignment time. Migration to a new version is explicit and electronically signed. - **BR-05-04** — Delegations MUST be a strict subset of the delegator's scope and MUST NOT exceed the maximum duration cap (DEC-05-06). - **BR-05-05** — Delegations MUST NOT be re-delegated. Chain depth = 1. - **BR-05-06** — Delegation across non-same-key Tier 1 jurisdictional variants is forbidden (e.g., `qp_eu` cannot delegate to `ap_india`). - **BR-05-07** — A profile flagged `delegation_eligible = false` cannot be delegated under any condition; the surface refuses to construct a delegation. - **BR-05-08** — The resolver MUST run all four steps in the prescribed order: eligibility → scope match → SoD → qualification. - **BR-05-09** — `validateApprovalAction` MUST be deterministic given the same `decisionContext` and resolver inputs at the same moment in time. Caches MUST be invalidated on any catalogue / assignment / delegation / SoD / qualification change for the affected tenant or user. - **BR-05-10** — The snapshot is created atomic with the electronic-signature row per URS-04 BR-04-04 and URS-04 BR-04-16; rollback on any failure. - **BR-05-11** — SoD exceptions require dual-sign by independent users; the requester cannot also be the approver. - **BR-05-12** — Periodic-access-review reviewers MUST NOT review their own assignments. The surface enforces this and the back-end re-asserts. - **BR-05-13** — Inactive-holder flagging is informational and does not auto-revoke. Revocation is always explicit with electronic signature. - **BR-05-14** — Catalogue retirement MUST cascade to active delegations (warn + force-revoke on confirm) but MUST NOT retroactively invalidate already-signed decisions. - **BR-05-15** — User-account deactivation (URS-01) cascades immediately to all of the user's active assignments and delegations (delegator side and delegate side). - **BR-05-16** — Already-committed regulated decisions remain valid evidence regardless of subsequent revocation, retirement, or expiry. The snapshot fixes the authority of record at decision time. - **BR-05-17** — Resolver dependency unavailability fails secure: if URS-28 (qualifications) or URS-03 (active scope) are unreachable, `validateApprovalAction` returns `503` and the signature ceremony refuses to insert. - **BR-05-18** — External identities (URS-01 §3.2.3) MUST NOT hold any Authority Profile that names an `esignRequired` workflow node action. The resolver excludes them by construction. - **BR-05-19** — The resolver MUST never return `system actors` (e.g., `mira-agent@verixa.internal`) as candidates. URS-04 has a parallel rejection at signature-insert time per URS-04 §6.7. - **BR-05-20** — Catalogue-version pinning includes the SoD rule version as well; the snapshot records the SoD rule versions evaluated. A subsequent SoD rule change does not retroactively alter prior decisions. - **BR-05-21** — The Tier 2 catalogue MUST NOT use a key reserved for Tier 1; conflict returns `KEY_CONFLICT_TIER_1`. - **BR-05-22** — A Tier 1 profile flagged `override_eligible = true` MAY be configured as a workflow node's `override_authority_profile_id` (Module 4 §6.2). Module 5 only resolves whether the actor holds the override profile; Module 4 enforces the override ceremony rules. - **BR-05-23** — Audit log writes are atomic with the action they describe; failure rolls back per URS-04 BR-04-15. - **BR-05-24** — A delegate MUST satisfy all profile-level required base roles AND every qualification requirement listed in the profile's `qualification_requirements_jsonb` at **two checkpoints**: (a) at acknowledgement time (the acknowledgement endpoint refuses with `DELEGATE_DOES_NOT_HOLD_REQUIRED_BASE_ROLE` or `QUALIFICATION_EVIDENCE_MISSING` / `QUALIFICATION_EVIDENCE_EXPIRED` if the delegate's qualifications do not meet the profile's requirements), and (b) at every signature time (the resolver step 4 re-checks the delegate's linked qualification evidence in URS-28 and refuses with `QUALIFICATION_EVIDENCE_EXPIRED` if any evidence has lapsed since acknowledgement). The delegator's qualifications are NOT a substitute for the delegate's. For jurisdictional batch-release profiles (`qp_eu`, `ap_india`, `qa_release_us`, `qa_release_uk`, `qa_release_ca`), same-key delegation is mandatory — the delegate MUST hold an active assignment of the same Tier 1 key in their own right (e.g., a `qp_eu` delegation can only be acknowledged by a user who is themselves an active `qp_eu` holder). Same-family delegation across jurisdictional variants is forbidden unless the Tier 1 profile catalogue version explicitly permits family delegation (which the launch set does not). - **BR-05-25** — Wildcard scope (`*`) on assignments is forbidden by default for jurisdictional batch-release profiles, `global_quality_oversight`, and `recall_decision_authority`. The assignment surface refuses wildcard for these profiles unless the request envelope carries `WILDCARD_SCOPE_QA_RA_APPROVED = true` and links dual-signed QA + RA approval evidence; absence returns `WILDCARD_SCOPE_REQUIRES_QA_RA_APPROVAL`. ### 6.6 Audit trail requirements Module 5 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): `AUTHORITY_PROFILE_VERSION_DRAFTED`, `AUTHORITY_PROFILE_VERSION_SUBMITTED_FOR_REVIEW`, `AUTHORITY_PROFILE_VERSION_APPROVED`, `AUTHORITY_PROFILE_VERSION_PUBLISHED`, `AUTHORITY_PROFILE_RETIRED`, `TIER_2_PROFILE_CREATED`, `TIER_2_PROFILE_RETIRED`, `AUTHORITY_PROFILE_ASSIGNED`, `ASSIGNMENT_REVOKED`, `ASSIGNMENT_MIGRATED`, `ASSIGNMENT_AUTO_EXPIRED_NO_REVIEW`, `DELEGATION_CREATED`, `DELEGATION_ACKNOWLEDGED`, `DELEGATION_ACTIVE` (state-transition event emitted at the moment the delegation status flips from `pending_acknowledgement` to `active` after delegate acknowledgement), `DELEGATION_DECLINED`, `DELEGATION_USED` (annotation event emitted on first signing use), `DELEGATION_REVOKED`, `DELEGATION_FORCE_REVOKED`, `DELEGATION_EXPIRED`, `DELEGATION_EXPIRED_UNACKNOWLEDGED` (state-transition event emitted at the moment the delegation status flips from `pending_acknowledgement` to `expired_unacknowledged` because the acknowledgement window passed without acknowledgement), `DELEGATION_AUTO_EXPIRED_NO_REVIEW` (emitted when an active delegation auto-expires at the periodic-review window boundary without an attestation), `DELEGATION_KEY_MISMATCH` (forensic), `DELEGATION_CHAIN_DEPTH_EXCEEDED` (forensic), `TIER_2_SOD_RULE_CREATED`, `TIER_2_SOD_RULE_RETIRED`, `SOD_EXCEPTION_REQUESTED`, `SOD_EXCEPTION_APPROVED`, `SOD_EXCEPTION_USED`, `SOD_EXCEPTION_REVOKED`, `SOD_EXCEPTION_EXPIRED`, `SOD_EXCEPTION_AUTO_EXPIRED_NO_REVIEW` (emitted when an active SoD exception auto-expires at the periodic-review window boundary without an attestation), `SOD_EXCEPTION_CLUSTER_DETECTED` (forensic; emitted by monitoring), `PERIODIC_REVIEW_OPENED`, `PERIODIC_REVIEW_ROW_CONFIRMED`, `PERIODIC_REVIEW_ROW_REJECTED`, `PERIODIC_REVIEW_ROW_REROUTED`, `PERIODIC_REVIEW_CLOSED`, `PERIODIC_REVIEW_ATTESTATION_EXPORTED`, `INACTIVE_HOLDER_FLAGGED`, `INACTIVE_HOLDER_ANNOTATED`, `RESOLVER_CANDIDATES_RUN` (forensic), `RESOLVER_PREVIEW_RUN` (forensic), `RESOLVER_SELF_TEST_RUN`, `RESOLVER_DEPENDENCY_UNAVAILABLE` (forensic), `OVERRIDE_AUTHORITY_RESOLVED`, `SNAPSHOT_INTEGRITY_EXPORTED`, `AUTHORITY_SELF_VIEW_OPENED`, `SELF_MODIFICATION_DENIED` (forensic; written when `SELF_MODIFICATION_FORBIDDEN` is returned), `PLATFORM_TENANT_ACCESS_USED`, `PLATFORM_TENANT_ACCESS_DENIED`. Events emitted by URS-04 and consumed (read-only) by Module 5 reports include: `APPROVAL_AUTHORITY_VALIDATED`, `APPROVAL_AUTHORITY_DENIED`, `APPROVAL_AUTHORITY_SNAPSHOT_WRITTEN`, `AUTHORITY_OVERRIDE_USED`. The two writers correlate through the shared `e_sig_id` and snapshot `record_hash`. ### 6.7 Record versioning and class-of-change governance - Versioned (immutable per published version): `authority_profile_catalogue` / `authority_profile_versions`, `sod_rules` / `sod_rule_versions`. - Stateful with append-only audit / event history: `authority_profile_assignments` (mutates through revoke / migrate fields with audit per transition; the row itself is preserved through revocation; audit history is append-only), `authority_profile_delegations` (state machine `pending_acknowledgement` / `active` / `revoked` / `expired` / `expired_unacknowledged` with audit per state transition), `sod_exceptions` (state machine `pending` / `active` / `revoked` / `expired` / `auto_expired_no_review`), `periodic_access_reviews` (state machine `open` / `closed` / `auto_closed_unreviewed`), `periodic_access_review_rows` (state machine `pending` / `decided` / `auto_expired`). - Append-only (no mutation post-insert): `inactive_holder_flags` (cleared via `cleared_at` annotation but the row is not deleted), `resolver_audit_log` (forensic log). - Soft-delete: `authority_profile_catalogue` (retirement), `authority_profile_assignments` (revocation), `sod_rules` (retirement). Soft-deleted rows remain query-accessible for audit purposes per URS-06. --- ## 7. Cross-Module Wiring and Change-Impact ### 7.1 Cross-module wiring #### Diagram 7-A — Module 5 substrate consumed by other modules ```mermaid graph LR subgraph M5 [Module 5 — Authority of Record Substrate] CAT[Catalogue] ASN[Assignments] DEL[Delegation Overlay] SOD[SoD Rules + Exceptions] RES[Resolver] end M1[URS-01 Auth] --> RES M2[URS-02 RBAC] --> RES M3[URS-03 Active Scope] --> RES M28[URS-28 Training Management & Qualification] --> RES RES --> M4[URS-04 Workflow / E-Sign / HITL] RES --> M6[URS-06 Audit substrate] M4 --> M12[URS-12..URS-34 Regulated modules] M30[URS-30 Notifications] --> ASN M30 --> DEL M30 --> SOD M35[URS-35 Backup / Restore] --> M5 ``` URS-01 is the substrate for identity verification, MFA step-up, and account lifecycle (deactivation cascades). URS-02 is the substrate for base roles and permissions; resolver consumes effective permissions when computing eligibility for some Tier 2 profiles whose `required_permissions` list includes module-specific permissions. URS-03 is the substrate for active scope, used in step 2 of the resolver. URS-28 (Training Management & Qualification) is the substrate for qualification evidence — training records, certifications, professional licences (QP licence, CDSCO registration, QA-leadership credentials, Health Canada DEL credential, etc.) — used in step 4 of the resolver. URS-04 is the consumer of every resolver output — the workflow runtime, the HITL lifecycle, the Controlled Approval Modal, the e-signature ceremony, and the per-decision authority snapshot path. URS-06 ingests every Module 5 audit event and persists the snapshot rows produced by `snapshotApprovalAuthority`. URS-30 delivers notifications for delegation acknowledgement, periodic-review windows, SoD-exception alerts, and inactive-holder flags. URS-35 preserves the catalogue-version chain, the snapshot chain, and the audit chain across backup / restore. ### 7.2 Change-Impact Matrix (CIM) Every change to Module 5 that affects external behaviour MUST be classified per the four-class change impact taxonomy. Class 1 changes require Founder + QA + RA approval and trigger full revalidation; Class 2 changes require QA approval and trigger targeted regression; Class 3 changes require Engineering Lead approval and unit / integration regression; Class 4 changes are non-functional and require code-review approval. | Change | Class | Impact on (modules) | Required revalidation | |---|---|---|---| | Add / remove Tier 1 Authority Profile key | 1 | URS-04 (template authoring), URS-12..34 (workflow templates referencing the key) | Full regression of resolver + every workflow template touching the key | | Add / remove scope dimension | 1 | URS-03, URS-04, URS-08, URS-09, URS-10, URS-11 | Full regression of resolver + scope intersection logic | | Change Tier 1 profile field schema (DEC-05-02) | 1 | URS-04, URS-06 | Full regression including snapshot chain validity | | Change resolver ordering or step semantics | 1 | URS-04 | Full regression | | Change snapshot composition | 1 | URS-04, URS-06, URS-35 | Full regression including chain integrity | | Add Tier 1 SoD rule (DEC-05-08) | 1 | URS-04, URS-12..34 | Full regression of resolver | | Add / change qualification requirement on Tier 1 profile | 2 | URS-28, URS-04 | Targeted regression of qualification linkage | | Change delegation duration cap (DEC-05-06) | 2 | URS-04 | Targeted regression of delegation lifecycle | | Change SoD-exception duration cap (DEC-05-09) | 2 | URS-04 | Targeted regression of exception lifecycle | | Change inactive-holder threshold (DEC-05-13) | 3 | none external | Unit regression of scheduled job | | Add audit event code | 3 | URS-06 | Writer presence regression | | Add Tier 2 profile by tenant administrator | 3 | tenant only | Tenant-scope regression of resolver and reports | | Add Tier 2 SoD rule by tenant administrator | 3 | tenant only | Tenant-scope regression of resolver | | UI copy or layout change | 4 | none | Visual regression only | Every change above is classified at design time and recorded in the URS-13. Class 1 changes require Founder electronic signature. ### 7.3 Cross-module dependencies (consumed by Module 5) | Dependency | Source | Impact | Blocking? | |---|---|---|---| | Active scope at decision time | URS-03 §6.4.1 | Step 2 resolver | Blocking | | Effective permissions snapshot | URS-02 §6.4 | Step 1 resolver (where Tier 2 profile names required permissions) | Blocking | | Authentication and MFA step-up | URS-01 §6.6 / §6.7 | Controlled Approval Modal pre-condition | Blocking | | Qualification register | URS-28 §6 (Training Management & Qualification) | Step 4 resolver | Blocking | | Workflow runtime, HITL, Controlled Approval Modal, e-signature ceremony, hash-chained snapshot write | URS-04 §6 | Snapshot persistence path | Blocking | | Audit substrate hash chain | URS-06 §6 | Audit-write integrity | Blocking | | Notifications | URS-30 | Delegation acknowledgement, review reminders, exception alerts | Non-blocking (direct e-mail fallback) | | Backup / restore | URS-35 | Chain preservation across DR | Blocking for PQ | | User-account lifecycle (deactivation cascade) | URS-01 | Cascade trigger | Blocking | --- ## 8. AI / Automation / Human-in-the-Loop Controls Module 5 contains **no AI / ML components**. The resolver is rule-based and deterministic. AI suggestions in any other module that touch authority computation (e.g., MIRA suggesting which profile to assign during onboarding) MUST be advisory only; humans MUST confirm through the Controlled Approval Modal before any Module 5 mutation. Module 5 does not consume any LLM provider, does not run inference, and does not contain probabilistic logic in the resolver. Static analysis MUST verify zero references to LLM SDKs in Module 5 source. The HITL lifecycle is owned by URS-04. Module 5's role is to be the authority-of-record evaluator that URS-04 calls. --- ## 9. Reports, Dashboards, and Exports | Report | Purpose | Audience | Format | |---|---|---|---| | Authority Profile inventory | Tier 1 + Tier 2 catalogue with version history and active assignment counts | Administrator, auditor | CSV + PDF (electronically signed) | | Assignment register | Active assignments with scope, effective dates, qualification status, last-used | Administrator, auditor | CSV + PDF | | Delegation register | Active and historical delegations with state machine path | Administrator, auditor | CSV + PDF | | SoD exception register | Active and historical exceptions with linked Founder notification timestamps | Administrator, auditor | CSV + PDF | | Periodic-access-review attestation pack | Per-window attestation with reviewer signatures | Administrator, auditor, inspector | PDF (electronically signed) | | Inactive-holder report | Assignments unused beyond threshold | Administrator | CSV | | Snapshot integrity manifest (per entity) | Hash-chain verification per regulated record | Administrator, auditor, inspector | PDF (electronically signed) + JSON | | Resolver verdict trail (per regulated decision) | Step-by-step verdict trail for forensic / inspection use | Administrator, auditor, inspector | JSON + PDF | | Catalogue version history | Hash-chain manifest of catalogue evolution | Platform admin, auditor | PDF + JSON | Every export routes through the Controlled Approval Modal. Signed download URLs with fifteen-minute TTL. Integrity manifest accompanies every export. --- ## 10. Notifications and Queues | Trigger | Recipient | Channel | Latency | |---|---|---|---| | Authority Profile assigned | the assigned user; tenant administrator | URS-30 in-app + e-mail | within 60 seconds | | Assignment revoked | the user; tenant administrator | URS-30 in-app + e-mail | within 60 seconds | | Delegation pending acknowledgement | delegate | URS-30 in-app + e-mail | within 60 seconds | | Delegation acknowledged | delegator | URS-30 in-app + e-mail | within 60 seconds | | Delegation revoked / expired | both delegator and delegate | URS-30 in-app + e-mail | within 60 seconds | | SoD exception requested | SoD-exception authority pool | URS-30 in-app + e-mail | within 60 seconds | | SoD exception approved | requester; Founder (within one business day) | URS-30 in-app + e-mail | requester within 60 seconds; Founder within one business day | | Periodic-review window opened | tenant administrator (reviewer) | URS-30 in-app + e-mail | at window open | | Periodic-review window approaching close | tenant administrator (reviewer) | URS-30 in-app + e-mail | T-7 days, T-1 day | | Inactive-holder flagged | tenant administrator | URS-30 in-app + e-mail digest weekly | T+0 | | Qualification evidence approaching expiry | the user; tenant administrator | URS-30 in-app + e-mail | T-30 days, T-7 days | | Profile retirement with active delegations affected | platform administrator (decision); tenant administrators (notification) | URS-30 + tenant-administrator surface banner | within 60 seconds | | Resolver dependency unavailable | platform on-call; SOC | URS-30 + SOC chat | within 60 seconds | | SoD exception cluster detected | Founder | URS-30 + executive authority e-mail | within one business day | --- ## 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 | resolver consumed by URS-04 | inline error in modal naming the failing step | | QUALIFICATION_EVIDENCE_MISSING | 400 | assignment create / migrate | inline error citing the missing evidence type | | QUALIFICATION_EVIDENCE_EXPIRED | 400 | assignment create / migrate / `validateApprovalAction` | inline error citing the expired evidence | | QUALIFICATION_EVIDENCE_UNAVAILABLE | 503 | `validateApprovalAction` | banner; signature ceremony refuses; retry | | SCOPE_DIMENSION_NOT_PERMITTED | 400 | assignment / delegation | inline error citing the unsupported dimension | | KEY_CONFLICT_TIER_1 | 409 | Tier 2 create | inline error | | DELEGATION_NOT_ELIGIBLE | 400 | delegation create | inline error citing `delegation_eligible = false` | | DELEGATION_KEY_MISMATCH | 400 | delegation create | inline error citing same-key requirement | | DELEGATION_CHAIN_DEPTH_EXCEEDED | 400 | delegation create | inline error citing chain depth = 1 | | DELEGATION_SCOPE_EXCEEDS_DELEGATOR | 400 | delegation create | inline error citing scope subset rule | | DELEGATION_DURATION_EXCEEDS_CAP | 400 | delegation create | inline error citing the 30-day cap | | DELEGATE_DOES_NOT_HOLD_REQUIRED_BASE_ROLE | 400 | delegation acknowledge | inline error | | EXCEPTION_DURATION_EXCEEDS_CAP | 400 | SoD exception create | inline error citing the 14-day cap | | MEANING_TEXT_TOO_SHORT | 400 | SoD exception create | inline error citing the 100-char minimum | | APPROVER_IS_REQUESTER | 403 | SoD exception approve | inline error | | APPROVER_IS_AUTHOR | 403 | catalogue version approve | inline error | | REVIEWER_CANNOT_REVIEW_OWN_ASSIGNMENT | 403 | periodic-review row decide | inline error | | SELF_MODIFICATION_FORBIDDEN | 403 | assignment / delegation / profile mutation where actor would alter their own authority | inline error; audit denial entry written to `resolver_audit_log` | | WILDCARD_SCOPE_REQUIRES_QA_RA_APPROVAL | 403 | assignment create / migrate where wildcard scope is requested for a restricted profile (jurisdictional batch-release, `global_quality_oversight`, `recall_decision_authority`) without the dual-signed QA+RA approval evidence linked | inline error | | UNRESOLVED_ROWS_AT_CLOSE | 409 | periodic-review close | inline error listing unresolved rows | | WINDOW_OVERLAP | 409 | periodic-review open | inline error | | STATE_NOT_DRAFT | 409 | catalogue / delegation / exception lifecycle endpoints | inline error | | STATE_NOT_UNDER_REVIEW | 409 | catalogue / delegation / exception lifecycle endpoints | inline error | | STATE_NOT_APPROVED | 409 | catalogue / delegation / exception lifecycle endpoints | inline error | | STATE_NOT_PUBLISHED | 409 | catalogue / delegation / exception lifecycle endpoints | inline error | | STATE_NOT_ACTIVE | 409 | catalogue / delegation / exception lifecycle endpoints | inline error | | STATE_NOT_PENDING | 409 | catalogue / delegation / exception lifecycle endpoints | inline error | | STATE_NOT_OPEN | 409 | catalogue / delegation / exception lifecycle endpoints | inline error | | TARGET_VERSION_NOT_EFFECTIVE | 409 | assignment migrate | inline error | | RESOLVER_CACHE_INVALIDATION_FAILED | 500 | back-end forensic | banner; on-call page | | SOD_RULE_VIOLATION (carried in `APPROVAL_AUTHORITY_DENIED.reasons[]`) | 403 | resolver | inline error naming the rule | | SOD_SAME_USER_TWO_SLOTS (carried in `APPROVAL_AUTHORITY_DENIED.reasons[]`) | 403 | resolver | inline error | | AUDIT_TRAIL_WRITE_FAILED | 500 | any state-changing action | toast; the originating action did NOT commit | | PLATFORM_TENANT_ACCESS_DENIED | 403 | platform identity outside support envelope | inline error; SOC alert | ### 11.3 Negative-path catalogue | Scenario | Detection | Response | UI behaviour | |---|---|---|---| | Assignment with missing qualification | back end at create | `400 QUALIFICATION_EVIDENCE_MISSING` | inline error | | Qualification expires between assignment and decision | back end at `validateApprovalAction` | `403 APPROVAL_AUTHORITY_DENIED` reason `QUALIFICATION_EVIDENCE_EXPIRED` | inline; URS-30 notify | | Delegation duration above cap | back end | `400 DELEGATION_DURATION_EXCEEDS_CAP` | inline | | Delegation scope exceeds delegator's | back end | `400 DELEGATION_SCOPE_EXCEEDS_DELEGATOR` | inline | | Cross-jurisdictional delegation attempt | back end | `400 DELEGATION_KEY_MISMATCH` | inline | | Re-delegation attempt | back end | `400 DELEGATION_CHAIN_DEPTH_EXCEEDED` | inline | | Delegation of non-eligible profile | back end | `400 DELEGATION_NOT_ELIGIBLE` | inline | | Same-user-two-slots violation at runtime | resolver | `403 APPROVAL_AUTHORITY_DENIED` reason `SOD_SAME_USER_TWO_SLOTS` | inline | | Reviewer attempts to attest own assignment | back end | `403 REVIEWER_CANNOT_REVIEW_OWN_ASSIGNMENT` | inline | | SoD exception requester equals approver | back end | `403 APPROVER_IS_REQUESTER` | inline | | Catalogue version author attempts to approve | back end | `403 APPROVER_IS_AUTHOR` | inline | | Tenant attempts Tier 1 key reuse | back end | `409 KEY_CONFLICT_TIER_1` | inline | | URS-28 unreachable | resolver | `503 QUALIFICATION_EVIDENCE_UNAVAILABLE` | banner; signature ceremony refuses | | URS-03 unreachable | resolver | `503` from upstream; defence-in-depth fail-secure | banner | | Catalogue migration to retired version | back end | `409 TARGET_VERSION_NOT_EFFECTIVE` | inline | | Periodic-review close with unresolved rows | back end | `409 UNRESOLVED_ROWS_AT_CLOSE` | inline listing rows | | External identity attempts to hold an esign-required profile | back end | resolver excludes by construction; admin surface refuses on assignment create | inline error | | System actor attempts to be returned as candidate | back end | resolver excludes by construction | not surfaced; forensic | --- ## 12. Security, Privacy, and Tenant Isolation ### 12.1 Authentication dependency URS-05 is reached only through an authenticated session established by URS-01. Every Module 5 mutation additionally requires re-authentication and (for high-risk: catalogue publish, override resolution, exception approval, profile retirement, force-revoke) multi-factor step-up. ### 12.2 Authorisation pipeline `authenticate hook → tenant hook → rbac hook → context gate hook → module5 hook → esigService.createSignature → snapshot chain write`. Module 5 owns the module5 hook position (catalogue / assignment / delegation / SoD admin actions) and owns the resolver functions called by URS-04's workflow hook. ### 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 Tier 1 catalogue and Tier 1 SoD rules are global / platform-context with explicit platform-only access policies. Tenant administrators cannot create rows in Tier 1 tables. ### 12.4 Encryption At rest: scope JSON content may contain regulated identifiers; 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, qualification evidence document content (only the linkage metadata is logged). Structured logs carry the correlation identifier on every request. Resolver-audit-log entries strip PII from `decision_context_hash` (the hash itself is non-reversible). ### 12.6 Privacy and data residency Inherits tenant data-residency configuration from URS-08. Snapshot content respects the tenant's residency. ### 12.7 Periodic access review Owned by Module 5 (DEC-05-12). Annual minimum; tenants may configure shorter intervals (e.g., quarterly); tenants may not extend beyond the default without controlled regulatory justification and approved change control. ### 12.8 Periodic audit-trail review Per URS-01 §12.11, high-risk Module 5 events triaged within one business day: `SOD_EXCEPTION_APPROVED`, `SOD_EXCEPTION_CLUSTER_DETECTED`, `DELEGATION_FORCE_REVOKED`, `AUTHORITY_PROFILE_RETIRED`, `PLATFORM_TENANT_ACCESS_USED` (Module 5 surface), `RESOLVER_DEPENDENCY_UNAVAILABLE` clusters. ### 12.9 Security-operations alert thresholds | Pattern | Threshold | Severity | Channel | |---|---|---|---| | `SOD_EXCEPTION_APPROVED` | any single event | critical | SOC chat + executive authority escalation | | `SOD_EXCEPTION_CLUSTER_DETECTED` (3 in 7 days same tenant) | any single event | critical | SOC chat + executive authority escalation | | `DELEGATION_FORCE_REVOKED` | any single event | high | SOC chat | | `AUTHORITY_PROFILE_RETIRED` (Tier 1) | any single event | high | SOC chat + tenant notifications | | `PLATFORM_TENANT_ACCESS_USED` for Module 5 | any single event | informational (real-time) | SOC chat | | `RESOLVER_DEPENDENCY_UNAVAILABLE` cluster | five in five minutes | critical | SOC chat + on-call page | | `QUALIFICATION_EVIDENCE_EXPIRED` denials | ten per tenant per hour | high | SOC chat | | `DELEGATION_CHAIN_DEPTH_EXCEEDED` cluster | five per user per hour | medium | SOC e-mail digest | ### 12.10 Self-modification block — scope A user MUST NOT modify their own Authority Profile assignments. The administrative surface refuses with `SELF_MODIFICATION_FORBIDDEN`. A reviewer MUST NOT attest their own assignments during periodic review (BR-05-12). Module 4's Mode A admin invariant applies recursively here: the only path to alter one's own authority is through another administrator's signed action. ### 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 5 control | Requirement | Verification | |---|---|---|---| | Attributable | Every catalogue version, assignment, delegation, exception, and review row carries `created_by` / `assigned_by` / `delegated_by` / etc.; system actors prohibited as resolver candidates | URS-05-AUD-001 | Integration test | | Legible | Catalogue / assignment / delegation surfaces render structured detail; exports render in PDF and machine-readable JSON | URS-05-REP-001 | Export test | | Contemporaneous | All timestamps from server clock; client-supplied timestamps dropped | URS-05-AUD-002 | Integration test | | Original | Catalogue versions immutable; assignments preserved through revocation; chain hash linkage | URS-05-AUD-003 | Validation test | | Accurate | Resolver runs the four steps deterministically; catalogue-version pinning prevents retroactive change | URS-05-DATA-001 | Concurrency test | | Complete | Every event in §6.6 has at least one writer; vocabulary completeness gate enforced | URS-05-AUD-004 | Validation test | | Consistent | Pinned catalogue version + SoD rule version on every snapshot; resolver cache invalidation on every relevant change | URS-05-AUD-005 | Concurrency test | | Enduring | Retention (seven years assignments and delegations; twenty-five years authority snapshots; cold archive after two years per URS-35) | URS-05-DATA-002 | Migration test | | Available | Read paths administrator / auditor accessible; export self-service | URS-05-REP-002 | End-to-end test | --- ## 14. Regulatory Mapping | Identifier | Control | Regulation / Guidance | Clause | Applicable | Implementation expectation | |---|---|---|---|---|---| | RG-05-001 | Limit access to authorised individuals | 21 CFR Part 11 | §11.10(d) | Yes | Authority Profile catalogue + assignment + resolver | | RG-05-002 | Authority checks for system functions | 21 CFR Part 11 | §11.10(g) | Yes | `validateApprovalAction` consumed by URS-04 | | RG-05-003 | Audit trail of operator actions | 21 CFR Part 11 | §11.10(e) | Yes | Hash-chained Module 5 events | | RG-05-004 | Identification code and password controls | 21 CFR Part 11 | §11.300 | Yes | Inherited from URS-01 | | RG-05-005 | Personnel and qualifications | EU GMP Annex 11 | §2 | Yes | Qualification-evidence linkage from URS-28 (Training Management & Qualification) | | RG-05-006 | Logical access controls | EU GMP Annex 11 | §12, §12.1 | Yes | Authority-of-record substrate | | RG-05-007 | Validation of computerised systems | EU GMP Annex 11 | §4 | Yes | CSV / CSA pack per §17 | | RG-05-008 | Documentation and record integrity | EU GMP Chapter 4 | applicable | Yes | Versioning + retention | | RG-05-009 | 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-05-010 | ALCOA+ data integrity | MHRA Data Integrity Guidance (2018) | nine principles | Yes | §13 mapping | | RG-05-011 | Records retention | EU GMP Annex 11 | §17 | Yes | Seven years assignments / twenty-five years snapshots | | RG-05-012 | Identity-management standards | ISO/IEC 27001 | A.5.16, A.8.5 | Yes | Inherited from URS-01 | | RG-05-013 | Segregation of duties | EU GMP Chapter 2 | §2.5 (responsibilities) | Yes | SoD rule registry + exception register | | RG-05-014 | EU AI Act applicability | Regulation (EU) 2024/1689 | Article 3(1) | Not applicable to this module | No AI; documented exclusion | | RG-05-015 | EU GMP Annex 22 (Draft 2025) | EU GMP Annex 22 | applicable forward-looking | Forward-looking only — no Module 5 control text depends on Annex 22 until incorporated through URS-13 | No Annex-22-dependent control | | RG-05-016 | Qualified Person responsibilities (EU) | Directive 2001/83/EC | Article 51 + Annex 16 | Yes | `qp_eu` profile semantics | | RG-05-017 | India batch-release authority | Drugs and Cosmetics Act 1940; Schedule M (revised 2023) | applicable | Yes | `ap_india` profile semantics | | RG-05-018 | US batch-release authority | 21 CFR Part 211 | §211.22 | Yes | `qa_release_us` profile semantics | | RG-05-019 | UK batch-release authority | post-Brexit MHRA equivalence | applicable | Yes | `qa_release_uk` profile semantics | | RG-05-020 | Canada batch-release authority | Health Canada DEL holder regulation | applicable | Yes | `qa_release_ca` profile semantics | ### 14.1 Predicate-rule applicability matrix | Record / artifact | Predicate-rule basis | Part 11 applicable? | Retention | Owner | Evidence | |---|---|---|---|---|---| | Authority Profile catalogue version (Tier 1) | Configuration baseline evidence | Yes | retain history | Platform / QA | Version row + hash chain + electronic signature | | Authority Profile catalogue version (Tier 2) | Tenant-configuration evidence | Yes | retain history | Tenant QA | Version row + hash chain + electronic signature | | Authority Profile assignment | Authority of record evidence | Yes | seven years post-revocation | QA / Information Security | Assignment row + audit + linked qualification evidence | | Approval delegation | Authority transfer evidence | Yes | seven years post-expiry | QA | Delegation row + acknowledgement signature + audit | | SoD rule version | Configuration baseline evidence | Yes | retain history | QA | Version row + hash chain | | SoD exception | Break-glass exception evidence | Yes | seven years post-expiry | QA / Founder oversight | Exception row + dual signatures + executive authority notification | | Periodic-access-review attestation | Periodic review evidence | Yes | seven years | QA / Information Security | Review row + reviewer electronic signature | | Snapshot row (per regulated decision) | Authority of record at decision time | Yes | twenty-five years | QA / Information Security | `approval_authority_snapshots` row (hash chained) | | Qualification-evidence link | Personnel qualification evidence | Yes | seven years | QA / Training | Linkage row + URS-28 evidence | --- ## 15. URS Requirements Register ### 15.1 Front-end (FE) - URS-05-FE-001 — The Authority Profile catalogue browser MUST render Tier 1 and own Tier 2 profiles with version history. Priority MUST. Risk MEDIUM. Maps RG-05-001. - URS-05-FE-002 — Tier 2 management surface MUST validate against Tier 1 key conflict at submission. Priority MUST. Risk MEDIUM. Maps RG-05-001. - URS-05-FE-003 — Assignment creation surface MUST surface inline qualification-evidence verification with URS-28 status. Priority MUST. Risk HIGH. Maps RG-05-005. - URS-05-FE-004 — Delegation creation surface MUST cap effective-to per DEC-05-06 and constrain scope subset of delegator's. Priority MUST. Risk HIGH. Maps RG-05-002. - URS-05-FE-005 — Delegation acknowledgement surface MUST require Controlled Approval Modal acknowledgement. Priority MUST. Risk HIGH. Maps RG-05-002. - URS-05-FE-006 — SoD-exception request surface MUST require ≥ 100-char meaning text and ≤ 14-day effective window. Priority MUST. Risk HIGH. Maps RG-05-013. - URS-05-FE-007 — Periodic-access-review wizard MUST refuse rows where the reviewer is the assignment holder. Priority MUST. Risk HIGH. Maps RG-05-001. - URS-05-FE-008 — "My authority" self-view MUST present resolver self-test inline. Priority SHOULD. Risk LOW. - URS-05-FE-009 — Snapshot integrity manifest viewer MUST render hash-chain verification badges. Priority MUST. Risk HIGH. Maps RG-05-003. - URS-05-FE-010 — Every route in §5.1 MUST be registered in the application router before release. Priority MUST. Risk LOW. - URS-05-FE-011 — Resolver self-test MUST explain failures plainly with the failing step (eligibility / scope / SoD / qualification) named. Priority SHOULD. Risk LOW. - URS-05-FE-012 — All Module 5 surfaces MUST meet WCAG 2.1 Level AA. Priority MUST. Risk MEDIUM. ### 15.2 Back-end (BE) - URS-05-BE-001 — `resolveApprovalCandidates` MUST run the four steps in the prescribed order (eligibility → scope match → SoD → qualification). Priority MUST. Risk CRITICAL. Maps RG-05-001, RG-05-005, RG-05-013. - URS-05-BE-002 — `validateApprovalAction` MUST be deterministic and idempotent for the same `decisionContext` at the same instant. Priority MUST. Risk CRITICAL. Maps RG-05-002. - URS-05-BE-003 — `snapshotApprovalAuthority` MUST be invoked atomic with the electronic-signature row write per URS-04 BR-04-04. Priority MUST. Risk CRITICAL. Maps RG-05-003. - URS-05-BE-004 — Catalogue versions MUST be immutable; published versions MUST NOT be edited. Priority MUST. Risk HIGH. Maps RG-05-008. - URS-05-BE-005 — Assignments MUST be pinned to the catalogue version effective at assignment time. Priority MUST. Risk HIGH. Maps RG-05-008. - URS-05-BE-006 — Delegation duration MUST NOT exceed the cap (DEC-05-06). Priority MUST. Risk HIGH. Maps RG-05-002. - URS-05-BE-007 — Delegation chain depth MUST be 1; re-delegation MUST be refused. Priority MUST. Risk HIGH. Maps RG-05-002. - URS-05-BE-008 — Cross-jurisdictional / non-same-key delegation MUST be refused. Priority MUST. Risk HIGH. Maps RG-05-016, RG-05-017, RG-05-018, RG-05-019, RG-05-020. - URS-05-BE-009 — SoD exception MUST be dual-signed by independent users with ≥ 100-char meaning and ≤ 14-day window. Priority MUST. Risk HIGH. Maps RG-05-013. - URS-05-BE-010 — Periodic-access-review reviewer MUST NOT be the assignment holder. Priority MUST. Risk HIGH. Maps RG-05-001. - URS-05-BE-011 — User-account deactivation MUST cascade to all of the user's active assignments and delegations. Priority MUST. Risk HIGH. Maps RG-05-001. - URS-05-BE-012 — Catalogue retirement MUST cascade to active delegations. Priority MUST. Risk MEDIUM. - URS-05-BE-013 — Resolver dependency unavailability (URS-28 / URS-03) MUST fail secure with HTTP 503. Priority MUST. Risk HIGH. - URS-05-BE-014 — Resolver MUST exclude system actors and esign-required-incompatible external identities by construction. Priority MUST. Risk HIGH. - URS-05-BE-015 — Resolver cache MUST invalidate on any catalogue / assignment / delegation / SoD / qualification change for the affected tenant or user. Priority MUST. Risk HIGH. - URS-05-BE-016 — Snapshot composition MUST capture catalogue version, SoD rule versions, scope match, qualification evidence, delegation overlay, override flags. Priority MUST. Risk CRITICAL. Maps RG-05-003. - URS-05-BE-017 — Tier 2 keys MUST NOT collide with Tier 1 keys. Priority MUST. Risk MEDIUM. - URS-05-BE-018 — `evaluateSoD` MUST evaluate Tier 1 launch set + active Tier 2 rules for the tenant. Priority MUST. Risk HIGH. Maps RG-05-013. - URS-05-BE-019 — Already-committed regulated decisions MUST remain valid evidence regardless of subsequent revocation, retirement, or expiry. Priority MUST. Risk CRITICAL. - URS-05-BE-020 — Audit-log writes MUST be atomic with the action; failure rolls back per URS-04 BR-04-15. Priority MUST. Risk HIGH. - URS-05-BE-021 — `authority_profile_versions.lifecycle_state` MUST be enforced as a state machine via database CHECK constraints; submitted, approved, published, and retired field groups MUST be nullable in earlier states and required (NOT NULL) from the gating state onward. Priority MUST. Risk HIGH. Maps RG-05-008. - URS-05-BE-022 — `sod_exceptions` and `periodic_access_review_rows` MUST follow the same per-state nullability discipline; approver / decision / signature fields MUST be nullable in `pending` and required from the decision state onward, enforced by database CHECK. Priority MUST. Risk HIGH. Maps RG-05-008. ### 15.3 Workflow (WF) - URS-05-WF-001 — Catalogue lifecycle: draft → under_review → approved → published; published → retired (no rollback). Priority MUST. Risk HIGH. - URS-05-WF-002 — Delegation state machine per Diagram J-05. Priority MUST. Risk HIGH. - URS-05-WF-003 — Periodic-access-review state machine: open → close (or auto_closed_unreviewed at boundary). Priority MUST. Risk MEDIUM. - URS-05-WF-004 — SoD-exception state machine: pending → active → expired/revoked. Priority MUST. Risk HIGH. ### 15.4 Data (DATA) - URS-05-DATA-001 — `scope_jsonb` keys MUST be from the launch scope-dimension set; unknown keys return `SCOPE_DIMENSION_NOT_PERMITTED`. Priority MUST. Risk HIGH. - URS-05-DATA-002 — Retention per §13 (seven years assignments / twenty-five years snapshots). Priority MUST. Risk HIGH. - URS-05-DATA-003 — Hash-chain verification job MUST run periodically and on every export. Priority MUST. Risk HIGH. ### 15.5 Security (SEC) - URS-05-SEC-001 — Tenant isolation enforced via TDAL + RLS on every Module 5 table. Priority MUST. Risk CRITICAL. - URS-05-SEC-002 — Multi-factor step-up required for catalogue publish, profile retire, override resolution, exception approval, force-revoke. Priority MUST. Risk HIGH. - URS-05-SEC-003 — Self-modification block: a user cannot modify their own assignments. Priority MUST. Risk HIGH. - URS-05-SEC-004 — Reviewer-cannot-attest-own-assignment block enforced. Priority MUST. Risk HIGH. ### 15.6 Audit (AUD) - URS-05-AUD-001 — Every Module 5 mutation MUST produce an audit row through URS-06 with `tenantId`, `userId`, `action`, `resourceType`, `resourceId`, `details`, `ipAddress`, `timestamp`. Priority MUST. Risk CRITICAL. - URS-05-AUD-002 — Server-set timestamps; client-supplied timestamps dropped. Priority MUST. Risk HIGH. - URS-05-AUD-003 — Append-only on every register and log table. Priority MUST. Risk HIGH. - URS-05-AUD-004 — Every event in §6.6 has at least one writer + regression test. Priority MUST. Risk HIGH. - URS-05-AUD-005 — Hash-chain integrity verifiable per entity. Priority MUST. Risk CRITICAL. ### 15.7 AI / HITL (AI) - URS-05-AI-001 — Module 5 contains no AI / ML components; static analysis MUST find zero LLM SDK references. Priority MUST. Risk HIGH. - URS-05-AI-002 — System actors MUST NOT be returned as resolver candidates. Priority MUST. Risk HIGH. ### 15.8 Integration (INT) - URS-05-INT-001 — Resolver MUST integrate with URS-03 active scope. Priority MUST. Risk CRITICAL. - URS-05-INT-002 — Resolver MUST integrate with URS-28 qualification register. Priority MUST. Risk HIGH. - URS-05-INT-003 — Snapshot MUST be written through URS-04 hash-chain transaction. Priority MUST. Risk CRITICAL. - URS-05-INT-004 — Account deactivation cascade MUST listen on URS-01 events. Priority MUST. Risk HIGH. - URS-05-INT-005 — Audit MUST flow through URS-06 substrate. Priority MUST. Risk CRITICAL. ### 15.9 Reporting (REP) - URS-05-REP-001 — Every report listed in §9 MUST be available for export with electronic signature. Priority MUST. Risk MEDIUM. - URS-05-REP-002 — Snapshot integrity manifest MUST validate the chain end-to-end per entity. Priority MUST. Risk HIGH. - URS-05-REP-003 — Signed download URL TTL MUST be 15 minutes. Priority MUST. Risk MEDIUM. ### 15.10 Notifications (NOTIF) - URS-05-NOTIF-001 — Every notification listed in §10 MUST be delivered through URS-30 with the specified latency. Priority MUST. Risk MEDIUM. - URS-05-NOTIF-002 — Founder MUST be notified within one business day of any SoD exception approval. Priority MUST. Risk HIGH. ### 15.11 Validation (VAL) - URS-05-VAL-001 — Test execution against this URS MUST cover IQ (schema, RLS, indexes, constraints, hash-chain bootstrap), OQ (per URS-05-VAL-002), PQ (per URS-05-VAL-003), regression (per URS-05-VAL-004). - URS-05-VAL-002 — OQ MUST validate every API endpoint, every error code path, every state transition, every audit event writer. - URS-05-VAL-003 — PQ MUST validate the resolver under representative tenant volume and concurrency. - URS-05-VAL-004 — Regression MUST run on every Class 1 / Class 2 change. - URS-05-VAL-005 — Requirements-to-test traceability matrix per §16.4. - URS-05-VAL-006 — Supplier qualification pack per §17.1. - URS-05-VAL-007 — Inspection-ready evidence index per §17.2. - URS-05-VAL-008 — Migration evidence gate: schema migrations are idempotent; migrations seed the Tier 1 catalogue and the Tier 1 SoD rule launch set; resolver dry-run executes deterministically against the seed. --- ## 16. Acceptance Criteria and Test Cases ### 16.1 Plain-language test cases (for non-domain readers) - TC-PLAIN-001 — Sarah is assigned `final_quality_approver` for Site A and Product Family Alpha; she can sign closure decisions for matching records. - TC-PLAIN-002 — Sarah's qualification expires; her next signature attempt is denied with a clear message. - TC-PLAIN-003 — Sarah delegates to Priya for two weeks; Priya acknowledges; Priya signs a decision; the audit trail shows `via_delegation = true`. - TC-PLAIN-004 — Priya cannot re-delegate to a third user. - TC-PLAIN-005 — A `qp_eu` holder cannot delegate to an `ap_india` holder. - TC-PLAIN-006 — The author of a deviation cannot approve it (SoD). - TC-PLAIN-007 — The tenant administrator creates a SoD exception with dual signatures and a 14-day window; the rule is bypassed in scope; Founder is notified. - TC-PLAIN-008 — The annual review surface refuses an attestor who is the holder of the assignment under review. - TC-PLAIN-009 — Inactive holders are flagged in a report; the flag does not auto-revoke. - TC-PLAIN-010 — Catalogue-version pinning prevents a Tier 1 change from retroactively altering the authority of an already-signed decision. - TC-PLAIN-011 — User-account deactivation cascades immediately to every active assignment and delegation for that user. - TC-PLAIN-012 — Resolver self-test names the failing step (eligibility / scope / SoD / qualification) when a user cannot sign. - TC-PLAIN-013 — A platform administrator under controlled-support posture force-revokes a delegation; SOC alert and tenant administrator notification are emitted. ### 16.2 Technical test cases - TC-TECH-001 — `resolveApprovalCandidates` returns the expected candidate list for a representative `decisionContext` against a seeded catalogue. - TC-TECH-002 — `validateApprovalAction` returns the same result when called twice with the same context within the same instant; cache invalidation works on assignment change. - TC-TECH-003 — `snapshotApprovalAuthority` writes one row per signature atomic with the e-signature row. - TC-TECH-004 — The four-step ordering (eligibility → scope → SoD → qualification) is enforced; reordering causes test failure. - TC-TECH-005 — Catalogue version row carries `record_hash` and `previous_hash`; hash chain verifier passes. - TC-TECH-006 — Tier 2 key conflict with Tier 1 returns `409 KEY_CONFLICT_TIER_1`. - TC-TECH-007 — Assignment creation refuses missing qualification evidence with `400 QUALIFICATION_EVIDENCE_MISSING`. - TC-TECH-008 — `validateApprovalAction` returns `403` with reason `QUALIFICATION_EVIDENCE_EXPIRED` when evidence has expired between assignment and call. - TC-TECH-009 — Delegation duration > 30 days returns `400 DELEGATION_DURATION_EXCEEDS_CAP`. - TC-TECH-010 — Delegation scope outside delegator's returns `400 DELEGATION_SCOPE_EXCEEDS_DELEGATOR`. - TC-TECH-011 — Re-delegation returns `400 DELEGATION_CHAIN_DEPTH_EXCEEDED`. - TC-TECH-012 — Cross-jurisdictional delegation returns `400 DELEGATION_KEY_MISMATCH`. - TC-TECH-013 — SoD exception with < 100-char meaning returns `400 MEANING_TEXT_TOO_SHORT`. - TC-TECH-014 — SoD exception with > 14-day window returns `400 EXCEPTION_DURATION_EXCEEDS_CAP`. - TC-TECH-015 — SoD exception requester equals approver returns `403 APPROVER_IS_REQUESTER`. - TC-TECH-016 — Periodic-review row decision by holder returns `403 REVIEWER_CANNOT_REVIEW_OWN_ASSIGNMENT`. - TC-TECH-017 — Periodic-review close with unresolved rows returns `409 UNRESOLVED_ROWS_AT_CLOSE`. - TC-TECH-018 — User-account deactivation cascade revokes all active assignments and delegations within 60 seconds. - TC-TECH-019 — URS-28 unreachable returns `503 QUALIFICATION_EVIDENCE_UNAVAILABLE`; signature ceremony refuses. - TC-TECH-020 — Resolver excludes system actors by construction. - TC-TECH-021 — Hash-chain integrity verifier runs ≤ 60 s for 1 M snapshot rows. - TC-TECH-022 — Schema migrations idempotent; RLS enabled on every Module 5 tenant-scoped table. - TC-TECH-023 — Penetration test: cross-tenant assignment query returns 404 with no other tenant's data. - TC-TECH-024 — Penetration test: bypass attempts of `validateApprovalAction` produce audit denials, never `allowed = true`. - TC-TECH-025 — Catalogue retirement cascade revokes referenced delegations with reason `profile_retired`. - TC-TECH-026 — Catalogue migration of an assignment opens a new pinned row and closes the prior with reason `migrated`. - TC-TECH-027 — Tier 2 SoD rule applied across tenant-scope decisions in the configured family. - TC-TECH-028 — Resolver cache invalidates on catalogue / assignment / delegation / SoD / qualification change for the affected tenant or user; stale-cache test fails if invalidation missing. - TC-TECH-029 — Self-view resolver self-test produces deterministic dry-run trail without commits or audit-mutation rows. - TC-TECH-030 — Override authority resolution returns the configured override candidates and tags `override = true` in the snapshot. - TC-TECH-031 — `DELEGATION_ACTIVE` audit event is written at the moment a delegation flips from `pending_acknowledgement` to `active` after delegate acknowledgement; writer-presence test covers the path. - TC-TECH-032 — `DELEGATION_EXPIRED_UNACKNOWLEDGED` audit event is written when the acknowledgement window passes without acknowledgement; the delegation status is `expired_unacknowledged`. - TC-TECH-033 — Periodic-review window close auto-expires every unreviewed delegation and SoD exception in addition to assignments; audit events `DELEGATION_AUTO_EXPIRED_NO_REVIEW` and `SOD_EXCEPTION_AUTO_EXPIRED_NO_REVIEW` are written. - TC-TECH-034 — Self-modification attempt (user editing their own assignment) returns `403 SELF_MODIFICATION_FORBIDDEN` and writes a `SELF_MODIFICATION_DENIED` audit row. - TC-TECH-035 — Delegate who does not hold the profile-required qualification at acknowledgement time is refused with `QUALIFICATION_EVIDENCE_MISSING` (BR-05-24 first checkpoint). - TC-TECH-036 — Delegate who acknowledged when qualified but whose qualification expires before signature is refused at decision time with `QUALIFICATION_EVIDENCE_EXPIRED` (BR-05-24 second checkpoint). - TC-TECH-037 — Same-key delegation enforcement for `qp_eu`: a user who does not themselves hold an active `qp_eu` assignment is refused at acknowledgement with `DELEGATE_DOES_NOT_HOLD_REQUIRED_BASE_ROLE` extended message naming the same-key requirement. - TC-TECH-038 — Wildcard scope on `qp_eu` assignment without the dual-signed QA + RA approval envelope returns `403 WILDCARD_SCOPE_REQUIRES_QA_RA_APPROVAL`. - TC-TECH-039 — Tier 2 profile `key = 'X'` succeeds for tenant A and tenant B independently (partial-unique-index behaviour); duplicate within the same tenant returns `409`; `key = 'X'` matching an active Tier 1 key returns `409 KEY_CONFLICT_TIER_1`. - TC-TECH-040 — `authority_profile_versions` lifecycle CHECK constraints: row in `draft` MAY have null `published_at` / `published_by` / `published_e_sig_id`; transitioning to `effective` MUST have these populated; bypass attempt returns database constraint violation. ### 16.3 Acceptance criteria (Given / When / Then) #### Functional - AC-05-FUN-01 — Given a regulated decision arriving at URS-04, When `resolveApprovalCandidates` runs, Then the four steps execute in order and the candidate list is returned with verdict trail. - AC-05-FUN-02 — Given an active delegation, When the delegate signs, Then the snapshot tags `via_delegation = true` and records the delegation identifier. - AC-05-FUN-03 — Given a SoD-rule violation, When `validateApprovalAction` runs, Then it returns `allowed = false` with the failing rule named. - AC-05-FUN-04 — Given a SoD exception covering the rule and scope, When `validateApprovalAction` runs, Then `allowed = true` with `sod_verdict = 'excepted'` and the snapshot records the exception identifier. #### Permissions - AC-05-PERM-01 — Given a non-administrator caller, When attempting any Module 5 administrative action, Then HTTP 403. - AC-05-PERM-02 — Given a self-modification attempt, When called, Then HTTP 403 `SELF_MODIFICATION_FORBIDDEN`. #### API - AC-05-API-01 — Every endpoint listed in §6.3 returns the documented status codes for happy-path and error paths. - AC-05-API-02 — Every error response carries a structured error envelope per §11.1. #### Audit - AC-05-AUD-01 — Every Module 5 mutation produces an audit row through URS-06. - AC-05-AUD-02 — Audit-write failure rolls back the originating action. #### Data integrity - AC-05-DI-01 — Catalogue version row hash chain validates end-to-end. - AC-05-DI-02 — Snapshot rows produced by Module 5 validate against the URS-04 chain integrity verifier. #### Integration - AC-05-INT-01 — Resolver consumes URS-03 active scope and URS-28 qualification register correctly. - AC-05-INT-02 — User-account deactivation in URS-01 triggers Module 5 cascade within 60 seconds. #### Report / export - AC-05-REP-01 — Every report in §9 is exportable with electronic signature; integrity manifest validates. #### AI / HITL - AC-05-AI-01 — Static analysis finds zero references to LLM SDKs in Module 5. - AC-05-AI-02 — System actors are not returned as resolver candidates. #### Negative paths - AC-05-NEG-01 — Every error code in §11.2 is reachable by an automated test that exercises the failure path. #### Performance - AC-05-PERF-01 — `resolveApprovalCandidates` p95 ≤ 200 ms at 200 RPS sustained at representative tenant volume. - AC-05-PERF-02 — Hash-chain integrity verifier ≤ 60 s for 1 M rows. #### Security - AC-05-SEC-01 — Penetration test: cross-tenant token replay returns 404 with no other tenant's data. - AC-05-SEC-02 — Penetration test: bypass attempts of `validateApprovalAction` produce denial audit entries. #### Migration / backfill - AC-05-MIG-01 — Module 5 migrations are idempotent. - AC-05-MIG-02 — Applying all Module 5 migrations seeds Tier 1 catalogue + Tier 1 SoD launch set. ### 16.4 Requirements-to-test traceability | Requirement | Plain-language | Technical | Given / When / Then | |---|---|---|---| | URS-05-FE-001 | TC-PLAIN-001 | TC-TECH-001 | — | | URS-05-FE-002 | TC-PLAIN-001 | TC-TECH-006 | — | | URS-05-FE-003 | TC-PLAIN-001, TC-PLAIN-002 | TC-TECH-007, TC-TECH-008 | AC-05-FUN-01 | | URS-05-FE-004 | TC-PLAIN-003, TC-PLAIN-004, TC-PLAIN-005 | TC-TECH-009, TC-TECH-010, TC-TECH-011, TC-TECH-012 | AC-05-FUN-02 | | URS-05-FE-005 | TC-PLAIN-003 | TC-TECH-009 | AC-05-FUN-02 | | URS-05-FE-006 | TC-PLAIN-007 | TC-TECH-013, TC-TECH-014 | AC-05-FUN-04 | | URS-05-FE-007 | TC-PLAIN-008 | TC-TECH-016 | AC-05-PERM-02 | | URS-05-FE-008 | TC-PLAIN-012 | TC-TECH-029 | — | | URS-05-FE-009 | — | TC-TECH-021 | AC-05-DI-01 | | URS-05-FE-010 | — | TC-TECH-022 | — | | URS-05-FE-011 | TC-PLAIN-012 | TC-TECH-029 | — | | URS-05-FE-012 | — | (accessibility test suite) | — | | URS-05-BE-001 | TC-PLAIN-001 | TC-TECH-001, TC-TECH-004 | AC-05-FUN-01 | | URS-05-BE-002 | TC-PLAIN-012 | TC-TECH-002 | AC-05-FUN-01 | | URS-05-BE-003 | TC-PLAIN-001 | TC-TECH-003 | AC-05-DI-02 | | URS-05-BE-004 | TC-PLAIN-010 | TC-TECH-005 | AC-05-DI-01 | | URS-05-BE-005 | TC-PLAIN-010 | TC-TECH-026 | — | | URS-05-BE-006 | TC-PLAIN-003 | TC-TECH-009 | — | | URS-05-BE-007 | TC-PLAIN-004 | TC-TECH-011 | — | | URS-05-BE-008 | TC-PLAIN-005 | TC-TECH-012 | — | | URS-05-BE-009 | TC-PLAIN-007 | TC-TECH-013, TC-TECH-014, TC-TECH-015 | AC-05-FUN-04 | | URS-05-BE-010 | TC-PLAIN-008 | TC-TECH-016 | AC-05-PERM-02 | | URS-05-BE-011 | TC-PLAIN-011 | TC-TECH-018 | AC-05-INT-02 | | URS-05-BE-012 | — | TC-TECH-025 | — | | URS-05-BE-013 | — | TC-TECH-019 | AC-05-NEG-01 | | URS-05-BE-014 | — | TC-TECH-020 | AC-05-AI-02 | | URS-05-BE-015 | TC-PLAIN-012 | TC-TECH-028 | — | | URS-05-BE-016 | TC-PLAIN-001 | TC-TECH-003 | AC-05-DI-02 | | URS-05-BE-017 | TC-PLAIN-001 | TC-TECH-006 | — | | URS-05-BE-018 | TC-PLAIN-006, TC-PLAIN-007 | TC-TECH-027 | AC-05-FUN-03 | | URS-05-BE-019 | TC-PLAIN-010 | TC-TECH-026 | — | | URS-05-BE-020 | — | TC-TECH-022 | AC-05-AUD-02 | | URS-05-WF-001 | — | TC-TECH-005 | AC-05-DI-01 | | URS-05-WF-002 | TC-PLAIN-003 | TC-TECH-009..012 | AC-05-FUN-02 | | URS-05-WF-003 | TC-PLAIN-008 | TC-TECH-016, TC-TECH-017 | — | | URS-05-WF-004 | TC-PLAIN-007 | TC-TECH-013..015 | AC-05-FUN-04 | | URS-05-DATA-001 | — | TC-TECH-022 | — | | URS-05-DATA-002 | — | TC-TECH-022 | — | | URS-05-DATA-003 | — | TC-TECH-021 | AC-05-DI-01 | | URS-05-SEC-001 | — | TC-TECH-022, TC-TECH-023 | AC-05-SEC-01 | | URS-05-SEC-002 | — | (MFA step-up test) | — | | URS-05-SEC-003 | — | (self-modification test) | AC-05-PERM-02 | | URS-05-SEC-004 | TC-PLAIN-008 | TC-TECH-016 | AC-05-PERM-02 | | URS-05-AUD-001 | — | TC-TECH-022, TC-TECH-024 | AC-05-AUD-01 | | URS-05-AUD-002 | — | TC-TECH-022 | — | | URS-05-AUD-003 | — | TC-TECH-022 | — | | URS-05-AUD-004 | — | (writer-presence test) | — | | URS-05-AUD-005 | — | TC-TECH-021 | AC-05-DI-01, AC-05-DI-02 | | URS-05-AI-001 | — | (static analysis) | AC-05-AI-01 | | URS-05-AI-002 | — | TC-TECH-020 | AC-05-AI-02 | | URS-05-INT-001 | — | TC-TECH-001, TC-TECH-019 | AC-05-INT-01 | | URS-05-INT-002 | TC-PLAIN-002 | TC-TECH-007, TC-TECH-008 | AC-05-INT-01 | | URS-05-INT-003 | — | TC-TECH-003 | AC-05-DI-02 | | URS-05-INT-004 | TC-PLAIN-011 | TC-TECH-018 | AC-05-INT-02 | | URS-05-INT-005 | — | TC-TECH-022 | AC-05-AUD-01 | | URS-05-REP-001 | — | (export test) | AC-05-REP-01 | | URS-05-REP-002 | — | TC-TECH-021 | AC-05-DI-01 | | URS-05-REP-003 | — | (TTL test) | — | | URS-05-NOTIF-001 | — | (notification delivery test) | — | | URS-05-NOTIF-002 | TC-PLAIN-007 | (Founder notification test) | — | | URS-05-VAL-001 | — | TC-TECH-022 | — | | URS-05-VAL-002 | All applicable | All applicable | All applicable | | URS-05-VAL-003 | All applicable | All applicable | All applicable | | URS-05-VAL-004 | — | full TC-TECH suite | — | | URS-05-VAL-005 | — | this table is the seed | — | | URS-05-VAL-006 | — | (supplier qualification) | — | | URS-05-VAL-007 | — | (evidence index) | — | | URS-05-VAL-008 | — | TC-TECH-022 | AC-05-MIG-01, AC-05-MIG-02 | | URS-05-BE-021 (lifecycle_state CHECK) | TC-PLAIN-010 | TC-TECH-040 | AC-05-DI-01 | | URS-05-BE-022 (per-state nullability for sod_exceptions / periodic review rows) | TC-PLAIN-007, TC-PLAIN-008 | TC-TECH-013, TC-TECH-014, TC-TECH-016 | AC-05-FUN-04 | | BR-05-24 (delegate qualification two-checkpoint) | TC-PLAIN-002, TC-PLAIN-005 | TC-TECH-035, TC-TECH-036, TC-TECH-037 | AC-05-FUN-02 | | BR-05-25 (wildcard scope QA+RA approval) | — | TC-TECH-038 | — | | `DELEGATION_ACTIVE` audit event | TC-PLAIN-003 | TC-TECH-031 | — | | `DELEGATION_EXPIRED_UNACKNOWLEDGED` audit event | — | TC-TECH-032 | — | | `DELEGATION_AUTO_EXPIRED_NO_REVIEW` and `SOD_EXCEPTION_AUTO_EXPIRED_NO_REVIEW` audit events | TC-PLAIN-008 | TC-TECH-033 | — | | `SELF_MODIFICATION_FORBIDDEN` error and `SELF_MODIFICATION_DENIED` audit | — | TC-TECH-034 | AC-05-PERM-02 | | Tier 1 / Tier 2 partial-unique-index behaviour | — | TC-TECH-039 | — | --- ## 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 `authority_profile_catalogue` (Tier 1) and `sod_rules` (Tier 1); resolver dry-run script | | Functional specification | Matches §6 of this document | | Design specification | Matches §6.1–§6.4 | | Test protocols | IQ (schema, RLS, indexes, hash-chain bootstrap, Tier 1 catalogue + SoD seed); OQ per URS-05-VAL-002; PQ per URS-05-VAL-003; regression per URS-05-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 5 expected state | | Periodic review | Annual review per EU GMP Annex 11 §11; trigger reviews on every Class 1 / Class 2 change | | Data migration evidence | Backfill of catalogue genesis hashes; backfill of resolver-audit-log retention; chain integrity verifier validates against migrated state | ### 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 | | Qualification register provider (URS-28) | Right-to-audit; data residency alignment | | Backup and restore provider | Restore drill preserving catalogue + 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 | |---|---|---|---|---|---| | Authority Profile catalogue versions | Platform / QA | `authority_profile_versions` (hash-chained) | retain history | URS-05-BE-004 | demonstrate authority-of-record baseline | | Authority Profile assignments | QA | `authority_profile_assignments` + audit | seven years post-revocation | URS-05-BE-005 | demonstrate authority of record per holder | | Approval delegations | QA | `authority_profile_delegations` + audit | seven years post-expiry | URS-05-WF-002 | demonstrate authority transfer events | | SoD rule versions | QA | `sod_rule_versions` (hash-chained) | retain history | URS-05-BE-018 | demonstrate SoD baseline | | SoD exceptions | QA / Founder | `sod_exceptions` + dual signatures + executive authority notifications | seven years post-expiry | URS-05-BE-009 | demonstrate break-glass exception governance | | Periodic-access-review attestation packs | QA / IS | `periodic_access_reviews` + rows + electronic signatures | seven years | URS-05-WF-003 | demonstrate periodic review | | Snapshot rows (per regulated decision) | QA / IS | `approval_authority_snapshots` (hash-chained; URS-04 / URS-06 owned write path) | twenty-five years | URS-05-BE-003, URS-05-BE-016 | demonstrate authority of record at decision time | | Resolver verdict trail (forensic) | IS | `resolver_audit_log` (PII-stripped) | thirteen months hot; archive per URS-35 | URS-05-AUD-005 | demonstrate resolver determinism | | Validation evidence pack (IQ / OQ / PQ) | Validation | testing system of record | retain per release | URS-05-VAL-001..008 | release approval | | Release approval (electronically signed) | Founder, QA, RA, Validation, Information Security | document control (URS-12) | retain per release | URS-05-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 5 internal open questions remain. | Closed decision | Spec reference | |---|---| | Two-tier Authority Profile architecture | DEC-05-01 | | Authority Profile schema field set | DEC-05-02 | | Scope dimension launch set | DEC-05-03 | | Assignment ceremony, scope binding, qualification linkage | DEC-05-04 | | Assignment revocation cascade rules | DEC-05-05 | | Delegation duration cap, acknowledgement, chain depth | DEC-05-06 | | Delegation eligibility flag and Tier 1 non-delegable list | DEC-05-07 | | Tier 1 SoD rule launch set | DEC-05-08 | | SoD exception dual-sign, ≥100-char meaning, ≤14-day window, executive authority oversight | DEC-05-09 | | Resolver four-step ordering | DEC-05-10 | | Catalogue-version immutability and pinning | DEC-05-11 | | Periodic-access-review cadence | DEC-05-12 | | Inactive-holder threshold and informational-only nature | DEC-05-13 | | Already-signed evidence preservation through revocation / expiry | DEC-05-14 | | Catalogue-version pinning per assignment | DEC-05-15 | | Qualification-evidence linkage | DEC-05-16 | | Atomic snapshot + e-signature write path | DEC-05-17 | ### 18.2 Dependencies | ID | Dependency | Source | Impact | Blocking? | Mitigation | |---|---|---|---|---|---| | DEP-05-01 | URS-01 authentication, MFA step-up, account-deactivation cascade | URS-01 | Substrate + cascade | Blocking | none | | DEP-05-02 | URS-02 base roles and effective permissions | URS-02 | Resolver Tier-2 eligibility | Blocking | none | | DEP-05-03 | URS-03 active scope | URS-03 | Resolver step 2 | Blocking | none | | DEP-05-04 | URS-04 workflow runtime, HITL, Controlled Approval Modal, e-sig ceremony, hash-chained snapshot write | URS-04 | Snapshot persistence | Blocking | none | | DEP-05-05 | URS-06 audit substrate | URS-06 | Audit ingest | Blocking | none | | DEP-05-06 | URS-08 active-tenant gate and tenant data residency | URS-08 | Lifecycle | Blocking | none | | DEP-05-07 | URS-28 qualification register (Training Management & Qualification) | URS-28 | Resolver step 4 | Blocking | none | | DEP-05-08 | URS-30 notification delivery service | URS-30 | Notifications | Non-blocking | direct e-mail fallback | | DEP-05-09 | URS-35 backup / restore preserves 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 | | Resolver semantics complete? | Yes | §6.4 | | Business rules complete? | Yes | §6.5 | | Audit trail complete? | Yes | §6.6, BR-05-23, URS-05-AUD-001..005 | | AI / Human-in-the-Loop complete? | Yes (no AI) | §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-05-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-05-VAL-008 (Migration Evidence Gate) and the §17 validation evidence pack are satisfied. **No Module 5 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, resolver semantics, audit, security, integration, and the qualification linkage 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 Tier 1 catalogue and SoD launch set are 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-05-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-05-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 — Resolver Pipeline Composite ```mermaid flowchart TD A([URS-04 invokes Module 5 resolver at HITL submit]) --> B[resolveApprovalCandidates / validateApprovalAction] B --> C[Step 1 Eligibility direct assignment] B --> CB[Step 1b Eligibility via active acknowledged delegation] C --> U[Union eligibility candidate pool path = direct or via_delegation] CB --> U U --> E[Step 2 Scope match relevant scope intersect URS-03 active scope] E --> F[Step 3 SoD evaluation Tier 1 + Tier 2 + active exceptions] F --> G{SoD passes / excepted / fails} G -- fails --> X1[allowed=false reason SOD_RULE_VIOLATION] G -- passes / excepted --> H[Step 4 Qualification re-check via URS-28 for the holder of record actor or delegate] H --> I{Qualifications in force?} I -- no --> X2[allowed=false reason QUALIFICATION_EVIDENCE_EXPIRED] I -- yes --> J[Step 5 Snapshot composition tags via_delegation sod_exception override] J --> K[URS-04 esigService.createSignature] K --> L[Module 5 snapshotApprovalAuthority] L --> M[atomic write: electronic_signatures + approval_authority_snapshots + hitl_decision_signatures slot] M --> N[URS-04 adapter applies state transition] N --> O[URS-06 audit + URS-30 notifications] O --> P[HTTP 200 to UI] ``` — End of Module 5 User Requirements Specification —