Platform verification scenarios

Scenario evidence baseline

Every attempted command records command/operation identity, actor and executing connection, Product/Action/Scope decision, entitlement/enablement receipts where applicable, target and expected revision, recorded/effective time, accepted/refused result, payload digest, contract revision and reason/evidence required by the command.

VS-01 — Suspected duplicate Studies arrive concurrently

Given two authorized registry administrators submit distinct commands with the same Sponsor and protocol identifier, and duplicate detection has no mutation authority.

When both RegisterStudy commands are evaluated concurrently.

Then the model must apply the selected duplicate-admission policy explicitly. If both are admitted, they receive distinct immutable IDs and two StudyRegistered facts; a duplicate-candidate projection may be created. A repeated command ID returns the original result. A repeated ID with different payload returns IDEMPOTENCY_KEY_REUSED.

Must not happen: title/protocol matching silently merges identities or creates EDC/eTMF roots.

Decision required: warn-and-admit, privileged override, or uniqueness refusal.

VS-02 — Duplicate resolution after product roots exist

Given two Studies both have EDC/eTMF roots with product-owned records.

When an administrator requests canonical merge/supersession.

Then current Core returns STUDY_MERGE_REQUIRES_MODEL_DECISION. Platform cannot re-parent, combine, delete or relabel product state. Any future resolution must retain both original identities and obtain explicit product impact acknowledgements.

Decision required: prohibition, cross-reference-only, or governed owner-by-owner migration.

VS-03 — Correct a Study label

Given Study revision 8 is referenced by both products.

When UpdateStudyRegistryDetails(expectedRevision=8) changes only the short title with a reason.

Then revision becomes 9, prior/resulting values and times are retained, and StudyRegistryDetailsUpdated is published. Product projections update by studyId; product evidence does not change. A concurrent correction against revision 8 receives EXPECTED_REVISION_CONFLICT.

Must not happen: the correction changes Sponsor, protocol meaning, Study ID or product roots.

VS-04 — Concurrent Study Site number reservation

Given two valid new Study Site commands request number 057 in one Study.

When they are accepted concurrently.

Then one association and number reservation succeeds; the other gets STUDY_SITE_NUMBER_CONFLICT and creates no Study Site. Later number correction retains identity, prior value and owner revision. EDC/eTMF continue using studySiteId.

Decision required: normalization and corrected-away/closed-number reuse policy.

VS-05 — Site country is wrong after product use

Given a Site in the US is referenced by a US Study Site that already has EDC data and eTMF records.

When ordinary CorrectSiteDetails attempts to change country to Canada.

Then no state changes and the owner returns USED_SITE_COUNTRY_CORRECTION_REQUIRES_MODEL_DECISION. Authority cannot waive identity history.

Must not happen: historical Study Country membership or product records are rewritten.

VS-06 — PI responsibility and application authority stay separate

Given a Person Profile has PI responsibility at a Study Site but its Principal has no EDC Access Assignment.

When EDC attestation is attempted.

Then Platform authority denies it. Adding explicit EDC authority may permit the attempt, after which EDC still evaluates attestation policy. Ending PI Participation changes responsibility only; access remains until a separate command. An explicit policy may raise an access-review proposal.

Must not happen: PI title, Site Organization or responsibility grants/revokes access implicitly.

VS-07 — Entitlement withdrawal races with enablement

Given enablement operation EN-44 was accepted using entitlement revision 5, and entitlement is withdrawn before the product acknowledgement arrives.

When the matching acknowledgement for EN-44 arrives.

Then behavior follows an explicit cutoff policy. Withdrawal never silently disables/deletes the product root. New enable requests are refused. All ordering coordinates and the exact entitlement receipt are retained.

Decision required: allow accepted in-flight completion, cancel explicitly, or require manual reconciliation.

VS-08 — Disable, re-enable and late acknowledgement

Given disable operation DIS-51 is followed through governed recovery by re-enable EN-52.

When a delayed acknowledgement for DIS-51 arrives after EN-52 is current.

Then state remains enabled under EN-52; the old acknowledgement receives STALE_OPERATION_ACKNOWLEDGEMENT and is retained for reconciliation. Duplicate acknowledgement for EN-52 is idempotent.

VS-09 — Unverified content cannot enter EDC or eTMF

Given Content Revision 1 fails digest/malware verification and Revision 2 later passes.

When EDC import and eTMF filing try to bind Revision 1.

Then both receive CONTENT_NOT_AVAILABLE. Only explicit new commands may bind Revision 2. Platform availability does not equal EDC design validity or eTMF quality acceptance.

VS-10 — Signature becomes stale before binding

Given a signature ceremony pins product record revision 17 and exact statement meaning.

When a concurrent correction creates revision 18 before signature binding.

Then binding returns SIGNATURE_TARGET_STALE; revision 18 receives no signature and requires a new ceremony. Abandoned/stale ceremony evidence is not a successful signature.

VS-11 — Disabled product preserves inspection access

Given eTMF contains retained finalized records and a properly scoped inspector has separate read, audit and export Actions.

When eTMF is disabled and entitlement withdrawn.

Then retained records remain. Ordinary filing/approval is refused. Inspection read/export is allowed only if the product’s explicitly accepted disabled-state policy and current authority both pass.

Decision required: disabled-mode action matrix and in-flight command cutoff.

VS-12 — Retention expiry meets legal hold

Given an eTMF record’s calculated retention period appears expired but an applicable hold or inspection requirement may exist.

When disposition is requested.

Then current Core refuses irreversible destruction until retention owner, hold contract, shared content bindings and serialization policy are accepted. Delete authority alone is insufficient.

VS-13 — Out-of-order correction delivery

Given owner revisions 11, 12 and 13 exist, EDC has applied 13, and eTMF receives 13 before 12.

When revision 12 arrives late.

Then EDC does not regress. eTMF detects the gap and applies the approved gap/reconciliation policy. Both products retain checkpoints, payload digests and receipts. A genuine later correction is 14, never mutation of 12.

VS-14 — Connection-contract mismatch

Given sender uses contract revision 7 and target requires 8 with different mapping meaning.

When delivery occurs.

Then no target state changes; CONTRACT_REVISION_MISMATCH is retained. Corrected transfer is linked to the same source fact but uses an accepted mapping revision. Support cannot write target data directly.

VS-15 — Authority allows; product policy refuses

Given Principal has exact Action/Scope authority and all Platform gates pass, but the EDC Casebook is locked or eTMF Document finalized.

When correction/replacement is attempted.

Then Platform retains Allow while the product returns its lifecycle/revision refusal. No Platform grant changes. Reopen/unlock, if supported, is another product-owned command with evidence.

VS-16 — Scoped list does not leak hidden records

Given a monitor can access one of ten Sites and the projection is slightly stale.

When the monitor searches, counts, filters, facets and paginates.

Then authorization is applied before every collection operation; only the accessible universe affects results. asOf is visible. A current owner decision—not projection membership—authorizes any later command.

VS-17 — Duplicate Study Country planning is serialized

Given Study ST-100 has no US Study Country and two authorized commands independently request US.

When both PlanStudyCountry commands compete.

Then one creates the retained Study/Country identity and emits StudyCountryPlanned; the other receives STUDY_COUNTRY_CONFLICT. A retry of the winning command returns the original identity. Neither command enables a product or asserts regulatory approval.

VS-18 — Last qualifying administrator cannot be removed

Given one effective Assignment is the final qualifying EDC access-administration grant for a Workspace × Product boundary.

When concurrent commands try to revoke it and revise its Role to remove the qualifying Action.

Then continuity-sensitive decisions serialize at Workspace × Product. At most one change can be considered first, and any resulting loss of all qualifying administration returns CONTINUITY_VIOLATION. No emergency authority is invented.

VS-19 — Overlapping responsibility intervals are refused

Given one Person Profile already holds exclusive PI responsibility at a Study Site for [2026-01-01, open).

When another identical Party/Responsibility/Scope Participation is added from 2026-06-01.

Then EFFECTIVE_INTERVAL_CONFLICT is returned and no Participation fact is emitted. A legitimate replacement uses one ReplaceStudyPartyParticipation intent that ends the predecessor and creates the successor at the same deterministic boundary.

VS-20 — Connection execution does not impersonate the initiator

Given a human registry administrator accepts a Study Site correction and an authenticated product connection later executes the corresponding target proposal.

When EDC/eTMF records the target decision.

Then evidence retains both initiating Human Principal and executing Connection Identity, source fact, contract revision and target decision. Missing either identity fails Evidence Profile validation; the connection is never recorded as the business originator.

VS-21 — Accepted target delivery replay is idempotent

Given one delivery idempotency identity already has an authenticated target acceptance receipt.

When the identical acknowledgement is replayed twice and a third message reuses the identity with a different payload digest.

Then identical replays return the original accepted outcome and create no second target effect. The divergent payload receives IDEMPOTENCY_KEY_REUSED and enters reconciliation evidence.

VS-22 — Site Activated milestone forecast, achievement and reversal

Given one open site_activated Milestone exists for a Study Site with planned Civil Date and no actual assertion.

When forecast is updated, an accepted authenticated first-person assertion achieves the Milestone, the actual date is corrected, and later the achievement is proven false and reversed.

Then forecast changes while lifecycle remains open; achievement changes open → achieved and pins its source evidence; correction retains the prior actual assertion; reversal changes achieved → open while retaining all prior evidence. No product fact or Study Site lifecycle is rewritten. Another Milestone of the same type/scope receives a uniqueness conflict. A different type or Scope receives the appropriate type/scope refusal.

Acceptance coverage

Each promoted command must ultimately have:

• one accepted success scenario;
• one authorization refusal;
• one lifecycle/invariant refusal;
• one stale-revision or competing-command scenario;
• one replay/idempotency scenario; and
• correction or reconciliation behavior where the action is externally consumed.