1.TL;DR a Visit is a Visit · universal Activity + Task foundation · accommodates any assessment

Visit is the operational visit-occurrence — a Participant attended a real visit at a StudySite on a real date. Per first-principles.md, the foundation carries one universal pattern: Visit → Activity → Task, where Activity is the universal work unit (Vitals, MRI, ePRO, biopsy, IP administration — same shape) and Task is the universal leaf data-capture (BP, MRI Study reference, PHQ-9 item, drug dose — same shape, polymorphic taskValue). Specialization is content (biomedicalConceptCode + taskValueType + URI references), never entity shape. Visit-occurrence is distinct from VisitDefinition (the protocol template, USDM-ingest-derivable). Per the temporal+PROV native commitment: every entity is a typed PROV node (Visit and Activity are prov:Activity, VisitDefinition is prov:Entity); status attributes are NGSI-LD temporal properties; Task captures observedAt as Property metadata. The foundation IS a W3C PROV graph by construction.

2.First-principles posture why the entity looks the way it looks

Three structural commitments, all applied:

1. Operator-grounded vocabulary. "Visit," "Activity," "Task" — what coordinators say. Not "Encounter" (FHIR's name), not "ScheduledActivityInstance" (USDM's name). Cross-walks live below the line.
2. Native temporal + provenance. Visit, Activity, Task all declare provType: prov:Activity via rdfs:subClassOf. VisitDefinition declares prov:Entity. visitStatus / activityStatus / taskStatus are NGSI-LD temporal properties. Task.observedAt is canonical Property metadata, not a flat performedDateTime attribute. performedBy declares provSemantics: wasAssociatedWith; usedEquipment declares used.
3. Universal foundation. Activity and Task are universal containers. A DICOM imaging Activity and a blood-draw Activity are the same TOP entity shape. Specialization is content (biomedicalConceptCode, taskValueType, taskValue) and links (usedEquipment, governedBy), never entity-type discrimination.

3.Architectural anchor Visit's place in the operational hierarchy

Anchor pattern: Visit.forParticipant (1..1) + Visit.forStudySite (1..1) + Visit.definedBy → VisitDefinition (0..1). The 0..1 cardinality on definedBy lets UNSCHEDULED visits exist (urgent care, AE workup, sponsor-requested) without a corresponding template. SHACL invariant #30 enforces cross-entity consistency: Visit.forParticipant.forStudySite must match Visit.forStudySite.

The OOUX correction tracked since the Site spec is applied here: Visit → 1 Site (OOUX) is corrected to Visit → 1 StudySite (TOP) — Visits anchor at the per-Study site role, not the institutional Site.

4.Universal Activity + Task specialization is content, not shape

Per the universal-foundation posture in FIRST-PRINCIPLES, Visit's sub-objects accommodate any assessment without modeling its specifics. The same TOP entity shape handles vitals, MRI, ePRO, biopsy, IP administration, lab draws, ECGs, sequencing — anything.

The architectural moat: standards-up vendors model N entity types per therapeutic area (DICOMImagingStudy, PHQ9Response, LabResult, EProSession). TOP carries one universal pattern that handles all of them. External systems (DICOM PACS, lab LIS, ePRO platform, EHR, sequencing pipelines) hold implementation specifics; TOP holds the universal trial-conduct-realm reference; URI references point to wherever the specialized artifact actually lives.

5.Native temporal + PROV — applied foundation IS a W3C PROV graph by construction

Every Visit-related entity declares its PROV type via rdfs:subClassOf in the emitted shapes (per the v0.4.1 commitment):

Relationship-level PROV semantics:

NGSI-LD temporal-property semantics on lifecycle attributes (visitStatus, activityStatus, taskStatus): each value bracketed by validFrom / validUntil, queryable as a trajectory. Task.observedAt is canonical Property metadata for the value's measurement timestamp — NOT a flat performedDateTime attribute.

6.FHIR Questionnaire projection force-multiplier for EHR / SMART / ePRO integration

TOP's universal Visit → Activity → Task hierarchy projects cleanly to FHIR R5 Questionnaire (form template) and QuestionnaireResponse (captured data). This is the consuming view that turns TOP into a single-source-of-truth for clinical-trial forms across Epic, Cerner, SMART on FHIR apps, ePRO vendors.

Force-multiplier story: today, sponsors maintain forms separately in 4-5 systems (CRF builder, SMART on FHIR app, ePRO vendor, EHR config). With TOP, the protocol → TOP VisitDefinition + ActivityTemplate + TaskTemplate is the single source; the FHIR Questionnaire adapter projects to canonical Questionnaire JSON; Epic / Cerner / ePRO devices all consume the same Questionnaire. Reverse: ePRO devices emit QuestionnaireResponse; the TOP ingester reads it and creates Visit + Activities + Tasks.

Adapter implementation deferred to v0.6+: tools/project_to_fhir_questionnaire.py takes a VisitDefinition (with linked Activity-template and Task-template metadata) and emits Questionnaire JSON. ~200-300 lines of Python. Bidirectional: also tools/ingest_fhir_questionnaire_response.py.

7.Chain-of-custody view the consuming view that compliance vendors render from audit logs; TOP renders from foundation facts

The foundation decisions in this lift enable per-Activity provenance views. Compliance vendors render these from hand-curated audit logs; TOP renders them from foundation facts in real time, against any Activity, by graph traversal. Example query for "show me the chain of custody for Maria's blood draw at C1D1":

PREFIX prov: <http://www.w3.org/ns/prov#>
PREFIX top:  <https://top.scientix.ai/onto/clinical/v1#>

SELECT ?activity ?actor ?equipment ?document ?observedAt WHERE {
  ?visit a top:Visit ;
         top:forParticipant ?participant ;
         top:hasActivity ?activity .
  ?participant top:firstName "Maria" .
  ?activity top:activityName "Blood Draw — CBC Panel" ;
            prov:wasAssociatedWith ?actor ;        # phlebotomist
            prov:used ?equipment ;                  # centrifuge, dry shipper
            top:governedBy ?document .              # SOP
  ?activity top:hasTask / top:observedAt ?observedAt .
}

No audit-log table. No translation layer. The chain assembles from foundation triples. Every checkmark in a regulator's compliance view is one of these triples.

8.Model summary attributes, relationships, sub-objects · full set in source/top-strawman.json

Visit attributes (~17)

Visit relationships (~7)

Sub-objects of Visit (3)

VisitDefinition (Study sub-object) — ~10 attrs

9.Why this shape — architectural decisions

10.Cross-walks FHIR R5 / SDTM / CDASH / USDM / OMOP · projection-edge documentation

Visit → standards (operational)

Activity → standards (varies by content, same TOP shape)

The same TOP Activity entity shape projects to different standards resources depending on its content (biomedicalConceptCode + activityType). The projection adapter at the deployment edge does the routing.

Task → standards (varies by taskValueType + content)

11.SHACL invariants 9 new for Visit lift · 34 total in the graph

12.Stress-test scenarios six cases · plain English to graph shape

13.Open issues

1. ActivityTemplate as Study sub-object (v0.6+). Currently VisitDefinition.hasExpectedActivityTemplate is flagged-missing. Lifts when the SOA grid needs richer template modeling and the FHIR Questionnaire projection adapter requires per-Activity template metadata.
2. FHIR Questionnaire projection adapter (tools/project_to_fhir_questionnaire.py). Implementation deferred to v0.6. Bidirectional: projects VisitDefinition → Questionnaire; ingests QuestionnaireResponse → Visit + Activities + Tasks.
3. Equipment.calibrationStatus as NGSI-LD temporal property. Per the chain-of-custody mock-up, Equipment calibration currency is a SHACL-queryable assertion at activity-time. Defers to a small Equipment enrichment PR.
4. Person.hasCredential richer credentialType enum. Per the chain-of-custody mock-up: phlebotomy certs, IATA shipping certs, GCP training certs all surface as Credentials. Defers to a Credential horizontal enrichment.
5. Document section anchors (§7.4, §7.6 references). Per the chain-of-custody mock-up. Defers to a Document horizontal enrichment.
6. Continuous monitoring data (Log temporal-property enrichment). Cold-chain temperature logs, CGM streams, wearable data. Log horizontal extension; URI_REFERENCE on Task to the log file is the foundation-side handle.
7. Event lift (v0.7+). AdverseEvent / Other Clinical Event with eventCategory enum + the OOUX Path C reportability handoff. Visit.hasAdverseEvent + VisitObservation.escalatedTo unlocks at that point.
8. Twin-spec planning note. Now that Visit + Activity + Task expand the queryability surface significantly, the twin-synthesizer contract spec lifts as a planning note in v0.6+.