# Vercy AI instruction - YAML 1.2 (JSON-compatible) { "vercy": "1.0-draft", "publication": { "status": "published", "adjudicationStatus": "reviewable-draft", "publishableCanonical": false, "generatedAt": "2026-08-22T22:18:03Z", "synthesisSha256": "4dfd1a69201eacd20d3cb97f3401ebc7140c5554aa96f53b84c8e5a53886b985", "providerMode": "dual-provider", "providers": [ "Claude", "Grok" ], "waivedProviders": [] }, "metaModel": { "id": "WM-XCT-021", "registryId": "vr.wm-xct-021", "name": "Lifecycle / Status", "version": "0.3.0-research.1", "previousVersions": [], "entryKind": "mixin", "family": "World Models", "category": "Cross-cutting context", "industry": [ "Cross-industry" ], "domain": [ "XCT.LIF" ], "tags": [ "lifecycle", "status", "xct.lif" ], "status": "published" }, "canonicalUrl": "https://ver.cy/models/wm-xct-021-lifecycle-status/", "sourceUrl": "https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-xct-021", "model": { "registry_id": "vr.wm-xct-021", "model_id": "WM-XCT-021", "name": "Lifecycle / Status", "entry_kind": "mixin", "purpose": "Provide one reusable, format-neutral context package that lets any host world-model entry declare the governed state machine it obeys, its current state on each status axis, the effective validity of that state in real-world time and in system time, and the authority, evidence, succession, invalidation and disposition rules that govern movement between states.", "scope_statement": "WM-XCT-021 is a cross-cutting mixin, not a standalone entity. It supplies (a) the definition of a lifecycle state machine as a governed, versioned, identified object; (b) the assertion of current state and the append-only history of transitions; (c) bitemporal effective validity, separating real-world (valid/application) time from record (transaction/ingestion) time; (d) succession, deprecation, revocation, suspension and disposition semantics including their reversibility and retroactive effect; and (e) the operational and interoperability surface needed to evaluate, apply, query, publish and map status. It deliberately carries no domain meaning: the semantics of any particular state ('active order', 'approved permit') belong to the host model that composes this mixin. It is independent of storage format and access interface; JSON, YAML, Markdown, HTML, Git, MCP and MongoDB are projections of these semantics, never their source.", "in_scope": [ "Definition of the state space: governed state code list, state identity, initial state, terminal states, reversible states", "Multiple concurrent status axes (governance/publication, operational, legal validity, quality) and their precedence rules", "Transition topology: permitted source/target pairs, triggers, guard conditions, mandated effects, deterministic conflict resolution", "Concurrent regions, composite states, and history (resumption) semantics where the host lifecycle needs them", "Identity, versioning, ownership and change procedure of the lifecycle definition itself, including self-application of the mixin", "Current-state assertion and append-only transition history, with actor, authorizer, delegation and reason code", "Effective validity intervals (valid-from / valid-until), boundary inclusivity, precision, open-endedness and no-expiry conventions", "Bitemporality: event time, observation time, record/ingestion time; retroactive correction, amendment and as-of/as-at reconstruction", "Supersession, replacement, deprecation and sunset links, and traversal to the current item", "Revocation versus suspension, invalidity dating, retroactive effect, and published status distribution to relying parties", "Lifecycle end as a retention/disposition trigger, legal hold, logical deletion, tombstones and erasure reconciliation", "Operational contract for evaluating and applying transitions (idempotency, concurrency, atomicity, rejection recording)", "Mapping of local states to external status vocabularies, mapping strength, lossiness and recorded conflicts", "Visibility and access classification of pre-publication states and of transition justifications" ], "out_of_scope": [ "Domain semantics of individual states (what 'dispensed', 'settled' or 'commissioned' means) — supplied by the host model", "Version identity, content diffing, branching and merging of the subject's content — belongs to a Versioning & Change Control model", "General provenance of content creation and derivation beyond lifecycle transitions — belongs to a Provenance & Lineage model", "Retention schedules, appraisal methodology and the legal instruments that authorise disposition — belongs to a Records Retention & Disposition model", "Authorization policy language, role engineering and enforcement — belongs to an Authorization & Access Control model", "Human workflow orchestration: task assignment, queues, escalation, service levels — belongs to a Process / Workflow model", "Calendars, business-day arithmetic, non-Gregorian temporal reference systems — belongs to a Temporal Reference & Calendar model", "Assignment and minting of subject identifiers — belongs to an Identity & Identifier model", "Governance of the state code list as a code list (publication, translation, code-list versioning) — belongs to a Classification / Code List Registry model", "Cryptographic formats, proofs and key management for credentials whose revocation patterns are reused here", "Physical storage, indexing, change-data-capture and database audit mechanisms — projection concerns", "Formal verification of state machines (deadlock, liveness, reachability proofs)" ], "boundary_notes": [ { "neighbor": "Provenance & Lineage model", "distinction": "This mixin records why, by whom and under what authority a state changed, and the invalidation instant. General entity generation, derivation and attribution graphs belong to the provenance model; PROV-O generation/invalidation and FHIR Provenance.occurred vs Provenance.recorded are the shared seam, not a duplication.", "source_refs": [ "SRC-004", "SRC-014" ] }, { "neighbor": "Versioning & Change Control model", "distinction": "Supersession and deprecation are represented here as lifecycle states and links because they change fitness for use. The identity of a version, its content delta and its release engineering belong to the versioning model; DCAT 3 previousVersion/hasCurrentVersion and DCMI replaces/isReplacedBy are the alignment points.", "source_refs": [ "SRC-009", "SRC-015", "SRC-011" ] }, { "neighbor": "Records Retention & Disposition model", "distinction": "Only the lifecycle-end trigger, the legal-hold flag and the resulting disposition state are modelled here. Appraisal, retention schedules and the authorising instrument are external; ISO 15489-1 requires disposition authorities to be authorised, dated, implemented and reviewed, which this mixin references rather than restates.", "source_refs": [ "SRC-017", "SRC-021" ] }, { "neighbor": "Authorization & Access Control model", "distinction": "This mixin records the authority basis actually exercised for a transition and the visibility class of a state; it does not define policy syntax, role hierarchies or an enforcement point.", "source_refs": [ "SRC-017", "SRC-020" ] }, { "neighbor": "Process / Workflow Orchestration model", "distinction": "The lifecycle here is a declarative state machine over one subject, in the sense of SCXML/UML behavioural state machines. Multi-actor task routing, work queues and durations belong to the workflow model.", "source_refs": [ "SRC-007", "SRC-019" ] }, { "neighbor": "Temporal Reference & Calendar model", "distinction": "Validity intervals, boundary conventions and RFC 3339/9557 timestamp rules are in scope. Temporal reference systems, non-Gregorian calendars and duration arithmetic belong to the temporal model; OWL-Time supplies the interval-relation vocabulary used across the seam.", "source_refs": [ "SRC-008", "SRC-001", "SRC-002" ] }, { "neighbor": "Classification / Code List Registry model", "distinction": "The state code list is governed as a code list elsewhere (registration authority, registration status of each code). This mixin binds a code list to a state space and adds transition structure that a plain code list does not carry.", "source_refs": [ "SRC-016", "SRC-018" ] }, { "neighbor": "Credential / Certificate model", "distinction": "Revocation, suspension and status-list distribution patterns are generalised here from PKI and Verifiable Credentials. Credential formats, signature suites and key lifecycle stay in the credential model.", "source_refs": [ "SRC-003", "SRC-005", "SRC-006" ] }, { "neighbor": "Event Record model", "distinction": "A lifecycle transition is a constrained event with a mandatory prior-state/new-state pair. General domain events, their payloads and their correlation belong to the event model.", "source_refs": [ "SRC-004", "SRC-014" ] } ] }, "sources": [ { "id": "SRC-001", "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": "July 2002", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T10:00:00Z", "relevance": "Normative timestamp syntax: full-date plus full-time, mandatory numeric offset or Z, leap-second value 60, the -00:00 unknown-local-offset convention, and string sortability of like-formatted timestamps." }, { "id": "SRC-002", "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": "April 2024", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T10:00:00Z", "relevance": "Extends RFC 3339 with IXDTF suffix tags, IANA time-zone annotation, the critical '!' flag, and redefines Z as 'UTC known, local offset unknown'. Governs future-dated validity boundaries that must survive time-zone rule changes." }, { "id": "SRC-003", "title": "RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc5280", "version_or_date": "May 2008", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T10:00:00Z", "relevance": "Validity notBefore/notAfter, the 99991231235959Z no-expiry convention, the CRLReason enumeration (including superseded, certificateHold, removeFromCRL) and the invalidityDate extension distinguishing known-invalid instant from decision instant." }, { "id": "SRC-004", "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; namespace http://www.w3.org/ns/prov#", "source_type": "ontology", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T10:00:00Z", "relevance": "Entity/Activity/Agent, generatedAtTime, wasInvalidatedBy and invalidatedAtTime, wasRevisionOf and specializationOf — the alignment target for transition provenance and invalidation dating." }, { "id": "SRC-005", "title": "Verifiable Credentials Data Model v2.0", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/vc-data-model-2.0/", "version_or_date": "W3C Recommendation, 15 May 2025", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T10:00:00Z", "relevance": "Separates validFrom/validUntil (time-bound, automatic) from credentialStatus (event-driven, issuer-controlled). Direct evidence that validity period and status are two distinct axes, not one." }, { "id": "SRC-006", "title": "Bitstring Status List v1.0", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/vc-bitstring-status-list/", "version_or_date": "W3C Recommendation, 15 May 2025", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T10:00:00Z", "relevance": "Status purposes revocation (not reversible), suspension (reversible), message and refresh; statusSize/statusMessage for multi-valued status; herd-privacy considerations for published status distribution." }, { "id": "SRC-007", "title": "State Chart XML (SCXML): State Machine Notation for Control Abstraction", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/scxml/", "version_or_date": "W3C Recommendation, 1 September 2015", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T10:00:00Z", "relevance": "Normative, format-neutral state-machine semantics: atomic/compound/parallel states, transition event/cond/target/type, initial and final states, shallow and deep history, onentry/onexit, and deterministic conflict resolution by document order." }, { "id": "SRC-008", "title": "Time Ontology in OWL", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/owl-time/", "version_or_date": "W3C Candidate Recommendation Draft, 15 November 2022 (this version: /TR/2022/CRD-owl-time-20221115/); namespace http://www.w3.org/2006/time#", "source_type": "ontology", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-23T10:00:00Z", "relevance": "TemporalEntity/Instant/Interval/ProperInterval, hasBeginning/hasEnd/inXSDDateTimeStamp, and Allen interval relations (meets, overlaps, during, starts, finishes, equals) used to constrain succession and overlap of validity intervals." }, { "id": "SRC-009", "title": "Data Catalog Vocabulary (DCAT) - Version 3", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/vocab-dcat-3/", "version_or_date": "W3C Recommendation, 22 August 2024", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T10:00:00Z", "relevance": "Version-lineage properties dcat:previousVersion, dcat:hasVersion, dcat:hasCurrentVersion, use of adms:status and dcterms:isReplacedBy for resource lifecycle — alignment for supersession traversal." }, { "id": "SRC-010", "title": "OWL 2 Web Ontology Language Structural Specification and Functional-Style Syntax (Second Edition)", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/owl2-syntax/", "version_or_date": "W3C Recommendation, 11 December 2012", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T10:00:00Z", "relevance": "owl:deprecated as a non-logical annotation, plus owl:versionInfo, owl:priorVersion, owl:backwardCompatibleWith and owl:incompatibleWith — evidence that deprecation is metadata about fitness for use, not a change of formal semantics." }, { "id": "SRC-011", "title": "Asset Description Metadata Schema (ADMS)", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/vocab-adms/", "version_or_date": "W3C Working Group Note, 1 August 2013 (retired August 2023); namespace http://www.w3.org/ns/adms#", "source_type": "schema", "primary_source": true, "authority_tier": 3, "accessed_at": "2026-08-23T10:00:00Z", "relevance": "adms:status (range skos:Concept, 'status in the context of a particular workflow process'), adms:versionNotes, adms:prev/next/last. Included as an alignment and as a recorded conflict: retired, yet still referenced by DCAT 3 and DCAT-AP." }, { "id": "SRC-012", "title": "FHIR ValueSet: PublicationStatus", "organization": "Health Level Seven International (HL7)", "url": "https://hl7.org/fhir/valueset-publication-status.html", "version_or_date": "FHIR R5, ValueSet version 5.0.0, published 2023-03-26; canonical http://hl7.org/fhir/ValueSet/publication-status; Normative since v4.0.0", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-23T10:00:00Z", "relevance": "A minimal normative governance-status axis: draft | active | retired | unknown, including an explicit 'unknown' code for indeterminate status distinct from a missing assertion." }, { "id": "SRC-013", "title": "FHIR Data Types (Period, instant, dateTime)", "organization": "Health Level Seven International (HL7)", "url": "https://hl7.org/fhir/datatypes.html", "version_or_date": "FHIR R5 (v5.0.0), 2023", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-23T10:00:00Z", "relevance": "Period boundaries are inclusive; a missing end means no end was known or planned at creation time; instant requires at least second precision with a time-zone offset; dateTime permits partial precision but requires an offset once time is present." }, { "id": "SRC-014", "title": "FHIR Resource: Provenance", "organization": "Health Level Seven International (HL7)", "url": "https://hl7.org/fhir/provenance.html", "version_or_date": "FHIR R5 (v5.0.0), 2023", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-23T10:00:00Z", "relevance": "Provenance.occurred[x] (when the activity happened) versus Provenance.recorded (the instant the activity was recorded), agent with onBehalfOf delegation, and entity roles including revision, source, instantiates and removal." }, { "id": "SRC-015", "title": "DCMI Metadata Terms", "organization": "Dublin Core Metadata Initiative (DCMI)", "url": "https://www.dublincore.org/specifications/dublin-core/dcmi-terms/", "version_or_date": "DCMI Recommendation, 2020-01-20", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-23T10:00:00Z", "relevance": "dcterms:valid ('date, often a range, of validity of a resource'), available, issued, modified, dateAccepted, and the replaces / isReplacedBy pair used for supersession links." }, { "id": "SRC-016", "title": "ISO 19135-1:2015 Geographic information — Procedures for item registration — Part 1: Fundamentals", "organization": "International Organization for Standardization (ISO)", "url": "https://www.iso.org/standard/54721.html", "version_or_date": "First edition, 2015 (ISO catalogue record 54721)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T10:00:00Z", "relevance": "RE_ItemStatus enumeration notValid | valid | superseded | retired; proposal management with disposition withdrawn | accepted | notAccepted; and the rule that retired, superseded and invalid items remain in the register so that data produced earlier can still be interpreted. Full normative text is paywalled; verified via ISO catalogue metadata, ISO/TC 211 schema listings and downstream implementations." }, { "id": "SRC-017", "title": "ISO 15489-1:2016 Information and documentation — Records management — Part 1: Concepts and principles", "organization": "International Organization for Standardization (ISO)", "url": "https://www.iso.org/standard/62542.html", "version_or_date": "Second edition, 2016 (ISO catalogue record 62542)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T10:00:00Z", "relevance": "Disposition authorities must be authorised, dated, implemented and regularly reviewed; appraisal is recurrent analysis of business activity determining what is retained and for how long. Full normative text is paywalled; verified via ISO catalogue metadata and professional literature." }, { "id": "SRC-018", "title": "ISO/IEC 11179-6:2023 Information technology — Metadata registries (MDR) — Part 6: Registration", "organization": "ISO/IEC JTC 1/SC 32", "url": "https://www.iso.org/standard/78916.html", "version_or_date": "Third edition, 2023 (ISO catalogue record 78916)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T10:00:00Z", "relevance": "Registration status of an administered item as seen by exactly one registration authority, split into lifecycle status categories (progression in metadata quality and preference of use) and documentation status categories (positions from which no further progression occurs). Full normative text is paywalled; verified via ISO catalogue metadata and registry implementations." }, { "id": "SRC-019", "title": "Unified Modeling Language (UML), version 2.5.1", "organization": "Object Management Group (OMG)", "url": "https://www.omg.org/spec/UML/2.5.1/About-UML/", "version_or_date": "Version 2.5.1, December 2017 (formal/17-12-05)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T10:00:00Z", "relevance": "The reference formalism for behavioural state machines (State, Transition, Trigger, Guard, Effect, Region, Pseudostate) used as an alignment for the lifecycle definition. Version and date confirmed from the OMG specification page; chapter-level content not retrieved live." }, { "id": "SRC-020", "title": "Regulation (EU) 2016/679 (General Data Protection Regulation)", "organization": "European Parliament and Council of the European Union", "url": "https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng", "version_or_date": "27 April 2016; CELEX 32016R0679; ELI http://data.europa.eu/eli/reg/2016/679/oj", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T10:00:00Z", "relevance": "Article 5(1)(e) storage limitation, Article 17 right to erasure and Article 30 records of processing — the legal constraint that forces reconciliation between an append-only lifecycle history and erasure obligations." }, { "id": "SRC-021", "title": "General Records Schedules (GRS)", "organization": "U.S. National Archives and Records Administration (NARA)", "url": "https://www.archives.gov/records-mgmt/grs", "version_or_date": "Current GRS portal, status updates as at June 2026; issued through GRS Transmittals", "source_type": "public-authority", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-23T10:00:00Z", "relevance": "A working example of externally issued disposition authority: mandatory schedules, temporary/permanent disposition instructions and transmittal-based versioning, showing that disposition rules are themselves versioned governed artifacts." }, { "id": "SRC-022", "title": "UK Government Linked Data Registry vocabulary (registryVocab.ttl)", "organization": "UK Government Linked Data Working Group (UKGovLD)", "url": "https://raw.githubusercontent.com/ukgovld/registry-core/master/src/main/vocabs/registryVocab.ttl", "version_or_date": "registry-core master branch, namespace http://purl.org/linked-data/registry#", "source_type": "registry", "primary_source": true, "authority_tier": 3, "accessed_at": "2026-08-23T10:00:00Z", "relevance": "A concrete governed status hierarchy (notAccepted{submitted,reserved,invalid} / accepted{valid{experimental,stable}, deprecated{superseded,retired}}) with explicit stated correspondences to ISO 19135:2005 statuses — evidence for status generalisation/specialisation rather than a flat enumeration." }, { "id": "SRC-023", "title": "schema.org EventStatusType", "organization": "Schema.org Community Group", "url": "https://schema.org/EventStatusType", "version_or_date": "schema.org release v30.0, 2026-03-19", "source_type": "schema", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-23T10:00:00Z", "relevance": "EventCancelled, EventMovedOnline, EventPostponed, EventRescheduled, EventScheduled — a widely deployed status vocabulary and a counterexample showing conflation of lifecycle state with modality change." }, { "id": "SRC-024", "title": "MariaDB Server documentation: Temporal Tables", "organization": "MariaDB", "url": "https://mariadb.com/docs/server/reference/sql-structure/temporal-tables", "version_or_date": "MariaDB Server current documentation, accessed 2026-08-23", "source_type": "first-party-doc", "primary_source": false, "authority_tier": 3, "accessed_at": "2026-08-23T10:00:00Z", "relevance": "Implementation evidence for SQL:2011 (ISO/IEC 9075-2) temporal semantics: system-versioned tables with PERIOD FOR SYSTEM_TIME and ROW_START/ROW_END, application-time periods via PERIOD FOR, bitemporal combination, and FOR SYSTEM_TIME AS OF / BETWEEN / ALL queries. Used only as secondary evidence; the SQL standard text itself was not retrieved." }, { "id": "SRC-025", "title": "FHIR Life Cycle Page (Resource Status, Current Lists, Entered in Error)", "organization": "Health Level Seven International (HL7)", "url": "https://www.hl7.org/fhir/lifecycle.html", "version_or_date": "FHIR R5 v5.0.0, 26 March 2023, Trial Use, Maturity 3", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-23T16:10:00Z", "relevance": "Four lifecycle pattern families, entered-in-error without implied deletion, technical versus business versions, and the rule that current-list membership cannot be inferred from status." }, { "id": "SRC-026", "title": "CodeSystem http://hl7.org/fhir/resource-status — Canonical Status Codes for FHIR Resources", "organization": "Health Level Seven International (HL7)", "url": "https://hl7.org/fhir/codesystem-resource-status.html", "version_or_date": "FHIR R5 v5.0.0, draft as of 2023-03-26, Experimental, Trial Use", "source_type": "classifier", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-23T16:15:00Z", "relevance": "Master set of canonical status codes including error, proposed, planned, draft, requested, active, suspended, failed, replaced, complete, inactive, abandoned, unknown, unconfirmed, confirmed, resolved and refuted, used as an alignment target not a mandated vocabulary." }, { "id": "SRC-027", "title": "ISO 19108:2002 Geographic information — Temporal schema", "organization": "International Organization for Standardization (ISO/TC 211)", "url": "https://www.iso.org/standard/26013.html", "version_or_date": "ISO 19108:2002, confirmed 2026-07-20, Cor 1:2006", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T16:25:00Z", "relevance": "Normative emphasis on valid time rather than transaction time for temporal characteristics abstracted from the real world; basis for validity intervals of features, operations and metadata." }, { "id": "SRC-028", "title": "Precise Semantics of UML State Machines (PSSM) Version 1.0", "organization": "Object Management Group (OMG)", "url": "https://www.omg.org/spec/PSSM/1.0/PDF", "version_or_date": "PSSM 1.0, May 2019, formal/2019-05-01", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T16:45:00Z", "relevance": "Operational execution semantics for a large subset of UML 2.5.1 state machines as an extension of fUML, including semantic variation points for time sources. Used to ground transition effects without treating UML XMI as the mixin semantics." }, { "id": "SRC-029", "title": "HL7 FHIR R5 Period datatype (StructureDefinition)", "organization": "Health Level Seven International (HL7)", "url": "https://www.hl7.org/fhir/R5/period.profile.json", "version_or_date": "FHIR R5 v5.0.0, 2023-03-26, Normative from 4.0.0", "source_type": "schema", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T17:05:00Z", "relevance": "Normative time range with inclusive start and end; missing end means ongoing; start SHALL be less than or equal to end; start may be past and end future. Complements OWL-Time intervals for effective validity." } ], "structure": { "bundles": [ { "id": "lifecycle-model-definition", "name": "Lifecycle Model Definition", "description": "The lifecycle state machine treated as a first-class, identified, versioned and owned object: its state space, its transition system, and the governance that keeps it stable and auditable.", "rationale": "Registration standards require that the status of an item be assigned by a named authority against a defined set of statuses, and state-machine standards require states and transitions to be declared before instances can be validated. Without an explicit machine definition, a status field is an ungoverned string and no conformance claim about instance histories is falsifiable.", "source_refs": [ "SRC-007", "SRC-016", "SRC-018", "SRC-019" ], "layers": [ { "id": "state-space", "name": "State Space and Status Axes", "description": "What states exist, how they are identified, how many independent status axes the subject carries, and which states are terminal or reversible.", "source_refs": [ "SRC-012", "SRC-016", "SRC-018", "SRC-022" ], "findings": [ { "id": "state-vocabulary", "name": "Governed state vocabulary", "description": "The finite set of states a subject may occupy is a governed code list whose members are identified concepts with definitions, not display labels. ISO 19135-1 fixes notValid/valid/superseded/retired for register items; ISO/IEC 11179-6 assigns registration status against exactly one registration authority; FHIR PublicationStatus fixes draft/active/retired/unknown.", "source_refs": [ "SRC-012", "SRC-016", "SRC-018", "SRC-022", "SRC-023" ], "questions": [ { "id": "q-sv-codelist", "text": "Which governed code list defines the permitted states for this subject, and where and at what version is it published?", "kind": "classification", "answer_data": [ "Code-list identifier (IRI or registry key)", "Publication URL", "Code-list version or edition" ] }, { "id": "q-sv-identity", "text": "What is the authoritative identifier and definition of each state, and is a state identified by an IRI or registry key rather than by its display label?", "kind": "identity", "answer_data": [ "State concept identifier per state", "Normative definition text per state", "Display labels marked as non-identifying" ] }, { "id": "q-sv-initial", "text": "Which state is entered on creation, and may a subject legitimately exist with no state assigned on this axis?", "kind": "lifecycle", "answer_data": [ "Initial state code", "Boolean: unassigned state permitted", "Rule for subjects created before the axis existed" ] }, { "id": "q-sv-unknown", "text": "How is an indeterminate status represented, and is it distinguishable from an absent assertion?", "kind": "exception", "answer_data": [ "Code used for indeterminate status (e.g. an explicit 'unknown' member)", "Rule distinguishing null from indeterminate", "Handling instruction for consumers" ] } ], "data_elements": [ { "id": "de-state-code", "name": "State code", "description": "The value asserted on a status axis, drawn from the bound code list.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-012", "SRC-016" ] }, { "id": "de-state-code-system", "name": "State code system identifier", "description": "Identifier of the code list from which the state code is drawn, with its version.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-018", "SRC-022" ] }, { "id": "de-state-definition", "name": "State definition", "description": "Normative definition of the state concept, independent of any display label or translation.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-012", "SRC-016" ] }, { "id": "de-state-is-initial", "name": "Initial-state flag", "description": "Marks the state entered by default when a subject is created under this lifecycle.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] } ], "artifacts": [ { "id": "lifecycle-state-code-list", "name": "Lifecycle state code list", "description": "The published, versioned set of state concepts with identifiers, definitions and any generalisation hierarchy between them.", "media_or_form": [ "Machine-readable concept scheme or enumeration (format-neutral)", "Human-readable published register page" ], "serial": false, "identity_strategy": "Governed global identifier: the code-list IRI or registry key assigned by the registration authority, with a per-state concept identifier. A UUID or ULID assigned by the adopting Dimension is used only where no governed identifier exists. A publication date is never used as the identifier.", "source_refs": [ "SRC-016", "SRC-018", "SRC-022" ] } ], "inline_only_rationale": null }, { "id": "status-axes", "name": "Concurrent status axes and precedence", "description": "Most subjects carry more than one simultaneous status: a governance/publication status, an operational status, a legal-validity status and sometimes a quality status. ISO/IEC 11179-6 already splits registration status into lifecycle and documentation categories, and VC 2.0 keeps validity period separate from credentialStatus. Collapsing these into one enumeration is the most common modelling defect this mixin must prevent.", "source_refs": [ "SRC-005", "SRC-006", "SRC-012", "SRC-018" ], "questions": [ { "id": "q-sa-count", "text": "How many independent status axes does this subject carry, and what is the name, purpose and code list of each?", "kind": "classification", "answer_data": [ "Axis identifier and label per axis", "Purpose statement per axis", "Bound code list per axis" ] }, { "id": "q-sa-precedence", "text": "When two axes disagree — for example publication status 'active' while operational status is 'suspended' — which axis governs a consumer's decision to rely on the subject?", "kind": "decision", "answer_data": [ "Precedence ordering of axes", "Decision rule expressed as a deterministic function", "Worked examples of disagreement" ] }, { "id": "q-sa-constraints", "text": "Does a value on one axis constrain the permitted values on another axis?", "kind": "constraint", "answer_data": [ "Cross-axis constraint expressions", "Violation severity (reject or warn)" ] }, { "id": "q-sa-default", "text": "Which single axis, if any, is exposed as the default 'status' in downstream projections and mappings?", "kind": "interoperability", "answer_data": [ "Default-exposed axis identifier", "Rationale and warning about information loss" ] } ], "data_elements": [ { "id": "de-status-axis-id", "name": "Status axis identifier", "description": "Stable identifier of one status axis carried by the subject.", "value_kind": "identifier", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-018", "SRC-006" ] }, { "id": "de-status-axis-precedence", "name": "Axis precedence rank", "description": "Ordinal rank used to resolve reliance decisions when axes disagree.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "de-axis-cross-constraint", "name": "Cross-axis constraint", "description": "Declarative rule restricting combinations of values across two or more axes.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-018" ] } ], "artifacts": [ { "id": "status-axis-matrix", "name": "Status axis matrix", "description": "Tabular declaration of every status axis, its code list, its precedence rank and the cross-axis constraints in force.", "media_or_form": [ "Tabular declaration (format-neutral)", "Rendered governance page" ], "serial": false, "identity_strategy": "Governed global identifier derived from the lifecycle-definition IRI plus an axis-matrix path segment; falls back to a ULID assigned by the adopting Dimension when the lifecycle definition has no IRI.", "source_refs": [ "SRC-018", "SRC-005" ] } ], "inline_only_rationale": null }, { "id": "terminality-and-reversibility", "name": "Terminal states and reversibility", "description": "Which states are absorbing and which can be left again. Bitstring Status List is explicit that revocation is not reversible while suspension is; RFC 5280 permits a certificateHold to be reversed via removeFromCRL; ISO 19135-1 keeps retired and superseded items resolvable rather than deleting them.", "source_refs": [ "SRC-003", "SRC-006", "SRC-012", "SRC-016" ], "questions": [ { "id": "q-tr-terminal", "text": "Which states have no outgoing transitions, and is that terminality enforced by the definition or merely by convention?", "kind": "lifecycle", "answer_data": [ "List of terminal state codes", "Enforcement mechanism (declared vs conventional)" ] }, { "id": "q-tr-reversible", "text": "Which states may be left again, and what procedure, authority and evidence are required to re-enter a prior state?", "kind": "process", "answer_data": [ "Reversible state codes", "Reinstatement procedure reference", "Required authority level and evidence" ] }, { "id": "q-tr-interval", "text": "On reinstatement, is the previously closed validity interval reopened or is a new interval started?", "kind": "temporal", "answer_data": [ "Interval policy on reinstatement", "Effect on continuity constraints" ] }, { "id": "q-tr-resolvable", "text": "Do subjects in terminal states remain retrievable and dereferenceable so that historical data can still be interpreted?", "kind": "retention", "answer_data": [ "Retrievability rule for terminal states", "Minimum information retained", "Reference to disposition trigger" ] } ], "data_elements": [ { "id": "de-state-is-terminal", "name": "Terminal-state flag", "description": "Declares a state as absorbing: no transitions leave it under the current lifecycle version.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006", "SRC-007" ] }, { "id": "de-state-is-reversible", "name": "Reversibility flag", "description": "Declares whether the state can be exited back to a previously held state.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003", "SRC-006" ] }, { "id": "de-reinstatement-policy-ref", "name": "Reinstatement policy reference", "description": "Reference to the rule governing re-entry to a prior state, including required authority.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003", "SRC-017" ] } ], "artifacts": [ { "id": "reinstatement-decision-record", "name": "Reinstatement decision record", "description": "The dated, attributed decision that returns a subject from a reversible non-valid state to a valid state, with its grounds and effective instant.", "media_or_form": [ "Decision record (format-neutral)", "Signed or countersigned rendering where non-repudiation is required" ], "serial": true, "identity_strategy": "Authoritative master-system identifier from the governing decision system where one exists; otherwise a ULID assigned by the adopting Dimension. Sequence numbers are ordering metadata, never the identifier.", "source_refs": [ "SRC-003", "SRC-006", "SRC-017" ] } ], "inline_only_rationale": null }, { "id": "lifecycle-pattern-family", "name": "Lifecycle pattern family", "description": "FHIR documents four families: clinical workflow process (planned, in-progress, on-hold, stopped, completed, cancelled); request/order (proposed, draft, requested, rejected, accepted, in-progress, completed, cancelled); entity availability (draft, active, suspended, amended, retired); and clinical status (active, inactive, unknown) which is explicitly not a workflow lifecycle. ISO 15489 adds a records-management process family of create, capture and manage over time. The mixin must declare which family a binding uses.", "source_refs": [ "SRC-025", "SRC-017" ], "questions": [ { "id": "lifecycle-pattern-family-q01", "text": "Which lifecycle pattern family does this binding use, and is more than one family attached to the same host via distinct aspects?", "kind": "classification", "answer_data": [ "pattern family code", "aspect code", "coexistence notes" ] }, { "id": "lifecycle-pattern-family-q02", "text": "Which status codes are meaningless in this family and must be rejected (for example retired on a clinical-interpretation binding)?", "kind": "constraint", "answer_data": [ "forbidden codes", "rejection reason" ] }, { "id": "lifecycle-pattern-family-q03", "text": "If the family is clinical interpretation, has it been kept distinct from workflow or request status so that inactive does not mean completed?", "kind": "validation", "answer_data": [ "boolean distinct", "paired workflow binding reference" ] } ], "data_elements": [ { "id": "lifecycle-pattern-family-data01", "name": "Pattern family", "description": "workflow-process, request-order, entity-availability, clinical-interpretation, records-management, or local family.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-025", "SRC-017" ] }, { "id": "lifecycle-pattern-family-data02", "name": "Family notes", "description": "Local interpretation of the family and any deviations from the FHIR characteristic sets.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-025" ] } ], "artifacts": [], "inline_only_rationale": "Pattern family is a classification field on the binding; characteristic code lists live in the bound code system artefact." } ] }, { "id": "transition-system", "name": "Transition System", "description": "The permitted movements between states, what triggers them, what conditions guard them, what they must cause, and how concurrency and resumption are handled.", "source_refs": [ "SRC-007", "SRC-016", "SRC-019" ], "findings": [ { "id": "transition-topology-and-guards", "name": "Transition topology, triggers, guards and effects", "description": "The allow-list of (source state, target state) pairs together with the trigger, guard condition, mandated effects and deterministic conflict resolution for each transition. SCXML supplies the normative shape (event, cond, target, type) and the rule that where several transitions match, the first in document order is taken.", "source_refs": [ "SRC-007", "SRC-016", "SRC-019", "SRC-022" ], "questions": [ { "id": "q-tt-pairs", "text": "What is the complete set of permitted source-state to target-state pairs for this lifecycle version?", "kind": "composition", "answer_data": [ "Enumerated transition pairs", "Transition identifier per pair", "Lifecycle definition version they belong to" ] }, { "id": "q-tt-closure", "text": "Is the transition set an explicit allow-list, or is any transition permitted unless expressly forbidden?", "kind": "constraint", "answer_data": [ "Closure mode (allow-list vs deny-list)", "Default behaviour for undeclared transitions" ] }, { "id": "q-tt-trigger", "text": "What triggers each transition — a domain event, an elapsed timer, or an explicit operator command — and which transitions fire automatically without human action?", "kind": "event", "answer_data": [ "Trigger kind per transition", "Trigger event identifier or timer expression", "Automatic vs operator-initiated flag" ] }, { "id": "q-tt-guard", "text": "What guard condition must hold for each transition, against which data is it evaluated, and at which instant?", "kind": "constraint", "answer_data": [ "Guard expression per transition", "Data inputs referenced by the guard", "Evaluation instant convention" ] }, { "id": "q-tt-conflict", "text": "If more than one transition matches the same trigger, how is the winner chosen deterministically?", "kind": "decision", "answer_data": [ "Conflict-resolution rule (priority, declaration order, guard specificity)", "Test cases demonstrating determinism" ] } ], "data_elements": [ { "id": "de-transition-id", "name": "Transition identifier", "description": "Stable identifier of a declared transition within a lifecycle definition version.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-007" ] }, { "id": "de-transition-source-state", "name": "Source state", "description": "The state the subject must occupy for the transition to be applicable.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-007", "SRC-019" ] }, { "id": "de-transition-target-state", "name": "Target state", "description": "The state entered when the transition is taken.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-007", "SRC-019" ] }, { "id": "de-transition-guard", "name": "Guard expression", "description": "Side-effect-free boolean condition that must evaluate true for the transition to be taken.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "de-transition-effect", "name": "Mandated transition effect", "description": "Action the system must perform on taking the transition (notification, artifact issuance, downstream state change).", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-016" ] }, { "id": "de-transition-priority", "name": "Transition priority", "description": "Ordinal used to resolve competing matching transitions deterministically.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] } ], "artifacts": [ { "id": "state-transition-table", "name": "State transition table", "description": "The machine-readable declaration of states, transitions, triggers, guards, effects and priorities that constitutes the executable lifecycle definition.", "media_or_form": [ "Declarative state-machine description (statechart, transition table or equivalent)", "Rendered state diagram for human review" ], "serial": false, "identity_strategy": "Governed global identifier: the lifecycle-definition IRI plus a version token; a ULID assigned by the adopting Dimension only when no governed IRI exists.", "source_refs": [ "SRC-007", "SRC-019" ] } ], "inline_only_rationale": null }, { "id": "concurrency-and-history", "name": "Concurrent regions and history semantics", "description": "Whether the subject may occupy several states at once in parallel regions, whether composite states nest, and whether a prior sub-state is remembered on re-entry. SCXML defines parallel regions, shallow and deep history and done.state completion events; UML 2.5.1 provides the equivalent behavioural formalism.", "source_refs": [ "SRC-007", "SRC-019" ], "questions": [ { "id": "q-ch-parallel", "text": "Does this lifecycle contain concurrent regions such that the subject is legitimately in more than one state simultaneously?", "kind": "state", "answer_data": [ "Region identifiers", "Boolean: concurrency used", "Active-state-configuration representation" ] }, { "id": "q-ch-nesting", "text": "Are composite or nested states used, and does exiting an outer state force exit of all inner states?", "kind": "composition", "answer_data": [ "Parent-child state relationships", "Exit propagation rule" ] }, { "id": "q-ch-history", "text": "Is the previously active sub-state remembered when a composite state is re-entered, and is that memory shallow or deep?", "kind": "state", "answer_data": [ "History kind (none, shallow, deep)", "Default sub-state when no history exists" ] }, { "id": "q-ch-completion", "text": "How is completion of a concurrent region signalled, and what joins the regions back together?", "kind": "process", "answer_data": [ "Completion event naming convention", "Join condition" ] } ], "data_elements": [ { "id": "de-region-id", "name": "Region identifier", "description": "Identifier of one concurrent region of the lifecycle.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-019" ] }, { "id": "de-active-state-configuration", "name": "Active state configuration", "description": "The complete set of states simultaneously active for the subject, not a single scalar status.", "value_kind": "collection", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-007" ] }, { "id": "de-history-kind", "name": "History kind", "description": "Declares whether re-entry restores no memory, the immediate child, or the full descendant configuration.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] } ], "artifacts": [ { "id": "state-configuration-snapshot", "name": "State configuration snapshot", "description": "A point-in-time capture of the full active state configuration across all regions, used for resumption and for audit reconstruction.", "media_or_form": [ "Structured snapshot (format-neutral)", "Audit export" ], "serial": true, "identity_strategy": "ULID assigned by the adopting Dimension, carrying both the subject identifier and the record instant; where the host system of record issues snapshot identifiers, those take priority.", "source_refs": [ "SRC-007", "SRC-024" ] } ], "inline_only_rationale": null } ] }, { "id": "machine-governance", "name": "Lifecycle Definition Governance", "description": "Identity, versioning, ownership, change procedure and conformance rules for the lifecycle definition itself.", "source_refs": [ "SRC-009", "SRC-010", "SRC-016", "SRC-018" ], "findings": [ { "id": "machine-identity-and-version", "name": "Identity, version and effective period of the lifecycle definition", "description": "A subject's history is only interpretable against the version of the lifecycle definition that was in force when each transition occurred. The definition therefore needs its own identifier, version, effective period and — recursively — its own status.", "source_refs": [ "SRC-009", "SRC-010", "SRC-012", "SRC-016", "SRC-018" ], "questions": [ { "id": "q-mi-id", "text": "What is the authoritative identifier and version of the lifecycle definition governing this subject?", "kind": "identity", "answer_data": [ "Lifecycle definition identifier (IRI or registry key)", "Version token", "Registration authority identifier" ] }, { "id": "q-mi-binding", "text": "How is a subject bound to a lifecycle version, and does that binding move automatically when the definition is revised?", "kind": "relationship", "answer_data": [ "Binding reference and its cardinality", "Binding policy: pinned vs floating", "Migration behaviour on revision" ] }, { "id": "q-mi-effective", "text": "Over what period is each lifecycle-definition version effective, and may two versions be effective at once for different subjects?", "kind": "temporal", "answer_data": [ "Effective-from and effective-until per version", "Overlap policy across versions" ] }, { "id": "q-mi-selfapply", "text": "Is the lifecycle definition itself governed by this same mixin, so that it can be draft, active, deprecated or retired?", "kind": "definition", "answer_data": [ "Boolean: self-application", "Status axis used for the definition", "Prior-version and incompatibility links" ] } ], "data_elements": [ { "id": "de-lifecycle-def-id", "name": "Lifecycle definition identifier", "description": "Identifier of the state machine that governs the subject.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-016", "SRC-018" ] }, { "id": "de-lifecycle-def-version", "name": "Lifecycle definition version", "description": "Version token of the governing definition, recorded on every transition so history remains interpretable.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-009", "SRC-010" ] }, { "id": "de-lifecycle-binding-mode", "name": "Binding mode", "description": "Whether the subject is pinned to a specific definition version or follows the current version.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-009" ] }, { "id": "de-lifecycle-def-effective-period", "name": "Definition effective period", "description": "The interval over which a lifecycle-definition version is in force.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013", "SRC-015" ] } ], "artifacts": [ { "id": "lifecycle-definition-document", "name": "Lifecycle definition document", "description": "The governed specification of one lifecycle version: state code list binding, transition table, axis matrix, temporal conventions and conformance rules, published as a single citable unit.", "media_or_form": [ "Specification document (format-neutral)", "Machine-readable definition package" ], "serial": false, "identity_strategy": "Governed global identifier: definition IRI with an explicit version token; the authoritative master-system identifier of the registration authority's registry takes priority where one exists; ULID otherwise.", "source_refs": [ "SRC-016", "SRC-018", "SRC-009" ] } ], "inline_only_rationale": null }, { "id": "machine-authority-and-conformance", "name": "Registration authority, change procedure and conformance", "description": "ISO/IEC 11179-6 requires each administered item to be administered by exactly one registration authority; ISO 19135-1 structures change as proposals with dispositions of accepted, notAccepted or withdrawn. Conformance rules make instance histories falsifiable against the definition.", "source_refs": [ "SRC-016", "SRC-017", "SRC-018", "SRC-007" ], "questions": [ { "id": "q-ma-authority", "text": "Which single registration authority or steward owns this lifecycle definition and may approve changes to it?", "kind": "authority", "answer_data": [ "Authority identifier and contact", "Delegation arrangements", "Scope of the authority's remit" ] }, { "id": "q-ma-procedure", "text": "What proposal, review and decision procedure governs a change, and which dispositions are possible?", "kind": "process", "answer_data": [ "Procedure reference", "Permitted disposition values", "Decision body identifier", "Appeal route" ] }, { "id": "q-ma-midflight", "text": "What happens to subjects that are mid-lifecycle when a state is removed or renamed, and who is accountable for their migration?", "kind": "ownership", "answer_data": [ "Migration rule per removed or renamed state", "Accountable role", "Deadline and fallback state" ] }, { "id": "q-ma-conformance", "text": "What makes a recorded state history conformant to the definition, and are non-conformant histories rejected, quarantined or tolerated?", "kind": "validation", "answer_data": [ "Conformance rule set", "Disposition of non-conformant histories", "Validation report retention" ] }, { "id": "q-ma-claim", "text": "Is conformance to any external standard claimed for this lifecycle, and what evidence supports the claim?", "kind": "evidence", "answer_data": [ "Claimed standard and clause", "Evidence artifact reference", "Explicit statement where only alignment, not conformance, is claimed" ] } ], "data_elements": [ { "id": "de-registration-authority", "name": "Registration authority", "description": "The single body accountable for the lifecycle definition and for status assignment under it.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-016", "SRC-018" ] }, { "id": "de-proposal-id", "name": "Change proposal identifier", "description": "Identifier of a proposal to change the lifecycle definition.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-016" ] }, { "id": "de-proposal-disposition", "name": "Proposal disposition", "description": "Outcome of a change proposal, such as accepted, not accepted or withdrawn.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016" ] }, { "id": "de-conformance-result", "name": "Conformance result", "description": "Outcome of validating a recorded history against the governing definition version.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-017" ] } ], "artifacts": [ { "id": "registration-decision-record", "name": "Registration and conformance decision record", "description": "The dated, attributed record of a decision on a change proposal or a conformance assessment, including grounds and effective date.", "media_or_form": [ "Decision record (format-neutral)", "Validation report export" ], "serial": true, "identity_strategy": "Authoritative master-system identifier issued by the registration authority's registry; otherwise a governed IRI under the authority's namespace; otherwise a ULID assigned by the adopting Dimension.", "source_refs": [ "SRC-016", "SRC-018", "SRC-017" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "state-assertion-and-history", "name": "State Assertion and Transition History", "description": "What the subject's state currently is, how that value is obtained, and the append-only record of how it got there.", "rationale": "A status value without a history is unauditable and a history without a resolved current value is unusable. PROV-O and FHIR Provenance both separate the occurrence of an activity from the recording of it, and registration standards require status to be attributable to an authority; both requirements land in this bundle.", "source_refs": [ "SRC-004", "SRC-012", "SRC-014", "SRC-018" ], "layers": [ { "id": "current-state-assertion", "name": "Current State Assertion", "description": "The authoritative current value on each axis and whether it is asserted, derived, or both.", "source_refs": [ "SRC-005", "SRC-012", "SRC-013" ], "findings": [ { "id": "state-assertion-record", "name": "Current-state assertion", "description": "The assertion that a subject is in a given state on a given axis from a given instant, attributed to an agent. It is the value consumers read; its trustworthiness depends entirely on the transition record behind it.", "source_refs": [ "SRC-004", "SRC-012", "SRC-014", "SRC-016" ], "questions": [ { "id": "q-sar-current", "text": "What is the subject's current state on each axis, and which record is authoritative if several systems hold a copy?", "kind": "state", "answer_data": [ "Current state code per axis", "System of record identifier", "Copy-reconciliation rule" ] }, { "id": "q-sar-since", "text": "Since which instant has the subject been in this state, and is that instant a real-world instant or the instant the system recorded it?", "kind": "temporal", "answer_data": [ "State-since timestamp with explicit offset", "Time-line designation (valid time or record time)" ] }, { "id": "q-sar-agent", "text": "Which agent asserted the current state, and on whose authority did they act?", "kind": "provenance", "answer_data": [ "Asserting agent identifier", "Authority basis", "On-behalf-of party where delegated" ] }, { "id": "q-sar-storage", "text": "Is the current state stored as a materialised value or always recomputed from the transition log, and how is divergence detected?", "kind": "quality", "answer_data": [ "Materialisation mode", "Recomputation procedure", "Divergence detection and alert rule" ] } ], "data_elements": [ { "id": "de-current-state", "name": "Current state", "description": "The state presently asserted for the subject on a named axis.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-012", "SRC-016" ] }, { "id": "de-state-since", "name": "State since instant", "description": "The instant from which the current state applies, on the declared time line.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-013" ] }, { "id": "de-state-asserted-by", "name": "Asserting agent", "description": "The agent responsible for the current-state assertion.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-014" ] }, { "id": "de-state-assertion-id", "name": "State assertion identifier", "description": "Identifier of the assertion itself, so that it can be superseded or corrected without ambiguity.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] } ], "artifacts": [], "inline_only_rationale": "The current-state assertion is inline context carried on the host record: it is a small set of values (state, since-instant, asserting agent) that every consumer of the host entry reads directly. Issuing a separate artifact for it would duplicate the host record and create two sources of truth. The durable, citable artifacts for this material are the transition-log entry in `transition-event-record` and, where a point-in-time answer must be reproducible, the `as-of-state-snapshot` in `temporal-state-resolution-queries`." }, { "id": "derived-vs-asserted-status", "name": "Derived status versus asserted status", "description": "Effective status may be asserted explicitly, derived from validity dates, or both. VC 2.0 keeps validFrom/validUntil (automatic, time-bound) distinct from credentialStatus (issuer-controlled, event-driven); RFC 5280 does the same with the validity period and the CRL. The precedence rule between them must be explicit, because 'active but outside its validity period' is otherwise undefined.", "source_refs": [ "SRC-003", "SRC-005", "SRC-012", "SRC-024" ], "questions": [ { "id": "q-dva-mode", "text": "Is effective status asserted, derived from validity dates, or a hybrid, and which source wins when they disagree?", "kind": "decision", "answer_data": [ "Derivation mode code", "Precedence rule", "Disagreement examples and expected outcomes" ] }, { "id": "q-dva-algorithm", "text": "What is the deterministic algorithm for deriving effective status, including its inputs and the instant at which it is evaluated?", "kind": "process", "answer_data": [ "Derivation algorithm specification", "Input element list", "Evaluation-instant parameter and its default" ] }, { "id": "q-dva-anomaly", "text": "Can a subject legitimately be 'active' on its status axis while outside its validity interval, or is that always a defect?", "kind": "constraint", "answer_data": [ "Legitimacy ruling", "Detection rule", "Remediation path" ] }, { "id": "q-dva-cache", "text": "How is a derived status cached and invalidated so that consumers never act on a stale computation?", "kind": "quality", "answer_data": [ "Cache lifetime", "Invalidation triggers", "Maximum tolerated staleness" ] } ], "data_elements": [ { "id": "de-status-derivation-mode", "name": "Status derivation mode", "description": "Whether effective status is asserted, derived or hybrid.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-005", "SRC-003" ] }, { "id": "de-status-derivation-rule", "name": "Status derivation rule", "description": "The specification of how effective status is computed from validity interval and asserted status.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005", "SRC-024" ] }, { "id": "de-status-evaluation-instant", "name": "Status evaluation instant", "description": "The instant at which effective status was computed, which is not necessarily the instant it is read.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-024" ] } ], "artifacts": [ { "id": "status-derivation-rule-set", "name": "Status derivation rule set", "description": "The declarative, testable rules that turn validity intervals plus asserted status into an effective status, together with their precedence ordering.", "media_or_form": [ "Declarative rule set (format-neutral)", "Executable test fixtures" ], "serial": false, "identity_strategy": "Governed global identifier under the lifecycle-definition namespace with a version token; ULID assigned by the adopting Dimension where no namespace exists.", "source_refs": [ "SRC-005", "SRC-003" ] } ], "inline_only_rationale": null }, { "id": "lifecycle-binding-identity", "name": "Lifecycle binding identifier", "description": "Each attached lifecycle record has its own identifier, distinct from the host identifier and from any timestamp. SCXML 3.14 requires IDs on machine vertices; FHIR resource identity is separate from status; a date is not an identifier.", "source_refs": [ "SRC-007", "SRC-025", "SRC-001" ], "questions": [ { "id": "lifecycle-binding-identity-q01", "text": "What authoritative master-system identifier uniquely names this lifecycle binding, and which system is the master?", "kind": "identity", "answer_data": [ "master-system identifier string", "master-system URI", "identifier type code" ] }, { "id": "lifecycle-binding-identity-q02", "text": "If no master-system identifier exists, what governed global IRI, or which Dimension-assigned UUID or ULID, identifies the binding?", "kind": "identity", "answer_data": [ "IRI", "UUID or ULID", "assignment authority", "assignment timestamp RFC 3339" ] }, { "id": "lifecycle-binding-identity-q03", "text": "Has any date, validity start, or observation time been incorrectly treated as the binding identifier?", "kind": "validation", "answer_data": [ "boolean flag", "offending field path", "corrective identifier" ] } ], "data_elements": [ { "id": "lifecycle-binding-identity-data01", "name": "Lifecycle record identifier", "description": "Primary identifier of this mixin instance, never a date.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-007", "SRC-025" ] }, { "id": "lifecycle-binding-identity-data02", "name": "Identifier scheme", "description": "Whether the identifier is a master-system key, a governed IRI, or a Dimension UUID/ULID.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-025", "SRC-015" ] }, { "id": "lifecycle-binding-identity-data03", "name": "Identifier assignment time", "description": "RFC 3339 instant when the identifier was assigned; not itself an identifier.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-004" ] } ], "artifacts": [], "inline_only_rationale": "The binding identifier is reference data carried on the mixin record; no separate artefact is required unless the master system issues a certificate or register extract." }, { "id": "host-subject-and-aspect-binding", "name": "Host subject binding", "description": "The mixin is meaningless without a host. FHIR status is a property of a resource; OWL-Time hasTime associates a temporal entity with anything; PROV generation times bound an Entity. The host is referenced, not copied.", "source_refs": [ "SRC-008", "SRC-025", "SRC-004" ], "questions": [ { "id": "host-subject-and-aspect-binding-q01", "text": "Which host subject does this lifecycle record describe, and by which identity priority is that host referenced?", "kind": "relationship", "answer_data": [ "host reference", "host identifier scheme", "host type or class" ] }, { "id": "host-subject-and-aspect-binding-q02", "text": "Does the status apply to the whole host, to a stated aspect, role, or version of the host, or to a process the host represents?", "kind": "composition", "answer_data": [ "aspect code", "aspect description", "process-versus-entity flag" ] }, { "id": "host-subject-and-aspect-binding-q03", "text": "May the same host carry multiple concurrent lifecycle bindings (for example workflow status plus clinical status plus publication status)?", "kind": "constraint", "answer_data": [ "boolean", "allowed pattern family list", "disambiguating aspect codes" ] } ], "data_elements": [ { "id": "host-subject-and-aspect-binding-data01", "name": "Host subject reference", "description": "Reference to the identified host to which this mixin is attached.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-025", "SRC-004" ] }, { "id": "host-subject-and-aspect-binding-data02", "name": "Status aspect", "description": "Which facet of the host this binding governs, so concurrent machines do not collide.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-025" ] }, { "id": "host-subject-and-aspect-binding-data03", "name": "Host type", "description": "Type or class of the host, for pattern selection, not a status code.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-025", "SRC-015" ] } ], "artifacts": [], "inline_only_rationale": "Host binding is a reference; the host artefact lives in the host model." }, { "id": "active-configuration-and-lossy-projection", "name": "Active configuration set", "description": "SCXML configuration is the set of active states. Parallel regions make a single status code insufficient. The mixin records the full set and optionally a projected code for interchange.", "source_refs": [ "SRC-007", "SRC-028" ], "questions": [ { "id": "active-configuration-and-lossy-projection-q01", "text": "Which states are currently active, and is that set a legal configuration?", "kind": "state", "answer_data": [ "active state identifiers", "legal-configuration boolean" ] }, { "id": "active-configuration-and-lossy-projection-q02", "text": "What single status code is projected from the configuration for systems that cannot represent a set, and is that projection lossy?", "kind": "interoperability", "answer_data": [ "projected code", "lossiness flag", "projection rule" ] }, { "id": "active-configuration-and-lossy-projection-q03", "text": "Are any child machines invoked from the current configuration, and what is their session identity and status?", "kind": "composition", "answer_data": [ "invoked machine references", "session identifiers", "child statuses" ] } ], "data_elements": [ { "id": "active-configuration-and-lossy-projection-data01", "name": "Active state identifiers", "description": "Set of currently active vertices.", "value_kind": "collection", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-007" ] }, { "id": "active-configuration-and-lossy-projection-data02", "name": "Projected status", "description": "Optional single-code projection of the configuration.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-026" ] }, { "id": "active-configuration-and-lossy-projection-data03", "name": "Invoked sessions", "description": "Child machine sessions started from current states.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007" ] } ], "artifacts": [], "inline_only_rationale": "The active configuration is runtime reference data; child machine definitions are separate artefacts already in scope." } ] }, { "id": "transition-record", "name": "Transition Record", "description": "The append-only record of each state change, with its reason, its evidence and the authority under which it was made.", "source_refs": [ "SRC-004", "SRC-014", "SRC-016", "SRC-024" ], "findings": [ { "id": "transition-event-record", "name": "Transition event record", "description": "Each state change is recorded as an immutable event carrying prior state, new state, the governing definition version, an event time and a record time. FHIR separates Provenance.occurred from Provenance.recorded; system-versioned tables maintain row_start/row_end automatically. Both patterns are required here because event time and record time routinely differ.", "source_refs": [ "SRC-001", "SRC-004", "SRC-014", "SRC-024" ], "questions": [ { "id": "q-ter-id", "text": "What is the identifier of each transition event, and is the log strictly append-only?", "kind": "identity", "answer_data": [ "Transition event identifier", "Append-only guarantee statement", "Mechanism preventing in-place edits" ] }, { "id": "q-ter-times", "text": "Which event time and which record time are captured for each transition, and by what rule may they differ?", "kind": "temporal", "answer_data": [ "Event time with explicit offset", "Record time with explicit offset", "Permitted divergence rule" ] }, { "id": "q-ter-states", "text": "Which state was left, which was entered, and which lifecycle-definition version was in force at that moment?", "kind": "state", "answer_data": [ "Prior state code", "New state code", "Definition version token" ] }, { "id": "q-ter-ordering", "text": "How are concurrent or out-of-order transition submissions ordered, de-duplicated and made replay-safe?", "kind": "process", "answer_data": [ "Ordering key", "De-duplication key", "Replay handling rule" ] } ], "data_elements": [ { "id": "de-transition-event-id", "name": "Transition event identifier", "description": "Identifier of one recorded state change.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-014" ] }, { "id": "de-transition-event-time", "name": "Transition event time", "description": "The instant at which the state change took effect in the world.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-014" ] }, { "id": "de-transition-record-time", "name": "Transition record time", "description": "The instant at which the state change was recorded in the system of record.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-014", "SRC-024" ] }, { "id": "de-prior-state", "name": "Prior state", "description": "The state occupied immediately before the transition.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-007" ] }, { "id": "de-new-state", "name": "New state", "description": "The state occupied immediately after the transition.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-007" ] } ], "artifacts": [ { "id": "lifecycle-transition-log-entry", "name": "Lifecycle transition log entry", "description": "The immutable, individually citable record of one state change, forming the append-only history from which any past state can be reconstructed.", "media_or_form": [ "Append-only log entry (format-neutral)", "Audit export" ], "serial": true, "identity_strategy": "Authoritative master-system identifier assigned by the system of record; otherwise a ULID assigned by the adopting Dimension whose lexical order matches record time. Sequence numbers and timestamps are ordering metadata, never identifiers.", "source_refs": [ "SRC-004", "SRC-014", "SRC-024" ] } ], "inline_only_rationale": null }, { "id": "reason-evidence-and-authority", "name": "Reason codes, evidence and transition authority", "description": "Why a transition happened, what proves it, and who was entitled to make it. RFC 5280's CRLReason shows that reason codes carry consequences, not just commentary; ISO 19135-1 distinguishes clarification, amendment and supersession information; PROV-O and FHIR record acting agents and delegation.", "source_refs": [ "SRC-003", "SRC-004", "SRC-014", "SRC-016", "SRC-017" ], "questions": [ { "id": "q-rea-code", "text": "Which governed reason code justifies this transition, and from which code list is it drawn?", "kind": "classification", "answer_data": [ "Reason code", "Reason code system identifier and version", "Mapping to external reason vocabularies" ] }, { "id": "q-rea-evidence", "text": "What supporting evidence is referenced for the transition, and is that evidence still retrievable for as long as the transition is relied upon?", "kind": "evidence", "answer_data": [ "Evidence references", "Evidence retention period", "Retrievability guarantee" ] }, { "id": "q-rea-consequence", "text": "Does the reason code change the consequences of the transition, for example by making invalidation retroactive rather than prospective?", "kind": "constraint", "answer_data": [ "Consequence rule per reason code", "Retroactivity flag per code" ] }, { "id": "q-rea-authority", "text": "Which role or agent was authorised to execute this transition, was dual control required, and was it exercised on behalf of another party?", "kind": "authority", "answer_data": [ "Acting agent identifier", "Authorising agent identifier", "On-behalf-of party", "Separation-of-duties requirement" ] }, { "id": "q-rea-repudiation", "text": "How is an unauthorised or repudiated transition detected, recorded and remediated?", "kind": "security", "answer_data": [ "Detection control", "Remediation transition", "Incident record reference" ] } ], "data_elements": [ { "id": "de-transition-reason-code", "name": "Transition reason code", "description": "Governed code stating why the transition occurred.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003", "SRC-016" ] }, { "id": "de-transition-justification-text", "name": "Transition justification", "description": "Free-text justification supplementing the reason code, which may carry a stricter access class than the state value.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017" ] }, { "id": "de-evidence-ref", "name": "Supporting evidence reference", "description": "Reference to a document, decision or measurement that substantiates the transition.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-017", "SRC-014" ] }, { "id": "de-transition-actor", "name": "Transition actor", "description": "The agent that executed the transition.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-014" ] }, { "id": "de-transition-authorizer", "name": "Transition authoriser", "description": "The agent that approved the transition where approval is separate from execution.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014", "SRC-016" ] } ], "artifacts": [ { "id": "transition-authorization-dossier", "name": "Transition authorisation and justification dossier", "description": "The bundle of reason code, justification, authority basis and evidence references supporting one transition, retained for the life of the reliance on that transition.", "media_or_form": [ "Structured dossier (format-neutral)", "Attached or referenced evidence items" ], "serial": true, "identity_strategy": "Authoritative master-system identifier from the approval system where one exists; otherwise a ULID assigned by the adopting Dimension, cross-referenced to the transition event identifier.", "source_refs": [ "SRC-003", "SRC-016", "SRC-017" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "effective-validity", "name": "Effective Validity and Bitemporal Semantics", "description": "When a state or assertion is effective in the world, when the system came to believe it, and how the two time lines are reconciled, corrected and queried.", "rationale": "Status without an effective period is ambiguous, and an effective period without a record time cannot be audited or corrected. VC 2.0, RFC 5280, DCMI and FHIR all carry an explicit validity interval; SQL:2011-style application-time and system-time periods provide the bitemporal frame; RFC 3339 and RFC 9557 fix the timestamp semantics.", "source_refs": [ "SRC-001", "SRC-002", "SRC-005", "SRC-013", "SRC-015", "SRC-024" ], "layers": [ { "id": "validity-interval", "name": "Validity Interval", "description": "The real-world interval over which an assertion is effective, its boundary conventions, and the constraints relating successive intervals.", "source_refs": [ "SRC-003", "SRC-005", "SRC-008", "SRC-013", "SRC-015" ], "findings": [ { "id": "valid-time-interval", "name": "Valid-time interval", "description": "The interval, on the real-world time line, over which the assertion or state is effective. VC 2.0 expresses this as validFrom/validUntil, RFC 5280 as notBefore/notAfter, DCMI as dcterms:valid and FHIR as a Period; all treat it as independent of when the record was written.", "source_refs": [ "SRC-003", "SRC-005", "SRC-013", "SRC-015", "SRC-024" ], "questions": [ { "id": "q-vti-from", "text": "From which real-world instant is this state or assertion effective, and until which instant?", "kind": "temporal", "answer_data": [ "Valid-from timestamp with explicit offset", "Valid-until timestamp with explicit offset or absent", "Time line designation" ] }, { "id": "q-vti-missing-end", "text": "When the end boundary is absent, does that mean open-ended, unknown, or not yet decided?", "kind": "definition", "answer_data": [ "Semantics of an absent end boundary", "Distinguishing marker where several meanings are possible" ] }, { "id": "q-vti-scope", "text": "Is the validity interval a property of the subject, of a particular assertion about it, or of one status axis?", "kind": "definition", "answer_data": [ "Scope designation", "Cardinality of intervals per subject", "Relationship to the status axis matrix" ] }, { "id": "q-vti-future", "text": "May validity begin in the future, and what state does the subject hold in the interval before that instant?", "kind": "state", "answer_data": [ "Pre-dating permitted flag", "State held before valid-from", "Publication rules for future-dated validity" ] } ], "data_elements": [ { "id": "de-valid-from", "name": "Valid from", "description": "Real-world instant from which the state or assertion takes effect.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-005", "SRC-003", "SRC-013" ] }, { "id": "de-valid-until", "name": "Valid until", "description": "Real-world instant at or after which the state or assertion ceases to be effective; absence carries a declared meaning.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005", "SRC-013" ] }, { "id": "de-validity-scope", "name": "Validity scope", "description": "Declares whether the interval qualifies the subject, one assertion, or one status axis.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-015", "SRC-005" ] } ], "artifacts": [ { "id": "effective-dating-schedule", "name": "Effective dating schedule", "description": "The ordered set of validity intervals and their associated states for one subject and axis, from which the effective state at any real-world instant can be read.", "media_or_form": [ "Interval schedule (format-neutral)", "Rendered timeline for review" ], "serial": false, "identity_strategy": "Derived governed identifier: subject identifier plus axis identifier; falls back to a ULID assigned by the adopting Dimension. Dates within the schedule are never used as identifiers.", "source_refs": [ "SRC-005", "SRC-013", "SRC-024" ] } ], "inline_only_rationale": null }, { "id": "boundary-precision-and-clock", "name": "Boundary inclusivity, precision, clock and time zone", "description": "Boundary conventions differ between ecosystems and silently corrupt comparisons if left implicit: FHIR states Period boundaries are inclusive, while SQL:2011-style period tables use closed-open intervals. RFC 3339 requires an explicit offset or Z and defines -00:00 for unknown local offset; RFC 9557 adds IANA time-zone annotations and redefines Z as 'UTC known, offset unknown'. RFC 5280 supplies the 99991231235959Z no-expiry convention.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-013", "SRC-024" ], "questions": [ { "id": "q-bpc-inclusive", "text": "Are interval boundaries closed-closed or closed-open, and is that rule stated normatively rather than assumed from the storage engine?", "kind": "constraint", "answer_data": [ "Boundary convention code", "Normative statement location", "Conversion rule when exchanging with the other convention" ] }, { "id": "q-bpc-precision", "text": "To what precision are boundaries recorded, and how is a date-only boundary widened to an instant?", "kind": "measurement", "answer_data": [ "Declared precision", "Date-to-instant widening rule", "Rounding direction at each boundary" ] }, { "id": "q-bpc-noexpiry", "text": "What convention marks 'no well-defined expiry', and is a sentinel value used rather than a null?", "kind": "definition", "answer_data": [ "No-expiry convention", "Sentinel value if used", "Consumer handling instruction" ] }, { "id": "q-bpc-zone", "text": "For a future-dated boundary, is the authoritative local context a fixed UTC offset or a named IANA time zone, and how are zone-rule changes handled?", "kind": "temporal", "answer_data": [ "Offset or named zone designation", "Zone annotation representation", "Recomputation policy when zone rules change" ] }, { "id": "q-bpc-clock", "text": "Which clock stamps record time, is it monotonic, and what inter-system skew is tolerated before a timestamp is rejected?", "kind": "quality", "answer_data": [ "Clock source and synchronisation regime", "Monotonicity guarantee", "Skew tolerance as a duration" ] } ], "data_elements": [ { "id": "de-interval-boundary-convention", "name": "Interval boundary convention", "description": "Declares closed-closed or closed-open boundary semantics for all intervals in scope.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-013", "SRC-024" ] }, { "id": "de-boundary-precision", "name": "Boundary precision", "description": "Declared precision of interval boundaries and the rule for widening coarser values.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-013" ] }, { "id": "de-utc-offset", "name": "UTC offset or zone annotation", "description": "The explicit offset, Z, or IANA time-zone annotation attached to a timestamp.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-002" ] }, { "id": "de-clock-skew-tolerance", "name": "Clock skew tolerance", "description": "Maximum accepted divergence between asserting systems' clocks.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-024" ] } ], "artifacts": [ { "id": "temporal-convention-profile", "name": "Temporal convention profile", "description": "The normative profile fixing boundary inclusivity, precision, offset and zone representation, no-expiry sentinel and clock-skew tolerance for every timestamp governed by this mixin.", "media_or_form": [ "Conformance profile document (format-neutral)", "Machine-checkable validation rules" ], "serial": false, "identity_strategy": "Governed global identifier under the adopting Dimension's namespace with a version token; ULID where no namespace exists.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-013" ] } ], "inline_only_rationale": null }, { "id": "interval-relations-and-continuity", "name": "Interval relations and continuity constraints", "description": "Whether successive status intervals must abut, may leave gaps or may overlap, and which interval relations are used in constraints and queries. OWL-Time supplies the Allen relations (meets, overlaps, during, starts, finishes, equals) and period predicates in SQL:2011-style engines supply the executable equivalents.", "source_refs": [ "SRC-008", "SRC-013", "SRC-024" ], "questions": [ { "id": "q-irc-gap", "text": "Must consecutive intervals on the same axis be contiguous, or are gaps permitted and what does a gap mean?", "kind": "constraint", "answer_data": [ "Contiguity requirement", "Meaning of a gap (no state vs unknown state)", "Validation severity" ] }, { "id": "q-irc-overlap", "text": "May two intervals on the same axis overlap, and if so how is the effective value chosen?", "kind": "decision", "answer_data": [ "Overlap permitted flag", "Resolution rule (most recent, highest precedence, reject)", "Worked examples" ] }, { "id": "q-irc-relations", "text": "Which interval relations are used in constraints and queries, and are they named from a governed vocabulary?", "kind": "interoperability", "answer_data": [ "Relation vocabulary reference", "Relations in active use", "Query predicate mapping" ] }, { "id": "q-irc-degenerate", "text": "How are zero-length and inverted intervals detected and handled?", "kind": "validation", "answer_data": [ "Degenerate-interval rule", "Detection check", "Rejection or correction path" ] } ], "data_elements": [ { "id": "de-interval-relation", "name": "Interval relation", "description": "Named relation between two intervals used in a constraint or query.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008", "SRC-024" ] }, { "id": "de-gap-allowed", "name": "Gap permitted flag", "description": "Whether a gap between consecutive intervals on an axis is legal.", "value_kind": "boolean", "cardinality": "1", "required": true, "source_refs": [ "SRC-008" ] }, { "id": "de-overlap-resolution-rule", "name": "Overlap resolution rule", "description": "Deterministic rule selecting the effective value where intervals overlap.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-024", "SRC-005" ] } ], "artifacts": [ { "id": "validity-continuity-constraint-set", "name": "Validity continuity constraint set", "description": "The machine-checkable constraints governing contiguity, overlap and degeneracy of validity intervals for each status axis.", "media_or_form": [ "Constraint set (format-neutral)", "Validation test fixtures" ], "serial": false, "identity_strategy": "Governed global identifier under the lifecycle-definition namespace with a version token; ULID assigned by the adopting Dimension otherwise.", "source_refs": [ "SRC-008", "SRC-024" ] } ], "inline_only_rationale": null } ] }, { "id": "record-time-and-correction", "name": "Record Time and Correction", "description": "The system time line, and how mistaken or superseded beliefs about the past are corrected without destroying the audit record.", "source_refs": [ "SRC-004", "SRC-014", "SRC-016", "SRC-024" ], "findings": [ { "id": "record-time-and-observation-time", "name": "Record, observation and event time", "description": "Three distinct instants must be separable: when the change happened, when it was observed or asserted, and when the system of record stored it. FHIR separates Provenance.occurred from Provenance.recorded; system-versioned tables maintain row_start/row_end without user control; PROV-O timestamps generation and invalidation separately.", "source_refs": [ "SRC-004", "SRC-014", "SRC-024", "SRC-001" ], "questions": [ { "id": "q-rt-three", "text": "For this transition, what are the event time, the observation or assertion time, and the record time, and are all three retained?", "kind": "temporal", "answer_data": [ "Event timestamp", "Observation timestamp", "Record timestamp", "Retention rule for each" ] }, { "id": "q-rt-authority", "text": "Which system and clock stamp the record time, and is it system-maintained and immutable by users?", "kind": "provenance", "answer_data": [ "Stamping system identifier", "Immutability guarantee", "Control preventing user override" ] }, { "id": "q-rt-inversion", "text": "May record time precede event time, and what does such an inversion indicate?", "kind": "exception", "answer_data": [ "Inversion permitted flag", "Interpretation (future-dated effect vs clock error)", "Detection and handling rule" ] }, { "id": "q-rt-latency", "text": "What ingestion latency between event time and record time is expected, and at what point does latency itself become a defect?", "kind": "measurement", "answer_data": [ "Expected latency distribution", "Latency threshold", "Escalation path" ] } ], "data_elements": [ { "id": "de-event-time", "name": "Event time", "description": "Instant at which the lifecycle change occurred in the world.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-014", "SRC-001" ] }, { "id": "de-observation-time", "name": "Observation or assertion time", "description": "Instant at which the change was observed or asserted by the reporting agent.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-014" ] }, { "id": "de-record-time", "name": "Record time", "description": "System-maintained instant at which the change entered the system of record.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-014", "SRC-024" ] }, { "id": "de-record-time-end", "name": "Record time end", "description": "System-maintained instant at which this row or assertion ceased to be the current belief, enabling as-at reconstruction.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-024" ] } ], "artifacts": [ { "id": "system-time-audit-entry", "name": "System-time audit entry", "description": "The system-maintained record-time envelope around each assertion, from which the state of belief at any past record instant can be reconstructed.", "media_or_form": [ "System-versioned row or equivalent audit entry", "Audit export" ], "serial": true, "identity_strategy": "Authoritative master-system identifier issued by the system of record; otherwise a ULID assigned by the adopting Dimension ordered by record time.", "source_refs": [ "SRC-024", "SRC-014" ] } ], "inline_only_rationale": null }, { "id": "retroactive-correction-and-restatement", "name": "Retroactive correction, amendment and restatement", "description": "Distinguishing a correction (the record was wrong) from an amendment (the world changed) is essential, because only the first invalidates prior reliance. ISO 19135-1 separates clarification, amendment and supersession; PROV-O provides wasRevisionOf; system-versioned tables preserve superseded beliefs for as-of reconstruction.", "source_refs": [ "SRC-004", "SRC-014", "SRC-016", "SRC-017", "SRC-024" ], "questions": [ { "id": "q-rcr-mechanism", "text": "How is a wrong past state corrected without destroying the record of what the system previously believed?", "kind": "provenance", "answer_data": [ "Correction mechanism (new record, never in-place edit)", "Link from correction to corrected record", "Preservation guarantee for the superseded belief" ] }, { "id": "q-rcr-kind", "text": "What distinguishes a correction from an amendment and from a retraction in this model, and does the distinction change downstream obligations?", "kind": "definition", "answer_data": [ "Correction kind code list", "Definitional boundaries", "Downstream obligation per kind" ] }, { "id": "q-rcr-notify", "text": "Which downstream consumers must be told about a retroactive change, through what channel and within what period?", "kind": "process", "answer_data": [ "Consumer register", "Notification channel", "Notification deadline" ] }, { "id": "q-rcr-reconstruct", "text": "Can an as-at reconstruction of any earlier belief be produced on demand, and is that capability routinely tested?", "kind": "validation", "answer_data": [ "Reconstruction procedure", "Test evidence", "Reconstruction retention horizon" ] } ], "data_elements": [ { "id": "de-correction-id", "name": "Correction identifier", "description": "Identifier of a correction, amendment or retraction record.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004", "SRC-016" ] }, { "id": "de-corrects-ref", "name": "Corrected record reference", "description": "Reference from a correction to the assertion or transition it corrects.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-correction-kind", "name": "Correction kind", "description": "Whether the change is a correction, an amendment, a clarification or a retraction.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016", "SRC-014" ] } ], "artifacts": [ { "id": "correction-and-restatement-notice", "name": "Correction and restatement notice", "description": "The published record that a previously asserted state or validity interval has been corrected, stating what changed, from when, and who is affected.", "media_or_form": [ "Notice document (format-neutral)", "Machine-readable change record for downstream consumers" ], "serial": true, "identity_strategy": "Authoritative master-system identifier from the issuing system of record; otherwise a governed IRI under the issuing authority's namespace; otherwise a ULID assigned by the adopting Dimension.", "source_refs": [ "SRC-016", "SRC-004", "SRC-017" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "succession-invalidation-disposition", "name": "Succession, Invalidation and Disposition", "description": "How a subject is replaced, discouraged, invalidated or finally disposed of, and the retroactive and retention consequences of each.", "rationale": "ISO 19135-1 distinguishes superseded from retired and requires both to remain resolvable; OWL 2 makes deprecation an annotation about fitness for use rather than a semantic change; Bitstring Status List separates reversible suspension from irreversible revocation; ISO 15489-1 and GDPR impose disposition and erasure duties at end of life. These are different mechanisms with different consequences and must not be collapsed.", "source_refs": [ "SRC-003", "SRC-006", "SRC-010", "SRC-016", "SRC-017", "SRC-020" ], "layers": [ { "id": "succession-and-deprecation", "name": "Succession and Deprecation", "description": "Replacement chains, current-version resolution, and the discouragement of continued use ahead of withdrawal.", "source_refs": [ "SRC-009", "SRC-010", "SRC-011", "SRC-015", "SRC-016" ], "findings": [ { "id": "supersession-and-replacement-links", "name": "Supersession and replacement links", "description": "The bidirectional links that let a consumer holding an outdated item find its successor. DCMI provides replaces/isReplacedBy, DCAT 3 provides previousVersion/hasCurrentVersion, ADMS provides prev/next/last, ISO 19135-1 changes an item's status from valid to superseded when it is replaced, and RFC 5280 records 'superseded' as a revocation reason.", "source_refs": [ "SRC-003", "SRC-009", "SRC-011", "SRC-015", "SRC-016" ], "questions": [ { "id": "q-srl-link", "text": "Which item supersedes this one, is the link recorded in both directions, and is it dereferenceable?", "kind": "relationship", "answer_data": [ "Superseded-by reference", "Supersedes reference", "Dereferenceability guarantee" ] }, { "id": "q-srl-kind", "text": "Is this a version relation (same thing, new version) or a replacement relation (a different thing taking over the role)?", "kind": "definition", "answer_data": [ "Relation kind code", "Criteria distinguishing version from replacement", "Effect on the subject's identifier" ] }, { "id": "q-srl-effective", "text": "From which instant does supersession take effect, and does the superseded item remain resolvable afterwards?", "kind": "temporal", "answer_data": [ "Supersession effective instant", "Resolvability rule for superseded items", "Reason interpretation for historical data" ] }, { "id": "q-srl-chain", "text": "How is a chain of successive supersessions traversed to reach the current item, and what terminates the traversal?", "kind": "process", "answer_data": [ "Traversal algorithm", "Current-version pointer where maintained", "Cycle detection rule" ] } ], "data_elements": [ { "id": "de-supersedes-ref", "name": "Supersedes reference", "description": "Reference from the successor to the item it replaces.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-015", "SRC-009" ] }, { "id": "de-superseded-by-ref", "name": "Superseded-by reference", "description": "Reference from the replaced item to its successor.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-015", "SRC-011" ] }, { "id": "de-current-version-ref", "name": "Current version reference", "description": "Direct pointer to the item currently in force, short-circuiting chain traversal.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009", "SRC-011" ] }, { "id": "de-supersession-effective", "name": "Supersession effective instant", "description": "Instant from which the successor takes over from the superseded item.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016", "SRC-013" ] } ], "artifacts": [ { "id": "supersession-record", "name": "Supersession record", "description": "The dated record linking a superseded item to its successor, with the reason and the effective instant, retained so that historical data remains interpretable.", "media_or_form": [ "Structured relation record (format-neutral)", "Published register entry" ], "serial": true, "identity_strategy": "Governed global identifier under the register's namespace where the register issues one; otherwise the authoritative master-system identifier of the issuing system; otherwise a ULID assigned by the adopting Dimension.", "source_refs": [ "SRC-016", "SRC-015", "SRC-009" ] } ], "inline_only_rationale": null }, { "id": "deprecation-and-sunset", "name": "Deprecation and sunset", "description": "Deprecation signals that continued use is discouraged without necessarily invalidating existing use. OWL 2 treats owl:deprecated as a non-logical annotation that does not change formal semantics, and pairs it with backwardCompatibleWith and incompatibleWith; the UKGovLD registry places deprecated under accepted, with superseded and retired as its specialisations.", "source_refs": [ "SRC-009", "SRC-010", "SRC-011", "SRC-016", "SRC-022" ], "questions": [ { "id": "q-ds-meaning", "text": "What does deprecated mean operationally here — still valid but discouraged, or invalid for new use while valid for existing use?", "kind": "definition", "answer_data": [ "Operational definition", "Permitted uses while deprecated", "Relationship to the valid/accepted axis" ] }, { "id": "q-ds-sunset", "text": "What sunset date has been announced, and what minimum notice period does the governing policy require?", "kind": "temporal", "answer_data": [ "Announcement instant", "Sunset date", "Minimum notice period" ] }, { "id": "q-ds-migration", "text": "What migration target and guidance are published with the deprecation, and is backward compatibility asserted or denied?", "kind": "interoperability", "answer_data": [ "Migration target reference", "Migration guidance", "Backward-compatibility assertion" ] }, { "id": "q-ds-grandfather", "text": "Are existing uses grandfathered, and until when?", "kind": "exception", "answer_data": [ "Grandfathering rule", "Expiry of grandfathering", "Register of grandfathered uses" ] } ], "data_elements": [ { "id": "de-deprecation-flag", "name": "Deprecation flag", "description": "Marks the subject as deprecated without altering its formal semantics.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010", "SRC-011" ] }, { "id": "de-deprecation-announced-at", "name": "Deprecation announcement instant", "description": "Instant at which deprecation was announced, which starts the notice period.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010", "SRC-015" ] }, { "id": "de-sunset-date", "name": "Sunset date", "description": "Date on or after which the deprecated subject will be withdrawn or retired.", "value_kind": "date", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016", "SRC-010" ] }, { "id": "de-migration-target-ref", "name": "Migration target reference", "description": "Reference to the item consumers should adopt instead.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009", "SRC-011" ] }, { "id": "de-version-notes", "name": "Version notes", "description": "Description of what changed between this version and the previous one, supporting migration decisions.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011", "SRC-010" ] } ], "artifacts": [ { "id": "deprecation-notice", "name": "Deprecation and sunset notice", "description": "The published, dated announcement that a subject is deprecated, stating the sunset date, migration target, compatibility position and grandfathering terms.", "media_or_form": [ "Notice document (format-neutral)", "Machine-readable deprecation annotation on the subject" ], "serial": true, "identity_strategy": "Governed global identifier under the publishing authority's namespace; otherwise the authoritative master-system identifier of the publication system; otherwise a ULID assigned by the adopting Dimension.", "source_refs": [ "SRC-010", "SRC-011", "SRC-016" ] } ], "inline_only_rationale": null }, { "id": "replacement-and-entered-in-error", "name": "Replacement and entered-in-error", "description": "FHIR replaced means information was replaced by another resource; DCMI replaces / isReplacedBy model supersession. entered-in-error is usually not a clinical workflow state but applies to request and entity-availability cycles; handling is business-specific and there are no generic rules for redaction. Replacement is a relationship plus a status, not a silent overwrite.", "source_refs": [ "SRC-025", "SRC-026", "SRC-015" ], "questions": [ { "id": "replacement-and-entered-in-error-q01", "text": "If this status or host is replaced, which resource or binding supersedes it, and is the inverse isReplacedBy asserted?", "kind": "relationship", "answer_data": [ "replacing reference", "replaced reference", "bidirectional boolean" ] }, { "id": "replacement-and-entered-in-error-q02", "text": "Is the host entered-in-error, replaced, retired, or inactive, and why is that distinction required for consumers?", "kind": "classification", "answer_data": [ "outcome code", "consumer instruction" ] }, { "id": "replacement-and-entered-in-error-q03", "text": "Must the erroneous or replaced record be retained for integrity or digital signatures even though it must be ignored?", "kind": "retention", "answer_data": [ "retain boolean", "integrity reason", "redaction applied boolean" ] } ], "data_elements": [ { "id": "replacement-and-entered-in-error-data01", "name": "Replaced-by reference", "description": "The binding or host that supersedes this one.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-015", "SRC-026" ] }, { "id": "replacement-and-entered-in-error-data02", "name": "Replaces reference", "description": "The binding or host this one supersedes.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-015" ] }, { "id": "replacement-and-entered-in-error-data03", "name": "Retain for integrity", "description": "True when deletion is forbidden despite error or replacement.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-025" ] } ], "artifacts": [], "inline_only_rationale": "Replacement links are references; the entered-in-error record artefact already covers accidental creation." } ] }, { "id": "invalidation", "name": "Invalidation", "description": "Revocation and suspension, their reversibility, their dating and their retroactive effect on acts already performed.", "source_refs": [ "SRC-003", "SRC-004", "SRC-005", "SRC-006" ], "findings": [ { "id": "revocation-and-suspension", "name": "Revocation versus suspension", "description": "Bitstring Status List states that revocation cancels validity and is not reversible while suspension temporarily prevents acceptance and is reversible; RFC 5280 makes the same distinction operationally through certificateHold and removeFromCRL. Treating them as one 'inactive' state destroys the reversibility contract relying parties depend on.", "source_refs": [ "SRC-003", "SRC-005", "SRC-006", "SRC-012" ], "questions": [ { "id": "q-rs-kind", "text": "Is this invalidation reversible (suspension) or irreversible (revocation), and where is that reversibility contract stated?", "kind": "lifecycle", "answer_data": [ "Invalidation kind code", "Reversibility statement location", "Procedure for reversal where permitted" ] }, { "id": "q-rs-communicate", "text": "How is invalidation communicated to relying parties who already hold a copy of the subject, and how fresh must that information be before reliance is permitted?", "kind": "interoperability", "answer_data": [ "Status distribution mechanism", "Maximum tolerated staleness", "Behaviour when status cannot be obtained" ] }, { "id": "q-rs-message", "text": "What reason code and human-readable status message accompany the invalidation, and can several statuses apply at once?", "kind": "classification", "answer_data": [ "Reason code", "Status message text", "Multi-status representation rule" ] }, { "id": "q-rs-artifacts", "text": "What happens to obligations, permissions and artifacts issued while the subject was valid?", "kind": "constraint", "answer_data": [ "Treatment of prior issuances", "Cascade rules to dependent subjects", "Exceptions preserved by law or contract" ] } ], "data_elements": [ { "id": "de-invalidation-kind", "name": "Invalidation kind", "description": "Whether the invalidation is a reversible suspension or an irreversible revocation.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-006", "SRC-003" ] }, { "id": "de-status-purpose", "name": "Status purpose", "description": "The purpose a published status entry serves, such as revocation, suspension, message or refresh.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "de-status-message", "name": "Status message", "description": "Human-readable message associated with a multi-valued status entry.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "de-status-freshness", "name": "Maximum status staleness", "description": "The longest period for which a cached status may be relied upon.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006", "SRC-003" ] } ], "artifacts": [ { "id": "invalidation-decision-record", "name": "Invalidation decision record", "description": "The dated, attributed decision to revoke or suspend, carrying the reason code, the reversibility class, the effective instant and the cascade instructions.", "media_or_form": [ "Decision record (format-neutral)", "Signed rendering where non-repudiation is required" ], "serial": true, "identity_strategy": "Authoritative master-system identifier of the issuing authority's system; otherwise a governed IRI under that authority's namespace; otherwise a ULID assigned by the adopting Dimension.", "source_refs": [ "SRC-003", "SRC-006", "SRC-004" ] } ], "inline_only_rationale": null }, { "id": "invalidity-dating-and-retroactive-effect", "name": "Invalidity dating and retroactive effect", "description": "RFC 5280's invalidityDate records the instant on which it is known or suspected that the subject became invalid, which may precede the decision and the publication. PROV-O's invalidatedAtTime records the same idea generically. The gap between those instants is where risk is allocated.", "source_refs": [ "SRC-003", "SRC-004", "SRC-014", "SRC-016" ], "questions": [ { "id": "q-ide-instant", "text": "From which instant is the subject considered invalid — the decision instant, the publication instant, or an earlier known-or-suspected instant?", "kind": "temporal", "answer_data": [ "Invalidity instant", "Decision instant", "Publication instant", "Rule selecting the governing instant" ] }, { "id": "q-ide-retro", "text": "Does invalidation apply retroactively to acts performed before the decision was published, and on what legal or policy basis?", "kind": "constraint", "answer_data": [ "Retroactivity flag", "Basis for retroactivity", "Scope of affected acts" ] }, { "id": "q-ide-suspicion", "text": "How is known invalidity distinguished from suspected invalidity, and does the distinction change the recorded instant?", "kind": "quality", "answer_data": [ "Confidence qualifier", "Evidence threshold for each level", "Revision path when suspicion is confirmed or cleared" ] }, { "id": "q-ide-risk", "text": "Who bears the risk for reliance occurring between the invalidity instant and the publication instant?", "kind": "ownership", "answer_data": [ "Risk allocation statement", "Notification obligations", "Compensating controls" ] } ], "data_elements": [ { "id": "de-invalidity-date", "name": "Invalidity instant", "description": "Instant on which the subject is known or suspected to have become invalid, which may precede the decision.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003", "SRC-004" ] }, { "id": "de-decision-time", "name": "Decision instant", "description": "Instant at which the invalidation decision was taken.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-014", "SRC-003" ] }, { "id": "de-publication-time", "name": "Publication instant", "description": "Instant at which the invalidation became discoverable by relying parties.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003", "SRC-006" ] }, { "id": "de-retroactive-effect-flag", "name": "Retroactive effect flag", "description": "Whether the invalidation reaches back to acts performed before publication.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003", "SRC-016" ] } ], "artifacts": [ { "id": "invalidity-dating-statement", "name": "Invalidity dating statement", "description": "The record fixing invalidity, decision and publication instants for one invalidation, together with the retroactivity ruling and risk allocation.", "media_or_form": [ "Structured statement (format-neutral)", "Published notice to relying parties" ], "serial": true, "identity_strategy": "Cross-referenced to the invalidation decision identifier; independently identified by the issuing system's master identifier or, failing that, a ULID assigned by the adopting Dimension.", "source_refs": [ "SRC-003", "SRC-004" ] } ], "inline_only_rationale": null } ] }, { "id": "end-of-life", "name": "End of Life", "description": "Lifecycle end as the trigger for retention, disposition, logical deletion and erasure.", "source_refs": [ "SRC-016", "SRC-017", "SRC-020", "SRC-021" ], "findings": [ { "id": "retention-trigger-and-disposition", "name": "Retention trigger and disposition authority", "description": "ISO 15489-1 requires disposition authorities to be authorised, dated, implemented and regularly reviewed, with retention decided by recurrent appraisal rather than case by case; NARA's GRS shows disposition authority issued and versioned externally. This mixin supplies only the trigger, the clock and the resulting state.", "source_refs": [ "SRC-016", "SRC-017", "SRC-020", "SRC-021" ], "questions": [ { "id": "q-rtd-trigger", "text": "Which lifecycle state or transition starts the retention clock, and how long does retention then run?", "kind": "retention", "answer_data": [ "Trigger state or event code", "Retention period as a duration", "Computed disposition due date" ] }, { "id": "q-rtd-authority", "text": "Which authority approved the disposition rule, when was it approved, and when is it next due for review?", "kind": "authority", "answer_data": [ "Disposition authority reference", "Approval date", "Next review date" ] }, { "id": "q-rtd-action", "text": "What action follows expiry — destroy, transfer, retain permanently, or re-appraise — and who executes it?", "kind": "process", "answer_data": [ "Disposition action code", "Executing role", "Evidence produced by execution" ] }, { "id": "q-rtd-hold", "text": "How is disposition suspended by a legal hold, who may impose and release it, and how is the suspension recorded?", "kind": "exception", "answer_data": [ "Legal hold flag and scope", "Imposing and releasing authority", "Hold record reference" ] } ], "data_elements": [ { "id": "de-retention-trigger-event", "name": "Retention trigger event", "description": "The lifecycle state or transition that starts the retention clock.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017", "SRC-021" ] }, { "id": "de-retention-period", "name": "Retention period", "description": "Duration for which the subject must be retained after the trigger.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017", "SRC-020" ] }, { "id": "de-disposition-action", "name": "Disposition action", "description": "The action due at expiry, such as destroy, transfer, retain permanently or re-appraise.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-021", "SRC-017" ] }, { "id": "de-disposition-authority-ref", "name": "Disposition authority reference", "description": "Reference to the authorised, dated instrument permitting the disposition.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017", "SRC-021" ] }, { "id": "de-legal-hold-flag", "name": "Legal hold flag", "description": "Suspends disposition regardless of the computed due date.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017", "SRC-020" ] } ], "artifacts": [ { "id": "disposition-authority-and-action-record", "name": "Disposition authority and action record", "description": "The record binding a subject's lifecycle end to an authorised disposition instrument, the computed due date, any hold, and the executed action.", "media_or_form": [ "Structured disposition record (format-neutral)", "Signed action confirmation" ], "serial": true, "identity_strategy": "Authoritative master-system identifier from the records system; otherwise the governed identifier of the disposition instrument plus a subject reference; otherwise a ULID assigned by the adopting Dimension.", "source_refs": [ "SRC-017", "SRC-021" ] } ], "inline_only_rationale": null }, { "id": "logical-deletion-and-erasure", "name": "Logical deletion, tombstones and erasure", "description": "ISO 19135-1 keeps retired, superseded and invalid items in the register so earlier data stays interpretable, while GDPR Article 17 can require erasure of personal data and Article 5(1)(e) limits storage. The reconciliation is a tombstone: a minimal, non-personal residue that keeps references resolvable.", "source_refs": [ "SRC-004", "SRC-014", "SRC-016", "SRC-017", "SRC-020" ], "questions": [ { "id": "q-lde-mode", "text": "Is deletion logical (retired status plus tombstone) or physical, and which mode applies to which class of content?", "kind": "definition", "answer_data": [ "Deletion mode per content class", "Criteria for physical destruction", "Reversibility statement" ] }, { "id": "q-lde-erasure", "text": "How is an erasure obligation reconciled with an append-only lifecycle history, and what is removed versus what is retained?", "kind": "privacy", "answer_data": [ "Erasure scope decision", "Fields removed and fields retained", "Legal basis for any retention despite erasure" ] }, { "id": "q-lde-tombstone", "text": "What minimum tombstone remains after deletion so that inbound references still resolve rather than dangle?", "kind": "interoperability", "answer_data": [ "Tombstone content specification", "Response semantics for a resolved tombstone", "Guarantee that the identifier is never reused" ] }, { "id": "q-lde-evidence", "text": "Who authorises and witnesses destruction, and what evidence of destruction is retained and for how long?", "kind": "evidence", "answer_data": [ "Authorising role", "Witness or dual-control requirement", "Destruction certificate retention period" ] } ], "data_elements": [ { "id": "de-deletion-mode", "name": "Deletion mode", "description": "Whether the subject is logically retired with a tombstone or physically destroyed.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016", "SRC-020" ] }, { "id": "de-tombstone-record", "name": "Tombstone record", "description": "The minimal residue left after deletion so that identifiers remain resolvable without exposing removed content.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016", "SRC-014" ] }, { "id": "de-erasure-request-ref", "name": "Erasure request reference", "description": "Reference to the request or obligation that triggered erasure.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-020" ] }, { "id": "de-destruction-certificate-ref", "name": "Destruction certificate reference", "description": "Reference to the evidence that destruction was carried out under authority.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017", "SRC-021" ] } ], "artifacts": [ { "id": "destruction-or-erasure-certificate", "name": "Destruction or erasure certificate", "description": "The retained evidence that content was destroyed or erased under a named authority at a stated instant, together with the tombstone left in its place.", "media_or_form": [ "Certificate document (format-neutral)", "Tombstone record published in place of the deleted subject" ], "serial": true, "identity_strategy": "Authoritative master-system identifier from the records or privacy system; otherwise a ULID assigned by the adopting Dimension. The certificate identifier must not encode personal data.", "source_refs": [ "SRC-017", "SRC-020", "SRC-021" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "operations-and-interoperability", "name": "Operations, Exposure and Interoperability", "description": "The executable surface: how transitions are requested and rejected, how state is queried across both time lines, how exceptions are handled, and how status is mapped, published and access-controlled.", "rationale": "A lifecycle model that cannot be operated deterministically or exchanged without loss is not usable by an agent. SCXML fixes deterministic execution semantics, system-versioned tables fix as-of querying, FHIR supplies an explicit 'unknown' code for indeterminate status, and Bitstring Status List supplies distribution and privacy considerations for published status.", "source_refs": [ "SRC-006", "SRC-007", "SRC-012", "SRC-024" ], "layers": [ { "id": "lifecycle-operations", "name": "Lifecycle Operations", "description": "Requesting and applying transitions, resolving state across both time lines, and handling exceptions.", "source_refs": [ "SRC-007", "SRC-012", "SRC-024" ], "findings": [ { "id": "transition-execution-contract", "name": "Transition execution contract", "description": "The operational guarantees around applying a transition: idempotency, optimistic concurrency against an expected current state, atomicity with mandated effects, and the recording of rejections. SCXML's serialised microstep processing is the reference for determinism despite concurrency.", "source_refs": [ "SRC-007", "SRC-024", "SRC-014" ], "questions": [ { "id": "q-tec-idempotency", "text": "What is the idempotency key for a transition request, and what exactly happens when the same request is replayed?", "kind": "process", "answer_data": [ "Idempotency key definition", "Replay response semantics", "Key retention window" ] }, { "id": "q-tec-concurrency", "text": "How is a lost update prevented when two agents attempt to transition the same subject at the same time?", "kind": "constraint", "answer_data": [ "Expected-current-state precondition", "Concurrency control mechanism", "Conflict response" ] }, { "id": "q-tec-atomicity", "text": "Is the state change atomic with its mandated effects, or eventually consistent, and what compensates a partial failure?", "kind": "quality", "answer_data": [ "Consistency model", "Compensation procedure", "Observable intermediate states" ] }, { "id": "q-tec-rejection", "text": "What is returned when a transition is rejected, and is the rejection itself recorded as evidence?", "kind": "exception", "answer_data": [ "Rejection outcome code", "Rejection reason detail", "Whether rejections are logged and for how long" ] } ], "data_elements": [ { "id": "de-transition-request-id", "name": "Transition request identifier", "description": "Identifier of a request to change state, distinct from the resulting event identifier.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-007", "SRC-014" ] }, { "id": "de-idempotency-key", "name": "Idempotency key", "description": "Key by which duplicate transition requests are recognised and collapsed.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "de-expected-current-state", "name": "Expected current state", "description": "The state the caller believes the subject occupies, used as an optimistic concurrency precondition.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-024", "SRC-007" ] }, { "id": "de-transition-outcome", "name": "Transition outcome", "description": "Whether the request was applied, rejected, or collapsed as a duplicate, with the reason.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-007", "SRC-014" ] } ], "artifacts": [ { "id": "transition-request-outcome-record", "name": "Transition request and outcome record", "description": "The record of a transition request, its preconditions, its outcome and any rejection reason, retained as evidence of attempted as well as successful changes.", "media_or_form": [ "Request/outcome log entry (format-neutral)", "Audit export" ], "serial": true, "identity_strategy": "Authoritative master-system identifier from the operating system of record; otherwise a ULID assigned by the adopting Dimension, linked to the idempotency key.", "source_refs": [ "SRC-007", "SRC-014" ] } ], "inline_only_rationale": null }, { "id": "temporal-state-resolution-queries", "name": "Bitemporal state resolution and reproducibility", "description": "Answering 'what was the state?' requires two parameters, not one: the real-world instant of interest and the record instant at which belief is taken. System-versioned tables expose exactly this through AS OF and BETWEEN queries; without both, audit answers are not reproducible.", "source_refs": [ "SRC-008", "SRC-013", "SRC-024", "SRC-001" ], "questions": [ { "id": "q-tsr-two", "text": "What was the state as of a given real-world instant, as known at a given record instant?", "kind": "temporal", "answer_data": [ "As-of valid instant parameter", "As-at record instant parameter", "Resolved state and the interval that produced it" ] }, { "id": "q-tsr-default", "text": "Which defaults apply when the caller supplies neither instant, and are those defaults stated rather than implied?", "kind": "decision", "answer_data": [ "Default valid instant", "Default record instant", "Location of the normative default statement" ] }, { "id": "q-tsr-repro", "text": "Is the same query guaranteed to return the same answer later, and how is that reproducibility demonstrated to an auditor?", "kind": "validation", "answer_data": [ "Reproducibility guarantee and its horizon", "Test evidence", "Conditions under which reproducibility is lost" ] }, { "id": "q-tsr-listing", "text": "How are subjects listed or filtered by status without disclosing states the caller is not permitted to see?", "kind": "access", "answer_data": [ "Filtering rule", "Permission-aware result trimming", "Behaviour on partially permitted result sets" ] } ], "data_elements": [ { "id": "de-as-of-valid-instant", "name": "As-of valid instant", "description": "The real-world instant for which state is being resolved.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-024", "SRC-001" ] }, { "id": "de-as-at-record-instant", "name": "As-at record instant", "description": "The record instant defining which state of belief is used to answer the query.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-024" ] }, { "id": "de-resolved-state", "name": "Resolved state", "description": "The state returned for the supplied instant pair, together with the interval and assertion that produced it.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-013", "SRC-024" ] } ], "artifacts": [ { "id": "as-of-state-snapshot", "name": "As-of state snapshot", "description": "A reproducible, citable answer to a bitemporal state question, recording both instants, the resolved state and the assertions relied upon.", "media_or_form": [ "Snapshot record (format-neutral)", "Audit-ready export" ], "serial": true, "identity_strategy": "ULID assigned by the adopting Dimension incorporating the subject reference; where the query service issues result identifiers, those take priority. The queried instants are parameters, never identifiers.", "source_refs": [ "SRC-024", "SRC-008" ] } ], "inline_only_rationale": null }, { "id": "exception-and-illegal-transition-handling", "name": "Exceptions, indeterminate status and staleness", "description": "Real registries contain states that no longer exist in the current definition, subjects whose status is genuinely unknown, and subjects stuck in a state far longer than expected. FHIR provides an explicit 'unknown' code precisely so that indeterminacy is not encoded as a null or as a real state.", "source_refs": [ "SRC-007", "SRC-012", "SRC-017", "SRC-018" ], "questions": [ { "id": "q-eih-orphan", "text": "What happens when a recorded state is not in the state set of the governing lifecycle version?", "kind": "exception", "answer_data": [ "Detection rule", "Disposition (quarantine, map, reject)", "Accountable role for remediation" ] }, { "id": "q-eih-unknown", "text": "How is indeterminate status represented so that it is not mistaken for a real state or for an absent record?", "kind": "definition", "answer_data": [ "Indeterminate status code", "Consumer handling instruction", "Rule for resolving indeterminacy" ] }, { "id": "q-eih-stale", "text": "How is a stale status detected — no transition for longer than the expected dwell time — and to whom is it escalated?", "kind": "quality", "answer_data": [ "Expected dwell time per state", "Staleness threshold", "Escalation path and owner" ] }, { "id": "q-eih-override", "text": "Is an emergency override of the transition rules permitted, who may authorise it, and what compensating controls and review apply?", "kind": "authority", "answer_data": [ "Override permitted flag", "Authorising role", "Compensating controls", "Mandatory post-hoc review" ] } ], "data_elements": [ { "id": "de-exception-code", "name": "Lifecycle exception code", "description": "Classification of a lifecycle anomaly such as an unknown state, an illegal transition or a stale subject.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-012" ] }, { "id": "de-staleness-threshold", "name": "Staleness threshold", "description": "Maximum expected dwell time in a state before the subject is flagged as stale.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017" ] }, { "id": "de-override-authorization-ref", "name": "Override authorisation reference", "description": "Reference to the approval permitting an out-of-model transition.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017", "SRC-018" ] } ], "artifacts": [ { "id": "lifecycle-exception-register-entry", "name": "Lifecycle exception register entry", "description": "The recorded anomaly — unknown state, illegal transition, staleness or override — with its detection instant, owner, remediation and closure.", "media_or_form": [ "Exception register entry (format-neutral)", "Escalation report" ], "serial": true, "identity_strategy": "Authoritative master-system identifier from the exception or incident system; otherwise a ULID assigned by the adopting Dimension.", "source_refs": [ "SRC-017", "SRC-012" ] } ], "inline_only_rationale": null } ] }, { "id": "status-interoperability", "name": "Status Interoperability and Exposure", "description": "Mapping local states to external vocabularies, publishing status to relying parties, and controlling who may see which states.", "source_refs": [ "SRC-006", "SRC-011", "SRC-012", "SRC-016", "SRC-022" ], "findings": [ { "id": "external-status-vocabulary-mapping", "name": "External status vocabulary mapping", "description": "Local states must be mapped, with declared strength and declared loss, to external vocabularies such as FHIR PublicationStatus, ISO 19135-1 item status, ADMS status and schema.org EventStatusType. The UKGovLD registry demonstrates the practice of stating explicit correspondences to ISO 19135 statuses rather than assuming them.", "source_refs": [ "SRC-011", "SRC-012", "SRC-016", "SRC-022", "SRC-023" ], "questions": [ { "id": "q-esm-targets", "text": "To which external status vocabularies is each local state mapped, at which version of each target, and with what mapping strength?", "kind": "interoperability", "answer_data": [ "Target vocabulary identifier and version", "Per-state target code", "Mapping strength (equivalent, broader, narrower, related, unmatched)" ] }, { "id": "q-esm-loss", "text": "Which mappings are lossy, and precisely what information is lost in each direction?", "kind": "quality", "answer_data": [ "Lossy mapping list", "Information lost per direction", "Compensating annotation carried alongside" ] }, { "id": "q-esm-conflict", "text": "Where external vocabularies conflict, is the conflict recorded rather than silently reconciled?", "kind": "exception", "answer_data": [ "Recorded conflict entries", "Chosen interpretation and its justification", "Statement that alignment, not conformance, is claimed" ] }, { "id": "q-esm-maintenance", "text": "Who maintains each mapping, and when was it last revalidated against the current version of the target vocabulary?", "kind": "ownership", "answer_data": [ "Mapping custodian", "Last revalidation date", "Revalidation cadence" ] } ], "data_elements": [ { "id": "de-mapping-id", "name": "Mapping identifier", "description": "Identifier of one mapping set between the local state vocabulary and an external vocabulary version.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012", "SRC-022" ] }, { "id": "de-mapping-relationship", "name": "Mapping relationship", "description": "The strength of correspondence between a local state and an external code.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012", "SRC-016" ] }, { "id": "de-mapping-target-version", "name": "Mapped target version", "description": "The exact version of the external vocabulary the mapping was validated against.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012", "SRC-023" ] } ], "artifacts": [ { "id": "status-concept-mapping-table", "name": "Status concept mapping table", "description": "The versioned, custodian-owned table mapping every local state to external status vocabularies, with mapping strength, loss notes and recorded conflicts.", "media_or_form": [ "Concept mapping table (format-neutral)", "Published crosswalk for external consumers" ], "serial": false, "identity_strategy": "Governed global identifier under the adopting Dimension's namespace, versioned; the authoritative master-system identifier of a terminology service takes priority where one manages the map.", "source_refs": [ "SRC-012", "SRC-016", "SRC-022" ] } ], "inline_only_rationale": null }, { "id": "status-publication-and-visibility", "name": "Status publication, distribution and visibility", "description": "How status reaches relying parties and who is entitled to see which states. Bitstring Status List addresses distribution and herd-privacy sizing; RFC 5280 addresses CRL distribution and freshness; ISO 15489-1 requires access and security controls over records. Draft and pre-publication states routinely carry stricter visibility than published ones.", "source_refs": [ "SRC-003", "SRC-006", "SRC-012", "SRC-017", "SRC-020" ], "questions": [ { "id": "q-spv-channel", "text": "In what form is status published — pull, push, or embedded in the subject — and what is the authoritative source if several channels exist?", "kind": "interoperability", "answer_data": [ "Publication channel list", "Authoritative channel designation", "Update cadence" ] }, { "id": "q-spv-freshness", "text": "How stale may published status be before a relying party must refuse to rely on it, and what should it do when status is unobtainable?", "kind": "constraint", "answer_data": [ "Maximum staleness duration", "Fail-open or fail-closed rule", "Fallback behaviour" ] }, { "id": "q-spv-integrity", "text": "How is published status protected against tampering, replay and rollback to an earlier state?", "kind": "security", "answer_data": [ "Integrity mechanism", "Freshness or anti-rollback marker", "Verification procedure for consumers" ] }, { "id": "q-spv-visibility", "text": "Who may see subjects in pre-publication states, and are transition reasons restricted more tightly than the state value itself?", "kind": "access", "answer_data": [ "Visibility class per state", "Separate access class for justification text", "Audience scope definitions" ] }, { "id": "q-spv-privacy", "text": "Does publishing status disclose information about individual subjects, and what minimum group size or padding protects them?", "kind": "privacy", "answer_data": [ "Disclosure analysis", "Minimum group size or list size", "Padding or randomisation measures" ] } ], "data_elements": [ { "id": "de-publication-channel", "name": "Publication channel", "description": "The mechanism by which status is made available to relying parties.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006", "SRC-003" ] }, { "id": "de-publication-instant", "name": "Publication instant", "description": "Instant at which the current published status became available.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003", "SRC-001" ] }, { "id": "de-visibility-class", "name": "Visibility class", "description": "Access classification of a state value or its justification, controlling who may read it.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017", "SRC-020" ] }, { "id": "de-integrity-proof", "name": "Integrity proof", "description": "Evidence protecting a published status projection against tampering or rollback.", "value_kind": "binary", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006", "SRC-003" ] } ], "artifacts": [ { "id": "published-status-package", "name": "Published status package", "description": "The distributable projection of status for a population of subjects, carrying its publication instant, validity window, integrity proof and privacy sizing.", "media_or_form": [ "Published status list or revocation list (format-neutral)", "Embedded status reference on the subject" ], "serial": true, "identity_strategy": "Governed global identifier: the publication endpoint IRI plus a monotonically increasing edition token; the issuing system's master identifier takes priority. The publication instant is metadata, never the identifier.", "source_refs": [ "SRC-006", "SRC-003" ] } ], "inline_only_rationale": null } ] } ] } ] }, "functions": [ { "id": "resolve-effective-state", "name": "Resolve effective state", "description": "Return the state of a subject on a named axis for a given real-world instant, as believed at a given record instant, together with the interval and assertion that produced the answer.", "inputs": [ "Subject reference", "Status axis identifier", "As-of valid instant (default: request instant)", "As-at record instant (default: latest)" ], "outputs": [ "Resolved state code", "Governing validity interval", "Assertion and transition event references", "Lifecycle definition version used" ], "preconditions": [ "The subject is bound to a lifecycle definition version", "At least one state assertion exists, or an explicit indeterminate status is returned" ], "effects": [ "No state change; read-only", "May emit a reproducible as-of state snapshot for audit" ], "source_refs": [ "SRC-013", "SRC-024", "SRC-008", "SRC-001" ] }, { "id": "evaluate-transition", "name": "Evaluate transition legality", "description": "Determine, without applying anything, whether a proposed transition is permitted: source state matches, transition is declared, guard holds, and the caller holds the required authority.", "inputs": [ "Subject reference", "Proposed target state or trigger", "Caller identity and authority basis", "Evaluation instant" ], "outputs": [ "Permitted or refused verdict", "Failing precondition detail", "Selected transition identifier when several match" ], "preconditions": [ "A lifecycle definition version is in force for the subject" ], "effects": [ "No state change", "Evaluation may be logged for audit without creating a transition event" ], "source_refs": [ "SRC-007", "SRC-019", "SRC-018" ] }, { "id": "apply-transition", "name": "Apply transition", "description": "Record a state change: append an immutable transition event, close the prior validity interval, open the new one, execute mandated effects and update any materialised current state.", "inputs": [ "Subject reference", "Selected transition identifier", "Reason code and justification", "Event time and expected current state", "Idempotency key" ], "outputs": [ "Transition event identifier", "New current state", "Outcome code (applied, rejected, duplicate)" ], "preconditions": [ "Transition evaluated as permitted", "Expected current state matches actual current state", "Event time conforms to the temporal convention profile" ], "effects": [ "Appends to the append-only transition log", "Sets record time from the system clock, not from caller input", "Triggers mandated effects atomically or with declared compensation" ], "source_refs": [ "SRC-007", "SRC-014", "SRC-024" ] }, { "id": "assert-validity-period", "name": "Assert or adjust validity period", "description": "Set or adjust the real-world validity interval of a state or assertion independently of the status value, honouring boundary and precision conventions.", "inputs": [ "Subject reference", "Status axis identifier", "Valid-from and optional valid-until with explicit offset or zone annotation", "Reason for adjustment" ], "outputs": [ "Updated validity interval", "Continuity validation result" ], "preconditions": [ "Boundary convention and precision are declared in the temporal convention profile", "Adjustment does not violate contiguity or overlap constraints unless an exception is authorised" ], "effects": [ "Creates a new assertion rather than editing the previous one", "May change the derived effective status without any status transition" ], "source_refs": [ "SRC-005", "SRC-003", "SRC-013", "SRC-015" ] }, { "id": "supersede-subject", "name": "Supersede subject", "description": "Record that a subject has been replaced by a successor: set the superseded state, write bidirectional links and fix the effective instant, keeping the superseded item resolvable.", "inputs": [ "Superseded subject reference", "Successor reference", "Supersession effective instant", "Relation kind (version or replacement)" ], "outputs": [ "Supersession record identifier", "Updated state on both items", "Current-version pointer" ], "preconditions": [ "Successor exists and is itself in a valid state", "Supersession is a declared transition for the current state" ], "effects": [ "Changes status from valid to superseded on the replaced item", "Retains the replaced item for interpretation of historical data" ], "source_refs": [ "SRC-016", "SRC-015", "SRC-009", "SRC-011" ] }, { "id": "deprecate-subject", "name": "Deprecate subject with sunset", "description": "Mark a subject as discouraged for new use, publish the sunset date, migration target and compatibility position, without changing its formal semantics.", "inputs": [ "Subject reference", "Sunset date", "Migration target reference", "Compatibility assertion and version notes" ], "outputs": [ "Deprecation notice identifier", "Deprecation annotation on the subject" ], "preconditions": [ "Minimum notice period satisfied by the announced sunset date", "A migration target exists or its absence is explicitly justified" ], "effects": [ "Adds a non-logical deprecation annotation", "Starts the notice clock leading to retirement or supersession" ], "source_refs": [ "SRC-010", "SRC-011", "SRC-009", "SRC-016" ] }, { "id": "invalidate-subject", "name": "Revoke or suspend subject", "description": "Apply an invalidation with an explicit reversibility class, reason code, invalidity instant and retroactivity ruling, and queue it for publication to relying parties.", "inputs": [ "Subject reference", "Invalidation kind (revocation or suspension)", "Reason code", "Invalidity instant and decision instant", "Retroactivity ruling" ], "outputs": [ "Invalidation decision record identifier", "Updated status and status-list entry", "Cascade instructions for dependent subjects" ], "preconditions": [ "Caller holds the authority declared for this invalidation kind", "Irreversible revocation is not applied where the governing policy requires suspension first" ], "effects": [ "Changes effective status independently of the validity interval", "Schedules publication of the new status", "May trigger cascading invalidation of dependent subjects" ], "source_refs": [ "SRC-003", "SRC-006", "SRC-005", "SRC-004" ] }, { "id": "reinstate-subject", "name": "Reinstate subject", "description": "Return a subject from a reversible non-valid state to a valid state, recording the grounds, the authority and whether a new validity interval is opened.", "inputs": [ "Subject reference", "Reinstatement grounds and evidence", "Effective instant", "Interval policy (reopen prior interval or open new)" ], "outputs": [ "Reinstatement decision record identifier", "Updated state and validity interval" ], "preconditions": [ "Current state is declared reversible", "Reinstatement is a declared transition and the caller holds the required authority" ], "effects": [ "Removes the subject from suspension listings on the next publication", "Leaves the original suspension event permanently in the history" ], "source_refs": [ "SRC-003", "SRC-006", "SRC-017" ] }, { "id": "correct-past-record", "name": "Correct or amend a past record", "description": "Issue a correction, clarification, amendment or retraction of an earlier assertion without editing it in place, preserving the earlier belief for as-at reconstruction.", "inputs": [ "Target assertion or transition reference", "Correction kind", "Corrected values", "Grounds and authorising agent" ], "outputs": [ "Correction record identifier", "Notification list for affected consumers" ], "preconditions": [ "The original record remains retrievable", "The correction kind is drawn from the governed code list" ], "effects": [ "Appends a new record and closes the record-time envelope of the prior belief", "Never deletes or rewrites the superseded assertion", "May oblige notification of downstream consumers within a stated period" ], "source_refs": [ "SRC-004", "SRC-014", "SRC-016", "SRC-024" ] }, { "id": "validate-lifecycle-conformance", "name": "Validate lifecycle conformance", "description": "Check a subject's recorded state history against the governing definition version: legal transitions only, no unknown states, interval continuity respected, timestamps conforming to the temporal profile.", "inputs": [ "Subject reference or population selector", "Lifecycle definition version", "Validation rule set" ], "outputs": [ "Conformance result per subject", "Violation details", "Conformance validation report" ], "preconditions": [ "A lifecycle definition version and constraint set are published", "Subjects are bound to a definition version" ], "effects": [ "Produces retained evidence of validation", "May raise lifecycle exception register entries; does not itself change state" ], "source_refs": [ "SRC-007", "SRC-018", "SRC-016", "SRC-017" ] }, { "id": "evaluate-disposition-trigger", "name": "Evaluate disposition trigger", "description": "Compute whether a subject has reached the end of its retention period following a lifecycle trigger, and what disposition action is due, respecting any legal hold.", "inputs": [ "Subject reference", "Retention trigger event", "Retention period and disposition authority reference", "Legal hold state" ], "outputs": [ "Disposition due date", "Eligibility verdict", "Due disposition action" ], "preconditions": [ "An authorised, dated disposition instrument is referenced", "The trigger event is recorded in the transition log" ], "effects": [ "No destruction occurs; the function only determines eligibility", "Suspends eligibility while a legal hold is in force" ], "source_refs": [ "SRC-017", "SRC-021", "SRC-020" ] }, { "id": "execute-disposition", "name": "Execute disposition", "description": "Carry out the due disposition action — destroy, transfer, retain permanently or re-appraise — and leave the required tombstone and evidence.", "inputs": [ "Subject reference", "Authorised disposition action", "Authorising and witnessing agents", "Tombstone specification" ], "outputs": [ "Destruction or erasure certificate", "Tombstone record", "Final lifecycle state" ], "preconditions": [ "Eligibility verified and no legal hold in force", "Authorisation and any dual-control requirement satisfied" ], "effects": [ "Irreversibly removes content where the action is destruction", "Leaves references resolvable through the tombstone", "Retains destruction evidence for the period required by the governing authority" ], "source_refs": [ "SRC-017", "SRC-021", "SRC-020", "SRC-016" ] }, { "id": "publish-status-projection", "name": "Publish status projection", "description": "Produce and distribute the current status projection for a population of subjects, with its publication instant, maximum staleness, integrity proof and privacy sizing.", "inputs": [ "Population selector", "Publication channel", "Maximum staleness policy", "Privacy sizing parameters" ], "outputs": [ "Published status package", "Publication instant and next expected update", "Integrity proof" ], "preconditions": [ "Statuses to be published are resolved and conformant", "Privacy analysis completed for the population" ], "effects": [ "Makes status externally observable; the act of publication is itself recorded", "May reveal population membership if sizing is inadequate" ], "source_refs": [ "SRC-006", "SRC-003", "SRC-012" ] }, { "id": "map-external-status", "name": "Map external status", "description": "Translate a state between the local vocabulary and a named external vocabulary version, returning the mapping strength and any information lost.", "inputs": [ "Source state code and vocabulary version", "Target vocabulary identifier and version", "Mapping direction" ], "outputs": [ "Target code or explicit unmatched result", "Mapping strength", "Loss notes and recorded conflicts" ], "preconditions": [ "A mapping table exists and has been revalidated against the target version", "Alignment is claimed rather than conformance unless evidence exists" ], "effects": [ "No state change", "Unmatched mappings are recorded rather than silently defaulted" ], "source_refs": [ "SRC-012", "SRC-016", "SRC-022", "SRC-011" ] }, { "id": "bind-lifecycle-mixin", "name": "Bind lifecycle mixin", "description": "Attach a lifecycle binding to a host with a governing machine, code system, pattern family and identifiers.", "inputs": [ "host reference", "machine reference", "code system reference", "pattern family", "identifier scheme" ], "outputs": [ "lifecycle record identifier", "initial configuration", "observation time" ], "preconditions": [ "Host identity exists in the identity sibling.", "Machine definition is identified and has a legal initial configuration." ], "effects": [ "Creates a lifecycle record bound to the host.", "Does not change host identity." ], "source_refs": [ "SRC-007", "SRC-025" ] }, { "id": "mark-entered-in-error", "name": "Mark entered in error", "description": "Set error or entered-in-error without deleting the host, record the correction, and apply any redaction or notification policy.", "inputs": [ "lifecycle record identifier", "authorising agent", "reason", "event time", "observation time" ], "outputs": [ "error status", "correction record identifier", "redaction applied boolean" ], "preconditions": [ "Agent is authorised.", "Deletion is not used as a substitute when integrity requires retention." ], "effects": [ "Sets modifier status so consumers ignore the host.", "Retains the record.", "Writes a correction artefact." ], "source_refs": [ "SRC-025", "SRC-026", "SRC-017" ] }, { "id": "restore-history-configuration", "name": "Restore history configuration", "description": "On re-entry of a compound state, apply stored shallow or deep history instead of the default child.", "inputs": [ "lifecycle record identifier", "history vertex identifier", "authorising agent" ], "outputs": [ "restored configuration", "current status" ], "preconditions": [ "History kind is declared.", "Stored configuration is compatible with the current machine version." ], "effects": [ "Replaces default initial entry with stored configuration.", "Audits the restoration." ], "source_refs": [ "SRC-007" ] } ], "composition": [ { "target": "Host world-model entry composing this mixin (any entity, event, relationship, aggregate, registry or classifier)", "relation": "MIX-IN", "purpose": "Supply the host entry with a governed state machine, current-state assertion, bitemporal validity and disposition hooks without imposing any domain semantics.", "required": true, "source_refs": [ "SRC-018", "SRC-016", "SRC-007" ] }, { "target": "Classification / Code List Registry model (sibling; not yet registered)", "relation": "COMPOSE", "purpose": "The state space is a governed code list administered by a registration authority; this mixin binds such a code list and adds transition structure that a plain code list does not carry.", "required": true, "source_refs": [ "SRC-016", "SRC-018", "SRC-022" ] }, { "target": "Identity & Identifier model (sibling; not yet registered)", "relation": "REFERENCE", "purpose": "Subject, artifact and authority identifiers are minted and governed there; this mixin only cites them and enforces the identity priority order for its own artifacts.", "required": true, "source_refs": [ "SRC-016", "SRC-018" ] }, { "target": "Provenance & Lineage model (sibling; not yet registered)", "relation": "REFERENCE", "purpose": "Transition attribution, generation and invalidation timestamps extend the general provenance graph rather than duplicating it.", "required": true, "source_refs": [ "SRC-004", "SRC-014" ] }, { "target": "Versioning & Change Control model (sibling; not yet registered)", "relation": "REFERENCE", "purpose": "Supersession and deprecation states here point at version lineage maintained there; version identity and content deltas are not modelled in this mixin.", "required": false, "source_refs": [ "SRC-009", "SRC-015", "SRC-011" ] }, { "target": "Records Retention & Disposition model (sibling; not yet registered)", "relation": "REFERENCE", "purpose": "Lifecycle end supplies the retention trigger; the authorised, dated disposition instrument and the appraisal behind it live in the retention model.", "required": false, "source_refs": [ "SRC-017", "SRC-021" ] }, { "target": "Authorization & Access Control model (sibling; not yet registered)", "relation": "REFERENCE", "purpose": "Transition authority basis and state visibility classes are recorded here and evaluated there; no policy language is defined in this mixin.", "required": false, "source_refs": [ "SRC-017", "SRC-020" ] }, { "target": "Process / Workflow Orchestration model (sibling; not yet registered)", "relation": "REFERENCE", "purpose": "Workflow tasks drive transitions but the declarative state machine, not the task graph, is the authority on legal states.", "required": false, "source_refs": [ "SRC-007", "SRC-019" ] }, { "target": "Temporal Reference & Calendar model (sibling; not yet registered)", "relation": "REFERENCE", "purpose": "Interval algebra, temporal reference systems and calendar arithmetic are supplied there; this mixin consumes them for validity intervals.", "required": false, "source_refs": [ "SRC-008", "SRC-002" ] }, { "target": "Event Record model (sibling; not yet registered)", "relation": "REFERENCE", "purpose": "A lifecycle transition is a constrained event subtype; general event payloads and correlation belong to the event model.", "required": false, "source_refs": [ "SRC-014", "SRC-004" ] }, { "target": "ISO 19135-1:2015 register item status (RE_ItemStatus: notValid, valid, superseded, retired) and proposal disposition", "relation": "ALIGN", "purpose": "Alignment target for register-style lifecycles, including the requirement that retired, superseded and invalid items remain resolvable. Alignment only; no conformance is claimed.", "required": false, "source_refs": [ "SRC-016" ] }, { "target": "ISO/IEC 11179-6:2023 registration status (lifecycle versus documentation status categories, single registration authority)", "relation": "ALIGN", "purpose": "Alignment target for the separation of governance status axes and for single-authority administration of status. Alignment only; the normative text is paywalled and was not read in full.", "required": false, "source_refs": [ "SRC-018" ] }, { "target": "HL7 FHIR R5 PublicationStatus value set (draft | active | retired | unknown)", "relation": "ALIGN", "purpose": "Alignment target for a minimal normative governance axis, including an explicit code for indeterminate status.", "required": false, "source_refs": [ "SRC-012" ] }, { "target": "W3C PROV-O (generation, invalidation, revision, attribution)", "relation": "ALIGN", "purpose": "Alignment target for transition provenance, invalidation instants and revision links.", "required": false, "source_refs": [ "SRC-004" ] }, { "target": "W3C Verifiable Credentials Data Model 2.0 and Bitstring Status List v1.0", "relation": "ALIGN", "purpose": "Alignment target for the separation of validity period from status, and for reversible suspension versus irreversible revocation with published status lists.", "required": false, "source_refs": [ "SRC-005", "SRC-006" ] }, { "target": "IETF RFC 5280 certificate validity and CRLReason enumeration", "relation": "ALIGN", "purpose": "Alignment target for validity boundaries, no-expiry conventions, reason codes with consequences, hold-and-release reversibility and invalidity dating.", "required": false, "source_refs": [ "SRC-003" ] }, { "target": "IETF RFC 3339 and RFC 9557 timestamp semantics", "relation": "ALIGN", "purpose": "Normative alignment for every timestamp in the model: explicit offset or Z, second precision, and IANA zone annotation for future-dated boundaries.", "required": true, "source_refs": [ "SRC-001", "SRC-002" ] }, { "target": "W3C SCXML and OMG UML 2.5.1 behavioural state machines", "relation": "ALIGN", "purpose": "Alignment target for the state-machine formalism: states, transitions, triggers, guards, effects, regions, history and deterministic conflict resolution.", "required": false, "source_refs": [ "SRC-007", "SRC-019" ] }, { "target": "SQL:2011-style application-time and system-versioned period tables", "relation": "ALIGN", "purpose": "Alignment target for bitemporal storage and as-of/as-at querying. Evidence is drawn from an implementation; the ISO/IEC 9075-2 text itself was not read.", "required": false, "source_refs": [ "SRC-024" ] }, { "target": "DCMI Metadata Terms and DCAT 3 / ADMS versioning and status properties", "relation": "ALIGN", "purpose": "Alignment target for validity dates and supersession links in catalogue and metadata contexts.", "required": false, "source_refs": [ "SRC-015", "SRC-009", "SRC-011" ] }, { "target": "ISO 15489-1:2016 disposition authorities and NARA General Records Schedules", "relation": "ALIGN", "purpose": "Alignment target for lifecycle-triggered retention: authorities that are authorised, dated, implemented and reviewed, issued and versioned externally.", "required": false, "source_refs": [ "SRC-017", "SRC-021" ] }, { "target": "Regulation (EU) 2016/679 Articles 5(1)(e), 17 and 30", "relation": "ALIGN", "purpose": "Legal constraint alignment for storage limitation, erasure and processing records, which bounds the append-only history where personal data is involved.", "required": false, "source_refs": [ "SRC-020" ] }, { "target": "schema.org EventStatusType", "relation": "ALIGN", "purpose": "Alignment target for widely deployed public status vocabularies, and a recorded counterexample of conflating lifecycle state with modality change.", "required": false, "source_refs": [ "SRC-023" ] } ], "serviceLayers": { "dimension": { "owner_package_requirements": [ "The adopting Dimension MUST designate exactly one registration authority or governance steward accountable for each lifecycle definition it publishes, mirroring the single-authority rule for administered items, and MUST record that accountability in the owner package.", "The owner package MUST ship the state code list, the transition table, the status axis matrix and the temporal convention profile as one coherent version set; a state code list published without its transition table and boundary conventions is not a usable lifecycle and MUST NOT be registered as one.", "The owner package MUST declare which host models compose this mixin, which status axis each host exposes by default in projections, and the binding mode (pinned or floating) between host subjects and lifecycle definition versions.", "The owner package MUST reference an authorised, dated disposition instrument for every terminal state that triggers retention or destruction, or explicitly record that no disposition duty applies.", "The owner package MUST name a mapping custodian for every external status vocabulary it claims alignment with, and record the target version each mapping was last revalidated against." ], "namespace_guidance": "Lifecycle definitions, state concepts, transitions and status axes are named under a namespace controlled by the adopting Dimension's registration authority, for example {dimension-base}/lifecycle/{definition-slug}/{version}#{state-or-transition}. State identifiers MUST be opaque with respect to display labels and MUST NOT encode dates, sequence positions or the state's own status. External vocabulary codes are never minted in the local namespace: they are referenced by their owning organisation's identifier plus version, and any local alias is recorded in the mapping table as an alias rather than as a code.", "registry_links": [ "vr.wm-xct-021 (this model) at nav path NAV.XCT.LIF, domain tag XCT.LIF, entry kind mixin, review state boundary-review-required", "Each adopting host model registers a composition link of type MIX-IN to vr.wm-xct-021 and declares its default status axis in its own registry entry", "Sibling registry entries for Identity, Provenance, Versioning, Retention, Authorization, Workflow, Temporal and Classification models are prerequisites for removing the boundary-review-required flag; none are registered at the time of research" ] }, "canon_and_patch": { "canonicalization_rules": [ "All timestamps are canonicalised to RFC 3339 date-time with seconds and an explicit numeric offset or Z; where the local calendar context matters for a future-dated boundary, an RFC 9557 IANA time-zone annotation is appended and the annotation is authoritative over any copied offset.", "Interval boundaries are canonicalised to the convention declared in the temporal convention profile; when exchanging with a system using the other convention, the boundary is converted explicitly and the conversion is recorded, never inferred.", "State values are canonicalised to the pair (code system identifier with version, state code); display labels and translations are non-canonical and MUST NOT be used for comparison, indexing or mapping.", "The transition log is canonically ordered by record time, then by the system-assigned sequence, then by the transition event identifier; event time is never used as the primary ordering key because it may be back-dated.", "An absent validity end boundary is canonicalised to an explicit open-ended marker with a declared meaning; a null is never allowed to stand for the three distinct meanings of open-ended, unknown and undecided.", "Identifiers are canonicalised without case folding; a date, sequence number or publication instant is never promoted to an identifier." ], "patch_rules": [ "The transition log, the invalidation records and the disposition evidence are append-only: a patch that edits or removes an existing entry is invalid regardless of authority.", "A change to a past assertion is expressed as a new correction record referencing the target, which closes the record-time envelope of the prior belief; the prior belief remains retrievable for as-at reconstruction.", "Every patch MUST cite the lifecycle definition version in force at the time of the change; a patch that silently reinterprets history under a newer definition version is invalid.", "Patches to the lifecycle definition itself follow the proposal-and-disposition procedure and produce a new definition version with its own effective period; in-place edits to a published definition version are prohibited.", "Erasure required by law is executed as a destruction action that removes the erasable payload and substitutes a tombstone; it is recorded as an event in the log rather than as a deletion of the log." ], "compatibility_rules": [ "Adding a new state or a new transition that widens what is permitted is a backward-compatible change; existing histories remain conformant.", "Removing or renaming a state, narrowing a guard, making a reversible state terminal, or changing boundary inclusivity is a breaking change requiring a new major definition version, a migration rule for in-flight subjects and a deprecation notice with a stated notice period.", "Deprecation MUST precede removal; a state may not be deleted from a published definition while any subject is bound to a version in which it is reachable.", "Compatibility claims are stated explicitly using backward-compatible and incompatible declarations against the prior version; silence is read as incompatible.", "Alignment to an external vocabulary is versioned: a new version of the target vocabulary does not automatically carry the mapping forward, and an unrevalidated mapping is treated as unverified rather than valid." ] }, "artifact_rules": { "identity_priority": [ "1. The authoritative master-system identifier issued by the system of record or registration authority that governs the artifact.", "2. A governed global identifier or IRI under a namespace controlled by the registration authority, including an explicit version token where the artifact is versioned.", "3. A UUID or ULID assigned by the adopting Dimension, used only where neither of the above exists; ULID is preferred for serial artifacts so that lexical order matches record time." ], "timestamp_rule": "All artifact timestamps use RFC 3339 date-time with seconds and an explicit numeric offset or Z; where local calendar semantics must survive time-zone rule changes, an RFC 9557 time-zone annotation is added and marked critical if consumers must honour it. Event time (when it happened) and record or ingestion time (when the system stored it) are recorded as separate fields whenever they can differ, and neither is ever used as the artifact identifier.", "serial_naming_rule": "Serial artifacts (transition log entries, decision records, notices, snapshots, published status packages, certificates) are named as {artifact-type}/{subject-or-population-reference}/{monotonic-edition-or-ulid}. The monotonic token orders the series; it is metadata, not the identity, and identity remains governed by the identity priority order. Series numbers are never reused, and gaps in a series must be explainable from the exception register.", "integrity_rule": "Every serial artifact records the lifecycle definition version in force, the acting and authorising agents, and both event and record timestamps. Artifacts that are published to relying parties carry an integrity proof and an anti-rollback marker so that a stale or replayed edition can be detected; artifacts that evidence destruction or erasure are retained under their own retention rule and must not contain the erased payload." }, "policies": [ "Status is never a free-text string: every state value cites a code system identifier and version drawn from a governed code list administered by a single named authority.", "Validity period and status are two independent axes and are stored separately; effective status is derived from both by a published, deterministic and testable rule, and the precedence between them is stated normatively rather than left to implementation.", "Lifecycle history is append-only. Corrections create new records; nothing is edited in place. Erasure required by law is executed as a recorded destruction action leaving a tombstone, not as a silent deletion.", "Reversibility is a contract: a state declared reversible may only be exited by the declared reinstatement procedure, and a state declared irreversible may never be exited, regardless of the authority of the requester.", "Retired, superseded and invalidated subjects remain resolvable for as long as data produced during their validity may need interpretation, subject only to an authorised disposition instrument or a legal erasure obligation.", "External standards are treated as alignments, not as conformance claims. A conformance claim requires cited evidence; where none exists the model records alignment and lists the known divergences.", "Every transition records who acted, who authorised, why (governed reason code) and on what evidence; a transition without an attributable actor is an exception, not a valid record.", "Every status change is a recorded transition with agent, event time and observation time; unmatched or unauthorised attempts are audited.", "unknown and entered-in-error are first-class; omission does not mean unknown; error does not mean delete.", "Valid time answers what was true in the world; record time answers what the system knew when. Queries MUST name the axis.", "Canonical FHIR resource-status and SCXML/UML alignments are optional; production use of experimental vocabularies requires an explicit Dimension decision." ], "crud": { "read": [ "Reading state requires two temporal parameters — the real-world instant of interest and the record instant of belief — with stated defaults when they are omitted.", "Reads are permission-aware: result sets are trimmed to states the caller may see, and trimming is signalled rather than silently applied.", "Reading justification text and evidence may require a higher access class than reading the state value itself.", "Reads of published status projections must be checkable against the declared maximum staleness; a consumer that cannot verify freshness applies the declared fail-open or fail-closed rule." ], "create": [ "Creating a subject under this mixin requires binding it to a lifecycle definition version and setting the declared initial state, or recording an explicit indeterminate status.", "Creating a transition requires a permitted transition identifier, a satisfied guard, an authorised actor, a governed reason code and an event time conforming to the temporal convention profile.", "Creating a lifecycle definition version requires a named registration authority, a complete state code list, a transition table, an axis matrix and a temporal convention profile.", "Record time is always assigned by the system of record and never accepted from the caller." ], "update": [ "The current-state value and any derived status may be recomputed, but the transition log, invalidation records and disposition evidence are immutable.", "Adjusting a validity interval creates a new assertion; the prior interval is closed in record time and remains retrievable.", "Correcting a past record requires a correction kind from the governed code list, a reference to the target record, grounds and an authorising agent.", "Rebinding a subject to a newer lifecycle definition version requires a declared migration rule for its current state and is itself recorded as an event." ], "delete": [ "Logical deletion is the default: the subject moves to a terminal state and a tombstone preserves reference resolvability and identifier non-reuse.", "Physical destruction requires an authorised, dated disposition instrument, verified eligibility, no legal hold, and the declared authorisation and witnessing controls.", "Erasure of personal data is scoped to the erasable payload; the fact of erasure, its authority and its instant are retained as evidence.", "Deletion of a lifecycle definition version is prohibited while any subject remains bound to it; definitions are retired, never removed." ] }, "roles": [ { "name": "Lifecycle registration authority (governance steward)", "responsibilities": [ "Own each lifecycle definition and approve every change to it through the proposal-and-disposition procedure", "Assign and publish status axes, state code lists and their versions", "Decide migration rules for subjects in flight when a definition changes", "Maintain the register so that retired and superseded items remain resolvable" ] }, { "name": "Transition authoriser", "responsibilities": [ "Approve transitions that require authorisation separate from execution, including dual-control cases", "Record the authority basis and any on-behalf-of delegation", "Refuse and record transitions that fail guards or authority checks", "Authorise emergency overrides and submit them for mandatory post-hoc review" ] }, { "name": "Records and disposition officer", "responsibilities": [ "Bind terminal lifecycle states to authorised, dated disposition instruments and keep those instruments under review", "Compute and monitor disposition eligibility and apply or release legal holds", "Execute or supervise destruction and retain destruction evidence", "Reconcile erasure obligations with the append-only history and approve tombstone content" ] }, { "name": "Interoperability mapping custodian", "responsibilities": [ "Maintain mappings from local states to external status vocabularies, with mapping strength and loss notes", "Revalidate each mapping against new versions of the target vocabulary and record the revalidation date", "Record conflicts between external vocabularies rather than silently reconciling them", "Ensure that only alignment, and not conformance, is claimed without cited evidence" ] }, { "name": "Conformance validator and auditor", "responsibilities": [ "Validate recorded histories against the governing definition version and publish validation reports", "Test bitemporal reproducibility by reconstructing past beliefs and comparing them with retained snapshots", "Raise and track lifecycle exception register entries for unknown states, illegal transitions and staleness", "Verify that record time is system-assigned and that append-only guarantees hold" ] }, { "name": "Data protection officer or equivalent privacy authority", "responsibilities": [ "Assess erasure and storage-limitation obligations against the append-only lifecycle history", "Approve tombstone content so that it carries no personal data", "Review privacy sizing of published status projections for disclosure risk", "Approve exceptions where legal obligations and audit requirements conflict" ] } ], "access": { "default_rule": "Deny by default. A caller may read a state value only for scopes it is explicitly granted, and may execute a transition only where the lifecycle definition names its role for that specific transition. Pre-publication states (draft, candidate, submitted, reserved) and all transition justification text default to a stricter access class than published state values, and are excluded from listings, search indexes and published status projections unless explicitly released.", "scopes": [ "bundle", "layer", "finding", "artifact" ], "exceptions": [ "Regulators, auditors and the registration authority may read all states, justifications and evidence within their remit, with each such read logged and attributed.", "Relying parties who hold a copy of a subject may read that subject's invalidation status through the published status projection without holding any other read permission, because withholding revocation information causes greater harm than disclosing it.", "Emergency overrides may bypass a guard or an authority check where a named role authorises them, subject to compensating controls and a mandatory post-hoc review recorded in the exception register.", "A legal hold overrides deletion permissions: no role, including the subject owner, may execute disposition while a hold is in force.", "Data subjects exercising erasure rights may compel removal of erasable payload from otherwise immutable records, with the fact, authority and instant of erasure retained.", "Break-glass read of redacted error records by an auditor with recorded justification.", "Machine authors may read machine definitions they do not operate.", "Public artefacts with publication-status active may expose publication status without exposing transition audits." ], "audit_requirements": [ "Every transition, rejection, override and reinstatement is logged with actor, authoriser, reason code, event time and system-assigned record time.", "Every read of a restricted state value, justification or evidence item is logged with the caller identity, the scope invoked and the instant of access.", "Every publication of a status projection is logged with its edition token, publication instant and population size, so that a stale or replayed edition can be traced.", "Every destruction or erasure is logged with the authorising instrument, the authorising and witnessing agents and the retained certificate reference.", "Audit logs are themselves append-only, carry their own retention rule, and must support reproducible as-at reconstruction for the full retention horizon.", "Every execute-transition, rejected transition, mark-entered-in-error, restore-history-configuration and supersede-status-record SHALL write a transition audit with agent, event time and observation time.", "Reads of redacted error records SHALL themselves be audited." ] }, "agents_bootstrap": { "filename": "AGENTS.md", "required_fields": [ "Name", "Type", "Specification URL", "Storage type URL", "Interface URL", "Processes URL", "Registration authority", "Lifecycle definition version and effective period", "Temporal convention profile URL", "Status axis matrix URL", "Disposition authority reference", "Access default rule" ], "read_order": [ "1. AGENTS.md — establish Name, Type, Specification URL, Storage type URL, Interface URL and Processes URL before any other action; these six fields are mandatory even when the storage is MongoDB or the interface is MCP.", "2. Specification URL — read the lifecycle definition: state code list, transition table, status axis matrix and terminality/reversibility declarations.", "3. Temporal convention profile — read boundary inclusivity, precision, offset and zone rules, no-expiry sentinel and clock-skew tolerance before interpreting any timestamp.", "4. Status axis matrix and status derivation rule set — determine which axis governs reliance decisions and how effective status is computed.", "5. Processes URL — read the transition execution contract, exception handling and disposition procedures before attempting any write.", "6. Storage type URL and Interface URL — bind to the projection last; treat format and interface as projections of the semantics already loaded, never as their source.", "7. Access default rule and audit requirements — confirm scope grants and logging obligations before reading restricted states or executing transitions." ] } }, "coverage": { "claim": "Dual-provider research synthesis for a format-independent Lifecycle / Status mixin. It covers governed state machines, concurrent status axes, current assertions, transition history, bitemporal validity, correction, succession, suspension, revocation, end-of-life, operations and external mappings. Domain-specific status vocabularies remain profiles, not universal core codes.", "confidence": "medium", "checklist": [ { "dimension": "identity", "status": "covered", "notes": "State concepts, lifecycle definitions, transition events and every artifact carry an explicit identity strategy following the priority order: authoritative master-system identifier, then governed IRI, then UUID/ULID. Dates, publication instants and series numbers are explicitly excluded as identifiers. Grounded in ISO 19135-1 register-item identity and ISO/IEC 11179-6 single-authority administration." }, { "dimension": "lifecycle", "status": "covered", "notes": "Whole bundles address state space, transition system, terminality and reversibility, succession, deprecation, invalidation and end of life. State-machine semantics are aligned to SCXML and UML 2.5.1; status vocabularies to FHIR PublicationStatus, ISO 19135-1 RE_ItemStatus and the UKGovLD registry hierarchy." }, { "dimension": "relationships", "status": "covered", "notes": "Supersession and replacement links (both directions plus a current-version pointer), migration targets, delegation of authority, cascade to dependent subjects, and composition links to nine sibling models and twelve external alignments. Grounded in DCMI replaces/isReplacedBy, DCAT 3 version lineage and ADMS prev/next/last." }, { "dimension": "temporal", "status": "covered", "notes": "Valid time and record time are separated throughout; boundary inclusivity, precision, open-endedness, no-expiry sentinel, offsets, IANA zone annotation, leap seconds and clock skew are all explicit. Grounded in RFC 3339, RFC 9557, FHIR Period/instant, RFC 5280 validity and SQL:2011-style period tables. Allen relations from OWL-Time constrain interval continuity." }, { "dimension": "provenance", "status": "covered", "notes": "Every transition records acting agent, authorising agent, on-behalf-of delegation, reason code, evidence references, event time and system-assigned record time. Aligned to PROV-O generation/invalidation/revision and FHIR Provenance occurred versus recorded." }, { "dimension": "ownership", "status": "covered", "notes": "A single registration authority owns each lifecycle definition; mapping custodians, records officers, transition authorisers and a privacy authority are named roles with responsibilities. Risk allocation for the window between invalidity and publication is an explicit question." }, { "dimension": "validation", "status": "covered", "notes": "Conformance rules, a constraint set for interval continuity and degeneracy, a conformance validation function producing retained reports, and a bitemporal reproducibility test. Non-conformant histories must be explicitly quarantined, mapped or rejected rather than tolerated silently." }, { "dimension": "access", "status": "covered", "notes": "Deny-by-default with four declared scopes, stricter default class for pre-publication states and justification text, five named exceptions including revocation visibility for relying parties and legal hold override, and five audit requirements including logging of restricted reads." }, { "dimension": "retention and deletion", "status": "covered", "notes": "Lifecycle end as retention trigger, authorised and dated disposition instruments, legal hold, disposition actions, logical deletion with tombstones and identifier non-reuse, destruction evidence, and reconciliation of erasure with append-only history. Grounded in ISO 15489-1, NARA GRS and GDPR Articles 5(1)(e), 17 and 30." }, { "dimension": "interoperability", "status": "covered", "notes": "Versioned mapping tables with declared mapping strength and loss notes, recorded conflicts rather than silent reconciliation, named custodians and revalidation dates, published status projections with freshness and integrity requirements, and an explicit rule that alignment is claimed rather than conformance." }, { "dimension": "authority", "status": "covered", "notes": "Single registration authority per definition, authority basis recorded per transition, dual control and separation of duties, emergency override with compensating controls and mandatory review, and proposal dispositions modelled on ISO 19135-1." }, { "dimension": "classification", "status": "covered", "notes": "State vocabularies, reason code lists, correction kinds, disposition actions, invalidation kinds and mapping relationships are all governed code lists with system identifier and version, never free text." }, { "dimension": "composition", "status": "covered", "notes": "Composite and nested states, concurrent regions, active state configuration as a set rather than a scalar, history semantics, and multi-axis status. Grounded in SCXML parallel/history and UML 2.5.1." }, { "dimension": "process and events", "status": "covered", "notes": "Triggers, guards, mandated effects, deterministic conflict resolution, idempotency, optimistic concurrency, atomicity and compensation, rejection recording, and fourteen declared functions with preconditions and effects." }, { "dimension": "evidence and quality", "status": "covered", "notes": "Evidence references with retrievability guarantees, confidence qualifiers distinguishing known from suspected invalidity, staleness detection with dwell-time thresholds, cache invalidation for derived status, and retained validation reports." }, { "dimension": "exception handling", "status": "covered", "notes": "Orphaned states after a definition change, explicit indeterminate status distinct from null, stale subjects, illegal transitions, emergency overrides, degenerate intervals and record-time inversion are each given detection and disposition rules." }, { "dimension": "privacy", "status": "covered", "notes": "Erasure versus append-only reconciliation, tombstone content approval so that no personal data remains, herd-privacy sizing of published status projections, and a named privacy authority role. Grounded in GDPR and Bitstring Status List privacy considerations." }, { "dimension": "security", "status": "covered", "notes": "Integrity proofs and anti-rollback markers on published status, system-assigned immutable record time, detection and remediation of unauthorised or repudiated transitions, and append-only audit logs." }, { "dimension": "measurement", "status": "covered", "notes": "Timestamp precision and rounding, ingestion latency expectations and thresholds, clock skew tolerance, and maximum status staleness are all quantified elements rather than prose." }, { "dimension": "decision", "status": "covered", "notes": "Axis precedence on disagreement, derived-versus-asserted precedence, overlap resolution, transition conflict resolution and default temporal parameters are each required to be deterministic and normatively stated." }, { "dimension": "spatial", "status": "not-applicable", "notes": "No inherent spatial dimension: a lifecycle state has no geometry. The one spatial-adjacent concern — territorial or jurisdictional scope of validity, where a subject is valid in one jurisdiction and not another — is recorded separately as a gap rather than forced into this dimension." }, { "dimension": "jurisdictional scope of validity", "status": "gap", "notes": "The model does not represent validity that is territorially or jurisdictionally scoped (valid in one jurisdiction, revoked in another). No primary source in the researched set models this directly; adopting Dimensions with cross-border subjects must treat it as an additional axis and mark it as unsupported structure until evidence is found." }, { "dimension": "non-repudiation of history", "status": "gap", "notes": "Append-only guarantees and integrity proofs are required, but the model does not specify a cryptographic construction (hash chain, signed log, transparency log) for proving that a transition log has not been rewritten. This is deliberately left to a security model; without it, the append-only policy rests on operational rather than mathematical assurance." }, { "dimension": "formal verification of the state machine", "status": "gap", "notes": "No requirement for reachability, deadlock or liveness analysis of declared lifecycles. SCXML and UML supply execution semantics but neither obliges verification, and no researched source requires it. Large lifecycles may therefore contain unreachable or trapping states that only the conformance validator will notice, after the fact." } ], "known_omissions": [ "The full normative texts of ISO 19135-1:2015, ISO 15489-1:2016 and ISO/IEC 11179-6:2023 are paywalled; the ISO catalogue pages returned HTTP 403 and the sample PDFs were not machine-readable. Their content here is verified from ISO catalogue metadata, ISO/TC 211 schema listings and downstream implementations, not from the clause text. Any structural node resting solely on these sources should be re-verified against the purchased standards.", "ISO/IEC 9075-2 (SQL:2011 temporal features) was not read; bitemporal alignment rests on MariaDB implementation documentation as secondary evidence. The SIGMOD Record industry paper on SQL:2011 temporal features was fetched but returned unparseable binary.", "GS1 EPCIS 2.0 eventTime, eventTimeZoneOffset, recordTime and errorDeclaration were targeted as a strong event-versus-record-time source but the GS1 endpoints returned unparseable PDF or HTTP 403. The event-versus-record-time seam is therefore grounded in HL7 FHIR Provenance and system-versioned tables instead, which is adequate but narrower in domain coverage.", "Domain-specific regulated lifecycles (medicinal product status, financial instrument state, employment status, planning permission) are deliberately excluded; each carries statutory state definitions that belong to host models.", "No treatment of probabilistic or fuzzy status (confidence-weighted state), of state machines whose transitions are learned rather than declared, or of eventual convergence in offline-first replicas that transition independently and later merge.", "Equipment and process state models (ISA-88/PackML-style operating states) were not researched because the registry entry records a robotics factor of zero; adopting Dimensions with machine-state subjects should treat that as unresearched territory rather than as excluded by evidence.", "No cost or performance model for maintaining full bitemporal history at scale, and no guidance on when history compaction is acceptable — compaction inherently conflicts with the append-only policy stated here.", "SQL:2011 APPLICATION_TIME and SYSTEM_TIME were not fetched as primary text and are not claimed.", "IEC 61512 / ISA-88 equipment and batch states, ISA-95, and Petri-net semantics are uncovered.", "ISO 55000:2024 asset life-cycle stage naming (organisation-defined) was seen only in secondary samples and is not canonical here.", "RFC 9557 updates to RFC 3339 (time-zone suffixes) were not incorporated beyond noting the update.", "BPMN 2.0 token state versus SCXML configuration is referenced as a sibling, not modelled.", "Fuzzy, probabilistic or interval-valued uncertain validity has no primary support in the cited sources.", "Saga/compensating-transaction status and two-phase commit states are omitted.", "Legal hold procedures beyond a boolean flag belong to records/legal siblings.", "Device-specific FHIR codes (transduc-discon, hw-discon) are not generalised.", "Full SCXML datamodel, ECMAScript profile and HTTP event I/O processor are execution-environment details, not mixin semantics.", "ISO 19108 TM_Period inner UML could not be quoted from the paywalled full text; only the official abstract (valid time versus transaction time) is used." ], "conflicts": [ "Interval boundary inclusivity is genuinely inconsistent across ecosystems: HL7 FHIR states that both Period boundaries are inclusive, while SQL:2011-style application-time and system-time periods are closed-open. Exchanging validity intervals between the two without explicit conversion silently shifts every boundary by one unit of precision. The model resolves this by requiring the convention to be declared and conversions to be recorded, not by choosing a winner.", "RFC 9557 updates RFC 3339's interpretation of Z: under RFC 3339, -00:00 signalled that UTC is known but the local offset is not, while RFC 9557 assigns that meaning to Z itself. Systems built to the two documents can disagree about whether a timestamp carries a meaningful local offset.", "FHIR PublicationStatus collapses withdrawal and supersession into a single 'retired' code, whereas ISO 19135-1 keeps 'superseded' and 'retired' distinct because only the former implies a successor. Mapping FHIR to ISO 19135-1 is lossy in one direction and requires an out-of-band successor link in the other.", "Reversibility is not consistent across ecosystems: Bitstring Status List declares revocation irreversible and suspension reversible, while RFC 5280 permits a certificateHold to be reversed by removeFromCRL and treats 'superseded' as a revocation reason rather than a separate lifecycle state. A subject that is 'revoked' in one ecosystem may be 'held' and later restored in the other.", "W3C ADMS is a Working Group Note that was retired in August 2023, yet adms:status remains the property that DCAT 3 and DCAT-AP reference for resource status. Citing it is unavoidable in catalogue contexts and simultaneously unsafe as a stable normative anchor.", "The latest published version of the W3C Time Ontology at /TR/owl-time/ is a Candidate Recommendation Draft dated 15 November 2022, not a Recommendation. Alignment to Allen relations is therefore alignment to a non-final draft and should be re-checked before any conformance claim.", "schema.org EventStatusType mixes lifecycle state (EventCancelled, EventPostponed) with a change of modality (EventMovedOnline), which is a property change rather than a state change. It is included as a widely deployed alignment target and as a documented counterexample of axis conflation, not as a model to imitate.", "ISO 19135-1 requires retired, superseded and invalid items to be kept so that historical data remains interpretable, while GDPR Article 17 can require erasure of personal data held in those very records. The tombstone construct is the model's reconciliation, but it is a policy compromise rather than a resolution: some jurisdictions will not accept a tombstone as sufficient erasure.", "FHIR says consistency of status codes across resources is not the primary objective, yet publishes an experimental canonical map that is not ready for production.", "ISO 19108 emphasises valid time; PROV and RFC 3339 emphasise event/transaction timestamps; both axes are required and must not be collapsed.", "RFC 3339 describes instants only; FHIR Period, OWL-Time and dcterms:valid describe intervals, with dcterms:valid as a literal rather than a structured period.", "OWL-Time encodings ignore leap seconds; ISO 8601 mandates them.", "OWL-Time 2022 is a Candidate Recommendation Draft; a 2017 Recommendation exists. Align to the cited 2022 CRD without claiming W3C Recommendation status for that edition.", "SCXML XML, UML graphical/XMI and PSSM operational semantics are related Harel descendants, not identical.", "Clinical status is not workflow status; using one code list for both is a conflict with FHIR.", "Current-list membership cannot be inferred from status=active.", "entered-in-error should be ignored but often cannot be removed, conflicting with naive CRUD delete.", "RFC 3339 -00:00 (unknown offset) is semantically distinct from Z." ], "regional_assumptions": [ "Erasure and storage-limitation duties are modelled on Regulation (EU) 2016/679 and apply to EU/EEA personal data. Other regimes (UK GDPR, Brazilian LGPD, US state privacy laws, sectoral rules) impose different triggers, exemptions and retention floors; the retention trigger and disposition action elements are deliberately parameterised rather than fixed.", "The NARA General Records Schedules are United States federal instruments and are cited as an example of externally issued, versioned disposition authority, not as an applicable rule outside that jurisdiction.", "Gregorian calendar, UTC and the IANA time-zone database are assumed for all timestamps. Non-Gregorian calendars, ordinal or geological time scales and other temporal reference systems are out of scope and delegated to a Temporal Reference model.", "ISO 19135-1 is written for geographic-information registers. Its generalisation to non-geographic registers is an interpretation made here, supported by the UKGovLD registry vocabulary explicitly reusing its status semantics, but it is an interpretation and not a claim about the standard's stated scope.", "ISO/IEC 11179-6 registration status semantics are drawn from metadata registries; applying lifecycle-versus-documentation status categories to arbitrary world-model subjects is an extension by analogy.", "Language and label handling assumes that display labels are non-identifying and may be translated freely; jurisdictions where a legally binding status must be expressed in a specific official language will need an additional constraint on label authority.", "Default TRS is Gregorian calendar with UTC offsets as in RFC 3339 and xsd:dateTimeStamp; other TRS are allowed but not defaulted.", "Canonical status tokens cited from FHIR are English codes; local systems may use other languages or jurisdictions.", "Healthcare-shaped pattern families are alignments, not a requirement outside clinical Dimensions.", "Records retention durations and legal holds are jurisdiction-specific and not specified here.", "Daylight-saving and political offset changes are out of RFC 3339 scope; scheduled local wall-clock transitions need a time sibling." ], "adversarial_checks": [ "Tested whether 'status' and 'validity period' could be modelled as one concept, and rejected it: VC Data Model 2.0 keeps validFrom/validUntil separate from credentialStatus, and RFC 5280 keeps the certificate validity period separate from the CRL, precisely because time-bound expiry and event-driven invalidation have different actors, different reversibility and different distribution needs.", "Tested whether a single flat status enumeration suffices, and rejected it: ISO/IEC 11179-6 already splits registration status into lifecycle and documentation categories, and the UKGovLD registry organises statuses into a two-level hierarchy under accepted and notAccepted. A flat enumeration cannot express that superseded and retired are both kinds of deprecated.", "Tested whether the transition log could be an audit-log projection rather than model semantics, and rejected it: the FHIR distinction between Provenance.occurred and Provenance.recorded and the RFC 5280 invalidityDate extension are semantic, not storage, facts — they change what a consumer may rely on. Storage-level change-data-capture is therefore explicitly excluded while the semantic log is retained.", "Searched for a counterexample to the append-only policy and found one: GDPR Article 17 erasure can compel removal of content from records that ISO 19135-1 requires to be preserved. Rather than asserting that append-only is absolute, the model records the conflict and specifies a tombstone mechanism, flagging it as a policy compromise that some jurisdictions may reject.", "Attempted to verify boundary-inclusivity as a universal convention and found the opposite: FHIR Period boundaries are inclusive while SQL:2011-style periods are closed-open. The model therefore declines to pick a canonical convention and instead requires the convention to be declared and conversions to be explicit — an attractive simplification was rejected for lack of support.", "Checked whether ADMS and OWL-Time could be used as stable normative anchors and found they cannot: ADMS is a retired W3C Note still referenced by DCAT 3, and the latest published OWL-Time is a Candidate Recommendation Draft. Both are retained as alignments only, with their maturity recorded as a conflict rather than glossed over.", "Tested whether ISO 19135-1's four item statuses could be presented as the canonical state set for all subjects, and rejected it: the standard's stated scope is geographic-information registers, and FHIR, schema.org and PKI each carry incompatible sets. The model therefore treats every external vocabulary as a mapping target and requires local state sets to be governed independently.", "Attempted to source the structural node on jurisdictional scoping of validity from a primary standard and failed; rather than presenting it as canonical structure, it is recorded as a gap in the coverage checklist and excluded from the bundle hierarchy.", "Treat any proposal that uses a date as the lifecycle identifier as invalid.", "Reject models that store only one timestamp for a late-entered historical status.", "Reject single-code current status as complete when the machine has parallel regions.", "Reject delete-as-correction when entered-in-error applies.", "Reject inference that status=active means membership of a current curated list.", "Reject unstated production use of experimental http://hl7.org/fhir/resource-status.", "Reject collapse of clinical-interpretation inactive with workflow completed.", "Reject unqualified local times without offset or Z.", "Reject silent overwrite of status without a transition audit and agent.", "Reject claims of universal completeness of any status vocabulary." ] }, "researchAdjudication": { "providerMode": "dual-provider", "activeProviders": [ "claude", "grok" ], "waivedProviders": [], "providerPolicy": {}, "boundaryDecision": { "entry_kind": "mixin", "status": "accepted", "rationale": "Both independent providers model lifecycle semantics as a reusable binding to a host subject or aspect. The host object, executing workflow, version/change history, time reference data, evidence, access policy and disposition schedule retain their own identity and ownership." }, "decisions": [ { "concept": "Lifecycle / Status is a host-bound mixin", "disposition": "accepted-from-both", "rationale": "A lifecycle binding governs the status of an identified host or aspect without replacing the host or its domain model." }, { "concept": "Five-bundle base plus explicit binding and profile findings", "disposition": "accepted-composite", "rationale": "Claude provides the stronger boundaries for definition, assertion/history, bitemporality, disposition and operations. Grok adds binding identity, host/aspect multiplicity, profile families, active configuration and entered-in-error semantics." }, { "concept": "One universal canonical status code list", "disposition": "rejected", "rationale": "Workflow, publication, clinical interpretation, records and other lifecycle families use incompatible meanings. The core defines mapping contracts and patterns, while codes remain versioned profiles." }, { "concept": "One status field represents the whole object", "disposition": "rejected", "rationale": "A host may carry multiple orthogonal lifecycle bindings and a state machine may have a legal set of concurrent active states. Any scalar projection must declare loss." }, { "concept": "Current status overwrites history", "disposition": "rejected", "rationale": "Every accepted transition records prior/new configuration, authority, reason, evidence, event time, record time and correction semantics." }, { "concept": "Valid time and transaction time are interchangeable", "disposition": "rejected", "rationale": "Retroactive correction and reproducible as-of queries require separate valid, event, observation and record times." }, { "concept": "Unknown, inactive, completed, retired, revoked and entered-in-error are synonyms", "disposition": "rejected", "rationale": "They have different evidence, authority, consumer behavior, reversibility, retention and integrity consequences." }, { "concept": "Timestamp as lifecycle binding or transition identifier", "disposition": "rejected", "rationale": "Use the master-system identifier or UUIDv7/ULID. RFC 3339 timestamps with seconds and explicit timezone remain separate temporal facts." }, { "concept": "Physical delete is the ordinary terminal transition", "disposition": "rejected", "rationale": "Retirement, tombstone, erasure and disposition are separately governed; history needed for integrity, signatures, audit or legal retention cannot be silently removed." } ], "publicationHolds": [ "Verify live editions and claim-level support for all accepted SCXML, W3C PROV/OWL-Time, HL7 FHIR, DCMI, ISO and records-management sources.", "Validate the mixin against at least five independent profiles: publication, workflow/request, clinical interpretation, software release and records disposition." ], "deferredResearch": [ "Formal model checking and executable conformance suites for hierarchical and parallel state machines.", "Distributed transition conflict resolution, offline replicas, consensus and eventual-consistency profiles.", "Jurisdiction-specific records disposition, legal hold, erasure and evidentiary integrity requirements.", "Domain mappings for court cases, security incidents, payments, projects, products, clinical resources and public-sector decisions.", "Probabilistic, fuzzy and partially observed state models that do not fit deterministic status assertions." ] }, "statistics": { "sources": 29, "bundles": 5, "layers": 12, "findings": 32, "questions": 128, "artifacts": 26, "functions": 17 } }