Platform object and relationship contracts

Reading rule

These are domain contracts, not database schemas. “Required” means required for valid domain state; it does not imply a column, request payload or screen field.

State terminology rule

Term	Use
lifecycle	Authoritative owner state with named commands and permitted transitions
registryAvailability	Whether a canonical coordinate accepts declared new registry relationships; not clinical/product status
coordinationState	Cross-owner request/acknowledgement progress; not the target product lifecycle
decisionOutcome	Immutable conclusion over exact inputs, such as allow/deny or available/quarantined
derivedCurrentness	Calculated from effective interval or latest accepted decision; never directly commanded
projection status	Read-model label with asOf; never mutation authority

Every object contract must use one of these qualified meanings. Unqualified “status” is prohibited.

Shared value objects

Value	Exact meaning
WorkspaceId, StudyId, StudyCountryId, StudySiteId	Opaque, immutable, never recycled identifiers
ExpectedRevision	Aggregate revision expected by a mutating command
ProductBoundary	Closed initial set: Platform, EDC, eTMF
ResourceScope	Workspace, Study, Study Country or Study Site with complete ancestor coordinates
EffectiveInterval	Half-open interval [effectiveFrom, effectiveTo)
CountryCode	Governed ISO-compatible country reference, never a display label
Reason	Governed reason code plus explanation when the code requires it
ExternalIdentifier	Namespace, value, issuer and intended use
Instant	Unambiguous point in time
CivilDate	Calendar date without an implied time or timezone
RecordedTime	Time the system committed evidence
EffectiveTime	Time the business fact became applicable
ContentDigest	Algorithm plus canonical digest value
PrivacyClassification	Owner-supplied handling classification
BlindClassification	Owner-supplied disclosure constraint; not a Role label
CommandId, OperationId, CorrelationId, CausationId	Distinct idempotency and trace coordinates

Relationship and cardinality model

Source	Relationship	Target	Cardinality	Contained?	End/delete rule
Workspace	boundary for	every Platform object	exactly 1 per object	No mega-aggregate	Closure retains identities and evidence
Principal	has	Authentication Binding	0..n	Policy-owned, separately revocable	Revocation preserves Principal
Role Definition	contains	Role Revision	1..n after activation	Yes, immutable revisions	Retire Role; never rewrite revisions
Principal	receives through	Access Assignment	0..n	No	End/revoke; never delete after use
Access Assignment	references	Role Definition	exactly 1	No	Follows the stable Role’s current revision; each decision pins the evaluated revision
Organization	operates	Site	0..n	No	Site remains independently identified
Study	references primary	Sponsor Organization	exactly 1	No	Change policy unresolved; never infer from Participation
Study	has	Study Country	0..n	No	Retained identity per Study/country
Study Country	has	Study Site	0..n	No	Study Site cannot silently move country
Site	participates through	Study Site	0..n	No	Site correction never rewrites Study Site identity
Study Site	references	Study, Study Country, Site	exactly 1 each	No	Close/reopen shared availability only
Party	participates through	Study Party Participation	0..n	No	End or replace with lineage
Participation	references	one typed Study scope	exactly 1	No	Scope correction is governed, never string edit
Study	coordinates	Study Product Enablement	0..1 per Software Product	No	Disable retains identity and product-root reference
Enablement	references	product-owned Study root	0..1	No	Only owning product acknowledges root
Content Item	contains	Content Revision	1..n after first receipt	Yes, immutable bytes/provenance	New bytes create new revision
Content Item	contains decisions for	Content Revision	0..n per revision	Yes; decisions are append-only	Monotonic decision sequence selects current decision
Content Revision	participates through	Content Binding	0..n	Binding evidence under item	Release binding; preserve history
Study Milestone	references	one exact Study scope	exactly 1	No	Correction/reversal preserves assertions
Development Product	participates through	Study Intervention	0..n	No	End association; preserve identity
Connection Contract	contains	immutable Contract Revision	1..n after publication	Yes if governed dynamically	Retire, never change active revision
Product Fact Delivery	pins	one source Fact + one Contract Revision	exactly 1 each	Yes for attempts	Retry cannot change pinned meaning

Identity and Access contracts

Principal

Field	Required	Meaning
principalId	yes	Stable acting identity
workspaceId	yes	Customer boundary
kind	yes	Human, service or connection
displayIdentity	yes	Correctable label, never an identity key
state	yes	Invited, active, disabled; exact lifecycle requires approval
revision	yes	Concurrency coordinate

Principal does not contain Roles, Assignments, business responsibility or credentials. A disabled Principal remains resolvable in historical evidence.

RoleDefinition and RoleRevision

Field	Required	Meaning
roleDefinitionId	yes	Stable Role identity
homeProduct	yes	One product only
displayName	yes	Presentation; never authorization
state	yes	Active or retired
currentRevisionId	yes when active	Revision used by the chosen policy
Role Revision actionKeys	yes, non-empty	Exact product-published Action meanings
Role Revision revisionNumber	yes	Monotonic business revision

Published revisions are immutable. Cross-product actions are rejected except explicitly declared Platform dependency Actions.

AccessAssignment

Field	Required	Meaning
accessAssignmentId	yes	Stable grant identity
principalId	yes	Recipient
roleDefinitionId	yes	Stable Role reference
productBoundary	yes	Platform, EDC or eTMF
resourceScope	yes	Typed full coordinate
effectiveInterval	yes	Half-open authority interval
delegatedByAssignmentId	when delegated	Proof of administration boundary
state	derived/retained	Scheduled, active or ended
revision	yes	Concurrency coordinate

Changing Principal, Role, product or scope creates a new Assignment. Ending authority preserves the exact prior grant and does not erase earlier Access Decisions.

AccessDecision

An immutable decision value containing Principal, Product, Action, Resource Scope, evaluation time, allowed/denied result, stable reason, Assignments and Role Revisions considered, and policy version. It has no business lifecycle and does not make a product command valid.

Party Registry contracts

Organization

Stable legal/operating identity with organizationId, names, governed external identifiers, registry availability and revision. Sponsor/CRO/laboratory/site institution are contextual responsibilities, not Organization subtypes. Inactivation blocks declared new relationships but does not erase existing Studies.

PersonProfile

Stable real-world person identity with personProfileId, governed name representation, minimal privacy classification and revision. Contact points, affiliations and professional credentials are Candidates until a current EDC/eTMF scenario justifies shared ownership. It is never a Subject.

Site

Field	Required	Meaning
siteId	yes	Stable operational-location identity
operatingOrganizationId	yes	One backing Organization in the initial model
displayName	yes	Correctable label
countryCode	yes	Canonical country coordinate
registryAvailability	yes	Active or inactive
revision	yes	Concurrency coordinate

Address and timezone remain Candidate. Site owns no Study site number, investigator, activation, enrollment or product state.

Study Registry contracts

Study

Field	Required	Meaning
studyId	yes	Stable suite coordinate
workspaceId	yes	Boundary
sponsorOrganizationId	yes	Primary Sponsor reference
sponsorProtocolIdentifier	yes	Sponsor-aware business identifier
officialTitle	yes	Correctable registry presentation
shortTitle	no	Correctable registry presentation
registryAvailability	yes	Registered, archived or superseded
canonicalStudyId	only when superseded	Explicit resolution target
revision	yes	Concurrency coordinate

Study contains no Countries, Sites, protocol design, Product Entitlements or product roots. Equal protocol identifiers are duplicate evidence, not identity.

StudyCountry

Field	Required	Meaning
studyCountryId	yes	Stable country-participation identity
studyId	yes	Immutable parent coordinate
countryCode	yes	Immutable governed reference in Core
localStudyIdentifier	no	Correctable local identifier
lifecycle	yes	Proposed: planned, active, closed
revision	yes	Concurrency coordinate

Lifecycle expresses shared coordination only; it is not regulatory approval, site activation or eTMF completeness.

StudySite

Field	Required	Meaning
studySiteId	yes	Stable Study-specific coordinate
studyId	yes	Immutable Study reference
studyCountryId	yes	Immutable country participation in Core
siteId	yes	Immutable canonical Site reference
studySiteNumber	yes before product use	Study-local correctable identifier
registryAvailability	yes	Open or closed only
revision	yes	Concurrency coordinate

Selected, activated, initiated, enrollment-open, EDC-live and inspection-ready are explicitly not Study Site states.

Clinical Coordination contract

Governed responsibility catalogue

Initial review candidates are explicit rather than free text:

Responsibility	Allowed party	Allowed scope
Contract Research Organization	Organization	Study, Study Country, Study Site
Principal Investigator	Person Profile	Study Site
Sub-investigator	Person Profile	Study Site
Study Coordinator	Person Profile	Study Site
Central Laboratory	Organization	Study
Imaging Vendor	Organization	Study
Technology Vendor	Organization	Study

Primary Sponsor remains a Study reference, not a second independently editable Participation.

StudyPartyParticipation

Fields: stable identity, one Party reference, one Responsibility code, one exact typed scope, half-open effective interval, state, predecessor/successor lineage, source evidence and revision. Identical party/responsibility/scope intervals cannot overlap. Replacement atomically ends the predecessor and establishes the successor under one intent.

Suite Composition contract

StudyProductEnablement

Fields: stable identity per Workspace × Study × Software Product, current operation identity, requested product, connection-contract revision, coordination state, optional product-root reference, acknowledgement or rejection evidence and aggregate revision.

absent   → enable requested → enabled
disabled → enable requested → enabled
enabled  → disable requested → disabled

Rejected and reconciliation states are outcomes, not product lifecycle. Only EDC or eTMF can issue the acknowledgement for its own root. Disable never asserts data deletion.

Content and evidence contracts

ContentItem and immutable ContentRevision

Content Item supplies stable provenance and binding/retention coordination. A Revision records revision identity, ordinal, declared filename, media type, size, content digest, source, received time and predecessor. Those values are immutable.

Verification is a separate immutable ContentVerificationDecision contained by the Content Item. It contains verificationDecisionId, target revision/digest, monotonic decisionSequence, verifier/rule revision, decision time, available/quarantined/rejected outcome, findings, supersedesDecisionId and evidence. ContentItem.currentVerificationDecisionByRevision maps each contentRevisionId to its current Decision and changes only with expected-revision concurrency. A binding pins both the Content Revision and the exact current available Verification Decision. A later quarantine decision does not mutate the earlier decision; it becomes current and blocks new bindings under an explicit existing-binding impact policy.

ContentBinding is Content-owned retained association evidence with contentBindingId, exact Revision and Verification Decision, owner Product/context/object, declared purpose, bound time, state active | released, and binding/release evidence. At most one active binding exists for the same owner Product/context/object/purpose/Revision coordinate. Releasing a binding preserves history and does not delete the product record. Retention interaction remains PD-PLAT-015/016.

EvidenceEnvelope

Contains exact business actor, executing identity when different, authority decision, target and expected/current revision, recorded and effective time, command/operation/correlation identities, reason, source, correction before/after values, input evidence references and integrity digest.

There is no generic CreateEvidence domain command. The owning command records its outcome and evidence atomically.

Narrow shared Milestone contract

Initial Proposed Core supports one governed type: Site Activated, Study Site scope, Civil Date, one retained Milestone per type/scope, and an explicit accepted source/attestation policy.

StudyMilestone.lifecycle is open | achieved | cancelled. Baseline, planned, forecast and actual are distinct temporal assertions—not lifecycle states. Achievement correction and reversal retain the prior assertion.

Candidate Development Product contracts

DevelopmentProduct owns stable asset identity, canonical name, coarse governed kind and Sponsor Organization reference. StudyIntervention owns the Study–Development Product association and protocol role. Neither owns formulation, dose, regimen, arm, randomization, supply, safety or regulatory lifecycle. Both remain Candidate until a current EDC/eTMF scenario proves that each is required by more than future extension pressure.

Integration contracts

An immutable ProductConnectionContractRevision pins source fact/schema, target proposal or command/version, mapping revision, allowed data, privacy/blind handling, idempotency derivation, delivery policy and reconciliation owner.

ProductFactDelivery pins one source Fact and one Contract Revision. Attempts may become accepted, target-refused, retryable-failure or exhausted. Retry never changes the source fact, mapping or target intent. Target refusal is a valid business outcome, not a transport failure.