# Vercy AI instruction - YAML 1.2 (JSON-compatible) { "vercy": "1.0-draft", "publication": { "status": "research-draft", "adjudicationStatus": "reviewable-draft", "publishableCanonical": false, "generatedAt": "2026-08-24T23:11:46Z", "synthesisSha256": "d57e39ceef269d8766e84cea69219763697665aa49daf352b2ee2180f85b100e", "providers": [ "Claude", "Grok" ] }, "metaModel": { "id": "WM-ACT-015", "registryId": "vr.wm-act-015", "name": "Occurrence / Event", "version": "0.3.0-research.1", "previousVersions": [], "entryKind": "event", "family": "World Models", "category": "Activities and processes", "industry": [ "Cross-industry" ], "domain": [ "ACT.EVT" ], "tags": [ "occurrence", "event", "act.evt" ], "status": "research draft" }, "canonicalUrl": "https://ver.cy/models/wm-act-015-occurrence-event/", "sourceUrl": "https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-act-015", "model": { "registry_id": "vr.wm-act-015", "model_id": "WM-ACT-015", "name": "Occurrence / Event", "entry_kind": "event", "purpose": "Provide the format-neutral backbone for recording that a discrete thing happened in the world — what occurred, when, where, who or what took part, on what evidence, with what certainty, and how it relates to other occurrences — so that every specialised event model reuses one shape for time, place, participation, causality and record correction.", "scope_statement": "This model covers the record of an individuated occurrence: its identity and boundary, its type, its factual and record status, its temporal position and extent (including event time versus observation and ingestion time, temporal reference frames and stated uncertainty), its spatial or virtual setting, the participation of parties and objects and the entities used or generated, its part-whole and causal relations to other occurrences, the sources and evidence on which it is asserted, and the governance of the record (stewardship, disclosure, correction, retention, alignment and exchange). It is deliberately storage- and interface-neutral: JSON, YAML, Markdown, RDF, Git, MCP and MongoDB are projections of these semantics, not the semantics.", "in_scope": [ "Individuation and identity of a single occurrence, including deduplication keys and identifier supersession", "Occurrence typing against governed code lists and mapping to external event vocabularies", "Factual and record status, including negative assertions (it did not happen) and in-error records", "Temporal position and extent as instants, intervals, durations and open-ended spans, with an explicit temporal reference frame", "Separation of event time, phenomenon time, observation/result time, record/ingestion time and correction declaration time", "Stated temporal precision, approximation and uncertainty, including unspecified components", "Place and setting statements that reference, but do not define, external place identities; geometry with a declared CRS", "Participation of parties and objects, the capacity or role in which each took part, and delegation of responsibility for participation", "Entities used, generated, transformed or invalidated by the occurrence, and the quantities involved", "Part-whole, series and episode aggregation of occurrences", "Asserted causal and influence links between occurrences, with asserter and confidence", "Source records, reporting chains, evidence artifacts and their integrity and custody", "Corroboration, certainty and conflicting accounts", "Append-only correction, retraction and supersession of occurrence records", "Stewardship, participant-level disclosure control, retention classes and disposition", "Alignment to external standards and projection into exchange envelopes" ], "out_of_scope": [ "Intent, deliberation, motive and moral or legal responsibility of an actor — these specialise the occurrence in the Act model", "Reciprocity and mutual-participation semantics — these specialise the occurrence in the Encounter model", "Identity, attributes and lifecycle of participating persons, organisations and assets", "Identity, naming, addressing and gazetteer resolution of places", "Result values, units, scales and measurement uncertainty of observations", "Planned, requested or scheduled future actions and their fulfilment workflow", "Type-level recurring patterns and phenomena as distinct from their individual instances", "State conditions that hold over an interval without being a discrete happening", "Incident triage, escalation and response workflow", "Transport bindings, wire formats, serialization and query-language syntax", "System audit trails of operations performed on the record store", "Business process and workflow definitions that occurrences might conform to" ], "boundary_notes": [ { "neighbor": "WM-ACT-002 Act", "distinction": "PROV-O separates mere occurrence from agent responsibility (prov:wasAssociatedWith, prov:Association) and CIDOC CRM separates E5 Event from E7 Activity, defined as actions intentionally carried out by an actor; intent and responsibility therefore belong to the Act model while this model records only that parties participated and in what capacity.", "source_refs": [ "SRC-001", "SRC-006" ] }, { "neighbor": "WM-ACT-018 Encounter", "distinction": "This model records participation as a set of one-sided involvements; reciprocal or mutual participation between two or more parties, and the obligations arising from it, are added by the Encounter specialisation.", "source_refs": [ "SRC-006", "SRC-007" ] }, { "neighbor": "Observation and measurement model", "distinction": "SOSA treats an Observation as an act that occurs and therefore as an occurrence, but the observable property, procedure, sensor and result value belong to the measurement model; this model retains only the linkage and the phenomenonTime/resultTime distinction.", "source_refs": [ "SRC-008" ] }, { "neighbor": "Address / Location Referencing model (legacy U7)", "distinction": "GeoSPARQL separates geo:Feature (the identified real-world thing) from geo:Geometry (its spatial representation); this model carries the geometry and the granularity of a place statement but references Feature identity externally.", "source_refs": [ "SRC-011" ] }, { "neighbor": "Request / Plan model", "distinction": "The HL7 FHIR workflow patterns distinguish Event (an activity that has taken place or is ongoing) from Request (a desired future action); scheduled-but-not-yet-occurred items are not occurrences here, which is why schema.org eventStatus values such as EventScheduled are treated as schedule state, not factual status.", "source_refs": [ "SRC-007", "SRC-012" ] }, { "neighbor": "Observed Phenomenon model (legacy X2)", "distinction": "A recurring pattern is a type-level construct; this model records individual instances and may reference the series they instantiate, but does not define the pattern itself.", "source_refs": [ "SRC-008", "SRC-012" ] }, { "neighbor": "Situation / Condition model (legacy X4)", "distinction": "OWL-Time distinguishes a temporal entity from what holds during it; states that persist over an interval are situations, while this model records the discrete happenings that open, advance and close them.", "source_refs": [ "SRC-002", "SRC-007" ] }, { "neighbor": "Exchange envelope and transport (CloudEvents)", "distinction": "CloudEvents defines an occurrence as the statement of fact and the event as the data record expressing it with context; the envelope attributes id, source, type and time are a projection of this model's identity, typing and event-time semantics, not additional semantics.", "source_refs": [ "SRC-009" ] }, { "neighbor": "Audit trail model (legacy S4)", "distinction": "Operations performed on the occurrence store are audited elsewhere; what stays here is the provenance of the assertion itself — who reported it, when it was recorded and by what declaration it was corrected.", "source_refs": [ "SRC-001", "SRC-005" ] } ] }, "sources": [ { "id": "SRC-001", "title": "PROV-O: The PROV Ontology", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/prov-o/", "version_or_date": "W3C Recommendation, 30 April 2013", "source_type": "ontology", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:10:00Z", "relevance": "Normative definitions of prov:Activity (something that occurs over a period of time and acts upon or with entities), prov:Entity, prov:Agent, startedAtTime/endedAtTime, wasAssociatedWith, wasAttributedTo, wasInformedBy, wasDerivedFrom, the qualified Association/Usage/Generation/Communication pattern and prov:atLocation." }, { "id": "SRC-002", "title": "Time Ontology in OWL (OWL-Time)", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/owl-time/", "version_or_date": "W3C Recommendation 19 October 2017; Candidate Recommendation Draft 15 November 2022", "source_type": "ontology", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:11:00Z", "relevance": "TemporalEntity with the two subclasses Instant and Interval, hasBeginning/hasEnd/hasTemporalDuration, Allen interval relations, DateTimeDescription and TimePosition, and the hasTRS property that makes the temporal reference system explicit for non-Gregorian, ordinal and geologic scales." }, { "id": "SRC-003", "title": "RFC 3339 — Date and Time on the Internet: Timestamps", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc3339", "version_or_date": "RFC 3339, July 2002, Proposed Standard (updated by RFC 9557)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:12:00Z", "relevance": "Normative timestamp grammar requiring seconds and a time-offset of 'Z' or a numeric offset, leap-second handling (23:59:60), and the '-00:00' convention meaning the UTC instant is known but the local offset is not." }, { "id": "SRC-004", "title": "RFC 9557 — Date and Time on the Internet: Timestamps with Additional Information", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc9557.html", "version_or_date": "RFC 9557, April 2024, Standards Track (updates RFC 3339)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:13:00Z", "relevance": "Time-zone annotations and suffix tags on RFC 3339 timestamps, and the explicit warning that copying a UTC offset into an offset-only time zone wrongly asserts that the offset will never change — grounding the requirement to keep the IANA time zone name alongside the offset." }, { "id": "SRC-005", "title": "EPCIS Ontology (EPCIS 2.0)", "organization": "GS1", "url": "https://ref.gs1.org/standards/epcis/epcis-ontology.ttl", "version_or_date": "EPCIS ontology version 2.0; created 2021-06-01, modified 2021-09-30", "source_type": "ontology", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:14:00Z", "relevance": "Machine-readable definition of EPCISEvent and its subclasses (ObjectEvent, AggregationEvent, AssociationEvent, TransactionEvent, TransformationEvent), the eventID/eventTime/eventTimeZoneOffset/recordTime split, action, bizStep, disposition, readPoint, bizLocation, bizTransactionList, sourceList/destinationList, sensorElementList, certificationInfo, and the ErrorDeclaration class with declarationTime, reason and correctiveEventIDs." }, { "id": "SRC-006", "title": "Definition of the CIDOC Conceptual Reference Model, version 7.1.3", "organization": "CIDOC CRM Special Interest Group / ICOM", "url": "https://cidoc-crm.org/html/cidoc_crm_v7.1.3.html", "version_or_date": "Version 7.1.3, February 2024", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:15:00Z", "relevance": "Scope notes for E5 Event, E4 Period, E7 Activity, E52 Time-Span, E53 Place and E93 Presence; properties P4 has time-span, P7 took place at, P11 had participant, P14 carried out by, P17 was motivated by, P9 consists of; and the P173–P185 family expressing fuzzy temporal ordering without precise boundaries." }, { "id": "SRC-007", "title": "FHIR Event Pattern (Release 5)", "organization": "Health Level Seven International (HL7)", "url": "https://www.hl7.org/fhir/event.html", "version_or_date": "FHIR Release 5 (R5), version 5.0.0, Standard for Trial-Use", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:16:00Z", "relevance": "The normative Event workflow pattern: identifier, basedOn, partOf, status and statusReason, category/code, subject, encounter, occurrence[x], recorded, reported, performer with function and actor, location, reason, relevantHistory; the status vocabulary including not-done and entered-in-error; and the explicit Event-versus-Request boundary." }, { "id": "SRC-008", "title": "Semantic Sensor Network Ontology (SSN/SOSA)", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/vocab-ssn/", "version_or_date": "W3C Recommendation, 19 October 2017 (link corrections 8 December 2017)", "source_type": "ontology", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:17:00Z", "relevance": "sosa:Observation, Sampling and Actuation as acts that occur; FeatureOfInterest, ObservableProperty, Procedure and Sensor; and the normative distinction between sosa:phenomenonTime (the time the result applies to the feature) and sosa:resultTime (when the act completed)." }, { "id": "SRC-009", "title": "CloudEvents — Version 1.0.2 Specification", "organization": "Cloud Native Computing Foundation (CNCF) Serverless Working Group", "url": "https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/spec.md", "version_or_date": "CloudEvents specification version 1.0.2", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-25T09:18:00Z", "relevance": "Definitions of occurrence ('the capture of a statement of fact') versus event ('a data record expressing an occurrence and its context'); REQUIRED attributes id, source, specversion, type; OPTIONAL time, subject, dataschema, datacontenttype; the rule that source+id MUST be unique per distinct event and the duplicate-detection consequence; and the caveat that producers may substitute an alternative time when the true occurrence time is unavailable." }, { "id": "SRC-010", "title": "Extended Date/Time Format (EDTF) Specification", "organization": "Library of Congress, Network Development and MARC Standards Office", "url": "https://lcnetdev.github.io/standards/datetime/edtf.html", "version_or_date": "Specification of 22 October 2018, last modified 4 February 2019; incorporated as a profile of ISO 8601-2:2019", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-25T09:19:00Z", "relevance": "Level 0/1/2 syntax for reduced precision, uncertain '?', approximate '~', uncertain-and-approximate '%', unspecified digits 'X', open and unknown interval endpoints ('..'), seasons and sub-year groupings, and one-of '[]' versus all-of '{}' sets — the only fetched source giving a normative encoding for temporal uncertainty." }, { "id": "SRC-011", "title": "OGC GeoSPARQL — A Geographic Query Language for RDF Data, version 1.1", "organization": "Open Geospatial Consortium (OGC)", "url": "https://docs.ogc.org/is/22-047r1/22-047r1.html", "version_or_date": "OGC 22-047r1, version 1.1, published 29 January 2024", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:20:00Z", "relevance": "geo:SpatialObject, geo:Feature and geo:Geometry with hasGeometry, hasDefaultGeometry, hasSerialization, asWKT, asGeoJSON, hasCentroid and hasBoundingBox, and the requirement to declare the coordinate reference system by URI — grounding the separation of place identity from geometric representation." }, { "id": "SRC-012", "title": "Event — Schema.org Type", "organization": "Schema.org community (W3C Schema.org Community Group)", "url": "https://schema.org/Event", "version_or_date": "Schema.org vocabulary version 30.0, 19 March 2026", "source_type": "classifier", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-25T09:21:00Z", "relevance": "Widely deployed public event typing with startDate/endDate/duration, location including VirtualLocation, eventAttendanceMode, superEvent/subEvent, organizer/performer/attendee, identifier — and the eventStatus vocabulary (EventScheduled, EventCancelled, EventPostponed, EventRescheduled) whose scheduling orientation is the counterexample that separates schedule state from factual status." }, { "id": "SRC-013", "title": "ODRL Information Model 2.2", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/odrl-model/", "version_or_date": "W3C Recommendation, 15 February 2018", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:22:00Z", "relevance": "Policy (Set/Offer/Agreement), Permission, Prohibition, Duty, Asset, Party, Action, Constraint, assigner/assignee roles and the conflict-resolution strategies perm/prohibit/invalid — a machine-readable grounding for participant-level disclosure control and for exceptions expressed as duties." }, { "id": "SRC-014", "title": "Art. 5 GDPR — Principles relating to processing of personal data (unofficial reproduction of Regulation (EU) 2016/679)", "organization": "Intersoft Consulting (gdpr-info.eu)", "url": "https://gdpr-info.eu/art-5-gdpr/", "version_or_date": "Reproduction of Regulation (EU) 2016/679; page accessed 25 August 2026", "source_type": "secondary", "primary_source": false, "authority_tier": 4, "accessed_at": "2026-08-25T09:23:00Z", "relevance": "Purpose limitation, data minimisation, accuracy (inaccurate data erased or rectified without delay) and storage limitation with the Article 89 archiving derogation — used only because the official EUR-Lex text could not be retrieved live at access time." }, { "id": "SRC-015", "title": "Art. 17 GDPR — Right to erasure ('right to be forgotten') (unofficial reproduction of Regulation (EU) 2016/679)", "organization": "Intersoft Consulting (gdpr-info.eu)", "url": "https://gdpr-info.eu/art-17-gdpr/", "version_or_date": "Reproduction of Regulation (EU) 2016/679; page accessed 25 August 2026", "source_type": "secondary", "primary_source": false, "authority_tier": 4, "accessed_at": "2026-08-25T09:24:00Z", "relevance": "Grounds for erasure in Article 17(1) and the Article 17(3) exceptions for freedom of expression, legal obligation and public-interest tasks, public health, archiving/scientific/historical research and statistics, and the establishment, exercise or defence of legal claims — the exception set that reconciles erasure with an append-only occurrence record." }, { "id": "SRC-016", "title": "Definition of the CIDOC Conceptual Reference Model, Version 7.0 and 7.1.3 (ISO 21127:2023 content)", "organization": "CIDOC CRM Special Interest Group / ICOM", "url": "https://cidoc-crm.org/html/cidoc_crm_v7.0.html", "version_or_date": "7.0 June 2020; 7.1.3 February 2024", "source_type": "ontology", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "E5 Event and E7 Activity scope notes, E52 Time-Span inner and outer bounds (P81/P82), participation (P11, P12, P14), meronymy (P9) and influence (P15) that ground the occurrence backbone." }, { "id": "SRC-017", "title": "ISO 21127:2023 Information and documentation — A reference ontology for the interchange of cultural heritage information", "organization": "ISO / CIDOC CRM SIG", "url": "https://www.iso.org/standard/85100.html", "version_or_date": "2023; community equivalent CIDOC CRM 7.1.3", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "Formal standard status of the CIDOC CRM alignment target used in the E5 Event alignment entry." }, { "id": "SRC-018", "title": "schema.org EventStatusType", "organization": "Schema.org", "url": "https://schema.org/EventStatusType", "version_or_date": "V30.0 2026-03-19", "source_type": "schema", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "Schedule-plane status values EventScheduled, EventCancelled, EventPostponed, EventRescheduled and EventMovedOnline, plus previousStartDate." }, { "id": "SRC-019", "title": "RFC 3339 Date and Time on the Internet: Timestamps", "organization": "IETF Network Working Group", "url": "https://www.rfc-editor.org/rfc/rfc3339.html", "version_or_date": "July 2002", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "Instant timestamps with seconds and explicit numeric offset or Z, the -00:00 unknown-offset convention, leap-second second=60, and the limits of RFC 3339 for intervals and non-Gregorian calendars." }, { "id": "SRC-020", "title": "GS1 EPCIS Standard (ISO/IEC 19987) — visibility event data model", "organization": "GS1", "url": "https://ref.gs1.org/standards/epcis/", "version_or_date": "EPCIS 2.0 / ISO-IEC 19987 family", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "eventTime versus recordTime and eventTimeZoneOffset, ObjectEvent/AggregationEvent/TransactionEvent/TransformationEvent/AssociationEvent, bizStep and disposition, readPoint versus bizLocation, and ADD/OBSERVE/DELETE action." }, { "id": "SRC-021", "title": "ISO/IEC 21838-2:2021 Basic Formal Ontology (BFO) and BFO 2020 occurrent hierarchy", "organization": "ISO/IEC JTC 1 and BFO-ontology maintainers", "url": "https://github.com/BFO-ontology/BFO-2020", "version_or_date": "ISO/IEC 21838-2:2021 / BFO 2020", "source_type": "ontology", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "Occurrent hierarchy in which unfolding happenings are processes and instantaneous beginnings and endings are process boundaries, with no separate Event class." } ], "structure": { "bundles": [ { "id": "occurrence-core", "name": "Occurrence Core", "description": "The identity, boundary, type and factual status of the happening itself, before anything is said about time, place, participation or cause.", "rationale": "PROV-O, CIDOC CRM, EPCIS, the FHIR Event pattern and CloudEvents all require a typed, identified, individuated occurrence as the anchor for every further assertion; CloudEvents makes identity normative (source+id MUST be unique) and FHIR makes factual status normative (not-done, entered-in-error).", "source_refs": [ "SRC-001", "SRC-005", "SRC-006", "SRC-007", "SRC-009" ], "layers": [ { "id": "identity-and-individuation", "name": "Identity and Individuation", "description": "How one occurrence is delimited from the continuum of activity and how that single occurrence is named and re-found across systems.", "source_refs": [ "SRC-005", "SRC-006", "SRC-009" ], "findings": [ { "id": "occurrence-identifier", "name": "Occurrence identifier and deduplication key", "description": "The authoritative name of the occurrence record, the scheme it belongs to, the fallback minting rule when no master system exists, and the key on which two records are judged to denote the same happening.", "source_refs": [ "SRC-005", "SRC-009", "SRC-001" ], "questions": [ { "id": "q-id-authority", "text": "Which system of record holds the authoritative identifier for this occurrence, and under what identifier scheme was it issued?", "kind": "identity", "answer_data": [ "Name and IRI of the master system", "Identifier value as issued", "Identifier scheme IRI and version" ] }, { "id": "q-id-sameness", "text": "What combination of attributes decides that two incoming records denote the same occurrence rather than two distinct occurrences?", "kind": "constraint", "answer_data": [ "Ordered list of deduplication key elements", "Producer context identifier equivalent to a CloudEvents source", "Normalisation applied before comparison" ] }, { "id": "q-id-fallback", "text": "When no master-system identifier exists, is a governed IRI or a locally minted UUID or ULID used, and which authority mints it?", "kind": "decision", "answer_data": [ "Identifier kind chosen", "Minting authority reference", "Mint instant in RFC 3339 with offset" ] }, { "id": "q-id-supersession", "text": "Under what conditions may the identifier be superseded, and how does a consumer resolve an old identifier to the current record?", "kind": "lifecycle", "answer_data": [ "Superseded identifier values", "Supersession relation and reason", "Resolution endpoint or alias register reference" ] } ], "data_elements": [ { "id": "de-occurrence-id", "name": "occurrenceIdentifier", "description": "The authoritative identifier of the occurrence record.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-005", "SRC-009" ] }, { "id": "de-occurrence-id-scheme", "name": "identifierScheme", "description": "Scheme or namespace under which the identifier was issued.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-005" ] }, { "id": "de-alternate-identifier", "name": "alternateIdentifier", "description": "Identifiers assigned by other systems for the same occurrence, including superseded ones.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-009" ] }, { "id": "de-dedup-key", "name": "deduplicationKey", "description": "Canonical key or digest used to detect that two records denote the same happening.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] } ], "artifacts": [], "inline_only_rationale": "Identifier assignment yields no separate deliverable: identifiers are inline attributes of the occurrence record and of any artifact that carries it. Nothing is produced, filed or exchanged as a standalone object, so introducing an artifact here would be unsupported structure." }, { "id": "occurrence-individuation", "name": "Occurrence boundary and granularity", "description": "The criterion by which the happening is delimited, whether it is recorded as instantaneous or extended, and what happens when one occurrence is later found to be several or several to be one.", "source_refs": [ "SRC-006", "SRC-002", "SRC-001" ], "questions": [ { "id": "q-ind-criterion", "text": "What criterion delimits this happening from the surrounding continuum of activity, and who applied it?", "kind": "definition", "answer_data": [ "Individuation criterion statement", "Granularity level code", "Applying party reference" ] }, { "id": "q-ind-extent", "text": "Is the occurrence recorded as an instant with no interior or as an extended process with internal constituent parts?", "kind": "composition", "answer_data": [ "Temporal entity kind (instant or interval)", "References to constituent occurrences", "Whether constituents are exhaustive of the whole" ] }, { "id": "q-ind-resplit", "text": "How is the record repaired when one recorded occurrence turns out to be two, or two turn out to be one?", "kind": "exception", "answer_data": [ "Split or merge relation type", "References to resulting and retired occurrences", "Declaration time and reason for the restructuring" ] } ], "data_elements": [ { "id": "de-granularity-level", "name": "granularityLevel", "description": "Declared level of resolution at which the happening was individuated.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "de-instantaneous-flag", "name": "isInstantaneous", "description": "Whether the occurrence is asserted to have zero extent at the recorded granularity.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-split-merge-link", "name": "splitOrMergeLink", "description": "Link from a retired occurrence to the occurrences that replaced it, or from several to the one that subsumed them.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005", "SRC-006" ] } ], "artifacts": [], "inline_only_rationale": "Individuation is a recorded modelling decision expressed as inline attributes and links between occurrence records; no fetched source treats it as producing a filed deliverable, and inventing one would be unsupported." }, { "id": "occurrence-designation-and-aboutness", "name": "Summary and aboutness", "description": "An occurrence has a human-readable name or summary and may be about other entities. Schema.org Event requires name and allows description, disambiguatingDescription, about and workFeatured or workPerformed. CIDOC P3 has note and P129 is about. FHIR Event.note captures comments by performer or subject. The summary is not a substitute for structured type, time or participants.", "source_refs": [ "SRC-016", "SRC-012", "SRC-007" ], "inline_only_rationale": null, "questions": [ { "id": "occurrence-designation-and-aboutness-q01", "text": "What short summary distinguishes this occurrence from similar happenings, and in which language?", "kind": "classification", "answer_data": [ "summary (string)", "language (bcp47)" ] }, { "id": "occurrence-designation-and-aboutness-q02", "text": "Which entities, works or topics is the occurrence about or did it feature, without treating those as participants?", "kind": "relationship", "answer_data": [ "about_refs (ref-list)", "featured_work_refs (ref-list)" ] }, { "id": "occurrence-designation-and-aboutness-q03", "text": "What disambiguating description is required when name and type are insufficient to separate this particular from another of the same kind?", "kind": "quality", "answer_data": [ "disambiguating_description (string)", "confused_with_refs (ref-list)" ] } ], "data_elements": [ { "id": "occurrence-designation-and-aboutness-data01", "name": "name", "description": "Human-readable name of the occurrence, as required by schema.org Event.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "occurrence-designation-and-aboutness-data02", "name": "summary", "description": "Short summary that distinguishes this occurrence from similar happenings.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-012", "SRC-016" ] }, { "id": "occurrence-designation-and-aboutness-data03", "name": "description", "description": "Longer description or note about the happening (schema.org description; CIDOC P3 has note; FHIR Event.note).", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016", "SRC-012", "SRC-007" ] }, { "id": "occurrence-designation-and-aboutness-data04", "name": "about_refs", "description": "Entities, works or topics the occurrence is about (CIDOC P129 is about; schema.org about, workFeatured, workPerformed), which are not participants.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-016", "SRC-012" ] }, { "id": "occurrence-designation-and-aboutness-data05", "name": "language", "description": "BCP 47 language tag of the name, summary and description text.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] } ], "artifacts": [ { "id": "occurrence-designation-and-aboutness-artifact01", "name": "Occurrence narrative", "description": "Language-tagged name, summary and optional notes used to disambiguate the happening.", "media_or_form": [ "language-tagged text" ], "serial": false, "identity_strategy": "Identified by the parent occurrence identifier plus BCP 47 language tag.", "source_refs": [ "SRC-016", "SRC-012", "SRC-007" ] } ] } ] }, { "id": "typing-and-factuality", "name": "Typing and Factuality", "description": "What kind of occurrence this is, and whether it is asserted to have happened, to be ongoing, not to have happened, or to have been recorded in error.", "source_refs": [ "SRC-005", "SRC-007", "SRC-012" ], "findings": [ { "id": "occurrence-classification", "name": "Occurrence type and governing vocabulary", "description": "The code or codes classifying the occurrence, the scheme that governs them, who may extend that scheme, and how local types map to external event vocabularies.", "source_refs": [ "SRC-005", "SRC-012", "SRC-007", "SRC-006" ], "questions": [ { "id": "q-cls-code", "text": "Which type code or codes classify this occurrence, and from which governed scheme and version do they come?", "kind": "classification", "answer_data": [ "Type code values", "Scheme IRI and version tag", "Human-readable label per code" ] }, { "id": "q-cls-multiplicity", "text": "May an occurrence carry more than one type, and how are conflicting or overlapping types reconciled?", "kind": "constraint", "answer_data": [ "Cardinality rule for type codes", "Precedence or primary-type rule", "Documented overlaps between codes" ] }, { "id": "q-cls-authority", "text": "Which body governs the type vocabulary, and what is the procedure for adding or retiring a code value?", "kind": "authority", "answer_data": [ "Governing body reference", "Change procedure reference", "Retirement and replacement policy" ] }, { "id": "q-cls-mapping", "text": "To which external event vocabularies is each local type mapped, and is the mapping exact, broader or narrower?", "kind": "interoperability", "answer_data": [ "Target term IRIs", "Mapping relation kind", "Evidence supporting the mapping" ] } ], "data_elements": [ { "id": "de-type-code", "name": "occurrenceTypeCode", "description": "Code classifying the kind of occurrence.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-005", "SRC-007" ] }, { "id": "de-type-scheme", "name": "typeSchemeUri", "description": "IRI and version of the scheme governing the type code.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-005", "SRC-012" ] }, { "id": "de-type-external-mapping", "name": "externalTypeMapping", "description": "Mapping from the local type to an external vocabulary term, with the relation kind.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012", "SRC-006" ] } ], "artifacts": [ { "id": "event-type-code-list", "name": "Occurrence type code list", "description": "The published, versioned code list of occurrence types with scheme IRI, labels, definitions, effective date and mappings to external vocabularies.", "media_or_form": [ "controlled vocabulary file (SKOS, CSV or JSON)", "published registry page", "specification annex" ], "serial": false, "identity_strategy": "Scheme IRI plus version tag issued by the governing registry; where the list is Dimension-local, a Dimension-minted UUID recorded with its minting authority. The publication date is metadata, never the identifier.", "source_refs": [ "SRC-005", "SRC-012", "SRC-007" ] } ], "inline_only_rationale": null }, { "id": "occurrence-factuality-status", "name": "Factual assertion and record status", "description": "Whether the happening is asserted to have occurred, is ongoing, is asserted not to have occurred, or the record is repudiated as entered in error, together with the reason and the allowed transitions.", "source_refs": [ "SRC-007", "SRC-005", "SRC-012" ], "questions": [ { "id": "q-fact-status", "text": "What is the current status of this occurrence record, and does that status describe the happening or the record?", "kind": "state", "answer_data": [ "Status code value", "Whether the code applies to the happening or the record", "Instant at which the status took effect" ] }, { "id": "q-fact-transitions", "text": "Which status transitions are permitted, which are terminal, and who is authorised to make each transition?", "kind": "lifecycle", "answer_data": [ "Permitted transition pairs", "Terminal status values", "Authorised role per transition" ] }, { "id": "q-fact-negative", "text": "When the record asserts that the happening did not occur, what evidence and reason support that negative assertion?", "kind": "evidence", "answer_data": [ "Negation flag", "Status reason code", "Supporting source references" ] }, { "id": "q-fact-schedule", "text": "How is schedule state such as cancelled, postponed or rescheduled kept distinct from the assertion that the happening occurred?", "kind": "validation", "answer_data": [ "Schedule status code", "Factual status code", "Constraint linking the two" ] } ], "data_elements": [ { "id": "de-record-status", "name": "recordStatus", "description": "Status of the occurrence record drawn from a governed status vocabulary that includes an in-error value.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-007" ] }, { "id": "de-status-reason", "name": "statusReason", "description": "Coded reason qualifying the status, required for negative and in-error statuses.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007", "SRC-005" ] }, { "id": "de-negation-flag", "name": "assertedNotOccurred", "description": "Explicit assertion that the happening did not take place.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "de-status-effective-at", "name": "statusEffectiveAt", "description": "Instant at which the current status took effect.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007", "SRC-003" ] } ], "artifacts": [], "inline_only_rationale": "Status is a coded inline attribute with a transition history; the deliverable that accompanies a repudiation is the correction notice recorded under the correction finding, so duplicating an artifact here would double-count the same object." } ] } ] }, { "id": "temporality", "name": "Temporality", "description": "When the occurrence happened, in what frame that time is expressed, how precisely it is known, and how event time is separated from the times at which it was observed, recorded and corrected.", "rationale": "OWL-Time supplies the instant/interval model and the explicit temporal reference system; RFC 3339 and RFC 9557 fix the lexical form and warn against offset-only zones; EPCIS separates eventTime, eventTimeZoneOffset and recordTime; SOSA separates phenomenonTime from resultTime; EDTF supplies the only fetched normative encoding of temporal uncertainty.", "source_refs": [ "SRC-002", "SRC-003", "SRC-004", "SRC-005", "SRC-008", "SRC-010" ], "layers": [ { "id": "temporal-position-and-extent", "name": "Temporal Position, Extent and Uncertainty", "description": "The stated time of the happening as instant, interval or duration, the reference frame it is expressed in, and the precision and qualification attached to it.", "source_refs": [ "SRC-002", "SRC-003", "SRC-004", "SRC-010" ], "findings": [ { "id": "event-time-extent", "name": "Event time position and extent", "description": "Whether the occurrence is placed at an instant or over an interval, how beginning, end and duration are stated, and how open-ended or still-running occurrences are expressed.", "source_refs": [ "SRC-002", "SRC-006", "SRC-012" ], "questions": [ { "id": "q-time-kind", "text": "Is the event time expressed as an instant, a bounded interval, or a duration anchored at one end?", "kind": "temporal", "answer_data": [ "Temporal entity kind", "Beginning instant", "End instant or duration" ] }, { "id": "q-time-open", "text": "How is an occurrence that has begun but not ended, or whose end is unknown, distinguished from one with a known end?", "kind": "state", "answer_data": [ "Open-endedness marker", "Reason the end is absent", "Latest instant at which the occurrence was known to be running" ] }, { "id": "q-time-fuzzy-bounds", "text": "Where the boundaries are inherently fuzzy, which outer and inner bounds are asserted for the beginning and the end?", "kind": "constraint", "answer_data": [ "Earliest and latest possible beginning", "Earliest and latest possible end", "Basis for each bound" ] } ], "data_elements": [ { "id": "de-event-begin", "name": "eventTimeBegin", "description": "Instant at which the occurrence began, or the instant of an instantaneous occurrence.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-003" ] }, { "id": "de-event-end", "name": "eventTimeEnd", "description": "Instant at which the occurrence ended, absent for open-ended or instantaneous occurrences.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-event-duration", "name": "eventDuration", "description": "Extent of the occurrence expressed as a duration with a stated temporal unit.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-012" ] }, { "id": "de-temporal-bounds", "name": "temporalOuterBounds", "description": "Asserted earliest and latest possible boundary instants where the true boundary is fuzzy.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] } ], "artifacts": [], "inline_only_rationale": "Temporal position is inline value data typed by OWL-Time and serialised as timestamp literals; no fetched source treats a time statement as a separate filed object." }, { "id": "temporal-reference-frame", "name": "Temporal reference frame, offset and time zone", "description": "The calendar or temporal reference system in which the time is expressed, the required lexical form, and the retention of local offset and IANA time zone name alongside the UTC instant.", "source_refs": [ "SRC-003", "SRC-004", "SRC-002", "SRC-005" ], "questions": [ { "id": "q-trs-frame", "text": "Which temporal reference system is the event time expressed in, and is it declared explicitly rather than assumed to be Gregorian and UTC?", "kind": "temporal", "answer_data": [ "Temporal reference system IRI", "Calendar or scale name", "Whether the frame is declared or defaulted" ] }, { "id": "q-trs-offset", "text": "What UTC offset was in effect at the place of the occurrence, and is the IANA time zone name recorded in addition to that offset?", "kind": "constraint", "answer_data": [ "Numeric UTC offset as recorded", "IANA time zone name", "Whether '-00:00' was used to mean the local offset is unknown" ] }, { "id": "q-trs-nonstandard", "text": "How are ordinal, relative, geologic or non-Gregorian times conveyed to consumers that expect a civil timestamp?", "kind": "interoperability", "answer_data": [ "Alternate position encoding", "Conversion rule or refusal to convert", "Consumer guidance recorded with the value" ] } ], "data_elements": [ { "id": "de-time-offset", "name": "eventTimeZoneOffset", "description": "UTC offset in effect where the occurrence took place, kept as a separate element from the normalised instant.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-005", "SRC-003" ] }, { "id": "de-time-zone-name", "name": "timeZoneName", "description": "IANA time zone name for the place of the occurrence.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-trs-uri", "name": "temporalReferenceSystem", "description": "IRI of the temporal reference system when it is not the Gregorian calendar with UTC.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [], "inline_only_rationale": "The reference frame is a declared attribute of a time value; the only candidate artifact — a time-source attestation — is recorded under ordering and clock integrity to avoid duplicating the same deliverable." }, { "id": "temporal-uncertainty-precision", "name": "Temporal precision, approximation and uncertainty", "description": "The stated precision of the time value and any qualification marking it uncertain, approximate, partly unspecified or drawn from a set of alternatives.", "source_refs": [ "SRC-010", "SRC-002", "SRC-006" ], "questions": [ { "id": "q-unc-precision", "text": "To what precision is the event time actually known, as distinct from the precision at which it happens to be serialised?", "kind": "measurement", "answer_data": [ "Known precision unit", "Serialised precision", "Reason for any difference" ] }, { "id": "q-unc-qualifier", "text": "Is the time asserted as uncertain, approximate, both, or partly unspecified, and to which components does the qualification apply?", "kind": "quality", "answer_data": [ "Qualification marker used", "Components qualified", "Qualified literal as written" ] }, { "id": "q-unc-comparison", "text": "How must a consumer treat an imprecise or qualified time value when ordering, filtering or joining occurrences?", "kind": "validation", "answer_data": [ "Comparison rule for qualified values", "Behaviour when precision differs between operands", "Whether qualified values may be silently coerced" ] } ], "data_elements": [ { "id": "de-time-precision", "name": "statedTimePrecision", "description": "Unit to which the event time is genuinely known.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010", "SRC-002" ] }, { "id": "de-time-qualifier", "name": "temporalQualification", "description": "Uncertainty or approximation marker attached to the time value or to specific components of it.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010" ] }, { "id": "de-edtf-literal", "name": "qualifiedDateLiteral", "description": "The qualified date expression exactly as written, preserved verbatim because its characters are semantically significant.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010" ] } ], "artifacts": [], "inline_only_rationale": "Uncertainty qualification is a literal syntax carried inside the time value itself; it has no independent existence as a deliverable and must not be normalised away into a separate object." } ] }, { "id": "record-time-and-ordering", "name": "Record Time, Observation Time and Ordering", "description": "The distinct clocks that bear on an occurrence record — when it happened, when it was observed, when the result applies, when it was ingested, when a correction was declared — and how records are ordered when those clocks disagree.", "source_refs": [ "SRC-005", "SRC-008", "SRC-007", "SRC-003" ], "findings": [ { "id": "event-versus-record-time", "name": "Event time versus observation and ingestion time", "description": "Separation of the time the happening occurred from the time a result applies to its subject, the time the observing act completed, the time the record entered the store, and the time any correction was declared.", "source_refs": [ "SRC-005", "SRC-008", "SRC-007" ], "questions": [ { "id": "q-rt-separation", "text": "Which distinct times are recorded for this occurrence, and which clock produced each of them?", "kind": "provenance", "answer_data": [ "Event time value", "Observation or result time value", "Record or ingestion time value", "Clock or system responsible for each" ] }, { "id": "q-rt-phenomenon", "text": "Where the record carries an observation, does the phenomenon time differ from the time the observing act completed, and by how much?", "kind": "temporal", "answer_data": [ "Phenomenon time", "Result time", "Stated or computed lag" ] }, { "id": "q-rt-basis", "text": "Which of the recorded times governs retention clocks, query windows and completeness watermarks?", "kind": "decision", "answer_data": [ "Governing time element per purpose", "Rationale for the choice", "Behaviour when the governing time is absent" ] }, { "id": "q-rt-backfill", "text": "How is a record ingested long after the fact distinguished from one captured in near real time?", "kind": "quality", "answer_data": [ "Latency between event time and record time", "Backfill or historical-load marker", "Reporting party for the late record" ] } ], "data_elements": [ { "id": "de-record-time", "name": "recordTime", "description": "Instant at which the occurrence record was accepted into the store.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005", "SRC-007" ] }, { "id": "de-result-time", "name": "resultTime", "description": "Instant at which an observing, sampling or actuating act that produced the record completed.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "de-phenomenon-time", "name": "phenomenonTime", "description": "Time to which an observed result applies to its feature of interest, which may precede the result time.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "de-declaration-time", "name": "declarationTime", "description": "Instant at which an error declaration or other assertion about the record was made.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [], "inline_only_rationale": "These are parallel timestamp attributes of one record; the artifact that carries them is the occurrence record itself, which is exchanged under the delivery finding rather than filed separately here." }, { "id": "ordering-and-clock-integrity", "name": "Ordering, interval relations and clock integrity", "description": "How occurrences are ordered when timestamps tie or clocks disagree, which qualitative interval relations are asserted, and what evidence supports the trustworthiness of the recorded time.", "source_refs": [ "SRC-002", "SRC-003", "SRC-004", "SRC-005" ], "questions": [ { "id": "q-ord-tiebreak", "text": "When two occurrences carry the same timestamp, what deterministic rule establishes their order?", "kind": "constraint", "answer_data": [ "Tie-break element and its ordering", "Sequence or monotonic counter value", "Scope within which the sequence is unique" ] }, { "id": "q-ord-relations", "text": "Which qualitative interval relations between this occurrence and others are asserted rather than computed from timestamps?", "kind": "relationship", "answer_data": [ "Interval relation code", "Related occurrence reference", "Asserting party and basis" ] }, { "id": "q-ord-clocktrust", "text": "What is known about the clock that produced the timestamp, and what protects the record against back-dating?", "kind": "security", "answer_data": [ "Clock source and synchronisation status", "Offset or drift applied at capture", "Attestation or signature covering the timestamp" ] } ], "data_elements": [ { "id": "de-sequence-number", "name": "sequenceNumber", "description": "Monotonic counter establishing order within a declared scope when timestamps are insufficient.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "de-interval-relation", "name": "assertedIntervalRelation", "description": "Qualitative temporal relation asserted between this occurrence and another.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-006" ] }, { "id": "de-clock-source", "name": "clockSource", "description": "Identity and synchronisation state of the clock that produced the recorded time.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003", "SRC-004" ] } ], "artifacts": [ { "id": "time-source-attestation", "name": "Time source attestation", "description": "Record of the clock source, its synchronisation status and any offset applied at the moment the occurrence timestamp was captured, used when the trustworthiness of the time itself is in question.", "media_or_form": [ "signed attestation record", "device or gateway log extract", "time-service status report" ], "serial": false, "identity_strategy": "Master-system identifier of the capturing device or gateway plus the attestation instant expressed in RFC 3339 with seconds and an explicit offset; where no device identifier exists, a Dimension-minted UUID with recorded minting authority.", "source_refs": [ "SRC-003", "SRC-004", "SRC-005" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "spatiality-and-setting", "name": "Spatiality and Setting", "description": "Where the occurrence took place — as a reference to an identified place, as geometry in a declared reference system, or as a non-physical setting — and at what granularity and accuracy.", "rationale": "CIDOC P7 took place at, PROV atLocation and EPCIS readPoint/bizLocation all make a place statement part of an occurrence, while GeoSPARQL supplies the normative separation of Feature identity from Geometry and the requirement to declare a CRS; schema.org adds VirtualLocation and attendance mode for non-physical settings.", "source_refs": [ "SRC-005", "SRC-006", "SRC-001", "SRC-011", "SRC-012" ], "layers": [ { "id": "place-specification", "name": "Place Specification", "description": "The reference to where the occurrence happened and its geometric expression, kept distinct from the identity of the place itself.", "source_refs": [ "SRC-011", "SRC-005", "SRC-001", "SRC-006" ], "findings": [ { "id": "place-reference-and-granularity", "name": "Place reference, role and granularity", "description": "Which identified place the occurrence is attached to, in what role that place plays, at what granularity, and how an unknown or deliberately withheld place is expressed.", "source_refs": [ "SRC-005", "SRC-011", "SRC-001", "SRC-006" ], "questions": [ { "id": "q-place-ref", "text": "Which identified place does this occurrence reference, and in which external register does that identity live?", "kind": "spatial", "answer_data": [ "Place feature IRI or master-system identifier", "Register or gazetteer reference", "Place label as recorded" ] }, { "id": "q-place-role", "text": "Does the record distinguish the precise point of capture from the wider business or organisational location, and how are both used?", "kind": "composition", "answer_data": [ "Capture point reference", "Enclosing location reference", "Rule relating the two" ] }, { "id": "q-place-granularity", "text": "At what granularity is the place asserted, and is that granularity a limit of knowledge or a deliberate generalisation?", "kind": "quality", "answer_data": [ "Granularity level code", "Whether generalisation was deliberate", "Party that decided the granularity" ] }, { "id": "q-place-absent", "text": "How is a place that is unknown, inapplicable or withheld distinguished from one that was simply not captured?", "kind": "exception", "answer_data": [ "Absence reason code", "Whether withholding is policy-driven", "Reference to the governing policy" ] } ], "data_elements": [ { "id": "de-place-ref", "name": "placeReference", "description": "Reference to the externally identified place at which the occurrence took place.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006", "SRC-001", "SRC-011" ] }, { "id": "de-capture-point", "name": "capturePointReference", "description": "The precise point at which the occurrence was captured, as distinct from the enclosing location.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "de-place-granularity", "name": "placeGranularity", "description": "Declared level of spatial resolution of the place statement.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "de-place-absence-reason", "name": "placeAbsenceReason", "description": "Coded reason why no place is asserted.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] } ], "artifacts": [], "inline_only_rationale": "A place statement is a typed reference into the Address / Location Referencing model; the referenced place record is that model's artifact, and duplicating it here would violate the no-duplication boundary rule." }, { "id": "geometry-crs-and-spatial-uncertainty", "name": "Geometry, coordinate reference system and positional accuracy", "description": "The geometric representation of where the occurrence happened, the coordinate reference system it is expressed in, its positional accuracy, and any generalisation applied before disclosure.", "source_refs": [ "SRC-011", "SRC-001" ], "questions": [ { "id": "q-geo-serialisation", "text": "In which serialisation is the geometry expressed, and which coordinate reference system URI governs its coordinates?", "kind": "spatial", "answer_data": [ "Geometry serialisation and literal", "Coordinate reference system URI", "Whether a default CRS was assumed" ] }, { "id": "q-geo-accuracy", "text": "What positional accuracy is claimed for the geometry, and what produced that claim?", "kind": "measurement", "answer_data": [ "Accuracy value and unit", "Measuring device or method", "Confidence level of the accuracy claim" ] }, { "id": "q-geo-generalisation", "text": "Has the geometry been coarsened, offset or clipped before disclosure, and is the original retained under restriction?", "kind": "privacy", "answer_data": [ "Generalisation method and parameter", "Whether the original geometry is retained", "Policy authorising the generalisation" ] } ], "data_elements": [ { "id": "de-geometry", "name": "occurrenceGeometry", "description": "Geometric representation of the place of the occurrence.", "value_kind": "geometry", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "de-crs-uri", "name": "coordinateReferenceSystem", "description": "URI of the coordinate reference system governing the geometry.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "de-position-accuracy", "name": "positionalAccuracy", "description": "Claimed positional accuracy of the geometry with its unit.", "value_kind": "quantity", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "de-spatial-generalisation", "name": "spatialGeneralisation", "description": "Method and parameter by which the disclosed geometry was coarsened relative to the captured one.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014" ] } ], "artifacts": [ { "id": "geospatial-trace-file", "name": "Geospatial trace or geometry file", "description": "Serialised geometry, track or map extract expressing where the occurrence took place, exchanged as a file when the geometry is too large or too structured to carry inline.", "media_or_form": [ "GeoJSON document", "WKT literal file", "GPS track file", "georeferenced map image" ], "serial": false, "identity_strategy": "File identifier issued by the producing capture system, paired with a cryptographic digest over the canonical bytes; geometry content alone is never treated as identity because identical coordinates recur across occurrences.", "source_refs": [ "SRC-011", "SRC-001" ] } ], "inline_only_rationale": null } ] }, { "id": "setting-and-non-physical-context", "name": "Setting and Non-Physical Context", "description": "Occurrences that take place wholly or partly outside physical space, and the declared context in which the producer situates them.", "source_refs": [ "SRC-012", "SRC-009", "SRC-011" ], "findings": [ { "id": "virtual-and-hybrid-setting", "name": "Virtual, hybrid and producer-context setting", "description": "Whether the occurrence took place physically, virtually or in both modes, how a virtual location is identified, and how the producer's declared context relates to the physical place.", "source_refs": [ "SRC-012", "SRC-009", "SRC-011" ], "questions": [ { "id": "q-set-mode", "text": "Did the occurrence take place in physical space, in a virtual environment, or in both simultaneously?", "kind": "classification", "answer_data": [ "Occurrence mode code", "Physical place reference where applicable", "Virtual location identifier where applicable" ] }, { "id": "q-set-virtualid", "text": "How is the virtual location identified so that two occurrences in the same environment can be recognised as co-located?", "kind": "identity", "answer_data": [ "Virtual location URI or system identifier", "Environment or tenant identifier", "Stability guarantees for that identifier" ] }, { "id": "q-set-context", "text": "What producer context does the record declare, and is it a substitute for the physical place or an addition to it?", "kind": "provenance", "answer_data": [ "Producer context URI", "Relationship of context to physical place", "Whether the context is the only locational statement" ] }, { "id": "q-set-jurisdiction", "text": "Which jurisdiction governs this occurrence, and is it derived from the physical place or asserted independently?", "kind": "authority", "answer_data": [ "Jurisdiction code", "Derivation basis", "Party that asserted the jurisdiction" ] } ], "data_elements": [ { "id": "de-occurrence-mode", "name": "occurrenceMode", "description": "Whether the occurrence was physical, virtual or hybrid.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-virtual-location", "name": "virtualLocation", "description": "Identifier of the virtual environment in which the occurrence took place.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-context-source-uri", "name": "producerContextUri", "description": "URI identifying the context in which the producer situates the occurrence.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "de-jurisdiction", "name": "jurisdiction", "description": "Jurisdiction asserted to govern the occurrence and its record.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-015" ] } ], "artifacts": [], "inline_only_rationale": "Setting is expressed as coded attributes and URIs on the occurrence record; virtual environments are referenced, not filed, and no fetched source supports a separate setting deliverable." } ] } ] }, { "id": "participation-and-effects", "name": "Participation and Effects", "description": "Who and what took part in the occurrence, in what capacity, and which entities were used, produced, transformed or invalidated by it.", "rationale": "CIDOC P11 had participant and P14 carried out by, PROV wasAssociatedWith with qualified Association and actedOnBehalfOf, FHIR performer with function and actor, SOSA featureOfInterest and EPCIS epcList/childEPCs/quantityList/transformationID together establish participation and entity effects as a distinct concern from time and place.", "source_refs": [ "SRC-001", "SRC-005", "SRC-006", "SRC-007", "SRC-008" ], "layers": [ { "id": "participants-and-roles", "name": "Participants and Roles", "description": "The parties and objects involved and the capacity in which each was involved, including delegation of that capacity.", "source_refs": [ "SRC-001", "SRC-006", "SRC-007", "SRC-008" ], "findings": [ { "id": "participant-reference", "name": "Participant and subject reference", "description": "Which parties and objects took part, which one is the subject or feature of interest, how they are referenced into external party models, and how pseudonymous or unidentified participants are handled.", "source_refs": [ "SRC-006", "SRC-007", "SRC-008", "SRC-001" ], "questions": [ { "id": "q-part-who", "text": "Which parties and objects are recorded as taking part, and by which external identifiers are they referenced?", "kind": "relationship", "answer_data": [ "Participant references and kinds", "External identifier scheme per participant", "Register in which each identity is maintained" ] }, { "id": "q-part-subject", "text": "Which participant is the subject or feature of interest of the occurrence, as distinct from the others involved?", "kind": "composition", "answer_data": [ "Subject reference", "Basis for singling it out", "Whether more than one subject is permitted" ] }, { "id": "q-part-minimum", "text": "Does this occurrence type require at least one participant, and is an occurrence with no identified participant valid?", "kind": "constraint", "answer_data": [ "Minimum participation cardinality per type", "Validity rule for participant-free occurrences", "Reason code when no participant is identified" ] }, { "id": "q-part-pseudonymous", "text": "How is a participant recorded when their identity is unknown, pseudonymous or deliberately not resolved?", "kind": "privacy", "answer_data": [ "Pseudonym or local handle", "Whether resolution is possible and by whom", "Policy governing non-resolution" ] } ], "data_elements": [ { "id": "de-participant-ref", "name": "participantReference", "description": "Reference to a party or object recorded as taking part in the occurrence.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006", "SRC-007" ] }, { "id": "de-participant-kind", "name": "participantKind", "description": "Whether the participant is a person, organisation, device, software agent or physical object.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-008" ] }, { "id": "de-subject-ref", "name": "subjectReference", "description": "The participant that is the subject or feature of interest of the occurrence.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007", "SRC-008" ] } ], "artifacts": [], "inline_only_rationale": "Participants are references into the Person, Organization and Asset models; their records belong to those models, and the participation link itself is inline relationship data on the occurrence." }, { "id": "role-capacity-and-delegation", "name": "Role, capacity, presence and delegation", "description": "The capacity in which each participant took part, whether they were present or absent, on whose behalf they acted, and the governed vocabulary from which roles are drawn.", "source_refs": [ "SRC-001", "SRC-006", "SRC-007" ], "questions": [ { "id": "q-role-code", "text": "In what capacity did each participant take part, and from which governed role vocabulary is that capacity drawn?", "kind": "classification", "answer_data": [ "Role code per participant", "Role vocabulary IRI and version", "Whether a participant may hold several roles" ] }, { "id": "q-role-delegation", "text": "On whose behalf did a participant act, and how far back does the recorded delegation chain reach?", "kind": "authority", "answer_data": [ "Delegating party reference", "Depth and completeness of the chain", "Instrument or plan authorising the delegation" ] }, { "id": "q-role-presence", "text": "Was the participant physically or virtually present, represented, or recorded as involved without being present?", "kind": "state", "answer_data": [ "Presence mode code", "Representing party where applicable", "Basis for asserting presence" ] }, { "id": "q-role-boundary", "text": "Which recorded participation facts stop short of asserting intent or responsibility, and where does that assertion belong instead?", "kind": "definition", "answer_data": [ "Participation facts recorded here", "Facts deferred to the Act model", "Reference to the specialising record if one exists" ] } ], "data_elements": [ { "id": "de-participation-role", "name": "participationRole", "description": "Capacity in which a participant took part in the occurrence.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-006", "SRC-007" ] }, { "id": "de-on-behalf-of", "name": "actedOnBehalfOf", "description": "Party on whose behalf a participant acted, forming a delegation chain.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-presence-mode", "name": "presenceMode", "description": "Whether the participant was present physically, present virtually, represented or absent.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006", "SRC-012" ] } ], "artifacts": [], "inline_only_rationale": "Role and delegation are qualified relationship attributes on the participation link; the governed role vocabulary is published as part of the owner package's code lists rather than as an artifact of an individual occurrence." } ] }, { "id": "entities-and-changes", "name": "Entities and Changes", "description": "What the occurrence consumed, produced, transformed or invalidated, and in what quantity.", "source_refs": [ "SRC-001", "SRC-005", "SRC-006" ], "findings": [ { "id": "affected-entities-and-transformation", "name": "Entities used, generated and transformed", "description": "The inputs consumed and outputs produced by the occurrence, the quantities involved, the state change effected, and the linkage that ties inputs to outputs across separately recorded steps.", "source_refs": [ "SRC-001", "SRC-005", "SRC-006" ], "questions": [ { "id": "q-ent-io", "text": "Which entities did the occurrence use as inputs and which did it generate, and are those sets asserted to be complete?", "kind": "composition", "answer_data": [ "Used entity references", "Generated entity references", "Completeness assertion for each set" ] }, { "id": "q-ent-quantity", "text": "In what quantities were entities consumed or produced, and in which units and measurement scale?", "kind": "measurement", "answer_data": [ "Quantity values with units", "Uncertainty or tolerance where stated", "Measuring method reference" ] }, { "id": "q-ent-statechange", "text": "What state or disposition of an affected entity changed as a result of the occurrence?", "kind": "state", "answer_data": [ "Entity reference", "Prior and resulting disposition codes", "Whether the change is reversible" ] }, { "id": "q-ent-linkage", "text": "When inputs and outputs are recorded by separate occurrences, what identifier links them into one transformation?", "kind": "relationship", "answer_data": [ "Transformation linkage identifier", "Occurrences sharing that identifier", "Authority that issued the linkage identifier" ] } ], "data_elements": [ { "id": "de-used-entity", "name": "usedEntity", "description": "Entity consumed or acted upon by the occurrence.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-005" ] }, { "id": "de-generated-entity", "name": "generatedEntity", "description": "Entity produced or brought into existence by the occurrence.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-005" ] }, { "id": "de-affected-quantity", "name": "affectedQuantity", "description": "Quantity of an affected entity with its unit of measure.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "de-transformation-link", "name": "transformationLinkIdentifier", "description": "Identifier linking separately recorded occurrences into a single transformation.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "de-resulting-disposition", "name": "resultingDisposition", "description": "Coded state of an affected entity after the occurrence.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [], "inline_only_rationale": "Affected entities are references into asset, product and document models; quantities and dispositions are inline coded values. The transformation itself is expressed by shared identifiers between occurrence records, not by a filed object." } ] } ] }, { "id": "explanation-and-composition", "name": "Explanation and Composition", "description": "How occurrences aggregate into larger units and how they are asserted to influence or explain one another.", "rationale": "CIDOC P9 consists of, FHIR partOf and schema.org superEvent/subEvent establish part-whole aggregation; PROV wasInformedBy and wasDerivedFrom establish influence between activities and entities; CIDOC P17 was motivated by and EPCIS bizStep/disposition/bizTransactionList establish the purpose or business context of a happening.", "source_refs": [ "SRC-001", "SRC-005", "SRC-006", "SRC-007", "SRC-012" ], "layers": [ { "id": "aggregation-and-recurrence", "name": "Aggregation, Series and Recurrence", "description": "Grouping occurrences into wholes, episodes and series, and separating an individual instance from the recurring pattern it instantiates.", "source_refs": [ "SRC-006", "SRC-007", "SRC-012", "SRC-002" ], "findings": [ { "id": "part-whole-episode-and-series", "name": "Part-whole aggregation, episodes and recurring series", "description": "How an occurrence sits inside a larger occurrence or narrative episode, how a member of a recurring series is distinguished from the series itself, and how the whole's temporal span relates to its members.", "source_refs": [ "SRC-006", "SRC-007", "SRC-012", "SRC-002" ], "questions": [ { "id": "q-agg-parent", "text": "Of which larger occurrence or episode is this occurrence a part, and is the parent's membership asserted to be exhaustive?", "kind": "composition", "answer_data": [ "Parent occurrence reference", "Sibling member references", "Whether membership is exhaustive" ] }, { "id": "q-agg-multi", "text": "May one occurrence belong to more than one episode or aggregate at the same time, and how are competing groupings reconciled?", "kind": "constraint", "answer_data": [ "Multiple-membership rule", "Grouping criterion per aggregate", "Precedence rule between aggregates" ] }, { "id": "q-agg-span", "text": "Is the temporal span of the aggregate asserted independently or derived from its members, and what happens when a member is added or retracted?", "kind": "temporal", "answer_data": [ "Aggregate span values", "Derivation rule or independent assertion", "Recomputation behaviour on membership change" ] }, { "id": "q-agg-series", "text": "Is this occurrence an instance of a recurring series, and how is the series identity kept distinct from the instance identity?", "kind": "identity", "answer_data": [ "Series reference and identifier", "Instance index or occurrence date within the series", "Recurrence rule governing the series" ] } ], "data_elements": [ { "id": "de-part-of", "name": "partOfOccurrence", "description": "Reference to the larger occurrence or episode of which this occurrence is a part.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006", "SRC-007", "SRC-012" ] }, { "id": "de-has-part", "name": "hasPartOccurrence", "description": "References to constituent occurrences of this aggregate.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006", "SRC-012" ] }, { "id": "de-aggregate-span", "name": "aggregateSpan", "description": "Temporal span of the aggregate, with a flag stating whether it is derived from members.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-006" ] }, { "id": "de-series-ref", "name": "seriesReference", "description": "Reference to the recurring series that this occurrence instantiates.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] } ], "artifacts": [], "inline_only_rationale": "Aggregation is expressed entirely as typed links between occurrence records. No fetched source supports a distinct 'episode' object with its own payload, so an episode is modelled as a typed aggregate occurrence rather than as a separate artifact." } ] }, { "id": "causality-and-purpose", "name": "Causality and Purpose", "description": "Asserted influence between occurrences, and the business or motivational context that explains why the occurrence took place.", "source_refs": [ "SRC-001", "SRC-005", "SRC-006", "SRC-007" ], "findings": [ { "id": "causal-and-influence-links", "name": "Asserted causal and influence links", "description": "Links stating that one occurrence caused, contributed to, informed or derived from another, always carrying the asserter, the basis and a confidence, and never inferred from temporal order alone.", "source_refs": [ "SRC-001", "SRC-006", "SRC-005" ], "questions": [ { "id": "q-cause-kind", "text": "What kind of influence is asserted between these occurrences — full causation, contribution, enablement, or mere information flow?", "kind": "relationship", "answer_data": [ "Link kind code", "Source and target occurrence references", "Directionality of the link" ] }, { "id": "q-cause-asserter", "text": "Who asserted this causal link, on what basis, and at what time?", "kind": "provenance", "answer_data": [ "Asserting party reference", "Basis or method statement", "Assertion time in RFC 3339 with offset" ] }, { "id": "q-cause-confidence", "text": "What confidence is attached to the link, on what scale, and what would falsify it?", "kind": "quality", "answer_data": [ "Confidence value and scale definition", "Competing or alternative explanations", "Falsifying evidence identified by the asserter" ] }, { "id": "q-cause-consistency", "text": "What constraints prevent cycles and temporally impossible causation among asserted links?", "kind": "validation", "answer_data": [ "Cycle-prevention rule", "Temporal ordering constraint between cause and effect", "Behaviour when a violating link is submitted" ] } ], "data_elements": [ { "id": "de-influence-link", "name": "influenceLink", "description": "Asserted influence from another occurrence to this one, with its kind.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-006" ] }, { "id": "de-link-kind", "name": "influenceLinkKind", "description": "Kind of influence asserted, from a governed vocabulary.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-link-confidence", "name": "influenceConfidence", "description": "Confidence attached to the asserted link, with the scale it is expressed on.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "de-link-asserted-by", "name": "influenceAssertedBy", "description": "Party that asserted the influence link.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [ { "id": "causal-graph-export", "name": "Causal graph export", "description": "Export of a set of occurrences and the influence links asserted between them, carrying asserter, link kind and confidence, used for review, publication or analysis.", "media_or_form": [ "graph serialisation (RDF, JSON-LD or similar)", "tabular edge list", "rendered diagram" ], "serial": false, "identity_strategy": "Export job identifier issued by the producing system plus a digest over the canonical export bytes; the export is a derived view and never becomes the identity of the underlying links.", "source_refs": [ "SRC-001", "SRC-006" ] } ], "inline_only_rationale": null }, { "id": "purpose-and-business-context", "name": "Purpose, business step and reason", "description": "Why the occurrence took place: the business process step it belongs to, the resulting disposition, the transactions it relates to, and the coded reasons recorded for it.", "source_refs": [ "SRC-005", "SRC-006", "SRC-007" ], "questions": [ { "id": "q-why-step", "text": "Which business process step does this occurrence represent, and from which governed vocabulary is that step drawn?", "kind": "classification", "answer_data": [ "Business step code", "Vocabulary IRI and version", "Process definition reference" ] }, { "id": "q-why-disposition", "text": "What business or physical disposition results from the occurrence, and does it persist until another occurrence changes it?", "kind": "state", "answer_data": [ "Disposition code", "Persistence assumption", "Occurrence that later changes it" ] }, { "id": "q-why-transaction", "text": "Which business transactions, orders or cases does the occurrence relate to, and in what role?", "kind": "relationship", "answer_data": [ "Transaction identifiers and types", "Role of the occurrence in each", "Issuing party for each transaction identifier" ] }, { "id": "q-why-motivation", "text": "What recorded reason or motivating circumstance is asserted for the occurrence, and is it a fact or an interpretation?", "kind": "evidence", "answer_data": [ "Reason code or motivating occurrence reference", "Whether recorded as fact or interpretation", "Party that supplied the reason" ] } ], "data_elements": [ { "id": "de-business-step", "name": "businessStep", "description": "Coded business process step that the occurrence represents.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "de-disposition", "name": "businessDisposition", "description": "Coded business or physical state resulting from the occurrence.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "de-business-transaction", "name": "businessTransactionReference", "description": "Reference to a business transaction, order or case related to the occurrence.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "de-reason", "name": "recordedReason", "description": "Coded reason or motivating occurrence recorded for the happening.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006", "SRC-007" ] } ], "artifacts": [], "inline_only_rationale": "Business context is carried as coded inline values and references to transaction records owned by commerce and case models; the governing vocabularies are published under the owner package rather than per occurrence." } ] } ] }, { "id": "evidence-and-assertion-quality", "name": "Evidence and Assertion Quality", "description": "On what basis the occurrence is asserted, what evidence supports it, how certain it is, and how a wrong record is corrected without destroying history.", "rationale": "FHIR distinguishes recorded and reported and carries relevantHistory; PROV supplies attribution and derivation of the assertion; EPCIS supplies certificationInfo, sensorElementList and a normative ErrorDeclaration with declarationTime, reason and correctiveEventIDs; CIDOC E13 Attribute Assignment treats an assertion as itself an occurrence that can be attributed and dated.", "source_refs": [ "SRC-001", "SRC-005", "SRC-006", "SRC-007", "SRC-008" ], "layers": [ { "id": "assertion-and-evidence", "name": "Assertion Provenance and Evidence", "description": "Who said the occurrence happened, through what chain of reporting, and what evidence is attached and protected.", "source_refs": [ "SRC-001", "SRC-005", "SRC-007", "SRC-008" ], "findings": [ { "id": "source-record-and-reporting-chain", "name": "Source record and reporting chain", "description": "The account from which the occurrence was recorded, whether it is first-hand or reported, the chain of intermediaries between the happening and the record, and the standing of each source.", "source_refs": [ "SRC-007", "SRC-001", "SRC-005", "SRC-006" ], "questions": [ { "id": "q-src-who", "text": "Who supplied the account from which this occurrence was recorded, and when did they supply it?", "kind": "provenance", "answer_data": [ "Reporting party reference", "Report submission time in RFC 3339 with offset", "Channel through which the report arrived" ] }, { "id": "q-src-firsthand", "text": "Is the account first-hand, reported by a proxy, or derived from another record, and is that standing recorded explicitly?", "kind": "authority", "answer_data": [ "First-hand or reported marker", "Proxy party where applicable", "Upstream record reference where derived" ] }, { "id": "q-src-chain", "text": "What intermediaries stand between the happening and this record, and is the chain complete?", "kind": "relationship", "answer_data": [ "Ordered intermediary references", "Completeness assertion for the chain", "Transformations applied at each hop" ] }, { "id": "q-src-standing", "text": "What is known about the reliability or accreditation of each source, and where is that judgement recorded?", "kind": "quality", "answer_data": [ "Reliability or accreditation value", "Scale or certification scheme used", "Party that made the judgement" ] } ], "data_elements": [ { "id": "de-reported-by", "name": "reportedBy", "description": "Party that supplied the account from which the occurrence was recorded.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-001" ] }, { "id": "de-reported-flag", "name": "isReported", "description": "Whether the record is a second-hand report rather than a first-hand capture.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "de-source-kind", "name": "sourceKind", "description": "Kind of account: witness statement, sensor capture, filing, message, derived record.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005", "SRC-008" ] }, { "id": "de-certification-info", "name": "certificationInfo", "description": "Reference to certification or accreditation asserted for the source or capture process.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [ { "id": "source-account-document", "name": "Source account document", "description": "The account on which the occurrence record rests: witness statement, submitted report, regulatory filing, message record or machine log extract.", "media_or_form": [ "text document or statement", "submitted form record", "message or transmission record", "machine log extract" ], "serial": true, "identity_strategy": "Document identifier issued by the reporting or filing system; failing that a governed IRI; failing that a Dimension-minted UUID recorded with its minting authority. Statements and filings that are numbered in a series keep the issuing body's serial as an alternate identifier.", "source_refs": [ "SRC-007", "SRC-001", "SRC-006" ] } ], "inline_only_rationale": null }, { "id": "evidence-artifacts-and-integrity", "name": "Evidence artifacts, integrity and custody", "description": "The media, sensor data and documents evidencing the occurrence, how each is bound to the record, how its integrity is demonstrated, and who has held it.", "source_refs": [ "SRC-005", "SRC-008", "SRC-001" ], "questions": [ { "id": "q-ev-what", "text": "What evidence artifacts are attached to this occurrence, and what does each purport to show?", "kind": "evidence", "answer_data": [ "Artifact references and media types", "Claim each artifact supports", "Capture device or system per artifact" ] }, { "id": "q-ev-integrity", "text": "What digest or signature demonstrates that an evidence artifact has not changed since capture, and who computed it?", "kind": "security", "answer_data": [ "Digest algorithm and value", "Computation time in RFC 3339 with offset", "Computing party reference" ] }, { "id": "q-ev-custody", "text": "Who has held or accessed the evidence since capture, and is the custody record gapless?", "kind": "access", "answer_data": [ "Ordered custody entries with parties and times", "Gap or discontinuity markers", "Register in which custody is maintained" ] }, { "id": "q-ev-binding", "text": "How is an evidence artifact bound to this occurrence rather than to a similar one, and what happens if the binding is disputed?", "kind": "validation", "answer_data": [ "Binding identifier or assertion", "Party that asserted the binding", "Dispute handling procedure" ] } ], "data_elements": [ { "id": "de-evidence-ref", "name": "evidenceReference", "description": "Reference to an artifact evidencing the occurrence.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005", "SRC-008" ] }, { "id": "de-evidence-digest", "name": "evidenceDigest", "description": "Cryptographic digest of an evidence artifact with the algorithm used.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "de-sensor-report", "name": "sensorReport", "description": "Structured sensor observation attached as evidence, with its device and procedure references.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005", "SRC-008" ] } ], "artifacts": [ { "id": "evidence-media-file", "name": "Evidence media file", "description": "Captured media or data file evidencing that the occurrence happened as recorded.", "media_or_form": [ "photograph", "video recording", "audio recording", "scanned or born-digital document", "sensor data file" ], "serial": false, "identity_strategy": "Identifier issued by the capturing device or ingest system, paired with a content digest computed at ingestion and recorded with its computation time; content digest serves as a deduplication key, never as primary identity.", "source_refs": [ "SRC-008", "SRC-005" ] }, { "id": "chain-of-custody-log", "name": "Chain of custody log", "description": "Sequential register of who held, moved, copied or accessed an evidence artifact from capture onward.", "media_or_form": [ "custody register entries", "signed transfer form", "seal or tamper-evidence record" ], "serial": true, "identity_strategy": "Custody register identifier from the holding organisation plus a gapless entry sequence scoped to the evidence artifact; entry numbers are never reused, and a missing number is itself recorded as a discontinuity.", "source_refs": [ "SRC-005", "SRC-001" ] } ], "inline_only_rationale": null } ] }, { "id": "certainty-and-correction", "name": "Certainty, Conflict and Correction", "description": "How confident the record is, how conflicting accounts are held, and how an erroneous record is corrected without mutation.", "source_refs": [ "SRC-005", "SRC-006", "SRC-007", "SRC-010" ], "findings": [ { "id": "corroboration-and-certainty", "name": "Corroboration, certainty and conflicting accounts", "description": "The certainty attached to the occurrence, how independent corroboration raises it, and how mutually inconsistent accounts of the same happening are retained side by side.", "source_refs": [ "SRC-006", "SRC-007", "SRC-010" ], "questions": [ { "id": "q-cert-level", "text": "What certainty is asserted that the occurrence happened as recorded, and on what defined scale?", "kind": "quality", "answer_data": [ "Certainty value", "Scale definition and its endpoints", "Party that assigned the certainty" ] }, { "id": "q-cert-corroboration", "text": "How many genuinely independent sources corroborate the occurrence, and what makes them independent?", "kind": "evidence", "answer_data": [ "Corroborating source references", "Independence criterion applied", "Certainty before and after corroboration" ] }, { "id": "q-cert-conflict", "text": "When two accounts of the same happening disagree, are both retained, and how is the disagreement represented?", "kind": "exception", "answer_data": [ "Conflicting record references", "Conflicting elements identified", "Whether a preferred account is designated and by whom" ] }, { "id": "q-cert-threshold", "text": "What certainty threshold must be met before the occurrence may be published, acted upon or propagated to downstream models?", "kind": "decision", "answer_data": [ "Threshold value per purpose", "Authorising role", "Behaviour for records below threshold" ] } ], "data_elements": [ { "id": "de-certainty", "name": "assertedCertainty", "description": "Certainty that the occurrence happened as recorded, with the scale it is expressed on.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006", "SRC-010" ] }, { "id": "de-corroborating-source", "name": "corroboratingSource", "description": "Reference to an independent source corroborating the occurrence.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-001" ] }, { "id": "de-conflicting-record", "name": "conflictingRecord", "description": "Reference to a record that asserts an incompatible account of the same happening.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005", "SRC-007" ] } ], "artifacts": [], "inline_only_rationale": "Certainty is an inline graded value and conflict is expressed as links between occurrence records; the corroborating material itself is filed as source account documents and evidence media under the preceding layer, so no additional artifact class is warranted." }, { "id": "correction-retraction-and-versioning", "name": "Correction, retraction and supersession", "description": "How a record found to be wrong is repudiated and superseded by corrective records, why in-place mutation is refused, and how consumers detect that a record they hold has been superseded.", "source_refs": [ "SRC-005", "SRC-007", "SRC-001" ], "questions": [ { "id": "q-corr-mechanism", "text": "By what mechanism is an erroneous record repudiated while the erroneous content itself is preserved?", "kind": "lifecycle", "answer_data": [ "Error declaration record reference", "Declaration time in RFC 3339 with offset", "Declaring party reference" ] }, { "id": "q-corr-identity", "text": "Does a corrective record reuse the identifier of the record it corrects, or take a new one, and how is the relation expressed?", "kind": "identity", "answer_data": [ "Identifier reuse rule", "Corrective record references", "Relation type between erroneous and corrective records" ] }, { "id": "q-corr-materiality", "text": "Which changes count as material and require a correction record rather than an additive in-place update?", "kind": "constraint", "answer_data": [ "List of material elements", "List of additive elements", "Adjudicating role when a change is contested" ] }, { "id": "q-corr-detection", "text": "How does a consumer holding a copy detect that the record has been superseded or repudiated?", "kind": "interoperability", "answer_data": [ "Supersession marker on the record", "Notification or feed mechanism", "Latest-version resolution rule" ] } ], "data_elements": [ { "id": "de-error-declaration", "name": "errorDeclaration", "description": "Structured declaration that a previously recorded occurrence is in error, carrying declaration time and reason.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "de-corrective-record", "name": "correctiveRecordReference", "description": "Reference to a record that corrects the repudiated occurrence.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "de-error-reason", "name": "errorReason", "description": "Coded reason for the error declaration.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005", "SRC-007" ] }, { "id": "de-record-version", "name": "recordVersionTag", "description": "Opaque version tag distinguishing successive additive states of the record.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] } ], "artifacts": [ { "id": "correction-notice-record", "name": "Correction notice record", "description": "The filed declaration that a recorded occurrence is in error, naming the erroneous record, the reason, the declaring party and the corrective records that replace it.", "media_or_form": [ "structured error declaration record", "signed notice document", "register entry" ], "serial": true, "identity_strategy": "Identifier of the erroneous occurrence plus a gapless correction sequence scoped to that occurrence; the declaration time is recorded as metadata and never used as the identifier.", "source_refs": [ "SRC-005", "SRC-007" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "governance-and-exchange", "name": "Governance and Exchange", "description": "Who stewards the occurrence record, who may see which parts of it, how long it is kept and how it is disposed of, and how it is aligned and exchanged with other systems.", "rationale": "ODRL supplies a machine-readable model for permissions, prohibitions, duties and conflict resolution over the record; GDPR Articles 5 and 17 supply the accuracy, storage-limitation and erasure obligations together with the exceptions that make an append-only occurrence log lawful; CloudEvents and EPCIS supply the exchange envelope, deduplication rule and correction propagation.", "source_refs": [ "SRC-005", "SRC-009", "SRC-013", "SRC-014", "SRC-015" ], "layers": [ { "id": "stewardship-access-and-retention", "name": "Stewardship, Access and Retention", "description": "Accountability for the record, control over its disclosure, and the rules governing how long it survives and how it ends.", "source_refs": [ "SRC-013", "SRC-014", "SRC-015", "SRC-005", "SRC-007" ], "findings": [ { "id": "ownership-and-stewardship", "name": "Ownership, stewardship and amendment authority", "description": "Which party is accountable for the occurrence record, which registrar maintains it, what rights participants retain over their own participation, and how stewardship transfers.", "source_refs": [ "SRC-013", "SRC-005", "SRC-007" ], "questions": [ { "id": "q-own-accountable", "text": "Which party is accountable for this occurrence record, and is that the primary actor or an observing registrar?", "kind": "ownership", "answer_data": [ "Accountable party reference", "Basis of accountability", "Registrar reference where distinct" ] }, { "id": "q-own-amend", "text": "Who is authorised to declare this record in error or to file a corrective record, and who is not?", "kind": "authority", "answer_data": [ "Authorised roles for repudiation", "Authorised roles for correction", "Escalation path when authority is contested" ] }, { "id": "q-own-participant", "text": "What rights does a recorded participant retain over the portion of the record describing their own participation?", "kind": "ownership", "answer_data": [ "Participant rights enumerated", "Mechanism by which they are exercised", "Limits imposed by other parties' rights" ] }, { "id": "q-own-transfer", "text": "How is stewardship transferred when the accountable party dissolves, merges or hands over the register?", "kind": "process", "answer_data": [ "Transfer instrument reference", "Effective time of transfer", "Continuity guarantees for identifiers" ] } ], "data_elements": [ { "id": "de-record-owner", "name": "accountableParty", "description": "Party accountable for the occurrence record.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-013", "SRC-007" ] }, { "id": "de-registrar", "name": "registrar", "description": "Party maintaining the register in which the occurrence is recorded.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "de-stewardship-transfer", "name": "stewardshipTransfer", "description": "Record of a transfer of accountability, with its effective time.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013" ] } ], "artifacts": [], "inline_only_rationale": "Stewardship is expressed as party references and effective-dated assertions on the record; the instrument that effects a transfer is owned by the contract and organisation models and is referenced, not duplicated here." }, { "id": "access-disclosure-and-projection", "name": "Access, disclosure and published projections", "description": "The default visibility of an occurrence, participant-level control over disclosure, the exceptions that override withholding, and the named projections in which the occurrence may be published.", "source_refs": [ "SRC-013", "SRC-014", "SRC-012" ], "questions": [ { "id": "q-acc-default", "text": "What is the default visibility of this occurrence, and which party decides that default?", "kind": "access", "answer_data": [ "Visibility class", "Deciding role", "Policy reference establishing the default" ] }, { "id": "q-acc-participant", "text": "How does a participant grant or withhold disclosure of their own participation without affecting the rest of the record?", "kind": "privacy", "answer_data": [ "Consent or grant reference", "Scope of the grant in model terms", "Withdrawal mechanism and its effect" ] }, { "id": "q-acc-override", "text": "Under what conditions may participant withholding be overridden, and who authorises the override?", "kind": "exception", "answer_data": [ "Override ground", "Authorising role", "Notification obligation to affected parties" ] }, { "id": "q-acc-projection", "text": "Which named projections of this occurrence may be published, and what does each deliberately omit?", "kind": "interoperability", "answer_data": [ "Projection names", "Elements omitted per projection", "Audience and licence per projection" ] } ], "data_elements": [ { "id": "de-visibility-class", "name": "visibilityClass", "description": "Governed visibility class assigned to the occurrence record.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-013" ] }, { "id": "de-access-policy-ref", "name": "accessPolicyReference", "description": "Reference to the machine-readable policy governing access to the record or a part of it.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "de-consent-ref", "name": "disclosureGrantReference", "description": "Reference to a participant's grant or withholding of disclosure over their own participation.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013", "SRC-014" ] }, { "id": "de-projection-name", "name": "publishedProjection", "description": "Name of a projection in which the occurrence is published, with its omission profile.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] } ], "artifacts": [ { "id": "access-policy-document", "name": "Access policy document", "description": "Machine-readable policy stating which parties may perform which actions on which parts of the occurrence record, with constraints, duties and a declared conflict-resolution strategy.", "media_or_form": [ "ODRL policy document", "policy register entry", "signed agreement record" ], "serial": false, "identity_strategy": "Policy IRI issued by the assigning party; where no IRI exists, a Dimension-minted UUID recorded with its minting authority and effective time. Policy version is a separate element from policy identity.", "source_refs": [ "SRC-013", "SRC-014" ] } ], "inline_only_rationale": null }, { "id": "retention-and-deletion", "name": "Retention, erasure and disposition", "description": "How long the occurrence record is kept and on which clock, how erasure obligations are reconciled with an append-only log, which exceptions permit continued retention, and what evidences that a disposition was executed.", "source_refs": [ "SRC-014", "SRC-015", "SRC-005", "SRC-013" ], "questions": [ { "id": "q-ret-period", "text": "How long is this occurrence retained, from which recorded time does that period run, and on what basis was it set?", "kind": "retention", "answer_data": [ "Retention period", "Governing time element", "Legal, contractual or policy basis" ] }, { "id": "q-ret-erasure", "text": "When an erasure obligation applies, which elements are removed and which survive so that the occurrence's existence and identifier remain intact?", "kind": "privacy", "answer_data": [ "Elements subject to removal", "Elements retained and why", "Resulting record state after redaction" ] }, { "id": "q-ret-exception", "text": "Which exceptions — legal hold, legal claims, public-interest archiving, research or statistics, legal obligation — justify continued retention here?", "kind": "exception", "answer_data": [ "Exception ground invoked", "Authorising role and decision time", "Safeguards applied under the exception" ] }, { "id": "q-ret-evidence", "text": "What evidences that a retention decision was actually executed against both the record and its evidence artifacts?", "kind": "validation", "answer_data": [ "Disposition action performed", "Execution time in RFC 3339 with offset", "Certificate or register entry reference" ] } ], "data_elements": [ { "id": "de-retention-class", "name": "retentionClass", "description": "Governed retention class assigned to the occurrence, from which the period and disposition derive.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014" ] }, { "id": "de-retention-period", "name": "retentionPeriod", "description": "Period for which the record is retained, anchored to a named time element.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014" ] }, { "id": "de-legal-hold", "name": "legalHold", "description": "Whether a hold suspends the normal disposition of the record.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-015" ] }, { "id": "de-disposition-action", "name": "dispositionAction", "description": "Action executed at end of retention: redaction, anonymisation, transfer to archive or destruction.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014", "SRC-015" ] }, { "id": "de-disposition-executed-at", "name": "dispositionExecutedAt", "description": "Instant at which the disposition action was executed.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [ { "id": "disposition-certificate", "name": "Disposition certificate", "description": "Evidence that a retention decision was carried out — redaction, anonymisation, archival transfer or destruction — covering both the occurrence record and its dependent evidence artifacts.", "media_or_form": [ "signed certificate", "disposition register entry", "destruction or transfer report" ], "serial": true, "identity_strategy": "Disposition register identifier issued by the accountable party plus a gapless certificate sequence within that register; the execution timestamp is metadata, never the identifier.", "source_refs": [ "SRC-014", "SRC-015", "SRC-005" ] } ], "inline_only_rationale": null } ] }, { "id": "interoperability-and-delivery", "name": "Interoperability and Delivery", "description": "How the occurrence is aligned to external vocabularies without overclaiming conformance, and how it is transmitted, deduplicated and assessed for completeness at the boundary.", "source_refs": [ "SRC-001", "SRC-005", "SRC-006", "SRC-009", "SRC-012" ], "findings": [ { "id": "external-alignment-and-conflicts", "name": "External alignment, conformance evidence and recorded conflicts", "description": "Which external vocabularies the model is aligned to, at what version, with what evidence, and which conflicts between those vocabularies are recorded rather than silently resolved.", "source_refs": [ "SRC-001", "SRC-005", "SRC-006", "SRC-009", "SRC-012" ], "questions": [ { "id": "q-align-targets", "text": "To which external vocabularies and versions is this model aligned, and is each alignment exact, broader or narrower?", "kind": "interoperability", "answer_data": [ "Target vocabulary IRIs and versions", "Alignment relation per mapped element", "Date the alignment was last verified" ] }, { "id": "q-align-evidence", "text": "What evidence supports any claim of conformance, as opposed to a claim of alignment?", "kind": "validation", "answer_data": [ "Conformance test or certification reference", "Scope of the conformance claim", "Elements explicitly excluded from the claim" ] }, { "id": "q-align-conflict", "text": "Which conflicts between aligned standards are recorded, and how must an implementer choose between them?", "kind": "exception", "answer_data": [ "Conflict statement per pair of standards", "Chosen behaviour and its rationale", "Consumer guidance for the unresolved cases" ] }, { "id": "q-align-owner", "text": "Who maintains each mapping, and how often is it re-verified against the upstream standard?", "kind": "authority", "answer_data": [ "Maintaining party reference", "Re-verification interval", "Notification path for upstream changes" ] } ], "data_elements": [ { "id": "de-alignment-target", "name": "alignmentTarget", "description": "External vocabulary term to which a local element is aligned, with the target version.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-006", "SRC-012" ] }, { "id": "de-alignment-kind", "name": "alignmentRelation", "description": "Whether the alignment is exact, broader, narrower or merely related.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-conformance-evidence", "name": "conformanceEvidence", "description": "Reference to evidence supporting a conformance claim against an external standard.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "de-recorded-conflict", "name": "recordedConflict", "description": "Statement of a known conflict between aligned standards affecting this model.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003", "SRC-005", "SRC-012" ] } ], "artifacts": [ { "id": "alignment-mapping-table", "name": "Alignment and conflict register", "description": "Versioned table mapping local occurrence elements to external vocabulary terms, recording the alignment relation, supporting evidence, verification date and known conflicts.", "media_or_form": [ "mapping table (CSV or JSON)", "SKOS mapping file", "specification annex" ], "serial": false, "identity_strategy": "Mapping-set IRI issued by the owner package plus a version tag; each row is keyed by the pair of local element identifier and target term IRI, so rows remain stable across versions.", "source_refs": [ "SRC-001", "SRC-005", "SRC-006", "SRC-009", "SRC-012" ] } ], "inline_only_rationale": null }, { "id": "delivery-deduplication-and-completeness", "name": "Delivery, deduplication and completeness", "description": "How the occurrence is carried in an exchange envelope, how receivers detect duplicates and replays, how corrections propagate to prior recipients, and how a consumer knows whether it has seen everything.", "source_refs": [ "SRC-009", "SRC-005" ], "questions": [ { "id": "q-del-envelope", "text": "Which envelope carries the occurrence in transit, and which envelope attributes are projections of model elements rather than new facts?", "kind": "interoperability", "answer_data": [ "Envelope specification and version", "Attribute-to-element mapping", "Attributes carrying no model semantics" ] }, { "id": "q-del-duplicate", "text": "On what rule may a receiver treat two deliveries as the same occurrence, and what must it never treat as a duplicate?", "kind": "constraint", "answer_data": [ "Duplicate detection key", "Redelivery marker where present", "Cases explicitly excluded from deduplication" ] }, { "id": "q-del-correction", "text": "How is a correction propagated to recipients that already consumed the erroneous record?", "kind": "process", "answer_data": [ "Propagation mechanism", "Ordering guarantee relative to the original", "Acknowledgement expectation" ] }, { "id": "q-del-completeness", "text": "How does a consumer determine that it has received all occurrences up to a given point, and how are gaps declared?", "kind": "quality", "answer_data": [ "Completeness watermark and its governing time element", "Gap declaration mechanism", "Backfill policy for late arrivals" ] } ], "data_elements": [ { "id": "de-envelope-id", "name": "envelopeIdentifier", "description": "Identifier assigned to the delivered envelope carrying the occurrence.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "de-envelope-source", "name": "envelopeSource", "description": "Producer context URI under which the envelope identifier is unique.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "de-completeness-watermark", "name": "completenessWatermark", "description": "Time up to which the producer asserts that all occurrences have been delivered.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005", "SRC-009" ] } ], "artifacts": [], "inline_only_rationale": "Delivery is an interface concern whose artifacts are transient envelopes owned by the transport layer, not records of the occurrence; the model records only the identity and completeness semantics that survive transport, so filing an envelope as an artifact would confuse projection with substance." } ] } ] } ] }, "functions": [ { "id": "record-occurrence", "name": "Record an occurrence", "description": "Accept an assertion that something happened and create an occurrence record with identity, type, event time, factual status and at least one asserting source.", "inputs": [ "Type code and governing scheme", "Event time specification with explicit offset", "Asserting source reference", "Optional place, participation and evidence references" ], "outputs": [ "Persisted occurrence record with an assigned identifier", "Assigned record status and record time", "Rejection with reason where mandatory elements are missing" ], "preconditions": [ "The type code resolves in a governed, versioned scheme", "The event time carries seconds and an explicit offset or Z", "An asserting source is identified" ], "effects": [ "A new occurrence exists and becomes visible under its default visibility class", "Record time is stamped independently of event time", "Deduplication is evaluated against the declared key" ], "source_refs": [ "SRC-005", "SRC-007", "SRC-009", "SRC-003" ] }, { "id": "assign-occurrence-identity", "name": "Assign occurrence identity", "description": "Apply the identity priority to select or mint the authoritative identifier for an occurrence and register any alternates.", "inputs": [ "Candidate master-system identifier", "Candidate governed IRI", "Minting authority for local identifiers" ], "outputs": [ "Authoritative identifier with its scheme", "Registered alternate identifiers", "Mint record with minting authority and mint instant" ], "preconditions": [ "The identity priority order is configured for the Dimension", "No existing record already claims the candidate identifier" ], "effects": [ "The occurrence becomes resolvable by its authoritative identifier", "Alternate identifiers resolve to the same record" ], "source_refs": [ "SRC-005", "SRC-009", "SRC-001" ] }, { "id": "normalise-temporal-position", "name": "Normalise temporal position", "description": "Convert a submitted time statement to the canonical form while preserving the original offset, time zone name, reference system and any uncertainty qualification.", "inputs": [ "Submitted time value in any accepted form", "Declared temporal reference system where non-default", "Declared offset or time zone name" ], "outputs": [ "Canonical RFC 3339 instant or interval with seconds and explicit offset", "Preserved original offset, time zone name and reference system", "Preserved qualified literal where uncertainty was expressed" ], "preconditions": [ "The reference system is declared or the Gregorian-with-UTC default is explicitly accepted", "Qualified literals are recognised and not coerced" ], "effects": [ "Times become comparable across records without losing local civil context", "Uncertainty is carried forward rather than silently resolved" ], "source_refs": [ "SRC-003", "SRC-004", "SRC-002", "SRC-010" ] }, { "id": "resolve-place-statement", "name": "Resolve place statement", "description": "Bind a place statement to an externally identified place, attach geometry with a declared coordinate reference system, and apply any disclosure generalisation.", "inputs": [ "Place reference or raw location description", "Geometry with coordinates", "Applicable disclosure policy" ], "outputs": [ "Resolved place reference and granularity", "Geometry with coordinate reference system URI and positional accuracy", "Generalised geometry for disclosure where required" ], "preconditions": [ "The place register is reachable or an unresolved marker is permitted", "A coordinate reference system is declared for any geometry" ], "effects": [ "Place identity remains owned by the location model while the occurrence carries only the reference", "Original geometry is retained under restriction when a generalised form is disclosed" ], "source_refs": [ "SRC-011", "SRC-005", "SRC-001" ] }, { "id": "assert-participation", "name": "Assert participation", "description": "Record that a party or object took part in the occurrence, in a governed role, with presence and any delegation chain, without asserting intent.", "inputs": [ "Participant reference", "Role code from the governed vocabulary", "Presence mode and delegating party where applicable" ], "outputs": [ "Participation link with role and presence", "Delegation chain where recorded", "Validation error where the role is not in the governed vocabulary" ], "preconditions": [ "The participant resolves in an external party or asset model", "The role vocabulary version is declared" ], "effects": [ "The occurrence gains a participant without acquiring responsibility or intent semantics", "Participant-level disclosure controls become applicable to the new link" ], "source_refs": [ "SRC-001", "SRC-006", "SRC-007" ] }, { "id": "attach-evidence", "name": "Attach evidence", "description": "Bind an evidence artifact to the occurrence, compute and record its digest, and open or extend its chain of custody.", "inputs": [ "Evidence artifact bytes or reference", "Capture device or system identity", "Custody holder identity" ], "outputs": [ "Evidence reference with media type and digest", "Custody entry with holder and time", "Binding assertion tying the artifact to this occurrence" ], "preconditions": [ "The artifact has an identifier from its capturing or ingest system", "A digest algorithm is configured" ], "effects": [ "Tampering becomes detectable by digest comparison", "Custody becomes auditable from capture onward" ], "source_refs": [ "SRC-005", "SRC-008", "SRC-001" ] }, { "id": "deduplicate-and-reconcile", "name": "Deduplicate and reconcile", "description": "Detect that an incoming record denotes an already recorded occurrence and either discard it as a duplicate or reconcile it as an additional independent account.", "inputs": [ "Incoming occurrence record", "Declared deduplication key", "Producer context identifier" ], "outputs": [ "Duplicate determination with the evidence used", "Merged alternate identifiers and corroborating sources", "New conflicting-account link where the accounts disagree" ], "preconditions": [ "The deduplication key is declared for the occurrence type", "Producer context is available for identifier scoping" ], "effects": [ "Redeliveries do not create spurious occurrences", "Genuinely independent accounts are retained rather than collapsed" ], "source_refs": [ "SRC-009", "SRC-005", "SRC-007" ] }, { "id": "assert-causal-link", "name": "Assert a causal or influence link", "description": "Record an asserted influence between two occurrences with its kind, asserter, basis and confidence, subject to temporal and acyclicity constraints.", "inputs": [ "Source and target occurrence references", "Link kind and confidence", "Asserting party and basis statement" ], "outputs": [ "Persisted influence link", "Constraint violation report where the link is cyclic or temporally impossible", "Updated causal graph view" ], "preconditions": [ "Both occurrences exist and carry event times or explicit ordering", "An asserter is identified; the link is never inferred from order alone" ], "effects": [ "The causal graph gains an attributable, falsifiable edge", "Downstream explanations can cite the asserter rather than the system" ], "source_refs": [ "SRC-001", "SRC-006" ] }, { "id": "compose-aggregate", "name": "Compose an aggregate or episode", "description": "Group related occurrences into a larger occurrence, episode or series instance and derive or assert the aggregate's temporal span.", "inputs": [ "Member occurrence references", "Grouping criterion", "Span derivation rule or asserted span" ], "outputs": [ "Aggregate occurrence with membership links", "Derived or asserted aggregate span", "Recomputation record when membership changes" ], "preconditions": [ "Members exist and the grouping criterion is stated", "Multiple-membership policy is configured" ], "effects": [ "Members become navigable from the whole and vice versa", "Span changes propagate deterministically when membership changes" ], "source_refs": [ "SRC-006", "SRC-007", "SRC-012" ] }, { "id": "declare-error-and-correct", "name": "Declare error and issue correction", "description": "Repudiate an erroneous occurrence record without mutating it and file the corrective records that supersede it.", "inputs": [ "Reference to the erroneous occurrence", "Reason code and declaring party", "Corrective record content" ], "outputs": [ "Correction notice with declaration time and reason", "Corrective occurrence records linked to the erroneous one", "In-error marker on the original, which retains its identifier and content" ], "preconditions": [ "The declaring party is authorised to repudiate", "The change is material rather than additive" ], "effects": [ "History is preserved and the error itself becomes part of the record", "Consumers holding the original can detect supersession" ], "source_refs": [ "SRC-005", "SRC-007", "SRC-001" ] }, { "id": "project-and-disclose", "name": "Project and disclose", "description": "Produce a named projection of an occurrence for a stated audience, applying the access policy, participant grants and any spatial or personal generalisation.", "inputs": [ "Occurrence record", "Applicable access policies and participant grants", "Target projection name and audience" ], "outputs": [ "Projection containing only permitted elements", "Omission profile stating what was withheld and why", "Access audit entry" ], "preconditions": [ "A visibility class and at least one applicable policy exist", "Conflicts between policies resolve under a declared strategy" ], "effects": [ "Non-consenting participation is omitted rather than obscured", "Every disclosure is auditable against its policy basis" ], "source_refs": [ "SRC-013", "SRC-014", "SRC-012" ] }, { "id": "apply-retention-disposition", "name": "Apply retention disposition", "description": "Evaluate the retention class, holds and legal exceptions for an occurrence and execute the resulting redaction, anonymisation, archival transfer or destruction.", "inputs": [ "Retention class and governing time element", "Legal hold and exception status", "Dependent evidence artifact references" ], "outputs": [ "Disposition decision with its basis", "Executed disposition against record and artifacts", "Disposition certificate" ], "preconditions": [ "The governing time element is present on the record", "Exceptions have been evaluated before any destructive action" ], "effects": [ "Personal elements can be removed while the occurrence's existence and identifier survive", "Every disposition leaves auditable evidence of what was done and why" ], "source_refs": [ "SRC-014", "SRC-015", "SRC-005" ] }, { "id": "validate-occurrence-record", "name": "Validate an occurrence record", "description": "Check a record against structural, temporal, referential and policy constraints before acceptance or publication.", "inputs": [ "Candidate occurrence record", "Governing code lists and their versions", "Applicable constraint set" ], "outputs": [ "Validation report listing violations by constraint", "Accept, quarantine or reject determination", "Machine-readable constraint identifiers for each failure" ], "preconditions": [ "Code list versions used by the record are resolvable", "Constraint set is versioned and published" ], "effects": [ "Invalid records are quarantined with a reason rather than silently coerced", "Validation outcomes are themselves recordable as occurrences" ], "source_refs": [ "SRC-005", "SRC-007", "SRC-003", "SRC-011" ] }, { "id": "record-conflicting-account", "name": "Dispute occurrence", "description": "Record a formal contest of the account, holding competing source records without collapsing them into one certainty flag.", "inputs": [ "contesting account", "disputing party reference", "grounds of dispute" ], "outputs": [ "dispute record holding competing source accounts" ], "preconditions": [ "The disputed occurrence record and the contested account are identified" ], "effects": [ "Competing accounts are held side by side", "Accounts are not collapsed into a single certainty flag" ], "source_refs": [ "SRC-016", "SRC-001" ] }, { "id": "map-external-alignment", "name": "Interchange event", "description": "Map an occurrence to or from CIDOC E5, schema.org Event, EPCIS, CloudEvents, PROV Activity or FHIR Event without implying conformance not evidenced by the alignment map.", "inputs": [ "occurrence record or external event payload", "target or source vocabulary", "alignment map" ], "outputs": [ "mapped event representation with conflict flags" ], "preconditions": [ "An alignment map exists for the target vocabulary", "Conformance is claimed only where evidenced" ], "effects": [ "The occurrence is mapped to or from the external event class", "Conflict flags are carried with the mapping", "Envelope attributes remain distinct from the world occurrence" ], "source_refs": [ "SRC-016", "SRC-012", "SRC-001", "SRC-020", "SRC-009", "SRC-007" ] } ], "composition": [ { "target": "WM-ACT-002 Act", "relation": "EXTEND", "purpose": "The Act model specialises this occurrence by adding an intentional or causal actor bearing responsibility; PROV separates responsibility (wasAssociatedWith) from occurrence and CIDOC separates E7 Activity, defined as intentionally carried out, from E5 Event, so intent must not be modelled here.", "required": false, "source_refs": [ "SRC-001", "SRC-006" ] }, { "target": "WM-ACT-018 Encounter", "relation": "EXTEND", "purpose": "The Encounter model specialises this occurrence by adding reciprocal participation and the mutual obligations arising from it, which this model deliberately does not express.", "required": false, "source_refs": [ "SRC-006", "SRC-007" ] }, { "target": "WM-FLW-013 Supply-chain trace", "relation": "COMPOSE", "purpose": "A supply-chain trace composes an ordered set of custody occurrences; the EPCIS event types and the what/when/where/why capture pattern supply the custody vocabulary that the trace assembles.", "required": false, "source_refs": [ "SRC-005" ] }, { "target": "Incident / Emergency model (legacy X3)", "relation": "EXTEND", "purpose": "Incident models specialise this occurrence with severity, escalation and response workflow, which are status and process semantics beyond the generic Event pattern.", "required": false, "source_refs": [ "SRC-007", "SRC-012" ] }, { "target": "Observed Phenomenon model (legacy X2)", "relation": "REFERENCE", "purpose": "Type-level recurring patterns live in the phenomenon model; this model references the series or pattern that an individual occurrence instantiates without defining it.", "required": false, "source_refs": [ "SRC-008", "SRC-012" ] }, { "target": "Situation / Condition model (legacy X4)", "relation": "REFERENCE", "purpose": "Occurrences open, advance and close states that hold over intervals; OWL-Time separates the temporal entity from what holds during it, so state persistence belongs to the situation model.", "required": false, "source_refs": [ "SRC-002", "SRC-007" ] }, { "target": "Address / Location Referencing model (legacy U7)", "relation": "REFERENCE", "purpose": "Place identity, addressing and gazetteer resolution are external; GeoSPARQL's separation of geo:Feature from geo:Geometry makes the reference mandatory whenever a place is asserted.", "required": true, "source_refs": [ "SRC-011", "SRC-005" ] }, { "target": "Person model (legacy H1)", "relation": "REFERENCE", "purpose": "Human participants are referenced, never defined here; the participation link carries only role, presence and delegation.", "required": true, "source_refs": [ "SRC-006", "SRC-007" ] }, { "target": "Organization model (legacy O1)", "relation": "REFERENCE", "purpose": "Organisational participants and the parties on whose behalf individuals act are referenced into the organisation model, which owns their identity and structure.", "required": true, "source_refs": [ "SRC-001", "SRC-007" ] }, { "target": "Measurement and Observation Result model", "relation": "REFERENCE", "purpose": "Where an occurrence is an observation, the observable property, procedure, result value, unit and measurement uncertainty belong to the measurement model; only the act and its phenomenon/result times are retained here.", "required": false, "source_refs": [ "SRC-008" ] }, { "target": "Consent / Access Grant model (legacy S2)", "relation": "MIX-IN", "purpose": "Participant-level disclosure grants are mixed in so a participant can control visibility of their own participation without owning the whole record.", "required": false, "source_refs": [ "SRC-013", "SRC-014" ] }, { "target": "Audit Trail model (legacy S4)", "relation": "REFERENCE", "purpose": "Operations performed on the occurrence store are audited in the audit model; only the provenance of the assertion itself stays here.", "required": false, "source_refs": [ "SRC-001", "SRC-005" ] }, { "target": "W3C Time Ontology in OWL (OWL-Time)", "relation": "COMPOSE", "purpose": "Supplies the temporal value types — TemporalEntity with Instant and Interval, hasBeginning/hasEnd, duration and the explicit temporal reference system — that this model composes rather than redefines.", "required": true, "source_refs": [ "SRC-002" ] }, { "target": "IETF RFC 3339 and RFC 9557", "relation": "ALIGN", "purpose": "Fix the lexical form of every timestamp (seconds plus explicit offset or Z) and the recording of IANA time zone names alongside offsets; alignment is asserted, not conformance certification.", "required": true, "source_refs": [ "SRC-003", "SRC-004" ] }, { "target": "OGC GeoSPARQL 1.1", "relation": "COMPOSE", "purpose": "Supplies geometry serialisations and the requirement to declare a coordinate reference system by URI for any spatial expression of where the occurrence took place.", "required": false, "source_refs": [ "SRC-011" ] }, { "target": "Library of Congress Extended Date/Time Format (EDTF)", "relation": "COMPOSE", "purpose": "Supplies the literal syntax for uncertain, approximate, partly unspecified and open-ended dates, which OWL-Time does not natively provide.", "required": false, "source_refs": [ "SRC-010", "SRC-002" ] }, { "target": "W3C PROV-O", "relation": "ALIGN", "purpose": "Aligns occurrence with prov:Activity and the attribution, association, delegation, usage, generation and communication relations used for participation, entity effects and influence links.", "required": false, "source_refs": [ "SRC-001" ] }, { "target": "CIDOC CRM 7.1.3", "relation": "ALIGN", "purpose": "Aligns occurrence with E5 Event and its time-span, place, participation, part-whole and motivation properties, and supplies the fuzzy temporal ordering pattern.", "required": false, "source_refs": [ "SRC-006" ] }, { "target": "GS1 EPCIS 2.0", "relation": "ALIGN", "purpose": "Aligns the what/when/where/why capture dimensions, the eventTime / eventTimeZoneOffset / recordTime split and the ErrorDeclaration correction pattern; alignment is scoped to supply-chain contexts and not asserted as conformance.", "required": false, "source_refs": [ "SRC-005" ] }, { "target": "HL7 FHIR R5 Event pattern", "relation": "ALIGN", "purpose": "Aligns the record status vocabulary including not-done and entered-in-error, the recorded/reported distinction and the normative Event-versus-Request boundary.", "required": false, "source_refs": [ "SRC-007" ] }, { "target": "W3C SSN/SOSA", "relation": "ALIGN", "purpose": "Aligns observation acts as occurrences and imports the phenomenonTime versus resultTime distinction into the temporality bundle.", "required": false, "source_refs": [ "SRC-008" ] }, { "target": "Schema.org Event", "relation": "ALIGN", "purpose": "Aligns public-chronicle typing, superEvent/subEvent and virtual location; the eventStatus vocabulary is explicitly treated as schedule state and is not mapped onto factual status.", "required": false, "source_refs": [ "SRC-012" ] }, { "target": "CNCF CloudEvents 1.0.2", "relation": "ALIGN", "purpose": "Aligns the exchange envelope as a projection: id, source, type and time map to model identity, typing and event time, and the source+id uniqueness rule grounds duplicate detection.", "required": false, "source_refs": [ "SRC-009" ] }, { "target": "W3C ODRL Information Model 2.2", "relation": "MIX-IN", "purpose": "Supplies the machine-readable expression of permissions, prohibitions, duties, constraints and conflict-resolution strategy over the occurrence record and its parts.", "required": false, "source_refs": [ "SRC-013" ] } ], "serviceLayers": { "dimension": { "owner_package_requirements": [ "Name one accountable steward package for WM-ACT-015 and publish its AGENTS.md bootstrap record before any occurrence is accepted into the Dimension.", "Publish and version the code lists this model depends on — occurrence types, participation roles, record statuses, business steps and dispositions, influence link kinds, visibility classes and retention classes — each with a scheme IRI, effective date and change procedure.", "Publish the alignment and conflict register naming every external vocabulary the package maintains, its pinned version, the alignment relation and the re-verification interval.", "Register retention classes, jurisdictional bases and disclosure exceptions before accepting any occurrence containing personal data, and record which jurisdiction's rules were assumed.", "Declare the identity priority configuration and the minting authority for locally minted identifiers." ], "namespace_guidance": "Use a single Dimension-controlled HTTPS namespace with a stable segment for occurrence terms; local identifiers are minted only under that namespace and never reuse an external authority's prefix. External terms keep their originating namespace and are referenced by IRI — prov:, time:, sosa:, geo:, gs1:, schema: and ODRL terms are imported, never copied or re-minted locally. Code-list member IRIs are opaque and stable: labels and definitions may change, member IRIs may not. Namespace segments must not encode dates, environments or storage technology, because storage and interface are projections.", "registry_links": [ "Vercy world-model registry entry vr.wm-act-015 (WM-ACT-015, nav path NAV.ACT.EVT, domain tag ACT.EVT)", "Occurrence type code list registry maintained by the owner package", "Participation role and record status vocabulary registry", "External alignment and conflict register recording target vocabulary IRIs, versions and verification dates", "Retention class and visibility class registry with jurisdictional bases" ] }, "canon_and_patch": { "canonicalization_rules": [ "Normalise every timestamp to RFC 3339 with seconds and an explicit offset or Z, while retaining the originally submitted offset and, where known, the IANA time zone name as separate elements; never discard local civil context in the course of normalising.", "Never coerce a qualified or reduced-precision date literal into a full timestamp: qualified literals are preserved verbatim because their characters carry uncertainty semantics, and a derived normalised value is stored alongside, flagged as derived.", "Resolve every reference to an absolute IRI or a scheme-qualified master-system identifier before persistence; display names and relative references are never stored as the reference itself.", "Order collections deterministically before hashing or diffing — participants by participant IRI then role code, influence links by target IRI then link kind, evidence by artifact identifier — so that digests are stable across producers.", "Normalise geometry to the declared coordinate reference system and a single canonical serialisation for hashing, while retaining the originally captured serialisation as evidence.", "Apply Unicode NFC normalisation and trim surrounding whitespace on free text; do not case-fold identifiers or code values." ], "patch_rules": [ "Occurrence facts are append-only. A correction is a new record that references the erroneous one; the erroneous record keeps its identifier and its original content and gains an in-error marker.", "Material changes — event time beyond the stated precision, place, participant identity, occurrence type, factual status — require a correction record and never an in-place patch.", "Additive changes are permitted in place: registering an alternate identifier, adding a corroborating source, attaching further evidence, adding an alignment mapping, or refreshing a derived index. Each still records author, time and reason.", "Every patch carries the patching party, the declaration time in RFC 3339 with an explicit offset, and a reason code drawn from a governed list; a patch without a reason is invalid.", "Redaction under a retention or erasure decision is applied as a recorded disposition, not as a patch, and leaves the occurrence's identifier and existence intact.", "Patches are never applied to an artifact's stored bytes; a superseding artifact version is filed and linked instead." ], "compatibility_rules": [ "Adding an optional element, a new code-list member, or a new alignment is backwards compatible. Removing an element, narrowing cardinality, tightening a constraint or retiring a code value is breaking and requires a version increment with a migration note.", "Consumers must ignore unknown extension elements rather than reject the record, so that producers running ahead of consumers remain interoperable.", "A retired code value remains resolvable indefinitely and carries a replacement pointer; historical records are never rewritten to the replacement value.", "Alignments may be added freely, but a claim of conformance to an external standard may only be added with cited evidence recorded in the alignment and conflict register.", "Pinned upstream standard versions are part of the model's compatibility surface: an upstream version bump is a reviewable change, not an automatic upgrade." ] }, "artifact_rules": { "identity_priority": [ "Authoritative master-system identifier issued by the system of record for the occurrence or artifact — for example the capturing registry's event identifier, the producer's context-scoped identifier pair, or the filing system's document number.", "Governed global identifier or IRI from a recognised scheme — a persistent HTTP IRI, a registry-governed event or document identifier, or another identifier whose issuing authority is named and resolvable.", "UUID or ULID minted by the adopting Dimension, recorded together with its minting authority and its mint instant in RFC 3339 with seconds and an explicit offset.", "Never identity: a date, a timestamp, a title, a natural-language summary or a sequence position alone. Content digests may serve as deduplication keys and integrity checks but never as primary identity, because identical content recurs across distinct occurrences." ], "timestamp_rule": "All time values are expressed in RFC 3339 form with seconds present and an explicit UTC offset or Z; where the local civil context matters, the originally observed offset is retained as a separate element and the IANA time zone name is recorded alongside it, since an offset alone wrongly asserts that the zone's rules will never change. Event time — when the occurrence happened — MUST be recorded separately from observation or result time, from record and ingestion time, and from the declaration time of any correction, whenever those can differ; where an observation applies to a period other than the moment it completed, phenomenon time is recorded separately again. An offset of '-00:00' means the UTC instant is known but the local offset is not, and is not interchangeable with 'Z' or '+00:00'.", "serial_naming_rule": "Artifacts that form a numbered series — source account documents, chain-of-custody entries, correction notices and disposition certificates — carry a serial of the form --, where the sequence is unique and gapless within its declared scope (the occurrence, the evidence artifact or the register). Serials are never reused after retraction or destruction; a retired serial resolves to a tombstone recording the retraction. A serial is an ordering and completeness device, not an identifier: it is always accompanied by an identifier assigned under the identity priority, and a missing number in a gapless series is itself recorded as a discontinuity.", "integrity_rule": "Every artifact records a cryptographic digest with its algorithm, the instant the digest was computed in RFC 3339 with seconds and an explicit offset, and the identity of the computing party. Digests are recomputed on ingestion, on custody transfer and on any read that supports an evidential claim. An artifact whose digest no longer matches is quarantined and never silently replaced or repaired; the mismatch is itself recorded as an occurrence with its own evidence, and the affected occurrence records are flagged pending review. Superseding versions of an artifact are filed as new artifacts linked to the original rather than overwriting its bytes." }, "policies": [ "Never mutate a recorded occurrence in place: corrections, retractions and redactions are additive, attributable records, and the erroneous content is preserved so that the error itself remains auditable.", "Never infer causality from temporal order or co-occurrence; an influence link requires a named asserter, a stated basis and a confidence, and must be falsifiable.", "Do not assert conformance to an external standard without cited evidence; publish alignment claims and known conflicts together in the alignment and conflict register.", "Minimise and separate personal-data elements within an occurrence so that disclosure restriction and erasure can be applied without destroying the record that the occurrence existed.", "Keep intent, responsibility and reciprocity out of this model: record that a party participated and in what capacity, and defer the rest to the specialising Act and Encounter models.", "Mark any structural node lacking primary source support as a gap rather than publishing it as canonical, and record the evidence sought and not found.", "Distinguish the world occurrence from the event record; never treat a cancellable scheduled EventStatus as proof that a happening occurred.", "Do not require an agent, subject or performer on the generic occurrence; those constraints belong to Act, Encounter or a FHIR Event profile.", "Least disclosure of participation: public chronicles omit non-consenting parties rather than emitting incomplete participant lists as complete.", "External standards are alignments; store conflict flags and forbid conformance claims without an evidenced mapping.", "Dual timestamps are mandatory when event time and observation or ingestion time differ; CloudEvents producer fallback must be labelled as time_basis, not as event_time.", "Sensitive participation and payload facts must not be copied into inspectable interchange context attributes." ], "crud": { "read": [ "A read returns event time, record time and record status together, so a consumer can judge both the currency and the validity of what it received.", "Reads apply the requester's applicable projection: participation of a party that has not consented to disclosure is omitted entirely rather than obscured or nulled in place.", "Superseded and in-error records remain readable to authorised auditors, always accompanied by their supersession and correction links.", "Reads of restricted findings or artifacts are audited with requester, scope, policy basis and timestamp." ], "create": [ "Create requires a governed type code, an event-time specification with seconds and an explicit offset, at least one asserting source, an accountable party and a record status.", "Create assigns identity strictly under the identity priority and records the minting authority and mint instant whenever a local identifier is minted.", "Create evaluates the declared deduplication key and is rejected as a duplicate unless the caller explicitly declares an independent additional account, in which case the record is retained and linked rather than merged.", "Create stamps record time from the receiving system's clock, independently of any submitted event time." ], "update": [ "Only additive, non-material elements may be updated in place: alternate identifiers, corroborating sources, further evidence, alignment mappings and derived indexes.", "Any material change requires a correction record referencing the original; the original retains its identifier and content and gains an in-error marker.", "Every update records the acting party, the time in RFC 3339 with an explicit offset, and a governed reason code.", "Updates never alter a stored artifact's bytes; a superseding artifact version is filed and linked." ], "delete": [ "Physical deletion is exceptional. The default end state is retention-class expiry followed by redaction or anonymisation of personal elements, preserving the occurrence's identifier and the fact that it existed.", "An erasure request is evaluated against legal hold, legal obligation, public-interest archiving, scientific or historical research, statistical purposes and the establishment or defence of legal claims before any destructive action is taken.", "Every deletion, redaction or anonymisation records the acting party, the time, the legal or policy basis and the exact scope of elements affected, and produces a disposition certificate.", "Dependent evidence artifacts are disposed of under their own custody rules and their disposal is recorded against both the artifact and the occurrence; orphaned artifacts are never left in place after the occurrence is disposed of." ] }, "roles": [ { "name": "Occurrence Registrar", "responsibilities": [ "Capture occurrences from sources, assign identity under the identity priority and stamp record time.", "Run deduplication and decide whether an incoming record is a duplicate or an independent additional account.", "Maintain factual and record status and file correction notices when authorised." ] }, { "name": "Participating Party", "responsibilities": [ "Grant or withhold disclosure of their own participation and withdraw a grant later.", "Dispute a recorded account of an occurrence in which they took part and have the dispute recorded.", "Request rectification of inaccurate participation details or erasure where an obligation applies." ] }, { "name": "Evidence Custodian", "responsibilities": [ "Compute and verify artifact digests at ingestion, on custody transfer and on evidential reads.", "Maintain a gapless chain of custody and record any discontinuity rather than closing the gap silently.", "Quarantine artifacts whose integrity fails and execute artifact-level disposition under retention decisions." ] }, { "name": "Model Steward", "responsibilities": [ "Maintain the bundles, layers, findings and questions, and record which nodes lack primary source support.", "Version and publish the governed code lists and the constraint set, with migration notes for breaking changes.", "Maintain the alignment and conflict register and re-verify pinned upstream standard versions on the declared interval." ] }, { "name": "Access and Retention Authority", "responsibilities": [ "Set default visibility classes and retention classes and adjudicate policy conflicts under the declared strategy.", "Decide disclosure overrides and legal holds, and record the ground, the authorising role and any notification obligation.", "Authorise erasure and disposition decisions after evaluating the applicable exceptions." ] }, { "name": "Exchange Operator", "responsibilities": [ "Project occurrences into exchange envelopes and maintain the attribute-to-element mapping.", "Operate duplicate detection, correction propagation to prior recipients and completeness watermarks.", "Declare delivery gaps and backfill policy rather than allowing silent incompleteness." ] } ], "access": { "default_rule": "Deny by default. An occurrence is visible only to its accountable party, its registrar and its recorded participants — each participant limited to their own participation and to the shared facts of the occurrence — until an explicit, recorded policy grants a wider scope. Broader visibility is granted per scope and never inherited implicitly from a parent aggregate.", "scopes": [ "bundle", "layer", "finding", "artifact" ], "exceptions": [ "Legal obligation, a public-interest task, a legal hold, or the establishment, exercise or defence of legal claims overrides participant-level withholding for the duration and scope of the ground invoked.", "Public-interest archiving, scientific or historical research and statistical purposes permit continued retention and controlled disclosure under recorded safeguards, including minimisation and, where possible, pseudonymisation.", "Imminent-harm disclosure may be authorised by the Access and Retention Authority ahead of the normal process, with mandatory post-hoc notification to affected participants and a recorded justification.", "Aggregate or de-identified projections may be released where a re-identification risk assessment has been performed and recorded, with the assessment method and residual risk stated.", "Freedom of expression and information may bar erasure of an occurrence record; the ground and its scope are recorded on the record itself.", "Lawful compelled disclosure or safety exception, logged with legal basis and auditor identity.", "Steward and registrar read of full participation for record-keeping.", "Participant read of their own involvement even when the public chronicle omits them." ], "audit_requirements": [ "Every read of a restricted finding or artifact records the requester identity, the scope requested, the policy basis relied on and the time in RFC 3339 with seconds and an explicit offset.", "Every access-policy change records the previous policy, the new policy, the authorising role and the effective time, so that a past disclosure can be evaluated against the policy then in force.", "Every erasure, redaction, anonymisation or legal hold is auditable with its legal or policy basis, the exact list of affected elements and the resulting disposition certificate.", "Every override of participant withholding records the ground invoked, the authorising role and whether the required notification was issued.", "Audit records are themselves occurrences and are subject to the same identity, immutability and correction rules as any other record.", "Log create, amend, corroborate, dispute, grant change, redaction, invalidation and interchange mapping with actor, artifact identifier, event time and ingestion time.", "Retain access-exception logs for at least as long as the occurrence record they refer to." ] }, "agents_bootstrap": { "filename": "AGENTS.md", "required_fields": [ "Name", "Type", "Specification URL", "Storage type URL", "Interface URL", "Processes URL", "Owner or Maintainer", "Version and Effective Date", "Identity Priority Statement", "Timestamp and Time Zone Rule", "Alignment and Conflict Register URL", "Retention and Access Policy URL" ], "read_order": [ "AGENTS.md — establishes the model's name, type and the URLs for every other contract before anything else is read.", "Specification URL — the format-neutral scope, boundaries, bundles, layers, findings and questions, and the out-of-scope list that prevents duplicating sibling models.", "Identity Priority Statement and Timestamp and Time Zone Rule — read before writing any record, because identity and time cannot be retrofitted.", "Storage type URL — the projection and canonicalization rules for the chosen store, including document stores such as MongoDB and tool interfaces such as MCP, which are projections and never redefine semantics.", "Interface URL — the read, create, update and delete surface, the query and subscription semantics, and the deduplication and completeness rules.", "Processes URL — the capture, correction, corroboration, disclosure, retention and disposition procedures and the roles authorised for each.", "Alignment and Conflict Register URL — read before asserting any external conformance or emitting any externally typed projection.", "Retention and Access Policy URL — read before any disclosure, export or destructive action." ] } }, "coverage": { "claim": "Base is Claude's seven-bundle occurrence backbone — identity and individuation, typing and factuality, temporality (position, reference frame, uncertainty, record time, ordering), spatiality and setting, participation and effects, explanation and composition, evidence and assertion quality, governance and exchange — grounded in thirteen version-pinned primary specifications from nine organisations, with per-finding inline-only rationales that keep artifacts disciplined. Grok contributes one materially absent node (human-readable designation and aboutness) and two absent operations (formal dispute of an account, external interchange mapping). Coverage is defensible for a generic occurrence record and is explicitly not universal: retention/erasure, clock integrity and the certainty scale remain declared gaps, EU-centric privacy grounding is secondary, and no domain-specific event vocabulary survey (hazard, judicial, astronomical, financial) has been performed.", "confidence": "medium", "checklist": [ { "dimension": "identity", "status": "covered", "notes": "Grounded in the CloudEvents rule that source+id MUST be unique per distinct event, the EPCIS eventID, FHIR identifier and PROV IRIs. The identity priority puts the authoritative master-system identifier first, then a governed IRI, then a Dimension-minted UUID or ULID, and explicitly bars dates, titles and content digests from serving as primary identity." }, { "dimension": "lifecycle", "status": "covered", "notes": "Grounded in the FHIR Event status vocabulary including not-done and entered-in-error, and in the EPCIS ErrorDeclaration with declarationTime, reason and correctiveEventIDs. Append-only correction with preservation of the erroneous record is normatively supported by both; schedule state is kept separate from factual status." }, { "dimension": "relationships", "status": "covered", "notes": "Participation (CIDOC P11/P14, FHIR performer, PROV wasAssociatedWith and actedOnBehalfOf), part-whole (CIDOC P9, FHIR partOf, schema.org superEvent/subEvent), influence (PROV wasInformedBy/wasDerivedFrom) and business transaction links (EPCIS bizTransactionList) are each separately grounded." }, { "dimension": "temporal", "status": "covered", "notes": "The strongest area. OWL-Time supplies Instant/Interval and the explicit hasTRS reference system; RFC 3339 fixes seconds and offset and the '-00:00' unknown-offset convention; RFC 9557 grounds keeping the IANA zone name alongside the offset; EPCIS separates eventTime, eventTimeZoneOffset and recordTime; SOSA separates phenomenonTime from resultTime; EDTF supplies uncertainty syntax that OWL-Time lacks." }, { "dimension": "provenance", "status": "covered", "notes": "PROV-O supplies attribution, association, delegation and derivation; FHIR supplies the recorded/reported distinction and relevantHistory; EPCIS supplies certificationInfo; CIDOC E13 Attribute Assignment supports treating the assertion itself as a datable, attributable act." }, { "dimension": "ownership", "status": "covered", "notes": "Grounded indirectly rather than by a single normative definition of record ownership: ODRL assigner/assignee for who issues and receives rights, FHIR performer and EPCIS registrar semantics for who captured the record, and the registry's own owner-or-maintainer field. No fetched source defines 'record owner' as a normative term, so the accountable-party element is a Vercy construct built on those alignments." }, { "dimension": "validation", "status": "covered", "notes": "Required-element rules, the FHIR constraint that a not-done reason may only accompany a not-done status, the GeoSPARQL requirement to declare a CRS, the RFC 3339 lexical requirements and the CloudEvents deduplication rule all supply testable constraints. Cycle and temporal-impossibility constraints on influence links are a model-level addition, not a cited requirement." }, { "dimension": "access", "status": "covered", "notes": "ODRL 2.2 supplies Policy, Permission, Prohibition, Duty, Constraint, assigner/assignee and the perm/prohibit/invalid conflict strategies, which ground the four access scopes and the exception structure. Participant-level control over one's own participation is a model construct supported by ODRL's party-scoped rules and by GDPR data-subject rights." }, { "dimension": "retention and deletion", "status": "gap", "notes": "The only fetched grounding is an unofficial reproduction of GDPR Articles 5 and 17; the official EUR-Lex text returned no article content at access time, and no records-management standard (ISO 15489) or public-authority retention schedule was retrievable. The reconciliation of erasure with append-only immutability — redaction of personal elements while preserving the occurrence's existence and identifier — is a reasoned construction, not a cited requirement, and must be re-validated against the official text and the applicable jurisdiction before use." }, { "dimension": "interoperability", "status": "covered", "notes": "Alignment targets are pinned by version across PROV-O, CIDOC CRM 7.1.3, EPCIS 2.0, FHIR R5, SOSA, schema.org v30.0, GeoSPARQL 1.1 and CloudEvents 1.0.2, with an explicit register recording alignment relation, evidence and conflicts. Conformance is nowhere asserted." }, { "dimension": "spatial", "status": "covered", "notes": "GeoSPARQL grounds the Feature/Geometry separation and the CRS URI requirement; EPCIS grounds the capture-point versus enclosing-location distinction; PROV atLocation and CIDOC P7 ground the place statement itself; schema.org grounds virtual and hybrid settings." }, { "dimension": "classification", "status": "covered", "notes": "EPCIS bizStep and disposition, FHIR code and category, schema.org's Event subtypes and CIDOC's E5/E7 distinction ground typed occurrences drawn from governed, versioned schemes with recorded external mappings." }, { "dimension": "evidence and certainty", "status": "covered", "notes": "Structurally covered — source records, evidence artifacts, digests, custody and corroboration are grounded in FHIR reported, PROV attribution, EPCIS certificationInfo and sensorElementList, and CIDOC's fuzzy-assertion machinery. The certainty scale itself is a gap: no fetched source defines a normative reliability or certainty scale, so the scale must be declared per Dimension and its endpoints published." }, { "dimension": "security and integrity", "status": "gap", "notes": "Digest, signature and clock-attestation requirements are model policy. Attempts to retrieve NIST log-management guidance failed at access time, and no fetched primary source specifies clock synchronisation evidence, log integrity protection or back-dating defences for event records. The time-source-attestation artifact is therefore the least supported structural node in the model." }, { "dimension": "causality", "status": "covered", "notes": "PROV wasInformedBy and wasDerivedFrom and CIDOC P17 was motivated by ground asserted influence. The requirement for a named asserter, a stated basis and a confidence — and the prohibition on inferring causality from temporal order — is a conservative model policy that the sources permit but do not mandate." }, { "dimension": "measurement", "status": "not-applicable", "notes": "Result values, observable properties, units, scales and measurement uncertainty are deliberately deferred to the measurement and observation model; SOSA is used only for the act-as-occurrence framing and the phenomenonTime/resultTime split." }, { "dimension": "privacy", "status": "covered", "notes": "Data minimisation, purpose limitation, accuracy and storage limitation from GDPR Article 5, the Article 17 erasure grounds and exceptions, ODRL duties, participant-level disclosure grants and spatial generalisation together cover the surface — but the legal grounding is secondary and jurisdiction-specific, as recorded under retention and deletion." } ], "known_omissions": [ "The official EUR-Lex text of Regulation (EU) 2016/679 could not be retrieved at access time across four URL forms; an unofficial reproduction was used instead, and every retention, erasure and privacy statement should be re-validated against the official text.", "ISO 8601-1 and ISO 8601-2, ISO 19108 (temporal schema) and ISO 15489 (records management) are paywalled and were not consulted; EDTF was used as the accessible profile of ISO 8601-2 and OWL-Time as the accessible temporal model.", "NIST log-management and audit-control guidance could not be parsed at access time, leaving clock synchronisation, log integrity and back-dating defences without primary grounding.", "The GS1 EPCIS 2.0 narrative specification is distributed as a PDF that could not be parsed; the machine-readable EPCIS ontology was used instead, so EPCIS conformance clauses and cardinality rules stated in prose were not verified.", "Event-sourcing and CQRS practice, stream ordering guarantees and exactly-once delivery semantics are not grounded; delivery semantics rest only on CloudEvents.", "Domain-specific event vocabularies not surveyed include disaster and hazard event taxonomies, judicial and legal proceeding events, astronomical and geological event scales, and financial transaction event standards; each may reveal required dimensions this model lacks.", "Uncertainty modelling beyond temporal qualification — for example probabilistic participation, geometric uncertainty distributions or evidential belief functions — is not modelled.", "Legal rules on evidence admissibility and on the evidential weight of digital records are out of scope and not surveyed.", "Non-Western and indigenous temporal reference systems are accommodated structurally through the temporal reference system element but no concrete system was modelled or tested.", "Multilingual labelling, transliteration and script handling for summaries, place names and party names are not addressed.", "No normative global event typology; kind schemes are adopted per Dimension.", "Relativistic spacetime beyond CIDOC E92/E93 Presence is not operationalized; marked as rare cultural-heritage alignment rather than a required layer.", "RFC 5545 iCalendar RECURRENCE-ID and exception dates were not fetched as a primary source in this pass; recurring calendars are bounded to schema.org Schedule and a schedule sibling.", "Legal 'event of default' and insurance loss-event statutes are jurisdiction-specific and not modelled as core kinds.", "Natural-language event extraction quality metrics are out of scope.", "Counterfactual and possible-world happenings have no primary-standard representation here.", "Quantum measurement events and sub-second distributed-systems happened-before calculi beyond PROV wasInformedBy are gaps.", "Detailed geospatial CRS and moving-object trajectories belong in location and mobility siblings." ], "conflicts": [ "Timestamp representation conflicts three ways: RFC 3339 embeds the offset in the timestamp, EPCIS keeps eventTime in UTC with eventTimeZoneOffset as a separate element, and RFC 9557 warns that an offset alone wrongly asserts unchanging zone rules and prefers a named IANA zone. The model keeps the normalised instant, the original offset and the zone name as three separate elements rather than choosing one convention.", "Schema.org eventStatus values (EventScheduled, EventCancelled, EventPostponed, EventRescheduled) are scheduling states, and schema.org Event covers planned events, whereas this model, CloudEvents and PROV treat an occurrence as something that happened. The model refuses to map eventStatus onto factual status and keeps schedule state separate.", "The FHIR Event pattern admits preparation and in-progress statuses, mixing not-yet-complete activity into an 'event' resource, which sits uneasily with a strict occurrence semantics; the model resolves this by distinguishing status of the happening from status of the record.", "OWL-Time provides no native mechanism for uncertain or indeterminate temporal positions, while EDTF provides uncertainty only as a literal syntax and CIDOC provides it as ordering relations between boundaries. These three approaches are not interoperable, and the model carries all three rather than forcing a single representation.", "CloudEvents permits a producer to substitute an alternative time when the true occurrence time is unavailable, which conflicts with a strict event-time semantics; the model requires the substitution to be flagged rather than silently accepted.", "GDPR erasure obligations conflict with the append-only immutability that EPCIS ErrorDeclaration and FHIR entered-in-error presuppose; the model reconciles them by redacting personal elements while preserving the occurrence's existence and identifier, which is a construction and not a cited resolution.", "PROV atLocation is deliberately underspecified as to what a location is, whereas GeoSPARQL enforces a strict Feature/Geometry separation with a declared CRS; a PROV-conformant record may therefore carry a location that this model would reject as unresolved.", "CIDOC CRM distinguishes E5 Event from E7 Activity by intentionality, while PROV Activity covers both and is defined by acting upon entities; a single occurrence may map to different classes depending on which alignment a consumer follows, which is recorded rather than resolved.", "EPCIS assigns strong supply-chain semantics to bizStep and disposition that do not generalise to non-commercial occurrences; the alignment is scoped rather than universal.", "schema.org Event is commonly a cancellable scheduled public happening; CIDOC E5 Event is a change-bearing process that occurred; they are not the same class.", "BFO has Process and process boundary, not Event; calling a BFO process an event is a vernacular alignment only.", "FHIR Event.subject is 1..1; generic world events may have no subject.", "CloudEvents time MAY be producer fallback rather than occurrence time; EPCIS eventTime is the occurrence time and recordTime is distinct.", "RFC 3339 describes instants with UTC offset and does not cover intervals, fuzzy bounds or non-Gregorian TRS required by OWL-Time and CIDOC E52.", "PROV Activity implies acting on entities; CIDOC E5 includes agentless happenings such as earthquakes.", "schema.org VirtualLocation versus CIDOC E53 Place (physical extent): virtual attendance is a mode, not a Place.", "EPCIS action DELETE means decommission of object identity in the visibility system, not erasure of the occurrence record." ], "regional_assumptions": [ "Retention, erasure and privacy statements assume an EU or EEA-style data-protection regime derived from Regulation (EU) 2016/679; jurisdictions with sectoral, statutory-records or no comparable regime will need different retention classes and exception grounds.", "The default temporal reference system is the Gregorian calendar with UTC; any other calendar, ordinal scale or geologic timescale must be declared explicitly through the temporal reference system element and will not be understood by consumers that assume the default.", "Availability and currency of the IANA time zone database is assumed; jurisdictions that change offsets at short notice may produce records whose stored offset and named zone disagree for a period.", "GS1 EPCIS conventions reflect commercial supply-chain practice and are not assumed to apply to civic, scientific, personal or cultural-heritage occurrences.", "Access and disclosure defaults assume that participants have legally recognised rights over records describing them; where they do not, the participant-level controls degrade to steward discretion.", "Identifier schemes are assumed to be resolvable over an open network; air-gapped or sovereign deployments will need a local resolution authority named in the AGENTS.md bootstrap record.", "Civil-time instants default to Gregorian calendar with RFC 3339 offset; historical, archaeological and geologic occurrences must declare a TRS.", "Leap seconds are representable (second=60) but not predictable; applications must not invent future leap-second timestamps.", "Privacy and erasure expectations assume a jurisdiction in which participation can be personal data; public-chronicle rules still omit non-consenting parties.", "Daylight-saving and political timezone changes make unqualified local time non-interoperable, as RFC 3339 requires.", "EPCIS CBV business steps are GS1-centric; other industries must supply their own bizStep schemes." ], "adversarial_checks": [ "Counterexample sought and found for the 'Event' label: schema.org Event — the most widely deployed event vocabulary on the web at version 30.0 — models planned events, and its entire eventStatus vocabulary consists of scheduling states. This falsifies any assumption that a general-purpose event type implies something that happened, and the model responds by separating schedule state from factual status rather than adopting schema.org's status list.", "Tested whether the UTC offset can be folded into the timestamp and discarded: RFC 3339 permits it, but EPCIS keeps eventTimeZoneOffset as a separate element and RFC 9557 explicitly warns that copying an offset into an offset-only zone improperly asserts that the offset will never change. The reduction was rejected and three separate elements retained.", "Tested whether participation implies responsibility: PROV separates wasAssociatedWith and its qualified Association from mere involvement, and CIDOC separates E7 Activity, defined as intentionally carried out by an actor, from E5 Event. Both confirm that responsibility and intent are a specialisation, so they were pushed to the Act model and the tempting 'responsibility' finding was removed.", "Tested whether a correction can be an update: EPCIS requires an ErrorDeclaration with declarationTime, reason and correctiveEventIDs, and FHIR provides entered-in-error as a status rather than a delete. Both preserve the erroneous record, so in-place mutation of material facts was rejected outright.", "Tested whether a distinct 'episode' primitive is canonical: CIDOC P9 consists of, FHIR partOf and schema.org superEvent/subEvent all support part-whole aggregation, but no fetched source supports a separate narrative episode class with its own payload. The attractive 'episode object' from the previous-version material was rejected and modelled as a typed aggregate occurrence instead.", "Tested whether temporal uncertainty could be expressed in the temporal ontology alone: OWL-Time has no native construct for indeterminate positions, confirmed directly from the specification's own acknowledgement that much temporal information is not well defined. Rather than inventing an unsupported ontology construct, the EDTF literal syntax was composed in and flagged as a representational conflict.", "Tested whether a source reliability scale could be presented as canonical: no fetched primary source defines a reliability or certainty scale for event assertions. The structure was retained but the scale itself was recorded as a gap requiring per-Dimension declaration, rather than published as a governed value set.", "Tested whether the time-source attestation artifact survives scrutiny: attempts to ground clock synchronisation and log integrity in NIST guidance failed at access time, so the artifact is retained but explicitly marked as the model's least supported node under the security and integrity checklist row and in known omissions.", "Would a cancelled concert be stored as an occurrence? No: it remains a scheduled Event/plan until a world happening occurs; EventCancelled is schedule-plane status only.", "Would an earthquake be rejected for lack of performer or subject? No: agentless E5 Events are in scope.", "Would two CloudEvents with the same source+id be treated as two happenings? No: they are duplicate records of one occurrence, possibly a retransmission.", "Would overlapping intervals be ingested as causation? No: Allen overlap and co-location are temporal/spatial relations, not P15/PROV influence.", "Would a participant-erasure request delete the Battle of Stalingrad record because one soldier is named? No: redaction of participation, not destruction of the public occurrence, unless the record is only that person's private timeline.", "Would storing JSON in MongoDB or exposing MCP tools change the semantics? No: those are projections; AGENTS.md still names specification, storage type, interface and processes URLs." ] }, "researchAdjudication": { "boundaryDecision": { "entry_kind": "event", "status": "accepted", "rationale": "Both providers independently arrive at entry_kind 'event' and at the same cut: a format-neutral record of an individuated happening that specialised models extend rather than re-derive. Intent, motive and responsibility go to WM-ACT-002 Act (CIDOC E5 vs E7; PROV Association); reciprocity to WM-ACT-018 Encounter; persons, organisations, assets, places and measurement results are referenced, not mastered; plans, requests and scheduled-but-unoccurred items are not occurrences; CloudEvents is a projection envelope, not added semantics. Claude's nine sourced neighbour distinctions are adopted as the boundary because each carries explicit source_refs. Grok's BFO occurrent-vs-event and FHIR-subject-1..1 observations agree with that boundary and are routed to a boundary-note review rather than reopening it." }, "decisions": [ { "concept": "Base provider selection", "disposition": "Claude as base", "rationale": "Not chosen on size. Claude gives nine neighbour distinctions each with source_refs, an explicit out_of_scope list that names the specialising model for every excluded concept, and an inline_only_rationale on every artifact-free finding — so the boundary and the artifact discipline are both auditable. Grok's boundary is compatible but thinner in sourced neighbour cuts and files seventeen artifacts with no equivalent justification test." }, { "concept": "Entry kind", "disposition": "event, accepted without reclassification", "rationale": "Both providers independently return 'event' and both scope it as the generic occurrence backbone rather than an agentive act, so there is no divergence to adjudicate and no reason to split or defer the node." }, { "concept": "Designation, summary and aboutness", "disposition": "Accept from Grok into identity-and-individuation", "rationale": "Materially absent from the base and conceded in the base's own known_omissions; evidence-backed in schema.org Event, CIDOC P3/P129 and FHIR Event.note; fits an existing layer without displacing the identifier or individuation findings." }, { "concept": "Grok f-occurrence-kind (kind and classification)", "disposition": "Reject as duplicate", "rationale": "The base occurrence-classification finding already covers type codes, scheme governance, multiplicity and external mapping, and purpose-and-business-context covers EPCIS bizStep and disposition. The only residue is the EPCIS structural event-type axis, which is a domain-specific detail the base already scopes as GS1-centric." }, { "concept": "Grok f-temporal-extent (temporal extent)", "disposition": "Reject as duplicate", "rationale": "Instant/interval shape, fuzzy inner and outer bounds, duration and Allen-style qualitative relations are already split across the base's event-time-extent, temporal-uncertainty-precision and ordering-and-clock-integrity findings. Re-adding it would double-count the strongest-grounded area of the base." }, { "concept": "Grok f-place-and-attendance (place and attendance mode)", "disposition": "Reject as duplicate", "rationale": "Place reference and granularity, the read-point versus business-location split, unknown or withheld place, and offline/online/mixed attendance are covered by the base's place-reference-and-granularity and virtual-and-hybrid-setting findings, which additionally carry GeoSPARQL CRS grounding that Grok lacks." }, { "concept": "Grok f-participation-roles (role qualification)", "disposition": "Reject as duplicate", "rationale": "The base role-capacity-and-delegation finding already carries governed role vocabulary, PROV actedOnBehalfOf delegation chains and presence mode, plus an explicit question fixing where intent assertions stop and the Act model begins." }, { "concept": "Grok f-record-status (status planes, amendment, invalidation)", "disposition": "Reject as duplicate", "rationale": "The three-plane separation is already present: the base occurrence-factuality-status finding asks whether a status describes the happening or the record and keeps schedule state separate, and correction-retraction-and-versioning covers amendment, supersession and entered-in-error with EPCIS ErrorDeclaration grounding." }, { "concept": "Grok f-episode-partonomy (episodes, sub-events, fulfilment)", "disposition": "Reject as duplicate; defer the fulfilment link", "rationale": "Roughly three-quarters overlaps the base part-whole-episode-and-series finding, and both providers agree an episode is a typed aggregate, not a new primitive. The genuinely distinct element — an explicit FHIR basedOn fulfilment relation to the Request/Plan model — is only partly reached by the base q-why-transaction and is sent to deferred research rather than smuggled in inside a duplicate finding." }, { "concept": "Grok f-retention-deletion (retention, redaction, erasure)", "disposition": "Reject; base retains its own weaker-but-broader node", "rationale": "Grok's retention grounding rests on PROV, CloudEvents and FHIR only and cites no data-protection instrument, so it is less supported than the base retention-and-deletion finding, which at least reaches GDPR Articles 5 and 17. Legal hold and tombstone semantics are already inside the base questions." }, { "concept": "Grok fn-corroborate-occurrence", "disposition": "Reject as covered", "rationale": "The base deduplicate-and-reconcile function explicitly branches to 'reconcile it as an additional independent account', which is the corroboration path. Adding a second function for the same branch would create duplicate operations over one decision point." }, { "concept": "Grok fn-amend-occurrence, fn-invalidate-record, fn-redact-participation, fn-project-timeline", "disposition": "Reject as duplicates", "rationale": "Each is already performed by a base function: declare-error-and-correct covers revision and entered-in-error invalidation, apply-retention-disposition covers redaction and anonymisation under erasure, and project-and-disclose covers timeline and chronicle projections with participant grants applied." }, { "concept": "Grok fn-dispute-occurrence and fn-interchange-event", "disposition": "Accept both", "rationale": "Both name operations the base structurally presupposes but never defines — holding contradicting accounts side by side, and exercising the alignment register. Neither collides with an existing base function's stated scope." }, { "concept": "BFO occurrent hierarchy boundary (Grok SRC-011)", "disposition": "Defer to boundary-note review", "rationale": "Grok's point that BFO has Process and process boundary but no Event class, so 'event' is a vernacular alignment, is a genuine and useful neighbour distinction. It is a boundary note, not a finding, and this plan cannot add boundary notes, so it is routed to deferred research rather than forced into a layer." }, { "concept": "CloudEvents cleartext context-attribute privacy warning", "disposition": "Reject as a finding; route to question-level refinement", "rationale": "A single evidence-backed constraint from CloudEvents 1.0.2 does not justify a whole finding, and the base already owns the surface through access-disclosure-and-projection and delivery-deduplication-and-completeness. Preferring a thin question over new structure follows the no-weakly-supported-structure rule." }, { "concept": "CIDOC P11 had participant versus P12 occurred in the presence of", "disposition": "Defer", "rationale": "Presence-without-participation is a real CIDOC distinction that the base only reaches from the opposite direction (a participant recorded as not present). Resolving it belongs in a question-level refinement of participant-reference, not in a new finding that would overlap it." }, { "concept": "Grok art-agents-md (AGENTS.md bootstrap artifact)", "disposition": "Reject", "rationale": "This is a Vercy packaging convention, not a research finding evidenced by any fetched primary source, and it does not describe the occurrence. It belongs to the publication pipeline rather than to the model's structure." }, { "concept": "Registry identifier form and CIDOC version pin", "disposition": "Adopt base forms: vr.wm-act-015 and CIDOC CRM 7.1.3", "rationale": "The vr.wm-act-015 versus vr.wm.act.015 divergence is a formatting matter for the synthesizer, not a research contradiction. On CIDOC, Claude pins 7.1.3 (February 2024) while Grok cites 7.0 alongside 7.1.3 and ISO 21127:2023; the newer explicit pin is adopted and the ISO equivalence is left as a source-verification item." }, { "concept": "Published confidence level", "disposition": "Adopt medium, not Grok's high", "rationale": "Grok's 'high' is asserted against a checklist that marks nothing as a gap, whereas the base marks retention/deletion and security/integrity as gaps and the certainty scale as undefined. The calibrated lower confidence is the honest one to carry forward." } ], "publicationHolds": [ "Source verification: every accepted URL must be re-fetched live and every version pin confirmed before publication — CIDOC CRM 7.1.3, schema.org v30.0, EPCIS 2.0 ontology, FHIR R5 5.0.0, CloudEvents 1.0.2, GeoSPARQL 1.1, RFC 3339, RFC 9557, EDTF, ODRL 2.2 and SSN/SOSA.", "OWL-Time version divergence must be pinned: the base cites the 19 October 2017 Recommendation plus the 15 November 2022 Candidate Recommendation Draft while Grok cites only the 2022 draft; one status must be chosen and stated before any temporal claim is published.", "Legal grounding hold: SRC-014 and SRC-015 are unofficial gdpr-info.eu reproductions at authority tier 4. Every retention, erasure and privacy statement must be re-validated against the official EUR-Lex text of Regulation (EU) 2016/679 before publication.", "Domain-profile validation hold: the backbone must be exercised against at least three unlike profiles — cultural heritage, supply-chain visibility, and clinical or civic recording — before any claim that time, place, participation and causality generalise across them.", "The time-source-attestation artifact and all clock-integrity, log-integrity and back-dating claims have no primary grounding (NIST retrieval failed in the base pass and Grok fetched nothing in this area). Publish only as declared model policy, or hold the node.", "No fetched source defines a normative reliability or certainty scale, so the corroboration scale must be published as a per-Dimension declaration with stated endpoints, never as a governed value set.", "The reconciliation of GDPR erasure with append-only correction — redacting personal elements while preserving the occurrence's existence and identifier — is a construction, not a cited resolution, and must be labelled as such wherever it appears." ], "deferredResearch": [ "Acquire the paywalled or unparsed normative texts and re-validate against them: ISO 8601-1 and 8601-2, ISO 19108 temporal schema, ISO 15489 records management, ISO 21127:2023, ISO/IEC 19987, ISO/IEC 21838-2, and the GS1 EPCIS 2.0 narrative PDF whose conformance clauses and cardinality rules were never verified.", "Fetch RFC 5545 iCalendar (RECURRENCE-ID, EXDATE, exception dates) as a primary source before finalising series, recurrence-template and instance-identity semantics; neither provider consulted it and both currently bound recurrence to schema.org Schedule alone.", "Decide whether an explicit fulfilment relation (FHIR Event.basedOn) from an occurrence to the Request/Plan model is required as a first-class link, or whether the existing business-transaction question adequately carries it.", "Review Grok's BFO occurrent-hierarchy distinction (Process and process boundary, no Event class) for inclusion as a boundary note, since this plan can add findings and functions but not boundary notes.", "Resolve whether CIDOC P12 occurred in the presence of, as distinct from P11 had participant, warrants its own question set under participant-reference or remains a refinement of the existing presence question.", "Decide the placement of the CloudEvents 1.0.2 guidance that context attributes are inspectable in the clear and must not carry sensitive payload — most likely a question under access-disclosure-and-projection.", "Survey the domain-specific event vocabularies neither provider examined — hazard and disaster taxonomies, judicial and legal proceeding events, astronomical and geological scales, financial transaction event standards, and insurance loss-event definitions — each of which may reveal a required dimension the backbone lacks.", "Ground delivery semantics beyond CloudEvents: event-sourcing and CQRS practice, stream ordering guarantees, exactly-once versus at-least-once delivery, and completeness watermarks currently rest on a single tier-2 source." ] }, "statistics": { "sources": 21, "bundles": 7, "layers": 14, "findings": 28, "questions": 105, "artifacts": 12, "functions": 15 } }