Platform domain model

Boundary

Platform supplies capabilities common to every vertical. It does not define what a Study Site, Casebook, Monitoring Event, Expected Document or Payable Item means.

Platform object/service	Responsibility
PartyDirectory	stable Person, Organization, Facility and Location identity
StudyIdentityRegistry	stable Study/Study Country/Study Site references and aliases
Document / DocumentVersion / Rendition	governed content identity, versioning and representation
ObjectLifecycleDefinition	permitted states and transitions for configured record types
WorkflowDefinition / WorkflowInstance / Task	coordinate human decisions without owning their clinical meaning
RoleAssignment / AuthorityGrant	application authority separate from study responsibility
ControlledTermSet	versioned terminology and translations
AuditEntry	actor, action, affected revision, timestamp, reason and provenance
ElectronicSignature	signer, meaning, signed manifest and validity
NotificationRequest	delivery request caused by a domain fact
IntegrationIdentity	source identity, target identity and mapping history

Governing rule

Platform lifecycle configuration can enforce a vertical’s accepted lifecycle, but configuration is not the source of that lifecycle’s meaning. StudySiteActivated remains a Study Startup/CTMS fact even when a platform workflow coordinates its approval.

Evidence crosswalk

Observed product behaviour	TechSol decision	Difference / question
Documents and object records have configurable lifecycles	platform enforces a lifecycle definition owned semantically by a vertical	how are incompatible lifecycle revisions migrated?
Workflows coordinate tasks, verdicts and state changes	workflow is orchestration; verdict produces a vertical decision	which verdicts require typed domain commands?
Document workflows use an envelope and contents	ReviewPackage may coordinate an exact content manifest	envelope is not automatically a clinical-domain object