Platform model

Review status

Proposed greenfield model — not yet accepted.

This documentation specifies the smallest Platform domain required for EDC and eTMF to compose around stable clinical-study coordinates without sharing product lifecycles. It is a product-review instrument, not an implementation description.

The previous single-page Platform catalogue was withdrawn because it did not permit systematic verification. The replacement separates object meaning, command behavior, invariants, evidence, contracts, scenarios, and unresolved decisions.

Platform thesis

Platform owns stable coordinates and reusable regulated mechanisms. EDC and eTMF own the meaning and lifecycle of clinical data and trial-master-file records.

Platform is not a base class for vertical products. It is a set of narrow bounded contexts:

Bounded context	Authoritative meaning
Account & Environment	Workspace boundary and operational Product Entitlement
Identity & Access	Principal identity, product-owned Action registration, Roles, Assignments and Access Decisions
Party Registry	Organization, Person Profile and Site identity
Study Registry	Study, Study Country and Study Site identity and registry availability
Clinical Coordination	Effective-dated Study Party Participation
Study Timeline	Narrow shared Milestone facts
Development Product Registry	Development Product identity and Study Intervention association
Suite Composition	Study Product Enablement coordination; never the product root lifecycle
Content	Content identity, immutable revisions, integrity and availability
Evidence & Audit	Actor, authority, reason, time, correction and signature evidence contracts
Integration Contracts	Allowed owner-to-owner fact-to-command mappings
Work & Integration Mechanisms	Durable delivery and reconciliation state, without product meaning

ProductEntitlement has one owner: Account & Environment. StudyProductEnablement has one owner: Suite Composition.

Independent gates and command profiles

Study-root-dependent EDC/eTMF command
  requires Product Entitlement
  AND Study Product Enablement
  AND Principal Application Authority
  AND Product-owned State Policy
  → command may be accepted

The four-gate profile is not universal:

Command class	Applicable gates
Platform registry/coordination command	Platform authority + owning Platform policy
Workspace-level EDC/eTMF library command	Product entitlement + product authority + product policy
Study-root-dependent EDC/eTMF command	Entitlement + Study enablement + product authority + product policy
Owner-to-owner product connection	Connection authority + exact contract + target product policy; initiating user authority retained where applicable
Disabled-product inspection command	Explicit inspection authority + product retained-access policy; entitlement exception remains a product decision

Passing one applicable gate never implies another. In particular:

• Study responsibility does not grant application authority.
• Platform authority is not a wildcard over EDC or eTMF.
• Product enablement does not create a Role or Assignment.
• An allowed Access Decision does not override EDC lock or eTMF finality.

Review specification

Read the pages in this order:

1. Authentication, roles and access — how people and connected systems sign in; how features map to actions; and how Roles, assignments, visibility, delegation and access evidence work.
2. Scope and promotion ledger — which concepts are Proposed Core, Candidate, Deferred or Rejected, and why.
3. Object and relationship contracts — definition, owner, archetype, identity, conceptual fields, cardinalities and non-responsibilities.
4. Command, refusal and evidence contracts — exact command preconditions, postconditions, stable refusals, facts and evidence profiles.
5. Invariant traceability — each invariant mapped to its owner, commands, refusals, scenarios and evidence claim.
6. EDC and eTMF contracts — the only meanings allowed to cross the Platform/product boundaries.
7. Verification scenarios — happy path, denial, concurrency, correction, retry and reconciliation behavior.
8. Evidence ledger — regulatory obligation, market evidence, modelling conclusion and non-conclusion.
9. Product decision ledger — decisions that must be resolved before the model can be accepted.

Acceptance rule

A concept is not accepted because it appears in another product or standard. It becomes Core only when the review can identify:

1. one authoritative owner;
2. an independent identity, lifecycle, invariant, authority, evidence or contract reason;
3. an exact command or policy that needs it;
4. at least one current Platform/EDC/eTMF scenario;
5. its correction and retirement behavior; and
6. what would become incorrect or unverifiable if the concept did not exist.

Explicit non-goals

This specification contains no database schema, API resource design, UI workflow, message broker, deployment model or framework choice. It also rejects a universal Document, Workflow, Task, Approval, Requirement, Custom Object, Regulated Record or state-machine abstraction.