# Verixa — User Requirements Specification # Module 7: Study Management | Field | Value | |---|---| | Document ID | VRX-URS-07 | | 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-07-VAL-008) and validation evidence pack are satisfied. | | Document Type | User Requirements Specification (URS) | | GAMP 5 Category | Category 5 — Custom Application | | Regulatory Classification | Domain operations substrate — operates the study catalogue, the study lifecycle, the study membership and role overlay, the study-scope binding consumed by URS-03, the study amendment lifecycle, the cross-tenant sponsor / contract-research-organisation collaboration model, study-bound document linkage to URS-12, and the close-out / archival path. Module 7 is the canonical scoping anchor for every regulated record that is part of a study (validation, stability, method validation, cleaning validation, equipment qualification, process validation, manufacturing campaign, audit study, and — in forward roadmap — clinical Phase I-III studies). | | Date of Issue | 2026-05-06 | | Module Owner (Engineering) | Study / Domain Operations Squad | | Module Owner (Quality Validation) | CSV / CSA Lead — Study Management | | Module Owner (Compliance) | Quality Assurance, Regulatory Affairs, Clinical Operations (where applicable) | | 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 7. | --- ## 0. Document Framing ### 0.1 Purpose of this document This URS defines the target expected state for Verixa's Study Management module (Module 7). 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 study catalogue, the study lifecycle, the study membership and role overlay, the study-scope binding consumed by URS-03 active scope, the study amendment lifecycle and protocol-version control, the cross-tenant sponsor / contract-research-organisation (CRO) collaboration model, the study-bound document linkage to URS-12 controlled documents (TMF / PMF / VMF), the close-out / archival path, and the study-bound regulated-entity discovery surface that maps to every consuming domain module URS-12 through URS-34. Compliance with this URS is mandatory. ### 0.2 Audience Engineering, QA, Validation, Regulatory Affairs, Clinical Operations (where clinical studies are in the tenant's posture), Information Security, executive authority, the platform's 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.4) and worked examples (§3.5) make Module 7 accessible to non-domain engineers, product owners, validation engineers, and clinical operations leads who have not previously specified study-management substrates 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 A **study** is a controlled investigation with a defined start, defined scope, defined deliverables, and a closed-out final state — for example a stability study that monitors how a drug product degrades over 24 months, a process validation study that demonstrates a manufacturing process consistently produces material meeting specification, an equipment qualification study that proves a piece of equipment operates as intended at installation / operation / performance qualification stages, or (where in scope) a clinical study that evaluates safety and efficacy in humans. Every regulated industry has its own study types, its own protocol templates, its own regulatory framework, and its own document master file (TMF for Trial Master File in clinical; PMF for Product Master File in manufacturing; VMF for Validation Master File in validation). Module 7 owns the platform substrate that lets a tenant model any of these as a first-class object. A study has three components: **identity** (a unique identifier, a title, a regulatory classification, a sponsor and one or more participating organisations), **scope** (which sites, products, suppliers, jurisdictions, and dates the study covers), and **lifecycle** (draft → in setup → active → optionally on hold → closed → archived). Module 7 owns all three. The study scope is not just descriptive metadata. It is **operational**: it tells URS-03 which records are part of the study at any given time, it tells URS-04 which workflows fire on those records, it tells URS-05 which Authority Profile assignments are in scope, and it tells URS-12 which documents belong to the study's master file. A deviation that occurs at a site that is in scope of a stability study is automatically discoverable through the study record without the user manually labelling the deviation; a CAPA that addresses a process validation finding inherits the study scope through the workflow that opened it. This is what makes the platform **study-aware** rather than just record-aware. A study has **members**. Study membership is a role overlay on top of the tenant base roles (URS-02): a user who is `quality_lead` at the tenant level may also be `study_lead` for stability study STB-2026-0044, with study-specific responsibilities and accountabilities. Membership grants access to the study record and inherited access to study-bound regulated records subject to URS-03 active-scope intersection and URS-05 authority resolution. A user who is not a study member cannot see the study's draft documents or in-progress findings even if they hold a tenant-level role that would otherwise grant them visibility. This is **study-level confidentiality**, which is essential for studies that contain pre-publication or competitively sensitive content. A study can be **single-tenant** (a tenant runs the study using its own users) or **cross-tenant** (typically a sponsor-CRO model where the sponsor commissions a contract research organisation to execute the study). Cross-tenant studies use the **collaboration model** in DEC-07-04: a lead tenant invites a partner tenant; both sides electronically sign the collaboration grant; specific users from each side are added as study members; access is enforced through Module 7's study-level access overlay plus URS-03 cross-tenant active-scope rules. Module 7 is the only Verixa module that supports cross-tenant data visibility, and it is strictly opt-in on both sides. A study is amended through **controlled amendments**. A protocol change creates an amendment record with rationale, scope of change, regulatory impact assessment, and a versioned protocol document; the amendment is reviewed and electronically signed before becoming effective. The original protocol version is preserved as the historical record; subsequent in-flight study activities reference the amended version from the effective date. A study is **closed** when its deliverables are complete (final report signed, all findings closed or accepted, all documents in TMF / PMF / VMF, regulatory submissions filed where applicable). After close-out the study moves to **archived** state; archived studies remain query-accessible for inspection / litigation / future-study reference for the configured retention period (typically the longer of regulatory minimum and the tenant's retention policy — for stability studies often 1 year past expiry; for clinical Phase III often the longer of 25 years and the regulatory framework's requirement; for validation studies typically 10-15 years). ### 0.5 Study lifecycle diagram ```mermaid stateDiagram-v2 [*] --> draft : Tenant administrator creates study draft --> in_setup : Study lead submits draft for setup in_setup --> active : Study activation electronic signature (executive authority for high-risk types) active --> on_hold : Controlled hold with reason and Founder notification on_hold --> active : Hold released with reason and electronic signature active --> closed : Close-out package signed; final report archived closed --> archived : Auto-transition after configured close-to-archive window archived --> [*] draft --> withdrawn : Withdrawn before activation (no archival; soft-deleted) withdrawn --> [*] ``` Diagram 0.5-A — Study lifecycle states. Activation requires electronic signature plus, for high-risk study types (e.g., process validation that gates batch release; clinical studies under the forward roadmap), executive authority co-sign. Withdrawal is permitted only before activation. Once active, the study can only progress to closed; it cannot revert to draft. Closed studies auto-transition to archived after a configured window (default 90 days) to allow late deliverables to land in the close-out package. ### 0.6 Glossary of key terms used in this document | Term | Definition | |---|---| | Amendment | A controlled change to an active study's protocol, scope, members, or deliverables, with rationale, regulatory impact assessment, electronic signature, and versioned protocol document. | | Archived | Terminal lifecycle state of a closed study; the study record and all linked artifacts remain query-accessible for inspection / litigation / future-study reference for the configured retention period. | | Close-out package | The set of artifacts that completes a study: final report, list of resolved and accepted findings, list of TMF / PMF / VMF documents, regulatory submission references where applicable, signed close-out attestation. | | Collaboration grant | The electronically signed mutual authorisation between a lead tenant and a partner tenant that opens a cross-tenant study. Both sides sign; either side can revoke. | | Cross-tenant study | A study whose members include users from more than one tenant, typically a sponsor and one or more CROs. Operated through Module 7's collaboration grant. | | Lead tenant | The tenant that owns the study record and the regulatory accountability; in sponsor-CRO models the sponsor is typically the lead tenant. | | Master file | The aggregated controlled-document set for a study: TMF (Trial Master File) for clinical studies, PMF (Product Master File) for manufacturing campaigns, VMF (Validation Master File) for validation studies. URS-12 owns the documents; Module 7 owns the linkage. | | Partner tenant | A tenant invited into a cross-tenant study by the lead tenant; typically a CRO or co-sponsor. | | Protocol | The document that defines the study's objectives, design, methodology, statistical considerations, and conduct. Version-controlled; amendments produce new protocol versions. | | Regulatory framework | The applicable regulatory regime for the study type and jurisdictions selected at study creation: ICH GCP for clinical, ICH Q1 for stability, GAMP 5 / ICH Q9 / Q10 for validation, GLP for non-clinical, etc. The framework drives downstream document requirements, audit cadence, and inspection readiness. | | Study | A controlled investigation with defined identity, scope, lifecycle, deliverables, and regulatory framework. The first-class object owned by Module 7. | | Study-bound regulated record | Any regulated record whose active scope (URS-03) intersects the study's scope; discoverable from the study without manual labelling. | | Study lead | The named accountable user for the study, with study-level authority to approve members, amendments, hold / release, and close-out. | | Study member | A user with a study-level role overlay (lead, coordinator, reviewer, member, observer); only members can see study-confidential content. | | Study scope | The set of sites, products, suppliers, jurisdictions, business units, and date range covered by the study; binds at activation; can change only through amendment. | ### 0.7 Module 7 architectural picture ```mermaid graph LR subgraph M7 [Module 7 — Study Management] CAT[Study Catalogue] LCY[Study Lifecycle] MEM[Study Membership] SCP[Study Scope Binding] AMD[Amendment Lifecycle] COLL[Cross-Tenant Collaboration] CLO[Close-Out and Archival] DOC[Master File Linkage] end M1[URS-01 Auth] --> MEM M2[URS-02 RBAC] --> MEM M3[URS-03 Active Scope] <--> SCP M4[URS-04 Workflow / E-Sign] --> LCY M4 --> AMD M5[URS-05 Authority] --> LCY M6[URS-06 Audit Substrate] --> LCY M8[URS-08 Tenant] --> COLL M12[URS-12 Document Control] <--> DOC M28[URS-28 Training] --> MEM M30[URS-30 Notifications] --> LCY M30 --> AMD CAT --> M14[URS-14..URS-34 Domain modules] SCP --> M3 ``` Diagram 0.7-A — Module 7 sits between the access-control / workflow / authority modules and the regulated-domain modules. The study catalogue and scope binding feed URS-03 active-scope computation, which in turn drives URS-04 workflow firing and URS-05 authority resolution for every study-bound regulated record. URS-12 owns the controlled documents that compose the master file; Module 7 owns the linkage. URS-28 owns qualification / training records; Module 7 enforces that members hold the study-required qualifications. URS-08 owns tenant lifecycle; Module 7's cross-tenant collaboration grant requires both tenants to be in valid lifecycle state. --- ## 1. Module Purpose Module 7 establishes Study Management as a first-class operational domain in Verixa. It owns the study catalogue, the study lifecycle state machine, the study membership and role overlay, the study-scope binding consumed by URS-03 active scope, the study amendment lifecycle with protocol-version control, the cross-tenant sponsor / CRO collaboration model, the master-file linkage to URS-12 controlled documents, the close-out / archival path, and the study-bound regulated-entity discovery surface. Module 7 is consumed by every regulated domain module (URS-12 through URS-34) that records activity within a study; consumed by URS-03 to compute active scope intersection; consumed by URS-04 to fire study-aware workflows; consumed by URS-05 to apply study-level Authority Profile overlays; and consumed by URS-06 to attribute audit rows to study scope. Module 7 is the anchor for the **study-aware platform** — the property that makes Verixa fit for regulated investigations rather than just regulated records. Without Module 7 there is no regulatory framework selection, no protocol versioning, no cross-tenant collaboration, no master-file aggregation, no close-out attestation, and no study-bound discovery — and consequently no platform-level support for stability, validation, qualification, manufacturing-campaign, audit, and (forward-roadmap) clinical workflows. --- ## 2. Scope ### 2.1 In scope - The study catalogue: per-tenant registry of every study with `id`, `title`, `study_type`, `regulatory_framework_jsonb`, `sponsor_tenant_id`, `partner_tenant_ids[]` (for cross-tenant), `lead_user_id`, `lifecycle_state`, `protocol_version_id` (current), `scope_jsonb` (consumed by URS-03), `created_by`, `created_at`, `closed_at` (nullable), `archived_at` (nullable), `retention_class`. - Study types at launch (DEC-07-01): `validation` (CSV / CSA), `stability` (ICH Q1), `method_validation`, `cleaning_validation`, `equipment_qualification` (IQ / OQ / PQ), `process_validation` (PPQ stages), `audit_study` (mock inspection / internal audit campaign), `manufacturing_campaign`, `bioequivalence`, plus `clinical_phase_1`, `clinical_phase_2`, `clinical_phase_3` enabled forward-roadmap with explicit Founder activation gate per tenant. - The study lifecycle state machine (DEC-07-02): `draft` → `in_setup` → `active` → `on_hold` (optional) → `closed` → `archived`, with `withdrawn` permitted only from `draft` / `in_setup`. - Study activation electronic signature, with executive authority co-sign for high-risk study types (process validation gating batch release, clinical studies, manufacturing campaigns of newly licensed products) per DEC-07-03. - Study membership and role overlay (DEC-07-04): roles `study_lead`, `study_coordinator`, `study_reviewer`, `study_member`, `study_observer`; sponsor-side and CRO-side discriminators for cross-tenant studies; member-level access overlay enforced on top of URS-02 base roles and URS-05 Authority Profile assignments. - Member qualification gating: members joining studies whose regulatory framework requires named qualifications (e.g., GCP training for clinical, GAMP-5 awareness for validation) MUST have linked URS-28 qualification evidence at member creation time and at every active-scope decision time. - Study scope binding (DEC-07-05): scope JSONB keyed by the canonical authority scope dimension registry from URS-05 §6.2.1 (`site`, `product`, `product_family`, `study`, `supplier`, `jurisdiction`, `business_unit`, `module`, `entity_type`, `workflow_type`); scope is bound at activation and can change only through amendment (DEC-07-06). - Study amendment lifecycle (DEC-07-06): per-amendment record with rationale, scope of change, regulatory impact assessment (`substantial` / `non_substantial` / `administrative` per ICH E6(R3) §3.10), versioned protocol document linked to URS-12, electronic signature plus regulatory-affairs co-sign for `substantial` amendments, propagation rules for in-flight regulated records. - Cross-tenant sponsor / CRO collaboration (DEC-07-07): collaboration grant requires both lead-tenant and partner-tenant electronic signatures; per-grant scope and member roster; either side MAY revoke with notification; cross-tenant access enforced through URS-03 cross-tenant active-scope rules and URS-06 audit substrate that emits `CROSS_TENANT_STUDY_ACCESS_USED` per access. - Master-file linkage (DEC-07-08): every study has exactly one master file (TMF / PMF / VMF / generic per study type); URS-12 owns the controlled documents; Module 7 owns the linkage table that asserts which URS-12 documents belong to which study and which version of the protocol. - Close-out and archival path (DEC-07-09): close-out package composition (final report + resolved-findings list + master-file completeness check + regulatory-submission references); close-out electronic signature; auto-transition to archived after configurable window (default 90 days); per-study retention class drives URS-06 retention policy and URS-35 archive duration. - Study-bound regulated-entity discovery (DEC-07-10): for every study, the platform computes the set of regulated records whose active scope (URS-03) intersects the study scope at any point in the study's active window; this is the source of truth for "what records are part of this study" without requiring manual labelling on the consuming records. - Per-jurisdiction regulatory framework selection (DEC-07-11): study creation captures a structured `regulatory_framework_jsonb` enumerating which regulations apply (ICH GCP E6(R3), 21 CFR Part 50/56/312, EU CTR 536/2014, ICH Q1A(R2), 21 CFR Part 211, 21 CFR Part 58, OECD GLP, ICH Q9 / Q10, GAMP 5, etc.); the framework drives downstream master-file requirements and audit cadence. - Study calendar and milestones: per-study milestones with dates, owners, completion attestations; reminder schedule per URS-30. - Reports and dashboards: per-study dashboard, cross-study portfolio view, sponsor-CRO collaboration register, amendment register, member register with qualification status, study-bound regulated-record discovery view. - Front-end: study catalogue browser, study detail view (overview / members / scope / amendments / master file / regulated records / calendar / close-out), study creation wizard, amendment authoring surface, collaboration invitation surface. - Cross-module wiring: URS-03 consumes study scope; URS-04 fires study-aware workflows on study activation / amendment / close-out; URS-05 applies study-member overlays; URS-06 audits every Module 7 lifecycle event; URS-12 owns the controlled documents linked to the master file; URS-28 owns the qualification evidence required for study members; URS-30 delivers notifications; URS-08 owns tenant lifecycle which gates cross-tenant collaboration; URS-35 owns the long-term archive. ### 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 resolution and approval-scope check (URS-03; Module 7 provides the study-scope input). - Workflow templates, runtime, e-signature ceremony, HITL lifecycle (URS-04). - Authority Profile catalogue, assignments, delegations, SoD (URS-05; Module 7 layers a study-level overlay). - Audit substrate (URS-06; Module 7 is a consumer through `appendAuditRow`). - Tenant lifecycle (URS-08; Module 7's collaboration grant requires both tenants to be in valid state). - Site / product / supplier master data (URS-09 / URS-10 / URS-11). - Document control implementation — version, approval, retire (URS-12; Module 7 owns the linkage to controlled documents but not the documents themselves). - The qualification register (URS-28; Module 7 enforces qualification linkage at member creation but does not own the records). - Domain-specific record semantics (every domain module owns its own state model; Module 7 is study-bound discovery, not record content). - AI-driven decision-making (explicitly prohibited; AI suggestion paths in MIRA / URS-32 are advisory only). ### 2.3 Closed launch decisions | Identifier | Closed launch decision | |---|---| | DEC-07-01 | Study types at launch are exactly: `validation` (CSV / CSA), `stability` (ICH Q1), `method_validation`, `cleaning_validation`, `equipment_qualification`, `process_validation`, `audit_study`, `manufacturing_campaign`, `bioequivalence`. Three additional types are present in the type registry but **gated for forward roadmap activation per tenant** with explicit Founder approval: `clinical_phase_1`, `clinical_phase_2`, `clinical_phase_3`. Adding a new type to the registry is a Class 1 change. Activating a clinical type for a tenant requires Founder electronic signature, the tenant's documented GCP-readiness pack, and tenant-level supplemental contract terms. | | DEC-07-02 | Study lifecycle states are fixed at six values: `draft`, `in_setup`, `active`, `on_hold`, `closed`, `archived`, plus the terminal pre-activation `withdrawn`. Allowed transitions are: `draft → in_setup → active → on_hold ↔ active → closed → archived`; `draft / in_setup → withdrawn` (terminal). All other transitions are forbidden. `closed → archived` is automatic after the configurable close-to-archive window; `archived → active` is forbidden (a re-opened study creates a new study record referencing the archived predecessor). | | DEC-07-03 | Study activation requires an electronic signature from the study lead (URS-04 Controlled Approval Modal). For high-risk study types (`process_validation` whose scope includes batch release, `manufacturing_campaign` for newly licensed products, all clinical types when activated), executive authority co-sign is mandatory at activation. The high-risk-list is enumerated and tenant-extendable (tenants MAY add types to the high-risk list, never remove). Multi-factor step-up is required for every activation signature. | | DEC-07-04 | Study membership roles at launch are: `study_lead` (one per study; the named accountable user), `study_coordinator` (operational coordinator; multiple permitted), `study_reviewer` (review and approval within the study; multiple permitted), `study_member` (regular contributor), `study_observer` (read-only). Each role applies as an overlay on top of URS-02 base roles. For cross-tenant studies, every member carries a `tenant_side` discriminator (`sponsor` or `cro` or named partner). Adding a role is a Class 1 change. | | DEC-07-05 | Study scope is bound at activation through `scope_jsonb` keyed by the canonical authority scope dimension registry from URS-05 §6.2.1. The scope MUST include at minimum a `study` key populated with the study's own identifier (so URS-03 can intersect it), plus zero or more of `site`, `product`, `product_family`, `supplier`, `jurisdiction`, `business_unit`, `module`, `entity_type`, `workflow_type`, plus an explicit date range (`scope_effective_from`, `scope_effective_to`) bounding the study's active window. Scope is **immutable from activation to close-out except through controlled amendment** (DEC-07-06). | | DEC-07-06 | Study amendments are per-amendment records with `rationale` (≥ 60 chars), `scope_of_change` (`scope_addition` / `scope_removal` / `scope_modification` / `members_change` / `protocol_text_change` / `milestone_change` / `regulatory_framework_change`), `regulatory_impact_classification` (`substantial` / `non_substantial` / `administrative` per ICH E6(R3) §3.10 for clinical and the equivalent classification for non-clinical), `versioned_protocol_document_id` linked to URS-12 (every protocol-text-change amendment produces a new protocol version), `effective_from` (≥ amendment-signature date), and electronic signatures: study lead always; regulatory-affairs co-sign mandatory for `substantial` amendments; executive authority co-sign mandatory for amendments that change the regulatory-framework selection. Amendments propagate to in-flight regulated records by activating the new scope from `effective_from` onward; in-flight records reference the protocol version effective at the time of the regulated decision (snapshot pinning). | | DEC-07-07 | Cross-tenant study collaboration is opt-in and bilateral. The lead tenant invites a partner tenant through the collaboration-grant API; the partner tenant administrator electronically signs the grant; only after both signatures is the collaboration active. The grant carries the study identifier, the partner tenant's per-grant scope (which subset of the study's scope the partner is authorised to see), the per-grant member roster (named users on each side), and the effective-from / effective-to dates. Either side MAY revoke the grant with electronic signature and reason; revocation immediately removes the partner tenant's access and emits `CROSS_TENANT_COLLABORATION_REVOKED` in both tenants' audit chains. URS-06 audits every cross-tenant access as `CROSS_TENANT_STUDY_ACCESS_USED`. | | DEC-07-08 | Every study has exactly one master file; the master-file type is determined by study type (`TMF` for clinical types, `PMF` for `manufacturing_campaign`, `VMF` for validation / qualification / method-validation / cleaning-validation types, `SMF` "study master file" generic for stability / bioequivalence / audit study). URS-12 owns the controlled documents; Module 7 owns the linkage table `study_master_file_documents` that asserts which URS-12 documents belong to the study at which protocol version. The launch master-file completeness checklist per type is published in the regulatory framework registry (DEC-07-11). | | DEC-07-09 | Study close-out requires: (a) a final-report document linked to the master file, (b) every active finding from study-bound regulated records is either closed or formally accepted (with electronic signature from study lead and quality lead), (c) the master-file completeness check passes, (d) regulatory submission references are recorded where applicable (e.g., a stability study's CTD §3.2.P.8 reference). Close-out is electronically signed by the study lead plus quality lead. Auto-transition to archived occurs after the configurable close-to-archive window (default 90 days; tenant-configurable upward only — never below 90 days). | | DEC-07-10 | Study-bound regulated-entity discovery is computed by intersecting the study's `scope_jsonb` (per DEC-07-05) with the active scope of every regulated record per URS-03 §6.4.1 over the study's `scope_effective_from` to `scope_effective_to` window. The discovery surface is read-only — it does not assign records to studies; it reports what records the platform observed during the study's active window with overlapping scope. Manual record-to-study labelling is also supported for edge cases through an `audit-trailed annotation`, but the canonical answer is the scope intersection. | | DEC-07-11 | Per-jurisdiction regulatory framework selection at study creation captures `regulatory_framework_jsonb` enumerating applicable regulations from a platform-managed registry: at minimum the predicate rule (e.g., `21_cfr_part_211`, `eu_gmp`, `ich_gcp_e6r3`, `21_cfr_part_312`, `eu_ctr_536_2014`, `ich_q1ar2`, `21_cfr_part_58_glp`, `oecd_glp`, `gamp_5`, `ich_q9`, `ich_q10`); the framework drives downstream master-file requirements (DEC-07-08), audit cadence (URS-12 / URS-22), and inspection readiness deliverables. Adding a regulation to the registry is a Class 2 change; changing the per-tenant default framework set is a tenant-administrator action with electronic signature. | | DEC-07-12 | Study members whose role within the study is gating regulated decisions (`study_lead`, `study_reviewer`) MUST have linked URS-28 qualification evidence at the time of member assignment and at every regulated-decision time. Required qualifications are derived from the study's regulatory framework registry — for example, `ich_gcp_e6r3` requires GCP training in URS-28; `gamp_5` requires GAMP-5 awareness training; `21_cfr_part_211` requires GMP training. Missing or expired qualification at member creation returns `STUDY_MEMBER_QUALIFICATION_MISSING`; expired between membership and decision returns `QUALIFICATION_EVIDENCE_EXPIRED` per URS-05 BR-05-24. | | DEC-07-13 | Study close-out and archival do not delete the study record or its linked artifacts. Archived studies remain query-accessible; URS-06 audit chain entries referencing the study remain in their original chains; URS-12 documents linked to the master file remain in their original retention; URS-35 owns the cold-archive class. The study record's retention defaults match the study type's regulatory framework requirement: clinical Phase III defaults to 25 years; validation studies default to 15 years; stability studies default to 1 year past expiry plus 5 years. Tenants MAY extend retention; they MAY NEVER reduce it. | | DEC-07-14 | Manual record-to-study labelling (the edge-case override path per DEC-07-10) is itself electronically signed and audited as `STUDY_RECORD_MANUAL_LABEL_APPENDED` with the rationale; it appears in the study-bound discovery surface visually distinguished from the canonical scope-intersection result so an inspector can immediately identify which records are part of the study by automatic computation versus by manual annotation. Manual labels never override scope-intersection exclusion — a record outside the scope cannot be brought into the study by manual label; it can only be annotated as related-but-out-of-scope. | | DEC-07-15 | Study amendments preserve the immutability of the historical record. The pre-amendment protocol version, scope, and member roster remain queryable; in-flight regulated decisions reference the protocol version effective at the time of the decision (pinned in the URS-05 authority snapshot per URS-05 DEC-05-15 catalogue-version pinning principle, applied here to protocol version). A subsequent amendment does not retroactively alter prior decisions. | | DEC-07-16 | Cross-tenant collaboration grants do NOT confer write access to the partner tenant's data. The partner tenant gains read access scoped to the per-grant scope, plus the right to contribute new records that are within the per-grant scope (e.g., a CRO contributing source data within the agreed sites and date range). Cross-tenant write access is governed by URS-05 Authority Profile assignments that the lead tenant explicitly grants to named partner-tenant users for the duration of the study; revocation of the collaboration grant cascades to revocation of those Authority Profile assignments per URS-05 BR-05-15 (account-deactivation cascade) extended to "study-collaboration-revocation cascade". | | DEC-07-17 | The launch posture explicitly enables non-clinical study types (validation, stability, method validation, cleaning validation, equipment qualification, process validation, audit study, manufacturing campaign, bioequivalence). Clinical types (`clinical_phase_1` / `2` / `3`) are present in the type registry but are **disabled by default at the platform tenant onboarding** and require Founder electronic signature plus tenant supplemental contract terms to enable. The disabled-by-default posture is a deliberate Phase 1 launch decision to avoid clinical-trial regulatory exposure (21 CFR Part 312 IND, EU CTR 536/2014, ICH GCP E6(R3) full applicability) until the tenant's GCP-readiness is documented. | --- ## 3. User Roles and Permissions ### 3.1 Architecture Module 7 consumes Layer 1 (base role) and Layer 2 (permission matrix) from URS-02; consumes the Authority Profile catalogue and resolver from URS-05; consumes the active scope from URS-03; consumes the qualification register from URS-28. Module 7 owns three administrative surfaces: (a) the study catalogue and creation wizard, (b) the per-study management surface (members, amendments, master file, calendar, close-out), (c) the cross-tenant collaboration surface. Module 7 owns the **study-level role overlay** that enforces study-confidential access on top of base roles. ### 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. Module 7 introduces five **study-level roles** that overlay the base roles per DEC-07-04: | Study role | Description | Cardinality per study | |---|---|---| | `study_lead` | Named accountable user; approves members, amendments, hold / release, close-out; co-signs activation. | Exactly 1 | | `study_coordinator` | Operational coordinator; manages calendar, milestones, day-to-day activity. | 1 or more | | `study_reviewer` | Reviews and approves within-study deliverables (protocol amendments, milestone completion, finding closure). | 0 or more | | `study_member` | Regular contributor; reads study content; contributes records within scope. | 0 or more | | `study_observer` | Read-only access to non-confidential study content; no contribution rights. | 0 or more | For cross-tenant studies, every member also carries a `tenant_side` discriminator: `sponsor` (lead tenant), `cro` or named partner (partner tenant). The discriminator drives URS-06 cross-tenant access auditing (`CROSS_TENANT_STUDY_ACCESS_USED`) and URS-30 notification routing. ### 3.3 Authority Profiles consumed by Module 7 | Authority Profile (consumed) | Module 7 action gated | |---|---| | `tenant_admin_authority` | Read tenant study catalogue; create studies of any type the tenant has activated; configure tenant defaults for regulatory framework registry. | | `final_quality_approver` | Co-sign close-out for studies whose final deliverables touch product release. | | `regulatory_oversight_admin` | Co-sign `substantial` amendments and regulatory-framework changes. | | `validation_approver` | Co-sign activation for `validation`, `method_validation`, `cleaning_validation`, `equipment_qualification`, `process_validation` study types. | | `clinical_oversight_admin` (Tier 1; gated by clinical-type activation) | Co-sign activation for clinical types; review GCP-readiness pack at clinical activation. | | `cross_tenant_collaboration_authority` | Sign cross-tenant collaboration grants and revocations. | | `global_quality_oversight` | Break-glass for studies whose immediate hold is required to prevent product-quality risk. | ### 3.4 Segregation-of-Duties rules consumed by Module 7 | SoD rule (consumed from URS-05) | Module 7 application | |---|---| | `AUTHOR_NEQ_APPROVER` | The user who created a study cannot also activate it through the activation electronic signature. | | `REVIEWER_NEQ_FINAL_APPROVER` | A `study_reviewer` who reviewed an amendment cannot also sign as the final approver of the same amendment when the workflow node requires both review and final approval. | | `STUDY_LEAD_NEQ_CLOSE_OUT_QUALITY_APPROVER` (Tier 1, study-specific) | The study lead who signs close-out cannot also sign the `final_quality_approver` co-sign on the same close-out package; the two signatures must be from distinct users. | | `CROSS_TENANT_SAME_USER_FORBIDDEN` (Tier 1, study-specific) | A user holding identities at both lead-tenant and partner-tenant sides of a cross-tenant study (uncommon but possible for consultants) cannot sign on both sides for the same regulated decision. | ### 3.5 Worked examples #### Worked example A — Stability study activation QA team at TenantCo opens a stability study for Product X (tablet, 100 mg) per ICH Q1A(R2) requirements: 24-month long-term, 6-month accelerated, three packaging configurations, two sites. The QA Manager (with `tenant_admin_authority`) creates the study record (state `draft`); fills in `regulatory_framework_jsonb = ['ich_q1ar2', '21_cfr_part_211', 'eu_gmp']`; binds scope `{site: ['site-A', 'site-B'], product: ['product-X-uuid'], jurisdiction: ['US', 'EU'], scope_effective_from: '2026-06-01', scope_effective_to: '2028-12-31'}`; assigns the QA Manager as `study_lead`, two QA technicians as `study_coordinator`, the QA Director as `study_reviewer`. URS-28 confirms all four hold ICH Q1 / GMP qualification. The QA Manager submits for setup (state `in_setup`); the QA Director (independent of creator per `AUTHOR_NEQ_APPROVER`) electronically signs activation; state moves to `active`. URS-06 captures `STUDY_CREATED`, `STUDY_SUBMITTED_FOR_SETUP`, `STUDY_ACTIVATED`. The study scope now feeds URS-03 active-scope intersection; any deviation, OOS, or URS-13 event whose record scope intersects `{site: A or B, product: X}` during the active window is automatically discoverable from the study record. #### Worked example B — Cross-tenant sponsor-CRO bioequivalence study SponsorPharma commissions CROServices to run a bioequivalence study comparing their generic to an innovator. SponsorPharma's `tenant_admin_authority` holder opens the study with type `bioequivalence`, scope `{study: 'BE-2026-0014', product: ['generic-X'], comparator: 'innovator-Y', jurisdiction: ['IN'], site: ['cro-site-A']}`, and lists CROServices as the partner tenant in the collaboration grant. CROServices' `tenant_admin_authority` holder receives the invitation through URS-30, opens the cross-tenant surface, electronically signs acceptance. The grant becomes active. SponsorPharma adds three CROServices users (per their tenant-discriminator `cro`) as `study_member` with the appropriate study-level overlay; CROServices adds two SponsorPharma users (per discriminator `sponsor`) as `study_reviewer`. CROServices contributes source data within the agreed sites and date range; SponsorPharma reviews and signs final-report acceptance. URS-06 emits `CROSS_TENANT_STUDY_ACCESS_USED` per access, `STUDY_AMENDMENT_PROPOSED` and `STUDY_AMENDMENT_SIGNED` for the one minor amendment, and `STUDY_CLOSED_OUT` at completion. #### Worked example C — Process validation study with batch-release gating ManufactureCo opens a process validation study (PPQ stages 1-3) for a new product line. The study type is `process_validation`; the regulatory framework is `['21_cfr_part_211', 'eu_gmp', 'ich_q9', 'ich_q10']`. Activation requires executive authority co-sign because the study scope includes batch release. The study lead activates with electronic signature; the executive authority receives the activation request through URS-30, reviews the validation protocol, and co-signs. Three PPQ batches run; each batch is a `manufacturing_campaign` study-bound regulated record. After successful PPQ, the study close-out package includes the validation final report, three batch records, three deviation records (all closed), the validated process description; close-out is signed by the study lead and `final_quality_approver`; the study moves to `closed`; after 90 days the study auto-archives. #### Worked example D — Substantial amendment to an active stability study Three months into the stability study, an unexpected impurity peak appears in the accelerated condition samples. The QA team determines the methodology needs to change to a more sensitive analytical method. This is a `substantial` amendment (per ICH Q1 equivalent classification): the rationale is documented (≥ 60 chars), scope of change is `protocol_text_change`, the new analytical method is documented in URS-12 producing protocol version 2.0, the amendment is electronically signed by the study lead and co-signed by `regulatory_oversight_admin`. From the amendment effective-from date, in-flight stability decisions reference protocol v2.0; the prior decisions remain pinned to protocol v1.0 in their authority snapshots (URS-05 catalogue-version pinning principle). URS-06 emits `STUDY_AMENDMENT_PROPOSED`, `STUDY_AMENDMENT_REVIEW_SIGNED`, `STUDY_AMENDMENT_FINAL_SIGNED`, `STUDY_AMENDMENT_EFFECTIVE`. #### Worked example E — Hold and release for product safety signal During an active manufacturing-campaign study, an environmental-monitoring excursion is detected at one of the sites. The study lead places the study `on_hold` with reason "EM excursion at Site A; investigation pending"; URS-30 notifies all members; cross-tenant partners are notified; pending milestones are paused. The investigation closes; the study lead releases the hold with reason "Investigation closed per CAPA-2026-0145; no impact to study deliverables" and electronic signature; state returns to `active`. URS-06 emits `STUDY_HOLD_PLACED`, `STUDY_HOLD_RELEASED`. #### Worked example F — Study close-out with regulatory submission A bioequivalence study for an Indian generic completes successfully. The close-out package includes: final report, three batches of data, the dissolution profile comparison, the pharmacokinetic results, the statistical analysis. The study lead signs close-out; the QA Director signs as `final_quality_approver`; the regulatory affairs lead provides the CDSCO submission reference. The study moves to `closed`; auto-archives after 90 days; the master file (a generic `SMF`) is permanently linked to the study record; archived state is reached. The CDSCO inspector arrives for audit; they query the platform's study-bound regulated-record discovery surface; the platform returns every record that intersected the study's scope during the active window with verifier-validated audit chain integrity. #### Worked example G — Withdrawn study before activation A QA team starts to draft a method-validation study, gets two days into the setup, and realises the method has been superseded by a corporate decision. The QA Manager withdraws the study (state `withdrawn`); the draft record is soft-deleted with a withdrawal reason and electronic signature; URS-06 captures `STUDY_WITHDRAWN`. The withdrawn study is not visible in the active catalogue but remains query-accessible to auditors for forensic purposes. #### Worked example H — Manual record-to-study label for edge case A deviation that occurred during a process validation study was filed against a generic site scope without specifying the product family; the canonical scope-intersection therefore did not pick it up automatically. The study lead identifies the case, opens the manual-label surface, asserts that the deviation is in fact related-and-in-scope, provides rationale, electronically signs. URS-06 emits `STUDY_RECORD_MANUAL_LABEL_APPENDED`. The discovery surface now shows the deviation under the study with a "manual" badge alongside the automatically discovered records. The deviation is otherwise unchanged and remains in its own domain module's chain. ### 3.6 Role-permission matrix (Module 7 administrative surface only) | Action (within Module 7) | viewer | reviewer | quality_lead | auditor | admin | platform_admin | super_admin | Authority Profile / Study role | |---|:-:|:-:|:-:|:-:|:-:|:-:|:-:|---| | Read study catalogue (own tenant) | — | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | — | | Create study (non-clinical types) | — | — | ✓ + sign | — | ✓ + sign | ✓ + sign | ✓ + sign | `tenant_admin_authority` | | Create study (clinical types) | — | — | — | — | ✓ + sign + executive authority | ✓ + sign + executive authority | ✓ + sign + executive authority | `tenant_admin_authority` + executive authority + `clinical_oversight_admin` | | Submit study for setup | — | — | study_lead | — | study_lead | study_lead | study_lead | `study_lead` | | Activate study (non-high-risk) | — | — | independent of creator + sign | — | independent of creator + sign | — | — | `study_lead` (independent of creator per SoD) | | Activate study (high-risk type per DEC-07-03) | — | — | — | — | — | ✓ + sign + executive authority + MFA | ✓ + sign + executive authority + MFA | `study_lead` + executive authority + `validation_approver` or `clinical_oversight_admin` | | Edit study draft | — | — | study_lead OR study_coordinator | — | study_lead OR study_coordinator | — | — | study-role overlay | | Add / remove study member | — | — | study_lead + sign | — | study_lead + sign | — | — | `study_lead` | | Place study on hold | — | — | study_lead + sign | — | study_lead + sign | — | — | `study_lead` | | Release study hold | — | — | study_lead + sign | — | study_lead + sign | — | — | `study_lead` | | Propose amendment | — | study_member or higher | study_member or higher | — | study_member or higher | — | — | study-role overlay | | Review amendment | — | — | study_reviewer + sign | — | study_reviewer + sign | — | — | `study_reviewer` | | Sign substantial amendment | — | — | study_lead + sign + RA co-sign | — | study_lead + sign + RA co-sign | — | — | `study_lead` + `regulatory_oversight_admin` | | Sign close-out | — | — | study_lead + sign + final_quality_approver co-sign | — | study_lead + sign + final_quality_approver co-sign | — | — | `study_lead` + `final_quality_approver` | | Invite partner tenant (cross-tenant grant) | — | — | — | — | ✓ + sign + MFA | — | — | `tenant_admin_authority` + `cross_tenant_collaboration_authority` | | Accept partner tenant invitation | — | — | — | — | ✓ + sign + MFA | — | — | `tenant_admin_authority` + `cross_tenant_collaboration_authority` | | Revoke cross-tenant collaboration | — | — | — | — | ✓ + sign | ✓ + sign + business justification | ✓ + sign + business justification | `tenant_admin_authority` (own tenant) or platform identity (controlled support) | | Manual record-to-study label | — | — | study_lead + sign | — | study_lead + sign | — | — | `study_lead` | | Read cross-tenant collaboration register | — | — | — | ✓ | ✓ | ✓ | ✓ | — | | Read study-bound regulated record discovery view | — | study-member or higher | study-member or higher | ✓ | study-member or higher | ✓ | ✓ | study-role overlay | | Read study master file | — | study-member or higher | study-member or higher | ✓ | study-member or higher | ✓ | ✓ | study-role overlay; URS-12 owns documents | External identities (URS-01 §3.2.3) MAY be added as `study_observer` only; they cannot hold any study role above observer. #### 3.6.1 Platform-identity tenant actions — controlled support / break-glass posture Per URS-02 §3.6.1, platform identities (`platform_admin`, `super_admin`) MAY perform tenant-scoped Module 7 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 (in URS-06 global chain) plus `PLATFORM_TENANT_ACCESS_NOTIFIED` in target tenant chain, Security Operations Centre alert, customer notification within 24 hours per privacy policy. Use outside the envelope returns `PLATFORM_TENANT_ACCESS_DENIED`. --- ## 4. End-to-End User Journeys ### J-01 — Study creation (non-clinical type) - Trigger: tenant administrator initiates new study. - Steps: opens study creation wizard; selects type (`stability` / `validation` / `method_validation` / etc.); enters identity (title, sponsor, principal investigator name); selects regulatory framework (multi-select from registry); binds scope; nominates study lead; system checks lead's URS-28 qualifications against framework requirements; saves draft. - Audit: `STUDY_CREATED` (state `draft`). ### J-02 — Study setup and activation (non-high-risk) - Trigger: study lead submits draft for setup. - Steps: lead reviews scope, members, regulatory framework, master-file template; submits for setup (state `in_setup`); URS-30 notifies the activation approver (typically the QA Director or another `tenant_admin_authority` holder independent of the creator); approver opens activation surface; reviews; opens Controlled Approval Modal; electronically signs; state moves to `active`; URS-06 captures the activation; URS-03 begins computing active-scope intersection for the study scope; the study calendar opens. - Audit: `STUDY_SUBMITTED_FOR_SETUP`, `STUDY_ACTIVATED`. ```mermaid sequenceDiagram autonumber participant L as Study Lead participant FE as Setup UI participant API as Module 7 API participant Q as URS-28 Qualifications participant A as Activation Approver participant ESIG as URS-04 Controlled Approval Modal participant LOG as URS-06 Audit L->>FE: open setup FE->>API: GET /studies/:id API->>Q: verify study lead and reviewer qualifications Q-->>API: in force L->>API: POST /studies/:id/submit-for-setup API->>LOG: STUDY_SUBMITTED_FOR_SETUP Note over A: URS-30 notifies activation approver A->>FE: open activation A->>ESIG: password meaning reason ESIG->>API: POST /studies/:id/activate API->>LOG: STUDY_ACTIVATED API-->>A: 200 active ``` ### J-03 — Study activation (high-risk type with executive authority co-sign) - Trigger: high-risk study type per DEC-07-03 reaches activation gate. - Steps: standard activation flow plus executive authority co-sign; Executive authority receives activation request through URS-30 with the protocol document and risk pack attached; opens Controlled Approval Modal with multi-factor step-up; co-signs. - Audit: `STUDY_ACTIVATED` plus `FOUNDER_COSIGN_APPLIED`. ### J-04 — Add study member with qualification gating - Trigger: study lead adds a new member. - Steps: lead opens member surface; selects user; selects study role; system checks URS-28 qualification linkage against framework; if missing returns `STUDY_MEMBER_QUALIFICATION_MISSING`; if present, opens Controlled Approval Modal; lead signs; member added. - Audit: `STUDY_MEMBER_ADDED`. ### J-05 — Remove study member - Trigger: lead removes a member who has left the study. - Steps: lead opens member surface; selects member; selects "Remove"; provides reason; signs; member removed; open decisions assigned to the member are reassigned per URS-04 escalation rules. - Audit: `STUDY_MEMBER_REMOVED`. ### J-06 — Hold study - Trigger: safety signal or operational issue requires immediate hold. - Steps: lead opens hold surface; provides reason (≥ 60 chars); signs; state moves to `on_hold`; URS-30 notifies all members and cross-tenant partners; pending milestones paused. - Audit: `STUDY_HOLD_PLACED`. ### J-07 — Release study hold - Trigger: investigation closed; safe to resume. - Steps: lead opens release surface; references the closing CAPA / investigation; provides reason; signs; state returns to `active`; URS-30 notifies. - Audit: `STUDY_HOLD_RELEASED`. ### J-08 — Propose amendment - Trigger: protocol change required. - Steps: any `study_member` or higher opens amendment surface; selects scope of change; documents rationale (≥ 60 chars); attaches updated protocol document (URS-12 produces new version); selects regulatory impact classification; submits. - Audit: `STUDY_AMENDMENT_PROPOSED`. ### J-09 — Review amendment - Trigger: amendment in review queue. - Steps: `study_reviewer` opens; reviews diff; opens Controlled Approval Modal; signs review; state moves to "ready-for-final-sign". - Audit: `STUDY_AMENDMENT_REVIEW_SIGNED`. ### J-10 — Sign substantial amendment with RA co-sign - Trigger: review complete; substantial classification. - Steps: study lead opens final-sign surface; opens Controlled Approval Modal; signs; URS-30 notifies `regulatory_oversight_admin`; RA opens the surface; opens Controlled Approval Modal; co-signs; amendment becomes `effective` from `effective_from`; in-flight regulated decisions from this date forward reference the new protocol version. - Audit: `STUDY_AMENDMENT_FINAL_SIGNED`, `STUDY_AMENDMENT_EFFECTIVE`. ```mermaid flowchart TD A[Member proposes amendment] --> B[STUDY_AMENDMENT_PROPOSED] B --> C[study_reviewer reviews] C --> D[STUDY_AMENDMENT_REVIEW_SIGNED] D --> E{Classification} E -- non_substantial --> F[Study lead final sign] E -- substantial --> G[Study lead sign] G --> H[regulatory_oversight_admin co-sign] H --> I[STUDY_AMENDMENT_EFFECTIVE] F --> I I --> J[New protocol version effective from amendment date] ``` ### J-11 — Cross-tenant collaboration invitation - Trigger: lead tenant administrator invites a partner tenant. - Steps: opens collaboration surface; enters partner tenant identifier; defines per-grant scope; nominates per-grant member roster; signs through Controlled Approval Modal with multi-factor step-up; URS-30 notifies partner tenant administrator. - Audit: `CROSS_TENANT_COLLABORATION_PROPOSED`. ### J-12 — Cross-tenant collaboration acceptance - Trigger: partner tenant administrator receives invitation. - Steps: opens collaboration inbox; reviews study scope, member roster, terms; signs through Controlled Approval Modal with multi-factor step-up; grant becomes active; both tenants' study members can now access the per-grant scope. - Audit: `CROSS_TENANT_COLLABORATION_ACCEPTED`. ### J-13 — Cross-tenant collaboration revocation - Trigger: either side decides to terminate collaboration. - Steps: tenant administrator opens collaboration register; selects active grant; selects "Revoke"; provides reason; signs; grant becomes `revoked`; partner tenant access immediately removed; cross-tenant Authority Profile assignments cascade-revoked per DEC-07-16; both tenants' audit chains receive `CROSS_TENANT_COLLABORATION_REVOKED`. - Audit: `CROSS_TENANT_COLLABORATION_REVOKED` (both tenants). ### J-14 — Cross-tenant access logged - Trigger: a partner-tenant member reads a study-confidential document. - Steps: URS-12 read API checks study-membership overlay; access permitted within per-grant scope; URS-06 emits `CROSS_TENANT_STUDY_ACCESS_USED` per access in both tenants' chains. - Audit: `CROSS_TENANT_STUDY_ACCESS_USED`. ### J-15 — Master-file completeness check - Trigger: lead approaches close-out. - Steps: opens master-file completeness surface; system enumerates the regulatory-framework-derived required document list; compares against linked URS-12 documents; reports missing items; lead resolves missing items by linking documents or attesting non-applicability. - Audit: `MASTER_FILE_COMPLETENESS_CHECK_RUN`. ### J-16 — Study close-out - Trigger: deliverables complete. - Steps: lead opens close-out surface; system surfaces the close-out package contents (final report; resolved-findings list; master-file completeness; regulatory submission references); lead reviews; signs through Controlled Approval Modal; URS-30 notifies `final_quality_approver`; quality lead opens; co-signs; state moves to `closed`. - Audit: `STUDY_CLOSED_OUT`. ### J-17 — Study auto-archives after window - Trigger: scheduled job at close-out + window (default 90 days). - Steps: scheduled job moves study to `archived`; URS-06 captures; URS-30 informs. - Audit: `STUDY_ARCHIVED`. ### J-18 — Study-bound regulated-entity discovery - Trigger: any user with study-membership opens the discovery view. - Steps: system intersects the study's `scope_jsonb` against URS-03 active scope of every regulated record over the study's `scope_effective_from` to `scope_effective_to` window; returns the result with per-record metadata (record id, type, current state, owning module); manual-label badges added where applicable. - Audit: read; `STUDY_DISCOVERY_VIEW_OPENED` once per session. ### J-19 — Manual record-to-study label - Trigger: edge case where scope-intersection misses a related record. - Steps: study lead opens label surface; selects record; provides rationale; signs; system asserts the record's actual scope still intersects the study scope (refuses if not — per DEC-07-14, manual labels cannot bring out-of-scope records into the study). - Audit: `STUDY_RECORD_MANUAL_LABEL_APPENDED`. ### J-20 — Withdrawn study before activation - Trigger: study no longer needed; never activated. - Steps: lead opens withdrawal surface; provides reason; signs; state moves to `withdrawn`; record soft-deleted from active catalogue; visible to auditors. - Audit: `STUDY_WITHDRAWN`. ### J-21 — Per-jurisdiction regulatory framework selection - Trigger: study creation; tenant operates in multiple jurisdictions. - Steps: wizard surfaces multi-select for applicable regulations from the platform-managed registry; the lead selects (e.g., for an EU-and-US bioequivalence: `21_cfr_part_320`, `eu_gmp_part_iv`, `ich_q1ar2_for_packaging_studies`); selection drives master-file completeness checklist and audit cadence; URS-30 notifies regulatory affairs lead. - Audit: `STUDY_REGULATORY_FRAMEWORK_SET`. ### J-22 — Member qualification expiry mid-study - Trigger: a study reviewer's GMP training expires. - Steps: at next regulated decision, URS-05 resolver step 4 returns `QUALIFICATION_EVIDENCE_EXPIRED`; URS-30 notifies the user and the study lead; the user retrains; URS-28 records new qualification; resolver returns valid; user resumes signing. - Audit: `APPROVAL_AUTHORITY_DENIED` per URS-05; once resolved, subsequent signatures emit normally. ### J-23 — executive break-glass hold (global_quality_oversight) - Trigger: serious quality signal across an entire site. - Steps: Founder uses `global_quality_oversight` Authority Profile to issue an immediate hold on every active study at the affected site; URS-04 override-use ceremony executes; URS-30 alerts every study lead; affected studies move to `on_hold` with the Founder-override reference recorded; investigation begins. - Audit: `STUDY_HOLD_PLACED` with `override_authority_profile_used = global_quality_oversight`. ### J-24 — Tenant offboarding cascades to studies - Trigger: URS-08 offboards a tenant. - Steps: URS-08 emits `TENANT_OFFBOARDING_INITIATED`; Module 7 listens; for cross-tenant studies where the offboarding tenant is the lead, the platform requires Founder-level resolution (typically a contractual transfer to a successor tenant or controlled close-out); for studies where the offboarding tenant is a partner, the platform automatically revokes the collaboration grant; offboarding cannot complete until all study commitments are resolved. - Audit: `TENANT_OFFBOARDING_BLOCKED_BY_OPEN_STUDIES` if outstanding commitments exist; resolution events recorded in both Module 7 and URS-08 chains. ### J-25 — Auditor reads study-bound discovery view - Trigger: regulatory inspector requests evidence of every record in the study. - Steps: auditor opens the study discovery view (URS-06 read access via `audit:read`); exports through Controlled Approval Modal; receives PDF + JSON bundle with integrity manifest spanning every URS-06 chain referenced (per-entity chains for each record, per-tenant chain for the study lifecycle, master-file document chains). - Audit: `STUDY_DISCOVERY_EXPORTED`. ### J-26 — Study-level confidentiality enforced - Trigger: a non-member with `quality_lead` base role attempts to read a draft study document. - Steps: URS-12 document read API checks study-membership overlay (since the document is study-confidential); request denied with `403 STUDY_CONFIDENTIAL_NOT_MEMBER`; URS-06 forensic. - Audit: `STUDY_CONFIDENTIAL_ACCESS_DENIED` (forensic). ### J-27 — Sponsor reviews CRO-contributed source data - Trigger: in cross-tenant bioequivalence study, sponsor opens CRO-contributed dataset. - Steps: sponsor user (with `study_reviewer` role on partner-tenant side) opens the dataset; URS-12 + URS-03 validate access; URS-06 emits `CROSS_TENANT_STUDY_ACCESS_USED` in both tenants' chains; sponsor reviews; signs review attestation per study workflow. - Audit: `CROSS_TENANT_STUDY_ACCESS_USED`, `STUDY_REVIEW_ATTESTED`. ### J-28 — Re-opening an archived study creates a successor - Trigger: post-close anomaly discovered (e.g., a stability study's data is later questioned). - Steps: per DEC-07-02, archived studies cannot transition back to active; instead a tenant administrator creates a successor study referencing the archived predecessor; the successor's regulatory framework, scope, and member roster are pre-populated from the predecessor; the successor enters its own draft → active flow; URS-06 captures the linkage. - Audit: `SUCCESSOR_STUDY_CREATED_FROM_ARCHIVED`. --- ## 5. Front-End Expected State ### 5.1 Routes | Route | Surface | Role / Authority gate | Notes | |---|---|---|---| | `/studies` | Study catalogue browser | `audit:read` or any base role within tenant | filterable by type, lifecycle state, lead | | `/studies/new` | Study creation wizard | `tenant_admin_authority` | type-specific multi-step wizard | | `/studies/:id` | Per-study detail (overview / members / scope / amendments / master file / records / calendar / close-out) | study-role overlay | tabbed | | `/studies/:id/members` | Members management | `study_lead` for write; members + auditor for read | qualification linkage shown inline | | `/studies/:id/amendments` | Amendment register | study-role overlay; write per role | versioned protocol diff viewer | | `/studies/:id/amendments/new` | Propose amendment | study-member or higher | classification helper | | `/studies/:id/master-file` | Master-file linkage and completeness | study-role overlay | URS-12 documents listed | | `/studies/:id/calendar` | Milestones and study calendar | study-role overlay | iCal export | | `/studies/:id/close-out` | Close-out package surface | `study_lead` + `final_quality_approver` co-sign | wizard | | `/studies/:id/discovery` | Study-bound regulated-record discovery view | study-role overlay or `audit:read` | filterable, exportable | | `/studies/:id/manual-label` | Manual record-to-study label | `study_lead` | surface refuses out-of-scope records | | `/studies/:id/collaboration` | Cross-tenant collaboration register | `tenant_admin_authority` | grant lifecycle | | `/admin/studies/cross-tenant-inbox` | Inbound cross-tenant invitations | `tenant_admin_authority` | accept / decline | | `/admin/studies/regulatory-framework-registry` | Tenant-level regulatory framework defaults | `tenant_admin_authority` | Class 2 change | | `/platform/studies/regulatory-framework-registry` | Platform-managed registry (Tier 1) | platform identity | Class 2 change with executive authority co-sign for new regulation entries | | `/platform/studies/clinical-activation` | Tenant clinical-type activation surface | platform identity + executive authority | per DEC-07-17 | ### 5.2 Component requirements - **Study catalogue browser** — high-density list with type chips, lifecycle badges, lead avatars; quick filters; cross-tenant studies show a partner-tenant chip with the cross-tenant icon. - **Study creation wizard** — multi-step: identity → regulatory framework → scope → members + qualification check → master-file template → review → submit. Live qualification check warns inline when a nominated member is missing required URS-28 evidence. - **Per-study detail (tabbed)** — Overview, Members, Scope, Amendments, Master File, Records (study-bound discovery), Calendar, Close-Out. Members tab shows tenant_side chips for cross-tenant. Scope tab shows the canonical scope JSON with a human-readable rendering. Amendments tab shows version timeline. Master File tab shows completeness against framework checklist. Records tab is the discovery view. Close-Out tab is the wizard. Visual lifecycle banner across the top. - **Amendment authoring surface** — form-driven; classification helper assists choosing substantial / non-substantial / administrative; protocol-diff viewer (where URS-12 supports diff); regulatory impact assessment field; effective-from picker. - **Cross-tenant collaboration surface** — table of grants with state (proposed / active / revoked); per-grant scope and member roster visible; revocation gated by Controlled Approval Modal; clear "your tenant" vs "partner tenant" framing. - **Study-bound regulated-record discovery view** — table of all records the study scope intersects, with module / type / state / scope-intersection-rationale columns; manual-label badges; export (electronically signed) per J-25. - **Manual-label surface** — input form; system shows the candidate record's current scope and the study scope; refuses if no intersection at all; allows annotation as related-but-out-of-scope (this is informational, not assertive). - **Close-out package surface** — checklist of required artifacts (final report, resolved findings, master file, regulatory references); inline validation; signature surface for lead and quality lead. ### 5.3 Accessibility and internationalisation - WCAG 2.1 Level AA across every Module 7 surface. - Study type names, regulatory framework names, lifecycle states translated; `study_id`, `protocol_version`, and identifiers remain canonical. - Date / time displayed in user time zone; stored UTC; ISO 8601. - Cross-tenant content visually distinguished (different border / chip / banner). --- ## 6. Back-End Expected State ### 6.1 Domain entities - `studies` — the study record per DEC-07-01..02. - `study_protocol_versions` — versioned protocol document linkage to URS-12 with immutable per-version row. - `study_members` — per-study membership and role overlay per DEC-07-04. - `study_scope_versions` — scope-binding history (one row per amendment-affected scope change). - `study_amendments` — amendment lifecycle records per DEC-07-06. - `study_master_file_documents` — linkage between study and URS-12 controlled documents per DEC-07-08. - `cross_tenant_collaboration_grants` — bilateral collaboration grants per DEC-07-07. - `study_calendar_milestones` — study calendar entries. - `study_record_manual_labels` — DEC-07-14 manual labels (audit-trailed annotations). - `study_close_out_packages` — per-study close-out package metadata and signature linkage. - `study_regulatory_framework_registry` — Tier 1 platform registry of applicable regulations. - `study_regulatory_framework_tenant_defaults` — per-tenant default selections. - `clinical_type_tenant_activations` — per-tenant activation grants for `clinical_phase_*` types per DEC-07-17. ### 6.1.1 Diagram 6.1-A — Module 7 entity-relationship overview ```mermaid erDiagram STUDIES ||--o{ STUDY_PROTOCOL_VERSIONS : has STUDIES ||--o{ STUDY_MEMBERS : has STUDIES ||--o{ STUDY_SCOPE_VERSIONS : has STUDIES ||--o{ STUDY_AMENDMENTS : amended_by STUDIES ||--o{ STUDY_MASTER_FILE_DOCUMENTS : linked_to STUDIES ||--o| STUDY_CLOSE_OUT_PACKAGES : closed_out_by STUDIES ||--o{ CROSS_TENANT_COLLABORATION_GRANTS : opens STUDIES ||--o{ STUDY_CALENDAR_MILESTONES : scheduled_by STUDIES ||--o{ STUDY_RECORD_MANUAL_LABELS : labels STUDY_AMENDMENTS ||--o| STUDY_PROTOCOL_VERSIONS : produces STUDY_AMENDMENTS ||--o{ STUDY_SCOPE_VERSIONS : may_change STUDY_MEMBERS }o--o| QUALIFICATION_EVIDENCE_LINKS : qualified_via STUDIES }o--|| STUDY_REGULATORY_FRAMEWORK_REGISTRY : selects_from STUDIES }o--o| CLINICAL_TYPE_TENANT_ACTIVATIONS : gated_by_for_clinical ``` `QUALIFICATION_EVIDENCE_LINKS` is owned by URS-05 (per its data model in URS-05 §6.2) referencing URS-28 evidence; Module 7's `STUDY_MEMBERS` references the appropriate qualification evidence via that linkage table. ### 6.1.2 Diagram 6.1-B — Study lifecycle state machine ```mermaid stateDiagram-v2 [*] --> draft : STUDY_CREATED draft --> in_setup : STUDY_SUBMITTED_FOR_SETUP in_setup --> active : STUDY_ACTIVATED active --> on_hold : STUDY_HOLD_PLACED on_hold --> active : STUDY_HOLD_RELEASED active --> closed : STUDY_CLOSED_OUT closed --> archived : STUDY_ARCHIVED (auto after window) draft --> withdrawn : STUDY_WITHDRAWN in_setup --> withdrawn : STUDY_WITHDRAWN archived --> [*] withdrawn --> [*] ``` ### 6.1.3 Diagram 6.1-C — Study scope feeds URS-03 active scope intersection ```mermaid flowchart LR M7[Module 7 study.scope_jsonb] --> U3[URS-03 active scope resolver] R[Regulated record] --> U3 U3 --> I{Scope intersect within study active window?} I -- yes --> D[Discoverable from study record] I -- no --> ND[Not discoverable; manual label permitted only if scope intersects elsewhere] ``` ### 6.1.4 Diagram 6.1-D — Cross-tenant collaboration grant lifecycle ```mermaid stateDiagram-v2 [*] --> proposed : Lead tenant signs invitation proposed --> active : Partner tenant signs acceptance proposed --> declined : Partner tenant signs decline active --> revoked : Either tenant signs revocation active --> expired : effective_to passes declined --> [*] revoked --> [*] expired --> [*] ``` ### 6.2 Data model requirements | Entity | Purpose | Key fields | Required | Unique | Tenant isolation | Versioning | Retention | Soft-delete | Audit | E-sig link | |---|---|---|---|---|---|---|---|---|---|---| | `studies` | Per-tenant study record | `id`, `tenant_id`, `title`, `study_type`, `regulatory_framework_jsonb`, `sponsor_tenant_id`, `lead_user_id`, `lifecycle_state` (enum per DEC-07-02), `current_protocol_version_id` (nullable until activation), `current_scope_version_id` (nullable until activation), `created_by`, `created_at`, `submitted_for_setup_at` (nullable), `activated_at` (nullable), `activated_e_sig_id` (nullable), `closed_at` (nullable), `closed_e_sig_id` (nullable), `archived_at` (nullable), `withdrawn_at` (nullable), `withdrawn_e_sig_id` (nullable), `retention_class`, `successor_of_study_id` (nullable; per J-28) | per-state per DEC-07-02 | unique(`tenant_id`, `id`); semantic uniqueness on `(tenant_id, title, study_type)` warning-only | RLS on `tenant_id`; cross-tenant studies enforce per-grant scope at read | stateful + append-only audit history | per `retention_class` (DEC-07-13) | yes (withdrawn / archived; never hard-deleted) | yes (per state) | yes (per state) | | `study_protocol_versions` | Immutable per-version protocol linkage | `id`, `study_id`, `version` (integer monotonic), `urs12_document_id` (FK to URS-12 controlled document), `effective_from`, `effective_to` (nullable), `published_by`, `published_e_sig_id`, `created_at`, `previous_hash`, `record_hash` | all required | unique(`study_id`, `version`); unique(`record_hash`) | RLS via study | versioned (immutable) | per study retention | not applicable | yes | yes | | `study_members` | Per-study membership and role overlay | `id`, `study_id`, `user_id`, `tenant_id_of_user` (for cross-tenant discriminator), `tenant_side` (`sponsor` / `cro` / partner-name), `study_role` (per DEC-07-04), `qualification_evidence_link_ids_jsonb` (jsonb array of URS-05 `qualification_evidence_links` ids), `effective_from`, `effective_to` (nullable), `assigned_by`, `assigned_e_sig_id`, `removed_at` (nullable), `removed_by` (nullable), `removed_e_sig_id` (nullable) | core required | unique active(`study_id`, `user_id`) | RLS via study | stateful + append-only audit | per study retention | yes (removal preserves row) | yes | yes | | `study_scope_versions` | Immutable per-version scope binding | `id`, `study_id`, `version` (integer monotonic), `scope_jsonb` (per DEC-07-05; canonical authority scope dimension keys), `scope_effective_from`, `scope_effective_to`, `set_by` (`activation` / `amendment_id`), `set_e_sig_id`, `created_at`, `previous_hash`, `record_hash` | all required | unique(`study_id`, `version`); unique(`record_hash`) | RLS via study | versioned (immutable) | per study retention | not applicable | yes | yes | | `study_amendments` | Amendment lifecycle records per DEC-07-06 | `id`, `study_id`, `proposing_user_id`, `proposed_at`, `rationale` (≥ 60 chars), `scope_of_change` (enum per DEC-07-06), `regulatory_impact_classification` (`substantial` / `non_substantial` / `administrative`), `urs12_document_id_proposed_protocol` (nullable), `produced_protocol_version_id` (nullable until effective), `produced_scope_version_id` (nullable until effective), `state` (`proposed` / `under_review` / `ready_for_final_sign` / `effective` / `withdrawn`), `reviewer_user_id` (nullable), `review_e_sig_id` (nullable), `lead_final_sign_e_sig_id` (nullable), `ra_co_sign_e_sig_id` (nullable; required for substantial), `founder_co_sign_e_sig_id` (nullable; required for regulatory_framework_change), `effective_from` (nullable until effective), `created_at` | per-state required | unique(`study_id`, `id`) | RLS via study | stateful + append-only | per study retention | yes (withdrawn) | yes | yes (per stage) | | `study_master_file_documents` | Linkage between study and URS-12 documents at protocol version | `id`, `study_id`, `protocol_version_id`, `urs12_document_id`, `document_role` (e.g., `protocol`, `final_report`, `analytical_method`, `irb_approval`, `consent_form`, `validation_plan`, `qualification_protocol`), `linked_at`, `linked_by`, `linked_e_sig_id` | all | unique(`study_id`, `protocol_version_id`, `urs12_document_id`, `document_role`) | RLS via study | append-only | per study retention | not applicable | yes | yes | | `cross_tenant_collaboration_grants` | Bilateral grants per DEC-07-07 | `id`, `lead_tenant_id`, `partner_tenant_id`, `study_id`, `per_grant_scope_jsonb` (subset of study scope), `state` (`proposed` / `active` / `revoked` / `expired` / `declined`), `effective_from`, `effective_to`, `proposed_by_user_id`, `proposed_e_sig_id`, `accepted_by_user_id` (nullable), `accepted_e_sig_id` (nullable), `revoked_by_user_id` (nullable), `revoked_by_tenant_id` (nullable), `revoked_e_sig_id` (nullable), `revocation_reason` (nullable) | core required per state | unique active(`study_id`, `partner_tenant_id`) | RLS in both lead and partner tenants | stateful + append-only | per study retention | yes (revoked) | yes | yes | | `study_calendar_milestones` | Study calendar entries | `id`, `study_id`, `title`, `description`, `due_at`, `owner_user_id`, `state` (`pending` / `completed` / `late` / `not_applicable`), `completed_at`, `completed_e_sig_id` | core required | unique(`study_id`, `id`) | RLS via study | stateful | per study retention | yes | yes | yes | | `study_record_manual_labels` | DEC-07-14 manual labels | `id`, `study_id`, `target_module`, `target_record_id`, `rationale`, `assertion` (`in_scope` / `related_out_of_scope`), `applied_by`, `applied_e_sig_id`, `applied_at`, `revoked_at` (nullable), `revoked_e_sig_id` (nullable) | all | unique active(`study_id`, `target_module`, `target_record_id`) | RLS via study | append-only | per study retention | yes (revocation) | yes | yes | | `study_close_out_packages` | Per-study close-out metadata | `id`, `study_id`, `final_report_document_id`, `resolved_findings_summary_jsonb`, `master_file_completeness_run_id`, `regulatory_submission_references_jsonb`, `lead_close_out_e_sig_id`, `quality_co_sign_e_sig_id`, `closed_out_at` | all | unique(`study_id`) | RLS via study | append-only | per study retention | not applicable | yes | yes | | `study_regulatory_framework_registry` | Platform-managed Tier 1 registry of applicable regulations | `id`, `regulation_key` (e.g., `21_cfr_part_312`), `name`, `jurisdiction`, `applicable_study_types_jsonb`, `master_file_template_id` (FK to URS-12), `audit_cadence`, `effective_from`, `effective_to`, `published_by_platform_admin_user_id`, `published_e_sig_id`, `record_hash`, `previous_hash` | all | unique(`regulation_key`, `effective_from`); unique(`record_hash`) | platform-context | versioned | retain (long-term) | not applicable | yes | yes | | `study_regulatory_framework_tenant_defaults` | Per-tenant default selections | `id`, `tenant_id`, `study_type`, `default_regulation_keys_jsonb`, `set_by`, `set_e_sig_id`, `created_at` | all | unique active(`tenant_id`, `study_type`) | RLS on `tenant_id` | versioned | retain | not applicable | yes | yes | | `clinical_type_tenant_activations` | Per-tenant activation grants for clinical types per DEC-07-17 | `id`, `tenant_id`, `clinical_type` (`clinical_phase_1` / `2` / `3`), `state` (`requested` / `active` / `revoked`), `gcp_readiness_pack_document_id`, `requested_by`, `requested_e_sig_id`, `founder_signed_e_sig_id`, `activated_at`, `revoked_at` (nullable), `revoked_e_sig_id` (nullable) | all | unique active(`tenant_id`, `clinical_type`) | platform-context | stateful | retain | yes (revoked) | yes | yes | ### 6.3 API requirements #### 6.3.1 Study catalogue and lifecycle | Method | Endpoint | Actor | Request | Response | Permission | Audit | Error codes | |---|---|---|---|---|---|---|---| | GET | `/studies` | tenant-scoped | filters | `Study[]` | `audit:read` or any base role | `STUDY_CATALOGUE_VIEW_OPENED` once per session | none | | POST | `/studies` | administrator | `{title, studyType, regulatoryFramework, sponsorTenantId, leadUserId, scope}` (electronic-signed) | `201` | `tenant_admin_authority`; clinical types require executive authority co-sign + activation grant per DEC-07-17 | `STUDY_CREATED` | `STUDY_TYPE_NOT_ENABLED_FOR_TENANT`, `LEAD_QUALIFICATION_MISSING`, validation | | POST | `/studies/:id/submit-for-setup` | study lead | reason (electronic-signed) | `200` | `study_lead` | `STUDY_SUBMITTED_FOR_SETUP` | `STATE_NOT_DRAFT` | | POST | `/studies/:id/activate` | activation approver (independent of creator) | reason (electronic-signed + MFA for high-risk) | `200` | `study_lead` (independent of creator); high-risk requires executive authority co-sign per DEC-07-03 | `STUDY_ACTIVATED` | `STATE_NOT_IN_SETUP`, `APPROVER_IS_CREATOR`, `FOUNDER_COSIGN_REQUIRED`, `LEAD_QUALIFICATION_EXPIRED` | | POST | `/studies/:id/hold` | study lead | reason (electronic-signed) | `200` | `study_lead` | `STUDY_HOLD_PLACED` | `STATE_NOT_ACTIVE` | | POST | `/studies/:id/release` | study lead | reason (electronic-signed) | `200` | `study_lead` | `STUDY_HOLD_RELEASED` | `STATE_NOT_ON_HOLD` | | POST | `/studies/:id/close-out` | study lead | close-out package (electronic-signed) | `200` | `study_lead` + `final_quality_approver` co-sign | `STUDY_CLOSED_OUT` | `MASTER_FILE_INCOMPLETE`, `OPEN_FINDINGS_REMAIN`, `STATE_NOT_ACTIVE` | | POST | `/studies/:id/withdraw` | study lead | reason (electronic-signed) | `200` | `study_lead` | `STUDY_WITHDRAWN` | `STATE_NOT_DRAFT_OR_IN_SETUP` | #### 6.3.2 Members | Method | Endpoint | Actor | Request | Response | Permission | Audit | Error codes | |---|---|---|---|---|---|---|---| | GET | `/studies/:id/members` | tenant-scoped or partner-tenant | none | `StudyMember[]` | study-role overlay or `audit:read` | none | none | | POST | `/studies/:id/members` | study lead | `{userId, studyRole, tenantSide?}` (electronic-signed) | `201` | `study_lead` | `STUDY_MEMBER_ADDED` | `STUDY_MEMBER_QUALIFICATION_MISSING`, `CROSS_TENANT_NOT_GRANTED`, validation | | POST | `/studies/:id/members/:memberId/remove` | study lead | reason (electronic-signed) | `200` | `study_lead` | `STUDY_MEMBER_REMOVED` | validation | #### 6.3.3 Amendments | Method | Endpoint | Actor | Request | Response | Permission | Audit | Error codes | |---|---|---|---|---|---|---|---| | GET | `/studies/:id/amendments` | tenant-scoped | filters | `StudyAmendment[]` | study-role overlay | none | none | | POST | `/studies/:id/amendments` | any study_member or higher | `{rationale, scopeOfChange, regulatoryImpactClassification, proposedProtocolDocumentId?, proposedScope?, effectiveFrom}` (electronic-signed) | `201` | study-role overlay | `STUDY_AMENDMENT_PROPOSED` | `RATIONALE_TOO_SHORT`, `EFFECTIVE_FROM_BEFORE_NOW`, validation | | POST | `/studies/:id/amendments/:amendmentId/review` | study reviewer | review notes (electronic-signed) | `200` | `study_reviewer` | `STUDY_AMENDMENT_REVIEW_SIGNED` | `STATE_NOT_PROPOSED` | | POST | `/studies/:id/amendments/:amendmentId/sign` | study lead | reason (electronic-signed; RA co-sign for substantial; executive authority co-sign for regulatory_framework_change) | `200` | `study_lead` (+ `regulatory_oversight_admin` / Founder per classification) | `STUDY_AMENDMENT_FINAL_SIGNED`, `STUDY_AMENDMENT_EFFECTIVE` | `STATE_NOT_REVIEW_SIGNED`, `RA_COSIGN_REQUIRED`, `FOUNDER_COSIGN_REQUIRED` | | POST | `/studies/:id/amendments/:amendmentId/withdraw` | study lead | reason (electronic-signed) | `200` | `study_lead` | `STUDY_AMENDMENT_WITHDRAWN` | `STATE_NOT_PROPOSED_OR_UNDER_REVIEW` | #### 6.3.4 Master file | Method | Endpoint | Actor | Request | Response | Permission | Audit | Error codes | |---|---|---|---|---|---|---|---| | GET | `/studies/:id/master-file` | tenant-scoped | none | linked-document list with completeness status | study-role overlay | none | none | | POST | `/studies/:id/master-file/link` | study lead | `{urs12DocumentId, documentRole, protocolVersionId}` (electronic-signed) | `201` | `study_lead` | `STUDY_MASTER_FILE_DOCUMENT_LINKED` | validation | | POST | `/studies/:id/master-file/completeness-check` | study lead | none (electronic-signed) | completeness manifest | `study_lead` | `MASTER_FILE_COMPLETENESS_CHECK_RUN` | none | #### 6.3.5 Cross-tenant collaboration | Method | Endpoint | Actor | Request | Response | Permission | Audit | Error codes | |---|---|---|---|---|---|---|---| | GET | `/studies/:id/collaboration` | tenant-scoped | none | `CollaborationGrant[]` | `tenant_admin_authority` or `audit:read` | none | none | | POST | `/studies/:id/collaboration/invite` | lead-tenant administrator | `{partnerTenantId, perGrantScope, perGrantMemberRoster, effectiveFrom, effectiveTo}` (electronic-signed + MFA) | `201` | `tenant_admin_authority` + `cross_tenant_collaboration_authority` | `CROSS_TENANT_COLLABORATION_PROPOSED` | `PARTNER_TENANT_NOT_VALID`, `PER_GRANT_SCOPE_EXCEEDS_STUDY`, validation | | POST | `/admin/studies/cross-tenant-inbox/:grantId/accept` | partner-tenant administrator | reason (electronic-signed + MFA) | `200` | `tenant_admin_authority` + `cross_tenant_collaboration_authority` | `CROSS_TENANT_COLLABORATION_ACCEPTED` | `STATE_NOT_PROPOSED` | | POST | `/admin/studies/cross-tenant-inbox/:grantId/decline` | partner-tenant administrator | reason (electronic-signed) | `200` | `tenant_admin_authority` | `CROSS_TENANT_COLLABORATION_DECLINED` | `STATE_NOT_PROPOSED` | | POST | `/studies/:id/collaboration/:grantId/revoke` | either-tenant administrator | reason (electronic-signed) | `200` | `tenant_admin_authority` (own tenant) | `CROSS_TENANT_COLLABORATION_REVOKED` (in both tenants) | `STATE_NOT_ACTIVE` | #### 6.3.6 Discovery and manual labels | Method | Endpoint | Actor | Request | Response | Permission | Audit | Error codes | |---|---|---|---|---|---|---|---| | GET | `/studies/:id/discovery` | tenant-scoped or partner-tenant | filters | `DiscoveryRecord[]` (records intersecting study scope plus manual labels) | study-role overlay or `audit:read` | `STUDY_DISCOVERY_VIEW_OPENED` once per session | none | | POST | `/studies/:id/discovery/export` | tenant administrator | filters + format (electronic-signed) | signed download URL + integrity manifest | `tenant_admin_authority` + `audit:export` | `STUDY_DISCOVERY_EXPORTED` | none | | POST | `/studies/:id/manual-labels` | study lead | `{targetModule, targetRecordId, rationale, assertion}` (electronic-signed) | `201` | `study_lead` | `STUDY_RECORD_MANUAL_LABEL_APPENDED` | `OUT_OF_SCOPE_RECORD_CANNOT_BE_LABELED_IN_SCOPE`, validation | #### 6.3.7 Platform-only APIs | Method | Endpoint | Actor | Request | Response | Permission | Audit | |---|---|---|---|---|---|---| | GET | `/platform/studies/regulatory-framework-registry` | platform identity / auditor | filters | `RegulationVersion[]` | platform identity | none | | POST | `/platform/studies/regulatory-framework-registry` | platform identity | regulation fields (electronic-signed + MFA + executive authority co-sign for new keys) | `201` | platform identity | `REGULATORY_FRAMEWORK_REGISTRY_PUBLISHED` | | POST | `/platform/studies/clinical-activation/:tenantId/:clinicalType/activate` | platform identity + executive authority | `{gcpReadinessPackDocumentId}` (electronic-signed + MFA + executive authority co-sign) | `201` | platform identity + executive authority | `CLINICAL_TYPE_ACTIVATED_FOR_TENANT` | | POST | `/platform/studies/clinical-activation/:tenantId/:clinicalType/revoke` | platform identity + executive authority | reason (electronic-signed + MFA + executive authority co-sign) | `200` | platform identity + executive authority | `CLINICAL_TYPE_REVOKED_FOR_TENANT` | ### 6.4 Workflow / lifecycle requirements | Workflow | Step | Time-to-live or timer | Auto-action | Reminder | |---|---|---|---|---| | Study close-out auto-archive | closed → archived | 90 days (tenant-configurable upward) | auto-transition; emit `STUDY_ARCHIVED` | T-7 days reminder | | Cross-tenant invitation acceptance | proposed → accepted/declined | 30 days default | auto-decline if no response; emit `CROSS_TENANT_COLLABORATION_AUTO_DECLINED` | T-7, T-1 day | | Member qualification expiry | none | continuous | block decisions per URS-05 BR-05-24 | T-30, T-7 from URS-28 | | Substantial amendment activation | proposed → effective | none (manual ceremony) | none | none | | Calendar milestone late | due_at passed | continuous | mark `late`; emit `STUDY_MILESTONE_LATE` | T-7, T-1 day | ### 6.5 Business rules - **BR-07-01** — Study activation requires the activation approver to be **independent of the study creator** per `AUTHOR_NEQ_APPROVER` SoD; bypass returns `403 APPROVER_IS_CREATOR`. - **BR-07-02** — High-risk study type activations require executive authority co-sign per DEC-07-03; bypass returns `403 FOUNDER_COSIGN_REQUIRED`. - **BR-07-03** — Adding a study member with role `study_lead`, `study_reviewer`, or `study_coordinator` for high-risk types requires URS-28 qualification verification at member-creation time; missing returns `400 STUDY_MEMBER_QUALIFICATION_MISSING`. - **BR-07-04** — Study scope is immutable from activation to close-out except through controlled amendment per DEC-07-05. - **BR-07-05** — Substantial amendments require `regulatory_oversight_admin` co-sign; regulatory-framework-change amendments require executive authority co-sign; bypass returns one of `RA_COSIGN_REQUIRED` or `FOUNDER_COSIGN_REQUIRED` per the missing co-sign role (codes per §11.2 catalogue). - **BR-07-06** — In-flight regulated decisions reference the protocol version effective at the decision moment (snapshot pinning via URS-05 catalogue-version pinning principle, applied to protocol version); subsequent amendments do NOT retroactively alter prior decisions per DEC-07-15. - **BR-07-07** — Cross-tenant collaboration grants are bilateral; both lead-tenant and partner-tenant signatures required for activation. - **BR-07-08** — Cross-tenant access is enforced at every read through URS-03 cross-tenant active-scope rules and URS-06 emits `CROSS_TENANT_STUDY_ACCESS_USED` per access in BOTH tenants' chains. - **BR-07-09** — Cross-tenant collaboration revocation cascades to revoke any URS-05 Authority Profile assignments granted to partner-tenant users for this study (per DEC-07-16). - **BR-07-10** — Study-bound regulated-record discovery is computed by URS-03 active-scope intersection over the study's `scope_effective_from` to `scope_effective_to` window per DEC-07-10. - **BR-07-11** — Manual labels with `assertion = 'in_scope'` are refused if the record's scope does not intersect the study scope at all (`OUT_OF_SCOPE_RECORD_CANNOT_BE_LABELED_IN_SCOPE`); manual labels with `assertion = 'related_out_of_scope'` are accepted. - **BR-07-12** — Master-file completeness check enumerates the regulatory-framework-derived required document list and identifies missing items; close-out cannot proceed with `MASTER_FILE_INCOMPLETE`. - **BR-07-13** — Close-out cannot proceed while open findings remain on study-bound regulated records; either close them or formally accept them (each acceptance is itself electronically signed and audited). - **BR-07-14** — Auto-archive transition fires after the configured close-to-archive window (default 90 days, tenant-configurable upward only). - **BR-07-15** — Archived studies cannot transition back to active; J-28 successor-study path applies. - **BR-07-16** — Withdrawn studies remain query-accessible for forensic / audit purposes; soft-delete preserves the row. - **BR-07-17** — Clinical type activation per tenant requires Founder electronic signature plus tenant supplemental contract terms per DEC-07-17. - **BR-07-18** — Tenant offboarding (URS-08) cannot complete while the tenant has active studies or unresolved cross-tenant grants where it is the lead; `TENANT_OFFBOARDING_BLOCKED_BY_OPEN_STUDIES` per J-24. - **BR-07-19** — Audit-log writes are atomic with the originating action per URS-04 BR-04-15 / URS-06 BR-06-01. - **BR-07-20** — Study-confidential content (draft documents, in-progress findings) is visible only to study members; non-members are denied with `403 STUDY_CONFIDENTIAL_NOT_MEMBER`. ### 6.6 Audit trail requirements Module 7 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): `STUDY_CREATED`, `STUDY_SUBMITTED_FOR_SETUP`, `STUDY_ACTIVATED`, `STUDY_HOLD_PLACED`, `STUDY_HOLD_RELEASED`, `STUDY_CLOSED_OUT`, `STUDY_ARCHIVED`, `STUDY_WITHDRAWN`, `STUDY_AMENDMENT_PROPOSED`, `STUDY_AMENDMENT_REVIEW_SIGNED`, `STUDY_AMENDMENT_FINAL_SIGNED`, `STUDY_AMENDMENT_EFFECTIVE`, `STUDY_AMENDMENT_WITHDRAWN`, `STUDY_MEMBER_ADDED`, `STUDY_MEMBER_REMOVED`, `STUDY_MEMBER_QUALIFICATION_REVALIDATED`, `STUDY_MASTER_FILE_DOCUMENT_LINKED`, `STUDY_MASTER_FILE_DOCUMENT_UNLINKED`, `MASTER_FILE_COMPLETENESS_CHECK_RUN`, `STUDY_REGULATORY_FRAMEWORK_SET`, `CROSS_TENANT_COLLABORATION_PROPOSED`, `CROSS_TENANT_COLLABORATION_ACCEPTED`, `CROSS_TENANT_COLLABORATION_DECLINED`, `CROSS_TENANT_COLLABORATION_REVOKED`, `CROSS_TENANT_COLLABORATION_AUTO_DECLINED`, `CROSS_TENANT_STUDY_ACCESS_USED`, `STUDY_RECORD_MANUAL_LABEL_APPENDED`, `STUDY_RECORD_MANUAL_LABEL_REVOKED`, `STUDY_DISCOVERY_VIEW_OPENED`, `STUDY_DISCOVERY_EXPORTED`, `STUDY_CATALOGUE_VIEW_OPENED`, `STUDY_MILESTONE_COMPLETED`, `STUDY_MILESTONE_LATE`, `SUCCESSOR_STUDY_CREATED_FROM_ARCHIVED`, `STUDY_CONFIDENTIAL_ACCESS_DENIED` (forensic), `REGULATORY_FRAMEWORK_REGISTRY_PUBLISHED`, `CLINICAL_TYPE_ACTIVATED_FOR_TENANT`, `CLINICAL_TYPE_REVOKED_FOR_TENANT`, `TENANT_OFFBOARDING_BLOCKED_BY_OPEN_STUDIES`, `PLATFORM_TENANT_ACCESS_USED`, `PLATFORM_TENANT_ACCESS_DENIED`. ### 6.7 Record versioning and class-of-change governance - Versioned (immutable per published version): `study_protocol_versions`, `study_scope_versions`, `study_regulatory_framework_registry`. - Stateful with append-only audit history: `studies` (lifecycle state machine), `study_amendments` (state machine), `study_members` (add / remove preserved), `cross_tenant_collaboration_grants` (state machine), `study_calendar_milestones`, `study_record_manual_labels`, `clinical_type_tenant_activations`. - Append-only: `study_master_file_documents`, `study_close_out_packages`. - Soft-delete: `studies` (withdrawn / archived; never hard-deleted). --- ## 7. Cross-Module Wiring and Change-Impact ### 7.1 Cross-module wiring #### Diagram 7-A — Module 7 in the suite ```mermaid graph LR subgraph M7 [Module 7 — Study Management] CAT[Study Catalogue] LCY[Lifecycle] MEM[Members] SCP[Scope] AMD[Amendments] COLL[Cross-Tenant] DOC[Master File] CLO[Close-Out] end M1[URS-01 Auth] --> MEM M2[URS-02 RBAC] --> MEM M3[URS-03 Active Scope] <--> SCP M4[URS-04 Workflow / E-Sign] --> LCY M4 --> AMD M5[URS-05 Authority] --> LCY M6[URS-06 Audit Substrate] --> LCY M8[URS-08 Tenant Lifecycle] --> COLL M12[URS-12 Document Control] <--> DOC M28[URS-28 Training Management & Qualification] --> MEM M30[URS-30 Notifications] --> LCY M30 --> AMD M30 --> COLL M35[URS-35 Backup / Restore / Cold Storage] <--> M7 CAT --> M14[URS-14..URS-34 Domain modules] ``` URS-03 active-scope intersection consumes the study scope from `study_scope_versions`. URS-04 fires study-aware workflows on study activation, amendment, hold / release, and close-out. URS-05 layers a study-level role overlay on top of base roles and Authority Profile assignments. URS-06 audits every Module 7 lifecycle event through the tenant chain (and the cross-tenant grant events into both tenants' chains). URS-08 owns tenant lifecycle; cross-tenant collaboration grants require both tenants in valid state. URS-12 owns the controlled documents that compose the master file; Module 7 owns the linkage. URS-28 owns the qualification register (per the URS-05 / URS-06 corrected mapping); Module 7 enforces qualification linkage at member creation. URS-30 delivers notifications. URS-35 owns the long-term archive. ### 7.2 Change-Impact Matrix (CIM) | Change | Class | Impact on (modules) | Required revalidation | |---|---|---|---| | Add / remove study type (DEC-07-01) | 1 | URS-04 templates referencing the type; URS-12 master-file templates | Full regression of lifecycle + master-file completeness | | Activate clinical type for tenant (DEC-07-17) | 1 | URS-04 workflow templates, URS-28 qualification registry, URS-12 TMF templates | Full regression including GCP-readiness pack review | | Add lifecycle state | 1 | every consuming module | Full regression | | Add study role (DEC-07-04) | 1 | URS-05 SoD evaluation, URS-04 workflow templates | Full regression | | Add scope dimension to study scope | 1 | URS-05 §6.2.1 (canonical registry); URS-03 | Full regression of intersection logic | | Add amendment classification | 1 | RA review path; URS-04 templates | Full regression | | Change auto-archive window default | 2 | URS-30 reminder timing | Targeted regression | | Add regulation to platform registry (DEC-07-11) | 2 | master-file templates, audit cadence | Targeted regression | | Change tenant default regulatory framework set | 3 | tenant only | Tenant-scope regression | | Add audit event code | 3 | URS-06 | Writer-presence regression | | UI copy or layout change | 4 | none | Visual regression | ### 7.3 Cross-module dependencies (consumed by Module 7) | Dependency | Source | Impact | Blocking? | |---|---|---|---| | Authentication, MFA step-up | URS-01 | Substrate | Blocking | | Effective permissions | URS-02 | Base role gate | Blocking | | Active scope | URS-03 | Study-bound discovery | Blocking | | Workflow / e-sig ceremony | URS-04 | Lifecycle and amendment signatures | Blocking | | Authority resolver | URS-05 | Activation, close-out, amendment authority | Blocking | | Audit substrate | URS-06 | Lifecycle audit | Blocking | | Tenant lifecycle | URS-08 | Cross-tenant collaboration; offboarding cascade | Blocking | | Document control | URS-12 | Master file linkage | Blocking | | Qualification register | URS-28 | Member qualification gating | Blocking | | Notifications | URS-30 | Reminders, escalations | Non-blocking (direct e-mail fallback) | | Backup / restore | URS-35 | Long-term archive | Blocking for PQ | --- ## 8. AI / Automation / Human-in-the-Loop Controls Module 7 contains **no AI / ML components** in the lifecycle, scope, amendment, master-file, collaboration, close-out, or discovery paths. Discovery is rule-based (URS-03 active-scope intersection); master-file completeness is a deterministic checklist over the regulatory framework registry; close-out is a deterministic checklist over study-bound findings. AI suggestions in URS-32 / MIRA that inform members about possible findings, suggested amendments, or master-file gaps are advisory only and MUST set `ai_advisory = true` per URS-06 DEC-06-15 and CLAUDE.md QS-21; the human acceptance is a separate audit row with `ai_advisory = false` and the human's electronic signature. The HITL lifecycle is owned by URS-04. Module 7 consumes the Controlled Approval Modal for every electronic signature (activation, amendment review and final sign, close-out, hold / release, member add / remove, manual label, cross-tenant grant invitation / acceptance / revocation). Static analysis MUST verify zero references to LLM SDKs in Module 7 source per QS-21. --- ## 9. Reports, Dashboards, and Exports | Report | Purpose | Audience | Format | |---|---|---|---| | Per-tenant study catalogue | Inventory and lifecycle posture | Tenant administrator, auditor | CSV + PDF | | Per-study dashboard | Lifecycle, members, amendments, master-file completeness, milestones | Study members, auditor | PDF + JSON | | Study-bound regulated-record discovery export | Inspection-ready list of all records intersecting study scope | Tenant administrator, auditor, inspector | PDF + JSON + integrity manifest | | Cross-tenant collaboration register | Bilateral grants, scope, members, lifecycle | Tenant administrator, auditor | CSV + PDF | | Amendment register (per study) | Amendment lifecycle and protocol-version history | Study members, auditor | PDF + JSON | | Member register with qualification status | Members, roles, qualification linkage | Study lead, auditor | CSV | | Master-file completeness report | Per-study against framework checklist | Study lead, auditor | PDF | | Close-out package | Final report + resolved findings + master file + signatures | Study lead, quality lead, auditor | PDF (electronically signed) | | Clinical-type activation register | Per-tenant clinical activations and revocations | Founder, platform administrator | PDF | | Successor-study linkage report | Archived studies with successor links | Auditor | CSV | Every export routes through the Controlled Approval Modal, carries an electronic signature, a signed download URL with 15-minute TTL unless a stricter TTL is specified, and an integrity manifest accompanies every export per URS-06 DEC-06-10. --- ## 10. Notifications and Queues | Trigger | Recipient | Channel | Latency | |---|---|---|---| | Study created | study lead, tenant administrator | URS-30 in-app + e-mail | within 60 seconds | | Study submitted for setup | activation approver pool | URS-30 in-app + e-mail | within 60 seconds | | Study activated | all members | URS-30 in-app + e-mail | within 60 seconds | | Study held / released | all members; cross-tenant partners | URS-30 in-app + e-mail | within 60 seconds | | Amendment proposed | study reviewers | URS-30 in-app + e-mail | within 60 seconds | | Amendment review signed | study lead | URS-30 in-app + e-mail | within 60 seconds | | Amendment effective | all members; cross-tenant partners | URS-30 in-app + e-mail | within 60 seconds | | Cross-tenant invitation | partner-tenant administrator | URS-30 in-app + e-mail | within 60 seconds | | Cross-tenant collaboration revoked | both tenants' administrators and members | URS-30 in-app + e-mail | within 60 seconds | | Close-out package ready | quality lead | URS-30 in-app + e-mail | within 60 seconds | | Close-out completed | tenant administrator | URS-30 in-app + e-mail | within 60 seconds | | Auto-archive approaching | study lead | URS-30 e-mail | T-7 days | | Member qualification expiring | member, study lead | URS-30 in-app + e-mail | T-30, T-7 | | Milestone late | owner, study lead | URS-30 in-app + e-mail | T-7, T-1, T+1 | | Clinical activation request | platform administrator, executive authority | URS-30 in-app + e-mail | within one business day | | Tenant offboarding blocked by open studies | tenant administrator (offboarding side) | URS-30 in-app + e-mail | within 60 seconds | --- ## 11. Error Handling and Negative Paths ### 11.1 Error envelope Standard envelope (human message, machine code in upper-snake-case, optional structured details, correlation identifier). ### 11.2 Error-code catalogue | Code | HTTP | Path | UI behaviour | |---|---|---|---| | STUDY_TYPE_NOT_ENABLED_FOR_TENANT | 403 | study create | inline error citing DEC-07-17 | | LEAD_QUALIFICATION_MISSING | 400 | study create | inline error citing required URS-28 evidence | | LEAD_QUALIFICATION_EXPIRED | 400 | study activate | inline error | | APPROVER_IS_CREATOR | 403 | study activate | inline error citing AUTHOR_NEQ_APPROVER | | FOUNDER_COSIGN_REQUIRED | 401 | study activate (high-risk) / amendment regulatory-framework-change | open executive authority co-sign request | | RA_COSIGN_REQUIRED | 401 | substantial amendment final-sign | open RA co-sign request | | STATE_NOT_DRAFT | 409 | lifecycle endpoints | inline error | | STATE_NOT_IN_SETUP | 409 | lifecycle endpoints | inline error | | STATE_NOT_ACTIVE | 409 | lifecycle endpoints | inline error | | STATE_NOT_ON_HOLD | 409 | lifecycle endpoints | inline error | | STATE_NOT_PROPOSED_LIFECYCLE | 409 | lifecycle endpoints | inline error | | STATE_NOT_REVIEW_SIGNED | 409 | lifecycle endpoints | inline error | | STATE_NOT_AMENDMENT_DRAFT | 409 | lifecycle endpoints | inline error | | STATE_NOT_AMENDMENT_REVIEW | 409 | lifecycle endpoints | inline error | | STATE_NOT_CLOSED_OUT | 409 | lifecycle endpoints | inline error | | MASTER_FILE_INCOMPLETE | 409 | close-out | inline error listing missing items | | OPEN_FINDINGS_REMAIN | 409 | close-out | inline error listing open findings | | STUDY_MEMBER_QUALIFICATION_MISSING | 400 | member add | inline error | | CROSS_TENANT_NOT_GRANTED | 403 | member add for partner-tenant user | inline error | | PARTNER_TENANT_NOT_VALID | 409 | cross-tenant invite | inline error | | PER_GRANT_SCOPE_EXCEEDS_STUDY | 400 | cross-tenant invite | inline error | | STATE_NOT_PROPOSED | 409 | cross-tenant accept / decline | inline error | | OUT_OF_SCOPE_RECORD_CANNOT_BE_LABELED_IN_SCOPE | 400 | manual label | inline error | | RATIONALE_TOO_SHORT | 400 | amendment / withdrawal | inline error citing minimum | | EFFECTIVE_FROM_BEFORE_NOW | 400 | amendment | inline error | | TENANT_OFFBOARDING_BLOCKED_BY_OPEN_STUDIES | 409 | URS-08 offboarding | banner + remediation list | | STUDY_CONFIDENTIAL_NOT_MEMBER | 403 | study-confidential read by non-member | 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 | |---|---|---|---| | Activator is the creator | back end | `403 APPROVER_IS_CREATOR` | inline error | | High-risk type missing executive authority co-sign | back end | `401 FOUNDER_COSIGN_REQUIRED` | open executive authority co-sign request | | Substantial amendment missing RA co-sign | back end | `401 RA_COSIGN_REQUIRED` | open RA co-sign request | | Member qualification expires mid-study | URS-05 resolver | `403 APPROVAL_AUTHORITY_DENIED` reason `QUALIFICATION_EVIDENCE_EXPIRED` | inline; URS-30 notify | | Cross-tenant invitation to invalid tenant | back end | `409 PARTNER_TENANT_NOT_VALID` | inline error | | Cross-tenant per-grant scope exceeds study scope | back end | `400 PER_GRANT_SCOPE_EXCEEDS_STUDY` | inline error | | Manual label for out-of-scope record asserted in_scope | back end | `400 OUT_OF_SCOPE_RECORD_CANNOT_BE_LABELED_IN_SCOPE` | inline error | | Close-out attempted with master file incomplete | back end | `409 MASTER_FILE_INCOMPLETE` | inline list | | Close-out attempted with open findings | back end | `409 OPEN_FINDINGS_REMAIN` | inline list | | Tenant offboarding while open studies exist | URS-08 → Module 7 | `409 TENANT_OFFBOARDING_BLOCKED_BY_OPEN_STUDIES` | banner + remediation list | | Non-member reads study-confidential content | URS-12 + Module 7 | `403 STUDY_CONFIDENTIAL_NOT_MEMBER` | inline error | | Audit-write failure mid-decision | back end | `500 AUDIT_TRAIL_WRITE_FAILED` | toast; the regulated decision did NOT commit | --- ## 12. Security, Privacy, and Tenant Isolation ### 12.1 Authentication dependency URS-07 is reached only through an authenticated session per URS-01. Every Module 7 mutation (create, submit-for-setup, activate, hold, release, amendment review and final sign, member add / remove, master-file link, cross-tenant grant invite / accept / revoke, manual label, close-out, withdraw) goes through the URS-04 Controlled Approval Modal with electronic signature; high-risk decisions (high-risk type activation, regulatory-framework-change amendment, cross-tenant grant invite / accept) additionally require multi-factor step-up. ### 12.2 Authorisation pipeline `authenticate hook → tenant hook → rbac hook → context gate hook → study-membership overlay hook → esigService.createSignature where applicable → module7 surface action`. Module 7 owns the study-membership overlay hook position. ### 12.3 Tenant isolation Every study-record query routes through TDAL with tenant context bound. RLS on `studies.tenant_id` enforces single-tenant scope. Cross-tenant access is enforced at the per-grant level: a partner-tenant user can read only the per-grant scope, never the lead-tenant's other studies, never other tenants. Every cross-tenant access emits `CROSS_TENANT_STUDY_ACCESS_USED` in BOTH tenants' URS-06 chains. ### 12.4 Encryption At rest: study `details_jsonb`, `regulatory_framework_jsonb`, `scope_jsonb`, `details` of amendments and discovery reports 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. Structured logs carry the correlation identifier on every request. ### 12.6 Privacy and data residency Inherits tenant data-residency configuration from URS-08. Cross-tenant studies respect both tenants' residency requirements; data location is determined by the lead-tenant's residency unless the per-grant terms specify otherwise; partner-tenant access does not move data across residency boundaries. ### 12.7 Periodic access review Per URS-05 §12.7: the Module 7 study-role overlays for every active study are reviewed annually. Reviewer enumerates every study member and attests continuation per role; rejections trigger member removal. ### 12.8 Periodic audit-trail review Per URS-06 DEC-06-14: high-risk Module 7 events triaged within one business day: `STUDY_HOLD_PLACED` (especially with `global_quality_oversight` override), `CROSS_TENANT_COLLABORATION_REVOKED`, `CLINICAL_TYPE_ACTIVATED_FOR_TENANT`, `STUDY_AMENDMENT_FINAL_SIGNED` for `substantial` classification, `TENANT_OFFBOARDING_BLOCKED_BY_OPEN_STUDIES`. ### 12.9 Security-operations alert thresholds | Pattern | Threshold | Severity | Channel | |---|---|---|---| | `STUDY_HOLD_PLACED` with `global_quality_oversight` override | any single event | critical | SOC chat + executive authority e-mail | | `CROSS_TENANT_COLLABORATION_REVOKED` cluster | three in 24 hours same tenant | high | SOC chat | | `STUDY_CONFIDENTIAL_ACCESS_DENIED` cluster | five per user per hour | medium | SOC e-mail digest | | `CLINICAL_TYPE_ACTIVATED_FOR_TENANT` | any single event | informational (real-time) | SOC chat | | `TENANT_OFFBOARDING_BLOCKED_BY_OPEN_STUDIES` | any single event | high | SOC chat | | `MASTER_FILE_INCOMPLETE` at close-out attempt | any single event | informational | log only | | `PLATFORM_TENANT_ACCESS_USED` for Module 7 | any single event | informational (real-time) | SOC chat | ### 12.10 Self-modification block A user MUST NOT activate a study they themselves created (BR-07-01 / `AUTHOR_NEQ_APPROVER`). A user MUST NOT review their own proposed amendment as `study_reviewer` if `REVIEWER_NEQ_FINAL_APPROVER` applies. Cross-tenant collaboration acceptance MUST be signed by a tenant administrator who is NOT the same human as the inviter on the lead-tenant side (`CROSS_TENANT_SAME_USER_FORBIDDEN`). ### 12.11 Secure export Every export routes through the Controlled Approval Modal. Signed download URLs with 15-minute TTL. Integrity manifest accompanies every export per URS-06. ### 12.12 Cross-tenant confidentiality envelope Cross-tenant studies operate under a strict per-grant envelope: the partner tenant sees only what the per-grant scope permits; lead-tenant other studies, lead-tenant other regulated records outside the per-grant scope, and lead-tenant authority assignments unrelated to the study are NEVER visible to the partner tenant; URS-03 cross-tenant active-scope rules enforce; URS-06 audits every access. --- ## 13. Data Integrity and ALCOA+ Controls | Principle | Module 7 control | Requirement | Verification | |---|---|---|---| | Attributable | Every study record carries `created_by`, `lead_user_id`, member rows attributed to assigner; system-actor writes prohibited as study lead | URS-07-AUD-001 | Integration test | | Legible | Study detail rendered in structured form; exports in PDF + JSON | URS-07-REP-001 | Export test | | Contemporaneous | Server-set timestamps; client-supplied dropped | URS-07-AUD-002 | Integration test | | Original | Immutable protocol versions and scope versions; amendment lifecycle preserves history | URS-07-AUD-003 | Validation test | | Accurate | Snapshot pinning (BR-07-06) prevents amendments from retroactively altering prior decisions; manual labels cannot bring out-of-scope records into study | URS-07-DATA-001 | Integration test | | Complete | Every event in §6.6 has at least one writer | URS-07-AUD-004 | Validation test | | Consistent | Master-file completeness check enforces framework-derived requirements; close-out enforces resolution of open findings | URS-07-AUD-005 | Validation test | | Enduring | Per-study-type retention class drives URS-06 / URS-35 long-term archive | URS-07-DATA-002 | Migration test | | Available | Studies remain query-accessible through archived state; cold-tier queries return with latency badge | URS-07-REP-002 | End-to-end test | --- ## 14. Regulatory Mapping | Identifier | Control | Regulation / Guidance | Clause | Applicable | Implementation expectation | |---|---|---|---|---|---| | RG-07-001 | Records of clinical-trial conduct | ICH GCP E6(R3) | §3, §4 | Conditional (clinical types) | Per-study TMF + amendment lifecycle | | RG-07-002 | Investigator records | 21 CFR Part 312 | §312.62 | Conditional (clinical types in US) | Member + study record | | RG-07-003 | IND application records | 21 CFR Part 312 | §312.20 | Conditional | Per-study regulatory submission references | | RG-07-004 | EU Clinical Trials Regulation | Regulation (EU) 536/2014 | applicable | Conditional (clinical types in EU) | Per-study EUDRACT references | | RG-07-005 | Stability testing | ICH Q1A(R2) | §2 | Yes (stability type) | Per-study scope + master file | | RG-07-006 | Process validation | 21 CFR Part 211 / FDA Process Validation Guidance (2011) / EU GMP Annex 15 | applicable | Yes (process_validation type) | Per-study lifecycle + close-out | | RG-07-007 | Equipment qualification | EU GMP Annex 15 / ASTM E2500 | applicable | Yes (equipment_qualification type) | Per-study lifecycle | | RG-07-008 | GLP records | 21 CFR Part 58 / OECD GLP Principles | applicable | Conditional | Per-study scope + audit cadence | | RG-07-009 | GMP records retention | EU GMP Chapter 4 / 21 CFR Part 211 §211.180 | applicable | Yes | Per-study retention class | | RG-07-010 | Audit trail | 21 CFR Part 11 | §11.10(e) | Yes | URS-06 substrate | | RG-07-011 | Validation of computerised systems | EU GMP Annex 11 | §4 | Yes | CSV / CSA pack per §17 | | RG-07-012 | Risk-based assurance | FDA Computer Software Assurance for Production and Quality Management System Software, Final Guidance, February 2026 | applicable | Yes | Risk classification per validation pack | | RG-07-013 | ALCOA+ data integrity | MHRA Data Integrity Guidance (2018) | nine principles | Yes | §13 mapping | | RG-07-014 | EU AI Act applicability | Regulation (EU) 2024/1689 | Article 3(1) | Not applicable to this module | No AI; documented exclusion | | RG-07-015 | EU GMP Annex 22 (Draft 2025) | EU GMP Annex 22 | applicable forward-looking | Forward-looking only | No Annex-22-dependent control | | RG-07-016 | Bioequivalence (US) | 21 CFR Part 320 | applicable | Yes (bioequivalence type) | Per-study scope + report | | RG-07-017 | India clinical / study regulatory framework — D&C Act 1940 + Drugs Rules 1945 + New Drugs and Clinical Trials Rules 2019 (where studies / clinical operations are in scope) + CDSCO GCP guidance + Revised Schedule M (where study scope spans GMP manufacturing) + Medical Devices Rules 2017 (where device / combination-product studies are in scope) | India Drugs and Cosmetics Act 1940; Drugs Rules 1945; New Drugs and Clinical Trials Rules 2019; CDSCO GCP guidance; Revised Schedule M; Medical Devices Rules 2017 | Applicable per India tenant operation and jurisdictional regulatory assessment | Conditional (India studies / clinical sites / device-product studies per applicable scope) | Per-study scope + RA disposition under URS-08 controls; CDSCO clinical-trial registration evidence captured per study; external jurisdictional legal / RA confirmation required for clause / form applicability per India study scope | ### 14.1 Predicate-rule applicability matrix | Record / artifact | Predicate-rule basis | Part 11 applicable? | Retention | Owner | Evidence | |---|---|---|---|---|---| | Study record (lifecycle states) | Investigation evidence | Yes (Part 11 §11.10(e)) | per study type | QA | Per-study lifecycle audit trail | | Protocol version | Investigation baseline evidence | Yes | per study type | QA | URS-12 controlled document + protocol-version row | | Scope version | Authority-of-record evidence | Yes | per study type | QA | URS-12 controlled document + scope-version row | | Amendment record | URS-13 evidence | Yes | per study type | QA / RA | Amendment row + signatures | | Master-file linkage | Document-control evidence | Yes | per study type | QA | URS-12 + Module 7 linkage table | | Cross-tenant collaboration grant | Bilateral authorisation evidence | Yes | per study type | QA / Legal | Grant row + bilateral signatures + URS-06 cross-tenant access trail | | Close-out package | Investigation completion evidence | Yes | per study type | QA / Founder | Final report + signatures + master file | | Member roster | Personnel-qualification evidence | Yes | per study type | QA / Training | Member rows + URS-28 qualification linkage | | Manual record-to-study label | Operational annotation evidence | Yes (operational) | per study type | QA | Manual-label row + signature | | Successor-study linkage | Continuity evidence | Yes | per study type | QA | Successor row + signature | | Clinical activation record (per tenant) | Founder-level governance evidence | Yes | retain (long-term) | Founder + QA | Activation row + executive authority signature + GCP-readiness pack | --- ## 15. URS Requirements Register ### 15.1 Front-end (FE) - URS-07-FE-001 — Study creation wizard MUST surface multi-select for regulatory framework and live-validate qualification linkage for the nominated lead. Priority MUST. Risk MEDIUM. Maps RG-07-005..009. - URS-07-FE-002 — Per-study detail MUST present a tabbed view (Overview, Members, Scope, Amendments, Master File, Records, Calendar, Close-Out). Priority MUST. Risk LOW. - URS-07-FE-003 — Cross-tenant studies MUST visually distinguish lead-tenant vs partner-tenant content. Priority MUST. Risk MEDIUM. - URS-07-FE-004 — Discovery view MUST show manual-label badges visually distinct from canonical scope-intersection results. Priority MUST. Risk MEDIUM. - URS-07-FE-005 — Master-file completeness check MUST list missing items inline and refuse close-out submission until resolved. Priority MUST. Risk HIGH. - URS-07-FE-006 — Manual-label surface MUST refuse `assertion = 'in_scope'` for records whose scope does not intersect the study scope. Priority MUST. Risk HIGH. - URS-07-FE-007 — Amendment surface MUST surface classification helper (substantial / non-substantial / administrative). Priority SHOULD. Risk MEDIUM. - URS-07-FE-008 — Every route in §5.1 MUST be registered in the application router before release. Priority MUST. Risk LOW. - URS-07-FE-009 — All Module 7 surfaces MUST meet WCAG 2.1 Level AA. Priority MUST. Risk MEDIUM. ### 15.2 Back-end (BE) - URS-07-BE-001 — Study activation MUST require an approver independent of the creator (`AUTHOR_NEQ_APPROVER`). Priority MUST. Risk HIGH. - URS-07-BE-002 — High-risk study type activation MUST require executive authority co-sign per DEC-07-03. Priority MUST. Risk HIGH. - URS-07-BE-003 — Member addition MUST verify URS-28 qualification linkage. Priority MUST. Risk HIGH. - URS-07-BE-004 — Study scope MUST be immutable from activation to close-out except through controlled amendment. Priority MUST. Risk CRITICAL. - URS-07-BE-005 — Substantial amendment MUST require `regulatory_oversight_admin` co-sign. Priority MUST. Risk HIGH. - URS-07-BE-006 — Regulatory-framework-change amendment MUST require executive authority co-sign. Priority MUST. Risk HIGH. - URS-07-BE-007 — Snapshot pinning MUST preserve protocol-version-at-decision-time so amendments do not retroactively alter prior decisions. Priority MUST. Risk CRITICAL. - URS-07-BE-008 — Cross-tenant collaboration grants MUST require bilateral electronic signatures. Priority MUST. Risk HIGH. - URS-07-BE-009 — Cross-tenant access MUST emit `CROSS_TENANT_STUDY_ACCESS_USED` in BOTH tenants' chains per access. Priority MUST. Risk HIGH. - URS-07-BE-010 — Cross-tenant collaboration revocation MUST cascade to revoke any URS-05 Authority Profile assignments granted to partner-tenant users for the study. Priority MUST. Risk HIGH. - URS-07-BE-011 — Study-bound regulated-record discovery MUST be computed via URS-03 active-scope intersection. Priority MUST. Risk CRITICAL. - URS-07-BE-012 — Manual labels with `in_scope` assertion MUST be refused for out-of-scope records. Priority MUST. Risk HIGH. - URS-07-BE-013 — Master-file completeness MUST be checked at close-out and prevent close-out on `MASTER_FILE_INCOMPLETE`. Priority MUST. Risk HIGH. - URS-07-BE-014 — Close-out MUST be blocked while open findings remain on study-bound regulated records. Priority MUST. Risk HIGH. - URS-07-BE-015 — Auto-archive MUST fire after the configured close-to-archive window. Priority MUST. Risk MEDIUM. - URS-07-BE-016 — Archived studies MUST NOT transition back to active; J-28 successor-study path applies. Priority MUST. Risk HIGH. - URS-07-BE-017 — Withdrawn studies MUST be soft-deleted and remain query-accessible. Priority MUST. Risk MEDIUM. - URS-07-BE-018 — Clinical type activation per tenant MUST require Founder electronic signature plus tenant supplemental contract terms. Priority MUST. Risk HIGH. - URS-07-BE-019 — Tenant offboarding MUST be blocked while open studies or unresolved cross-tenant grants exist on the offboarding side. Priority MUST. Risk HIGH. - URS-07-BE-020 — Audit-log writes MUST be atomic with the originating action per URS-04 BR-04-15 / URS-06 BR-06-01. Priority MUST. Risk CRITICAL. - URS-07-BE-021 — Study-confidential content MUST be visible only to study members. Priority MUST. Risk HIGH. ### 15.3 Workflow (WF) - URS-07-WF-001 — Lifecycle state machine per Diagram 6.1-B. Priority MUST. Risk HIGH. - URS-07-WF-002 — Amendment state machine: `proposed → under_review → ready_for_final_sign → effective` (or `withdrawn`). Priority MUST. Risk HIGH. - URS-07-WF-003 — Cross-tenant collaboration state machine per Diagram 6.1-D. Priority MUST. Risk HIGH. - URS-07-WF-004 — Auto-archive scheduled at `closed_at + close_to_archive_window`. Priority MUST. Risk MEDIUM. - URS-07-WF-005 — Cross-tenant invitation auto-decline at 30 days default. Priority SHOULD. Risk MEDIUM. ### 15.4 Data (DATA) - URS-07-DATA-001 — Snapshot pinning per BR-07-06; subsequent amendments do not retroactively alter prior decisions. Priority MUST. Risk CRITICAL. - URS-07-DATA-002 — Per-study-type retention class drives URS-06 / URS-35 long-term archive. Priority MUST. Risk HIGH. - URS-07-DATA-003 — Scope JSONB keys MUST be from URS-05 §6.2.1 canonical authority scope dimension registry. Priority MUST. Risk HIGH. ### 15.5 Security (SEC) - URS-07-SEC-001 — Tenant isolation via TDAL + RLS on every Module 7 tenant-scoped table. Priority MUST. Risk CRITICAL. - URS-07-SEC-002 — Cross-tenant access enforced at per-grant level; lead-tenant content outside per-grant scope NEVER visible to partner. Priority MUST. Risk CRITICAL. - URS-07-SEC-003 — Multi-factor step-up required for high-risk activations, regulatory-framework-change amendments, cross-tenant invite/accept. Priority MUST. Risk HIGH. - URS-07-SEC-004 — Self-modification block: creator cannot activate own study; reviewer cannot review own amendment when SoD applies. Priority MUST. Risk HIGH. ### 15.6 Audit (AUD) - URS-07-AUD-001 — Every Module 7 mutation MUST produce an audit row through URS-06. Priority MUST. Risk CRITICAL. - URS-07-AUD-002 — Server-set timestamps; client-supplied dropped. Priority MUST. Risk HIGH. - URS-07-AUD-003 — Append-only protocol versions, scope versions, master-file linkages, close-out packages. Priority MUST. Risk HIGH. - URS-07-AUD-004 — Every event in §6.6 has at least one writer + regression test. Priority MUST. Risk HIGH. - URS-07-AUD-005 — Cross-tenant access emits in BOTH tenants' chains per BR-07-08. Priority MUST. Risk HIGH. ### 15.7 AI / HITL (AI) - URS-07-AI-001 — Module 7 contains no AI / ML components in core path; static analysis MUST find zero LLM SDK references. Priority MUST. Risk HIGH. - URS-07-AI-002 — AI suggestions to study members MUST set `ai_advisory = true` per URS-06 DEC-06-15. Priority MUST. Risk HIGH. ### 15.8 Integration (INT) - URS-07-INT-001 — Study scope MUST feed URS-03 active-scope intersection. Priority MUST. Risk CRITICAL. - URS-07-INT-002 — Member qualification MUST integrate with URS-28. Priority MUST. Risk HIGH. - URS-07-INT-003 — Master-file linkage MUST integrate with URS-12. Priority MUST. Risk HIGH. - URS-07-INT-004 — Lifecycle audit MUST flow through URS-06. Priority MUST. Risk CRITICAL. - URS-07-INT-005 — Tenant offboarding integration with URS-08 per BR-07-18. Priority MUST. Risk HIGH. - URS-07-INT-006 — Notifications via URS-30. Priority MUST. Risk MEDIUM. ### 15.9 Reporting (REP) - URS-07-REP-001 — Every report listed in §9 MUST be exportable with electronic signature and integrity manifest. Priority MUST. Risk MEDIUM. - URS-07-REP-002 — Discovery export MUST verify chain integrity end-to-end across all involved chains per URS-06. Priority MUST. Risk HIGH. - URS-07-REP-003 — Signed download URL TTL MUST be 15 minutes. Priority MUST. Risk MEDIUM. ### 15.10 Notifications (NOTIF) - URS-07-NOTIF-001 — Every notification listed in §10 MUST be delivered through URS-30 with the specified latency. Priority MUST. Risk MEDIUM. - URS-07-NOTIF-002 — Cross-tenant notifications MUST reach both tenants. Priority MUST. Risk HIGH. ### 15.11 Validation (VAL) - URS-07-VAL-001 — Test execution MUST cover IQ (schema, RLS, indexes, constraints, scope-intersection bootstrap), OQ (per URS-07-VAL-002), PQ (per URS-07-VAL-003), regression (per URS-07-VAL-004). - URS-07-VAL-002 — OQ MUST validate every API endpoint, every error code, every state transition, every audit event writer. - URS-07-VAL-003 — PQ MUST validate the scope-intersection discovery view under representative tenant volume (e.g., 100K records per study) with acceptable latency. - URS-07-VAL-004 — Regression MUST run on every Class 1 / Class 2 change. - URS-07-VAL-005 — Requirements-to-test traceability matrix per §16.4. - URS-07-VAL-006 — Supplier qualification pack per §17.1. - URS-07-VAL-007 — Inspection-ready evidence index per §17.2. - URS-07-VAL-008 — Migration evidence gate: schema migrations idempotent; seed of regulatory framework registry; clinical-type activation registry seed; chain-bootstrap consistent; restore drill verifies study integrity. --- ## 16. Acceptance Criteria and Test Cases ### 16.1 Plain-language test cases - TC-PLAIN-001 — A QA Manager opens a stability study, fills in scope, nominates members, and the system warns inline if any member is missing required ICH Q1 training. - TC-PLAIN-002 — The user who created a study cannot also activate it; a different user must sign activation. - TC-PLAIN-003 — A process validation study that gates batch release requires executive authority co-sign at activation. - TC-PLAIN-004 — A substantial amendment requires a regulatory affairs co-sign in addition to the study lead. - TC-PLAIN-005 — Sponsor and CRO both sign before a cross-tenant collaboration is active; either can revoke. - TC-PLAIN-006 — When a study is on hold, no new milestones progress; releasing the hold resumes activity. - TC-PLAIN-007 — At close-out, the system refuses to close the study while master-file documents are missing. - TC-PLAIN-008 — At close-out, the system refuses to close the study while open findings remain on study-bound records. - TC-PLAIN-009 — A withdrawn study still appears for the auditor; it is not deleted. - TC-PLAIN-010 — An archived study cannot be reactivated; instead, a successor study can be created referencing the archived predecessor. - TC-PLAIN-011 — Manual labelling cannot bring an out-of-scope record into the study; it can only annotate as related-out-of-scope. - TC-PLAIN-012 — Tenant offboarding is blocked while the tenant has open lead-tenant studies. - TC-PLAIN-013 — A non-member cannot read draft study documents even with `quality_lead` base role. - TC-PLAIN-014 — Clinical phase types are disabled at launch and require Founder activation per tenant. ### 16.2 Technical test cases - TC-TECH-001 — Study activation by creator returns `403 APPROVER_IS_CREATOR`. - TC-TECH-002 — High-risk type activation without executive authority co-sign returns `401 FOUNDER_COSIGN_REQUIRED`. - TC-TECH-003 — Member add without URS-28 qualification linkage returns `400 STUDY_MEMBER_QUALIFICATION_MISSING`. - TC-TECH-004 — Substantial amendment without RA co-sign returns `401 RA_COSIGN_REQUIRED`. - TC-TECH-005 — Regulatory-framework-change amendment without executive authority co-sign returns `401 FOUNDER_COSIGN_REQUIRED`. - TC-TECH-006 — Cross-tenant collaboration without partner acceptance remains in `proposed` state; access not granted. - TC-TECH-007 — Cross-tenant access by partner-tenant member emits `CROSS_TENANT_STUDY_ACCESS_USED` in both tenants' chains. - TC-TECH-008 — Cross-tenant collaboration revocation cascades Authority Profile assignments per BR-07-09. - TC-TECH-009 — Manual label with `assertion='in_scope'` for out-of-scope record returns `400 OUT_OF_SCOPE_RECORD_CANNOT_BE_LABELED_IN_SCOPE`. - TC-TECH-010 — Close-out with master file incomplete returns `409 MASTER_FILE_INCOMPLETE`. - TC-TECH-011 — Close-out with open findings remaining returns `409 OPEN_FINDINGS_REMAIN`. - TC-TECH-012 — Auto-archive scheduled job moves studies from `closed` to `archived` after the window. - TC-TECH-013 — Archive-to-active transition refused with `409 STATE_NOT_PERMITTED`. - TC-TECH-014 — Withdrawn study appears in auditor query but not in active catalogue. - TC-TECH-015 — Snapshot pinning: a regulated decision signed at protocol v1.0 references v1.0 in its authority snapshot even after v2.0 is effective. - TC-TECH-016 — Tenant offboarding while study is `active` returns `409 TENANT_OFFBOARDING_BLOCKED_BY_OPEN_STUDIES`. - TC-TECH-017 — Non-member attempt to read draft document returns `403 STUDY_CONFIDENTIAL_NOT_MEMBER`. - TC-TECH-018 — Clinical-type study creation in a tenant without activation returns `403 STUDY_TYPE_NOT_ENABLED_FOR_TENANT`. - TC-TECH-019 — Schema migrations idempotent; RLS enabled on every Module 7 tenant-scoped table. - TC-TECH-020 — Penetration test: cross-tenant query without active collaboration returns RLS-empty. - TC-TECH-021 — Discovery view computes intersection correctly across multiple scope dimensions including `module`, `entity_type`, `workflow_type` from URS-05 §6.2.1 registry. - TC-TECH-022 — Per-study export integrity manifest includes Merkle proofs for all per-entity chains in the discovery footprint per URS-06 BR-06-10. - TC-TECH-023 — Static analysis finds zero LLM SDK references in Module 7 source. - TC-TECH-024 — `STUDY_CATALOGUE_VIEW_OPENED` and `STUDY_DISCOVERY_VIEW_OPENED` emit once per session each. - TC-TECH-025 — Close-to-archive window tenant-configurable upward only; below-default returns `400`. - TC-TECH-026 — Cross-tenant invitation auto-decline after 30 days; emits `CROSS_TENANT_COLLABORATION_AUTO_DECLINED`. ### 16.3 Acceptance criteria (Given / When / Then) - AC-07-FUN-01 — Given a study creator attempts activation, When called, Then `403 APPROVER_IS_CREATOR`. - AC-07-FUN-02 — Given a high-risk study type, When activation submitted without executive authority co-sign, Then `401 FOUNDER_COSIGN_REQUIRED`. - AC-07-FUN-03 — Given a substantial amendment, When final-sign submitted without RA co-sign, Then `401 RA_COSIGN_REQUIRED`. - AC-07-FUN-04 — Given an active cross-tenant collaboration, When partner-tenant user reads a study-confidential document, Then both tenants emit `CROSS_TENANT_STUDY_ACCESS_USED`. - AC-07-FUN-05 — Given cross-tenant collaboration revocation, When applied, Then any Authority Profile assignments to partner-tenant users for this study are cascade-revoked. - AC-07-FUN-06 — Given an out-of-scope record, When manual label `in_scope` attempted, Then `400 OUT_OF_SCOPE_RECORD_CANNOT_BE_LABELED_IN_SCOPE`. - AC-07-FUN-07 — Given study close-out attempt, When master file incomplete, Then `409 MASTER_FILE_INCOMPLETE`. - AC-07-FUN-08 — Given study close-out attempt, When open findings remain, Then `409 OPEN_FINDINGS_REMAIN`. - AC-07-PERM-01 — Given non-member, When study-confidential read, Then `403 STUDY_CONFIDENTIAL_NOT_MEMBER`. - AC-07-PERM-02 — Given non-`tenant_admin_authority`, When cross-tenant invite attempted, Then `403`. - AC-07-AUD-01 — Every Module 7 mutation produces an audit row through URS-06. - AC-07-AUD-02 — Audit-write failure rolls back the originating action. - AC-07-DI-01 — Snapshot pinning preserves protocol version at decision time. - AC-07-DI-02 — Backup-restore drill produces same study record state and same chain HEAD as source. - AC-07-INT-01 — URS-03 active-scope intersection produces correct discovery view. - AC-07-INT-02 — URS-08 offboarding integration blocks correctly. - AC-07-INT-03 — URS-28 qualification linkage enforced at member add and at decision time. - AC-07-REP-01 — Every export carries integrity manifest + electronic signature. - AC-07-AI-01 — Static analysis finds zero LLM SDK references in Module 7. - AC-07-NEG-01 — Every error code in §11.2 reachable by automated test. - AC-07-PERF-01 — Discovery view p95 ≤ 2 s for 100K-record tenant. - AC-07-SEC-01 — Penetration test: cross-tenant query without active collaboration returns RLS-empty. - AC-07-MIG-01 — Module 7 migrations idempotent. - AC-07-MIG-02 — Migrations seed regulatory framework registry; clinical-type activation registry; chain bootstrap consistent. ### 16.4 Requirements-to-test traceability | Requirement | Plain-language | Technical | Given / When / Then | |---|---|---|---| | URS-07-FE-001 | TC-PLAIN-001 | TC-TECH-003 | — | | URS-07-FE-002 | — | (UI test) | — | | URS-07-FE-003 | TC-PLAIN-005 | TC-TECH-007 | AC-07-FUN-04 | | URS-07-FE-004 | TC-PLAIN-011 | TC-TECH-009 | AC-07-FUN-06 | | URS-07-FE-005 | TC-PLAIN-007 | TC-TECH-010 | AC-07-FUN-07 | | URS-07-FE-006 | TC-PLAIN-011 | TC-TECH-009 | AC-07-FUN-06 | | URS-07-FE-007 | TC-PLAIN-004 | TC-TECH-004 | AC-07-FUN-03 | | URS-07-FE-008 | — | TC-TECH-019 | — | | URS-07-FE-009 | — | (accessibility test) | — | | URS-07-BE-001 | TC-PLAIN-002 | TC-TECH-001 | AC-07-FUN-01 | | URS-07-BE-002 | TC-PLAIN-003 | TC-TECH-002 | AC-07-FUN-02 | | URS-07-BE-003 | TC-PLAIN-001 | TC-TECH-003 | — | | URS-07-BE-004 | — | TC-TECH-015 | AC-07-DI-01 | | URS-07-BE-005 | TC-PLAIN-004 | TC-TECH-004 | AC-07-FUN-03 | | URS-07-BE-006 | — | TC-TECH-005 | — | | URS-07-BE-007 | — | TC-TECH-015 | AC-07-DI-01 | | URS-07-BE-008 | TC-PLAIN-005 | TC-TECH-006 | — | | URS-07-BE-009 | — | TC-TECH-007 | AC-07-FUN-04 | | URS-07-BE-010 | — | TC-TECH-008 | AC-07-FUN-05 | | URS-07-BE-011 | — | TC-TECH-021 | AC-07-INT-01 | | URS-07-BE-012 | TC-PLAIN-011 | TC-TECH-009 | AC-07-FUN-06 | | URS-07-BE-013 | TC-PLAIN-007 | TC-TECH-010 | AC-07-FUN-07 | | URS-07-BE-014 | TC-PLAIN-008 | TC-TECH-011 | AC-07-FUN-08 | | URS-07-BE-015 | — | TC-TECH-012 | — | | URS-07-BE-016 | TC-PLAIN-010 | TC-TECH-013 | — | | URS-07-BE-017 | TC-PLAIN-009 | TC-TECH-014 | — | | URS-07-BE-018 | TC-PLAIN-014 | TC-TECH-018 | — | | URS-07-BE-019 | TC-PLAIN-012 | TC-TECH-016 | AC-07-INT-02 | | URS-07-BE-020 | — | TC-TECH-019 | AC-07-AUD-02 | | URS-07-BE-021 | TC-PLAIN-013 | TC-TECH-017 | AC-07-PERM-01 | | URS-07-WF-001 | — | TC-TECH-012, TC-TECH-013 | — | | URS-07-WF-002 | TC-PLAIN-004 | TC-TECH-004 | — | | URS-07-WF-003 | TC-PLAIN-005 | TC-TECH-006, TC-TECH-026 | — | | URS-07-WF-004 | — | TC-TECH-012 | — | | URS-07-WF-005 | — | TC-TECH-026 | — | | URS-07-DATA-001 | — | TC-TECH-015 | AC-07-DI-01 | | URS-07-DATA-002 | — | TC-TECH-019 | — | | URS-07-DATA-003 | — | TC-TECH-021 | AC-07-INT-01 | | URS-07-SEC-001 | — | TC-TECH-019, TC-TECH-020 | AC-07-SEC-01 | | URS-07-SEC-002 | — | TC-TECH-007, TC-TECH-020 | AC-07-SEC-01 | | URS-07-SEC-003 | — | (MFA step-up test) | — | | URS-07-SEC-004 | TC-PLAIN-002 | TC-TECH-001 | AC-07-FUN-01 | | URS-07-AUD-001 | — | TC-TECH-024 | AC-07-AUD-01 | | URS-07-AUD-002 | — | (server timestamp test) | — | | URS-07-AUD-003 | — | TC-TECH-019 | — | | URS-07-AUD-004 | — | (writer-presence test) | — | | URS-07-AUD-005 | — | TC-TECH-007 | AC-07-FUN-04 | | URS-07-AI-001 | — | TC-TECH-023 | AC-07-AI-01 | | URS-07-AI-002 | — | (URS-32 integration test) | — | | URS-07-INT-001 | — | TC-TECH-021 | AC-07-INT-01 | | URS-07-INT-002 | TC-PLAIN-001 | TC-TECH-003 | — | | URS-07-INT-003 | TC-PLAIN-007 | TC-TECH-010 | AC-07-FUN-07 | | URS-07-INT-004 | — | TC-TECH-024 | AC-07-AUD-01 | | URS-07-INT-005 | TC-PLAIN-012 | TC-TECH-016 | AC-07-INT-02 | | URS-07-INT-006 | — | (notification delivery test) | — | | URS-07-REP-001 | — | TC-TECH-022 | AC-07-REP-01 | | URS-07-REP-002 | — | TC-TECH-022 | — | | URS-07-REP-003 | — | (TTL test) | — | | URS-07-NOTIF-001 | — | (notification delivery test) | — | | URS-07-NOTIF-002 | TC-PLAIN-005 | (cross-tenant notification test) | — | | URS-07-VAL-001 | — | TC-TECH-019 | — | | URS-07-VAL-002 | All applicable | All applicable | All applicable | | URS-07-VAL-003 | — | (PQ test) | AC-07-PERF-01 | | URS-07-VAL-004 | — | full TC-TECH suite | — | | URS-07-VAL-005 | — | this table is the seed | — | | URS-07-VAL-006 | — | (supplier qualification) | — | | URS-07-VAL-007 | — | (evidence index) | — | | URS-07-VAL-008 | — | TC-TECH-019 | AC-07-MIG-01, AC-07-MIG-02 | --- ## 17. Validation and CSV/CSA Evidence Expectations | Item | Required evidence | |---|---| | URS traceability | Per §16.4 | | Risk assessment | GAMP 5 risk register; risk-based assurance per FDA CSA | | Configuration specification | Documented seed of `study_regulatory_framework_registry` (Tier 1); per-study-type retention class defaults; clinical-type activation registry seed | | Functional specification | Matches §6 | | Design specification | Matches §6.1–§6.4 | | Test protocols | IQ (schema, RLS, indexes, constraints, scope-intersection bootstrap), OQ per URS-07-VAL-002, PQ per URS-07-VAL-003, regression per URS-07-VAL-004 | | Test evidence | Pass / fail per protocol step, traced to requirement | | Defect log | Defects mapped to URS requirements | | 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 7 | | Periodic review | Annual per Annex 11 §11; trigger reviews on every Class 1 / Class 2 change | | Data migration evidence | Backfill of regulatory framework registry; clinical-type activation seed; restore drill verifies study integrity | ### 17.1 Supplier and service-provider qualification pack | Category | Required evidence | |---|---| | Cloud hosting provider | Inherited from URS-01 §17.1 | | Document control provider (URS-12) | Right-to-audit; retention compliance | | Qualification register provider (URS-28) | Right-to-audit; data residency | | Notification provider (URS-30) | Inherited from URS-01 §17.1 | | Backup / restore provider (URS-35) | Restore drill preserving study state and chain HEAD | | 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 | |---|---|---|---|---|---| | Study record (lifecycle states) | QA | `studies` + URS-06 audit | per study type | URS-07-WF-001 | demonstrate investigation conduct | | Protocol versions | QA | `study_protocol_versions` + URS-12 | per study type | URS-07-DATA-001 | demonstrate baseline | | Scope versions | QA | `study_scope_versions` | per study type | URS-07-DATA-003 | demonstrate authority of record per scope | | Amendment register | QA / RA | `study_amendments` + signatures | per study type | URS-07-WF-002 | demonstrate URS-13 governance | | Master-file linkage | QA | `study_master_file_documents` + URS-12 | per study type | URS-07-INT-003 | demonstrate document control | | Cross-tenant collaboration register | QA / Legal | `cross_tenant_collaboration_grants` + bilateral signatures | per study type | URS-07-BE-008 | demonstrate bilateral authorisation | | Cross-tenant access trail | QA / IS | URS-06 chain entries `CROSS_TENANT_STUDY_ACCESS_USED` | per study type | URS-07-AUD-005 | demonstrate confidentiality envelope | | Member roster with qualification | QA / Training | `study_members` + URS-28 linkage | per study type | URS-07-INT-002 | demonstrate personnel qualification | | Close-out package | QA / Founder | `study_close_out_packages` + signatures + final report | per study type | URS-07-BE-013 | demonstrate completion | | Manual labels | QA | `study_record_manual_labels` + signatures | per study type | URS-07-FE-006 | demonstrate edge-case annotations | | Successor-study linkage | QA | `studies.successor_of_study_id` | per study type | URS-07-BE-016 | demonstrate continuity | | Clinical activation register (per tenant) | Founder | `clinical_type_tenant_activations` + executive authority signatures + GCP-readiness pack | retain (long-term) | URS-07-BE-018 | demonstrate clinical-type governance | | Validation evidence pack (IQ / OQ / PQ) | Validation | testing system of record | retain per release | URS-07-VAL-001..008 | release approval | | Release approval (electronically signed) | Founder, QA, RA, Validation, IS | URS-12 | retain per release | URS-07-VAL-007 | demonstrate authority chain for release | --- ## 18. Closed Decision and Dependency Register ### 18.1 Closed Launch Decisions Register | Closed decision | Spec reference | |---|---| | Launch study types + clinical-type forward roadmap | DEC-07-01 | | Lifecycle state machine | DEC-07-02 | | Activation electronic signature + executive authority co-sign for high-risk | DEC-07-03 | | Study membership roles + tenant_side discriminator | DEC-07-04 | | Scope binding using URS-05 canonical scope dimension registry | DEC-07-05 | | Amendment lifecycle + RA co-sign for substantial + executive authority co-sign for regulatory framework change | DEC-07-06 | | Cross-tenant collaboration grants (bilateral, opt-in, scoped, revocable) | DEC-07-07 | | Master-file linkage by study type | DEC-07-08 | | Close-out / archival path | DEC-07-09 | | Discovery via URS-03 active-scope intersection | DEC-07-10 | | Per-jurisdiction regulatory framework selection | DEC-07-11 | | Member qualification gating | DEC-07-12 | | Retention by study type; never below default | DEC-07-13 | | Manual labels with `assertion` types | DEC-07-14 | | Snapshot pinning (protocol-version at decision time) | DEC-07-15 | | Cross-tenant write boundary; collaboration revocation cascades | DEC-07-16 | | Clinical types disabled by default; per-tenant activation by Founder | DEC-07-17 | ### 18.2 Dependencies | ID | Dependency | Source | Impact | Blocking? | Mitigation | |---|---|---|---|---|---| | DEP-07-01 | URS-01 authentication, MFA step-up | URS-01 | Substrate | Blocking | none | | DEP-07-02 | URS-02 base roles | URS-02 | Member overlay | Blocking | none | | DEP-07-03 | URS-03 active scope | URS-03 | Discovery | Blocking | none | | DEP-07-04 | URS-04 e-sig ceremony | URS-04 | Lifecycle / amendment signatures | Blocking | none | | DEP-07-05 | URS-05 authority resolver, scope-dimension registry | URS-05 | Activation, close-out, scope keys | Blocking | none | | DEP-07-06 | URS-06 audit substrate | URS-06 | Audit | Blocking | none | | DEP-07-07 | URS-08 tenant lifecycle | URS-08 | Cross-tenant; offboarding | Blocking | none | | DEP-07-08 | URS-12 document control | URS-12 | Master file, protocol documents | Blocking | none | | DEP-07-09 | URS-28 qualification register | URS-28 | Member qualification gating | Blocking | none | | DEP-07-10 | URS-30 notifications | URS-30 | Reminders, escalations | Non-blocking | direct e-mail fallback | | DEP-07-11 | URS-35 backup / restore / cold storage | URS-35 | Long-term archive | Blocking for PQ | DR drill | --- ## 19. Completeness Checklist | Item | Yes / No | Evidence | |---|---|---| | Controlled-document metadata complete? | Yes | front matter | | Approval block complete? | Yes (signatures pending) | Document Approval section | | Version history complete? | Yes | Version History | | Glossary complete? | Yes | §0.6 | | Scope complete? | Yes | §2 | | Roles and permissions complete? | Yes | §3 | | User journeys complete? | Yes | §4 (28 journeys) | | Front-end complete? | Yes | §5 | | Backend complete? | Yes | §6 | | Data model complete? | Yes | §6.2 | | APIs complete? | Yes | §6.3 | | Workflow / lifecycle complete? | Yes | §6.4 | | Business rules complete? | Yes | §6.5 | | Audit trail complete? | Yes | §6.6 | | AI / Human-in-the-Loop complete? | Yes (no AI in core) | §8 | | Reports complete? | Yes | §9 | | Notifications complete? | Yes | §10 | | Cross-module wiring complete? | Yes | §7 | | Change-impact matrix complete? | Yes | §7.2 | | Negative paths complete? | Yes | §11 | | Security / privacy / tenant isolation complete? | Yes | §12 | | ALCOA+ complete? | Yes | §13 | | Regulatory mapping complete? | Yes | §14 | | Predicate-rule applicability matrix complete? | Yes | §14.1 | | Requirements register complete? | Yes | §15 | | Acceptance tests complete? | Yes | §16 | | Requirements-to-test traceability complete? | Yes | §16.4 | | Validation evidence complete? | Yes | §17 | | 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-07-VAL-008 (Migration Evidence Gate) and the §17 validation evidence pack are satisfied. **No Module 7 internal open questions remain.** - **Specification ready for engineering review?** Yes — every MUST requirement is declarative, atomic, and testable. Front end, back end, data, APIs, lifecycle, scope, amendment, cross-tenant collaboration, master-file linkage, close-out, archival, discovery, and integrations are covered as a single self-contained contract. - **Specification ready for quality validation review?** Yes — IQ/OQ/PQ scope specified; traceability matrix in §16.4; regulatory framework registry seed enumerated. - **Specification ready for compliance review?** Yes — ALCOA+ table, regulatory mapping, predicate-rule applicability matrix populated. - **Specification ready for inspector / 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-07-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. 2. **Released for validation execution.** Reached after URS-07-VAL-008 is satisfied and the §17 evidence pack is complete. --- ## Appendix A — Study Lifecycle Composite ```mermaid flowchart TD A([Tenant administrator initiates study]) --> B[STUDY_CREATED state draft] B --> C[Study lead submits for setup] C --> D[STUDY_SUBMITTED_FOR_SETUP state in_setup] D --> E{High-risk type?} E -- yes --> F[executive authority co-sign + study lead activation signature] E -- no --> G[Activation approver independent of creator signature] F --> H[STUDY_ACTIVATED state active] G --> H H --> I[URS-03 active-scope intersection begins] I --> J[Study members contribute records within scope] J --> K{Hold required?} K -- yes --> L[STUDY_HOLD_PLACED state on_hold] L --> M[Investigation closes] M --> N[STUDY_HOLD_RELEASED state active] N --> O K -- no --> O[Amendments processed when needed] O --> P{All deliverables complete?} P -- no --> J P -- yes --> Q[Master-file completeness check] Q --> R[Open findings closed or accepted] R --> S[Close-out package signed by lead and quality lead] S --> T[STUDY_CLOSED_OUT state closed] T --> U[Auto-archive after window] U --> V[STUDY_ARCHIVED state archived] V --> W[Inspection-ready discovery export available with integrity manifest] ``` — End of Module 7 User Requirements Specification —