{"schema":"https://ver.cy/schemas/card/1.0.0","id":"vr.wm-xct-021","code":"wm-xct-021-lifecycle-status","url":"https://ver.cy/models/wm-xct-021-lifecycle-status/","name":"Lifecycle / Status","alternateNames":[],"kind":"world-model","status":"published","version":"0.3.0-research.1","language":"en","classifiers":{"family":"World Models","category":"Cross-cutting context","entryKind":"mixin","plane":"","domain":["XCT.LIF"],"industry":["Cross-industry"],"navPath":"NAV.XCT.LIF","tags":["lifecycle","status","xct.lif"],"facets":{}},"whatItIs":"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.","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":{"in":["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":["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)"],"boundaries":[{"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."},{"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."},{"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."},{"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."},{"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."},{"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."},{"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."},{"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."},{"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."}]},"distinguishingFeatures":["A mixin that adds governed state machines and state history to any host record, not an entity of its own.","Separates valid time in the world from record time in the system.","Differs from workflow orchestration: it records state and legal transitions, it does not run the process.","Covers supersession, deprecation, revocation and reinstatement with reasons."],"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.","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.","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.","questions":[{"text":"Which governed code list defines the permitted states for this subject, and where and at what version is it published?","id":"q-sv-codelist","kind":"classification"},{"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?","id":"q-sv-identity","kind":"identity"},{"text":"Which state is entered on creation, and may a subject legitimately exist with no state assigned on this axis?","id":"q-sv-initial","kind":"lifecycle"},{"text":"How is an indeterminate status represented, and is it distinguishable from an absent assertion?","id":"q-sv-unknown","kind":"exception"}]},{"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.","questions":[{"text":"How many independent status axes does this subject carry, and what is the name, purpose and code list of each?","id":"q-sa-count","kind":"classification"},{"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?","id":"q-sa-precedence","kind":"decision"},{"text":"Does a value on one axis constrain the permitted values on another axis?","id":"q-sa-constraints","kind":"constraint"},{"text":"Which single axis, if any, is exposed as the default 'status' in downstream projections and mappings?","id":"q-sa-default","kind":"interoperability"}]},{"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.","questions":[{"text":"Which states have no outgoing transitions, and is that terminality enforced by the definition or merely by convention?","id":"q-tr-terminal","kind":"lifecycle"},{"text":"Which states may be left again, and what procedure, authority and evidence are required to re-enter a prior state?","id":"q-tr-reversible","kind":"process"},{"text":"On reinstatement, is the previously closed validity interval reopened or is a new interval started?","id":"q-tr-interval","kind":"temporal"},{"text":"Do subjects in terminal states remain retrievable and dereferenceable so that historical data can still be interpreted?","id":"q-tr-resolvable","kind":"retention"}]},{"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.","questions":[{"text":"Which lifecycle pattern family does this binding use, and is more than one family attached to the same host via distinct aspects?","id":"lifecycle-pattern-family-q01","kind":"classification"},{"text":"Which status codes are meaningless in this family and must be rejected (for example retired on a clinical-interpretation binding)?","id":"lifecycle-pattern-family-q02","kind":"constraint"},{"text":"If the family is clinical interpretation, has it been kept distinct from workflow or request status so that inactive does not mean completed?","id":"lifecycle-pattern-family-q03","kind":"validation"}]}]},{"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.","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.","questions":[{"text":"What is the complete set of permitted source-state to target-state pairs for this lifecycle version?","id":"q-tt-pairs","kind":"composition"},{"text":"Is the transition set an explicit allow-list, or is any transition permitted unless expressly forbidden?","id":"q-tt-closure","kind":"constraint"},{"text":"What triggers each transition — a domain event, an elapsed timer, or an explicit operator command — and which transitions fire automatically without human action?","id":"q-tt-trigger","kind":"event"},{"text":"What guard condition must hold for each transition, against which data is it evaluated, and at which instant?","id":"q-tt-guard","kind":"constraint"},{"text":"If more than one transition matches the same trigger, how is the winner chosen deterministically?","id":"q-tt-conflict","kind":"decision"}]},{"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.","questions":[{"text":"Does this lifecycle contain concurrent regions such that the subject is legitimately in more than one state simultaneously?","id":"q-ch-parallel","kind":"state"},{"text":"Are composite or nested states used, and does exiting an outer state force exit of all inner states?","id":"q-ch-nesting","kind":"composition"},{"text":"Is the previously active sub-state remembered when a composite state is re-entered, and is that memory shallow or deep?","id":"q-ch-history","kind":"state"},{"text":"How is completion of a concurrent region signalled, and what joins the regions back together?","id":"q-ch-completion","kind":"process"}]}]},{"id":"machine-governance","name":"Lifecycle Definition Governance","description":"Identity, versioning, ownership, change procedure and conformance rules for the lifecycle definition itself.","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.","questions":[{"text":"What is the authoritative identifier and version of the lifecycle definition governing this subject?","id":"q-mi-id","kind":"identity"},{"text":"How is a subject bound to a lifecycle version, and does that binding move automatically when the definition is revised?","id":"q-mi-binding","kind":"relationship"},{"text":"Over what period is each lifecycle-definition version effective, and may two versions be effective at once for different subjects?","id":"q-mi-effective","kind":"temporal"},{"text":"Is the lifecycle definition itself governed by this same mixin, so that it can be draft, active, deprecated or retired?","id":"q-mi-selfapply","kind":"definition"}]},{"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.","questions":[{"text":"Which single registration authority or steward owns this lifecycle definition and may approve changes to it?","id":"q-ma-authority","kind":"authority"},{"text":"What proposal, review and decision procedure governs a change, and which dispositions are possible?","id":"q-ma-procedure","kind":"process"},{"text":"What happens to subjects that are mid-lifecycle when a state is removed or renamed, and who is accountable for their migration?","id":"q-ma-midflight","kind":"ownership"},{"text":"What makes a recorded state history conformant to the definition, and are non-conformant histories rejected, quarantined or tolerated?","id":"q-ma-conformance","kind":"validation"},{"text":"Is conformance to any external standard claimed for this lifecycle, and what evidence supports the claim?","id":"q-ma-claim","kind":"evidence"}]}]}]},{"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.","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.","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.","questions":[{"text":"What is the subject's current state on each axis, and which record is authoritative if several systems hold a copy?","id":"q-sar-current","kind":"state"},{"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?","id":"q-sar-since","kind":"temporal"},{"text":"Which agent asserted the current state, and on whose authority did they act?","id":"q-sar-agent","kind":"provenance"},{"text":"Is the current state stored as a materialised value or always recomputed from the transition log, and how is divergence detected?","id":"q-sar-storage","kind":"quality"}]},{"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.","questions":[{"text":"Is effective status asserted, derived from validity dates, or a hybrid, and which source wins when they disagree?","id":"q-dva-mode","kind":"decision"},{"text":"What is the deterministic algorithm for deriving effective status, including its inputs and the instant at which it is evaluated?","id":"q-dva-algorithm","kind":"process"},{"text":"Can a subject legitimately be 'active' on its status axis while outside its validity interval, or is that always a defect?","id":"q-dva-anomaly","kind":"constraint"},{"text":"How is a derived status cached and invalidated so that consumers never act on a stale computation?","id":"q-dva-cache","kind":"quality"}]},{"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.","questions":[{"text":"What authoritative master-system identifier uniquely names this lifecycle binding, and which system is the master?","id":"lifecycle-binding-identity-q01","kind":"identity"},{"text":"If no master-system identifier exists, what governed global IRI, or which Dimension-assigned UUID or ULID, identifies the binding?","id":"lifecycle-binding-identity-q02","kind":"identity"},{"text":"Has any date, validity start, or observation time been incorrectly treated as the binding identifier?","id":"lifecycle-binding-identity-q03","kind":"validation"}]},{"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.","questions":[{"text":"Which host subject does this lifecycle record describe, and by which identity priority is that host referenced?","id":"host-subject-and-aspect-binding-q01","kind":"relationship"},{"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?","id":"host-subject-and-aspect-binding-q02","kind":"composition"},{"text":"May the same host carry multiple concurrent lifecycle bindings (for example workflow status plus clinical status plus publication status)?","id":"host-subject-and-aspect-binding-q03","kind":"constraint"}]},{"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.","questions":[{"text":"Which states are currently active, and is that set a legal configuration?","id":"active-configuration-and-lossy-projection-q01","kind":"state"},{"text":"What single status code is projected from the configuration for systems that cannot represent a set, and is that projection lossy?","id":"active-configuration-and-lossy-projection-q02","kind":"interoperability"},{"text":"Are any child machines invoked from the current configuration, and what is their session identity and status?","id":"active-configuration-and-lossy-projection-q03","kind":"composition"}]}]},{"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.","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.","questions":[{"text":"What is the identifier of each transition event, and is the log strictly append-only?","id":"q-ter-id","kind":"identity"},{"text":"Which event time and which record time are captured for each transition, and by what rule may they differ?","id":"q-ter-times","kind":"temporal"},{"text":"Which state was left, which was entered, and which lifecycle-definition version was in force at that moment?","id":"q-ter-states","kind":"state"},{"text":"How are concurrent or out-of-order transition submissions ordered, de-duplicated and made replay-safe?","id":"q-ter-ordering","kind":"process"}]},{"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.","questions":[{"text":"Which governed reason code justifies this transition, and from which code list is it drawn?","id":"q-rea-code","kind":"classification"},{"text":"What supporting evidence is referenced for the transition, and is that evidence still retrievable for as long as the transition is relied upon?","id":"q-rea-evidence","kind":"evidence"},{"text":"Does the reason code change the consequences of the transition, for example by making invalidation retroactive rather than prospective?","id":"q-rea-consequence","kind":"constraint"},{"text":"Which role or agent was authorised to execute this transition, was dual control required, and was it exercised on behalf of another party?","id":"q-rea-authority","kind":"authority"},{"text":"How is an unauthorised or repudiated transition detected, recorded and remediated?","id":"q-rea-repudiation","kind":"security"}]}]}]},{"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.","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.","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.","questions":[{"text":"From which real-world instant is this state or assertion effective, and until which instant?","id":"q-vti-from","kind":"temporal"},{"text":"When the end boundary is absent, does that mean open-ended, unknown, or not yet decided?","id":"q-vti-missing-end","kind":"definition"},{"text":"Is the validity interval a property of the subject, of a particular assertion about it, or of one status axis?","id":"q-vti-scope","kind":"definition"},{"text":"May validity begin in the future, and what state does the subject hold in the interval before that instant?","id":"q-vti-future","kind":"state"}]},{"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.","questions":[{"text":"Are interval boundaries closed-closed or closed-open, and is that rule stated normatively rather than assumed from the storage engine?","id":"q-bpc-inclusive","kind":"constraint"},{"text":"To what precision are boundaries recorded, and how is a date-only boundary widened to an instant?","id":"q-bpc-precision","kind":"measurement"},{"text":"What convention marks 'no well-defined expiry', and is a sentinel value used rather than a null?","id":"q-bpc-noexpiry","kind":"definition"},{"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?","id":"q-bpc-zone","kind":"temporal"},{"text":"Which clock stamps record time, is it monotonic, and what inter-system skew is tolerated before a timestamp is rejected?","id":"q-bpc-clock","kind":"quality"}]},{"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.","questions":[{"text":"Must consecutive intervals on the same axis be contiguous, or are gaps permitted and what does a gap mean?","id":"q-irc-gap","kind":"constraint"},{"text":"May two intervals on the same axis overlap, and if so how is the effective value chosen?","id":"q-irc-overlap","kind":"decision"},{"text":"Which interval relations are used in constraints and queries, and are they named from a governed vocabulary?","id":"q-irc-relations","kind":"interoperability"},{"text":"How are zero-length and inverted intervals detected and handled?","id":"q-irc-degenerate","kind":"validation"}]}]},{"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.","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.","questions":[{"text":"For this transition, what are the event time, the observation or assertion time, and the record time, and are all three retained?","id":"q-rt-three","kind":"temporal"},{"text":"Which system and clock stamp the record time, and is it system-maintained and immutable by users?","id":"q-rt-authority","kind":"provenance"},{"text":"May record time precede event time, and what does such an inversion indicate?","id":"q-rt-inversion","kind":"exception"},{"text":"What ingestion latency between event time and record time is expected, and at what point does latency itself become a defect?","id":"q-rt-latency","kind":"measurement"}]},{"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.","questions":[{"text":"How is a wrong past state corrected without destroying the record of what the system previously believed?","id":"q-rcr-mechanism","kind":"provenance"},{"text":"What distinguishes a correction from an amendment and from a retraction in this model, and does the distinction change downstream obligations?","id":"q-rcr-kind","kind":"definition"},{"text":"Which downstream consumers must be told about a retroactive change, through what channel and within what period?","id":"q-rcr-notify","kind":"process"},{"text":"Can an as-at reconstruction of any earlier belief be produced on demand, and is that capability routinely tested?","id":"q-rcr-reconstruct","kind":"validation"}]}]}]},{"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.","layers":[{"id":"succession-and-deprecation","name":"Succession and Deprecation","description":"Replacement chains, current-version resolution, and the discouragement of continued use ahead of withdrawal.","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.","questions":[{"text":"Which item supersedes this one, is the link recorded in both directions, and is it dereferenceable?","id":"q-srl-link","kind":"relationship"},{"text":"Is this a version relation (same thing, new version) or a replacement relation (a different thing taking over the role)?","id":"q-srl-kind","kind":"definition"},{"text":"From which instant does supersession take effect, and does the superseded item remain resolvable afterwards?","id":"q-srl-effective","kind":"temporal"},{"text":"How is a chain of successive supersessions traversed to reach the current item, and what terminates the traversal?","id":"q-srl-chain","kind":"process"}]},{"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.","questions":[{"text":"What does deprecated mean operationally here — still valid but discouraged, or invalid for new use while valid for existing use?","id":"q-ds-meaning","kind":"definition"},{"text":"What sunset date has been announced, and what minimum notice period does the governing policy require?","id":"q-ds-sunset","kind":"temporal"},{"text":"What migration target and guidance are published with the deprecation, and is backward compatibility asserted or denied?","id":"q-ds-migration","kind":"interoperability"},{"text":"Are existing uses grandfathered, and until when?","id":"q-ds-grandfather","kind":"exception"}]},{"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.","questions":[{"text":"If this status or host is replaced, which resource or binding supersedes it, and is the inverse isReplacedBy asserted?","id":"replacement-and-entered-in-error-q01","kind":"relationship"},{"text":"Is the host entered-in-error, replaced, retired, or inactive, and why is that distinction required for consumers?","id":"replacement-and-entered-in-error-q02","kind":"classification"},{"text":"Must the erroneous or replaced record be retained for integrity or digital signatures even though it must be ignored?","id":"replacement-and-entered-in-error-q03","kind":"retention"}]}]},{"id":"invalidation","name":"Invalidation","description":"Revocation and suspension, their reversibility, their dating and their retroactive effect on acts already performed.","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.","questions":[{"text":"Is this invalidation reversible (suspension) or irreversible (revocation), and where is that reversibility contract stated?","id":"q-rs-kind","kind":"lifecycle"},{"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?","id":"q-rs-communicate","kind":"interoperability"},{"text":"What reason code and human-readable status message accompany the invalidation, and can several statuses apply at once?","id":"q-rs-message","kind":"classification"},{"text":"What happens to obligations, permissions and artifacts issued while the subject was valid?","id":"q-rs-artifacts","kind":"constraint"}]},{"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.","questions":[{"text":"From which instant is the subject considered invalid — the decision instant, the publication instant, or an earlier known-or-suspected instant?","id":"q-ide-instant","kind":"temporal"},{"text":"Does invalidation apply retroactively to acts performed before the decision was published, and on what legal or policy basis?","id":"q-ide-retro","kind":"constraint"},{"text":"How is known invalidity distinguished from suspected invalidity, and does the distinction change the recorded instant?","id":"q-ide-suspicion","kind":"quality"},{"text":"Who bears the risk for reliance occurring between the invalidity instant and the publication instant?","id":"q-ide-risk","kind":"ownership"}]}]},{"id":"end-of-life","name":"End of Life","description":"Lifecycle end as the trigger for retention, disposition, logical deletion and erasure.","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.","questions":[{"text":"Which lifecycle state or transition starts the retention clock, and how long does retention then run?","id":"q-rtd-trigger","kind":"retention"},{"text":"Which authority approved the disposition rule, when was it approved, and when is it next due for review?","id":"q-rtd-authority","kind":"authority"},{"text":"What action follows expiry — destroy, transfer, retain permanently, or re-appraise — and who executes it?","id":"q-rtd-action","kind":"process"},{"text":"How is disposition suspended by a legal hold, who may impose and release it, and how is the suspension recorded?","id":"q-rtd-hold","kind":"exception"}]},{"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.","questions":[{"text":"Is deletion logical (retired status plus tombstone) or physical, and which mode applies to which class of content?","id":"q-lde-mode","kind":"definition"},{"text":"How is an erasure obligation reconciled with an append-only lifecycle history, and what is removed versus what is retained?","id":"q-lde-erasure","kind":"privacy"},{"text":"What minimum tombstone remains after deletion so that inbound references still resolve rather than dangle?","id":"q-lde-tombstone","kind":"interoperability"},{"text":"Who authorises and witnesses destruction, and what evidence of destruction is retained and for how long?","id":"q-lde-evidence","kind":"evidence"}]}]}]},{"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.","layers":[{"id":"lifecycle-operations","name":"Lifecycle Operations","description":"Requesting and applying transitions, resolving state across both time lines, and handling exceptions.","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.","questions":[{"text":"What is the idempotency key for a transition request, and what exactly happens when the same request is replayed?","id":"q-tec-idempotency","kind":"process"},{"text":"How is a lost update prevented when two agents attempt to transition the same subject at the same time?","id":"q-tec-concurrency","kind":"constraint"},{"text":"Is the state change atomic with its mandated effects, or eventually consistent, and what compensates a partial failure?","id":"q-tec-atomicity","kind":"quality"},{"text":"What is returned when a transition is rejected, and is the rejection itself recorded as evidence?","id":"q-tec-rejection","kind":"exception"}]},{"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.","questions":[{"text":"What was the state as of a given real-world instant, as known at a given record instant?","id":"q-tsr-two","kind":"temporal"},{"text":"Which defaults apply when the caller supplies neither instant, and are those defaults stated rather than implied?","id":"q-tsr-default","kind":"decision"},{"text":"Is the same query guaranteed to return the same answer later, and how is that reproducibility demonstrated to an auditor?","id":"q-tsr-repro","kind":"validation"},{"text":"How are subjects listed or filtered by status without disclosing states the caller is not permitted to see?","id":"q-tsr-listing","kind":"access"}]},{"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.","questions":[{"text":"What happens when a recorded state is not in the state set of the governing lifecycle version?","id":"q-eih-orphan","kind":"exception"},{"text":"How is indeterminate status represented so that it is not mistaken for a real state or for an absent record?","id":"q-eih-unknown","kind":"definition"},{"text":"How is a stale status detected — no transition for longer than the expected dwell time — and to whom is it escalated?","id":"q-eih-stale","kind":"quality"},{"text":"Is an emergency override of the transition rules permitted, who may authorise it, and what compensating controls and review apply?","id":"q-eih-override","kind":"authority"}]}]},{"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.","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.","questions":[{"text":"To which external status vocabularies is each local state mapped, at which version of each target, and with what mapping strength?","id":"q-esm-targets","kind":"interoperability"},{"text":"Which mappings are lossy, and precisely what information is lost in each direction?","id":"q-esm-loss","kind":"quality"},{"text":"Where external vocabularies conflict, is the conflict recorded rather than silently reconciled?","id":"q-esm-conflict","kind":"exception"},{"text":"Who maintains each mapping, and when was it last revalidated against the current version of the target vocabulary?","id":"q-esm-maintenance","kind":"ownership"}]},{"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.","questions":[{"text":"In what form is status published — pull, push, or embedded in the subject — and what is the authoritative source if several channels exist?","id":"q-spv-channel","kind":"interoperability"},{"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?","id":"q-spv-freshness","kind":"constraint"},{"text":"How is published status protected against tampering, replay and rollback to an earlier state?","id":"q-spv-integrity","kind":"security"},{"text":"Who may see subjects in pre-publication states, and are transition reasons restricted more tightly than the state value itself?","id":"q-spv-visibility","kind":"access"},{"text":"Does publishing status disclose information about individual subjects, and what minimum group size or padding protects them?","id":"q-spv-privacy","kind":"privacy"}]}]}]}]},"agentConduct":{"may":["Resolve the effective state of a subject at an instant.","Check whether a requested transition is legal under the pinned lifecycle definition.","Apply a legal transition with actor, reason and time.","Correct a past record by appending a correction, keeping the original."],"mustNot":["Apply a transition that the lifecycle definition does not allow.","Overwrite state history instead of appending.","Confuse record time with effective time when answering as-of questions.","Revoke, suspend or dispose of a subject without the required authority.","Reinstate a revoked subject without recorded reasons."],"requiresHuman":["Revoking or suspending a subject with legal or safety effect.","Executing disposition.","Changing a published lifecycle definition."]},"ethics":{"considerations":["Status such as revoked or suspended can cut people off from services, credentials or rights.","History must stay accurate so people can prove their status at a past date.","Retroactive corrections must stay visible to keep accountability."],"affectedParties":["Holders and subjects of the records","Authorities that change status","Parties who rely on status checks"]},"owners":{"steward":"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.","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"]}],"masterSystems":[]},"relations":[{"target":"Host world-model entry composing this mixin (any entity, event, relationship, aggregate, registry or classifier)","type":"composes","note":"Supply the host entry with a governed state machine, current-state assertion, bitemporal validity and disposition hooks without imposing any domain semantics."},{"target":"Classification / Code List Registry model (sibling; not yet registered)","type":"composes","note":"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."},{"target":"Identity & Identifier model (sibling; not yet registered)","type":"references","note":"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."},{"target":"Provenance & Lineage model (sibling; not yet registered)","type":"references","note":"Transition attribution, generation and invalidation timestamps extend the general provenance graph rather than duplicating it."},{"target":"Versioning & Change Control model (sibling; not yet registered)","type":"references","note":"Supersession and deprecation states here point at version lineage maintained there; version identity and content deltas are not modelled in this mixin."},{"target":"Records Retention & Disposition model (sibling; not yet registered)","type":"references","note":"Lifecycle end supplies the retention trigger; the authorised, dated disposition instrument and the appraisal behind it live in the retention model."},{"target":"Authorization & Access Control model (sibling; not yet registered)","type":"references","note":"Transition authority basis and state visibility classes are recorded here and evaluated there; no policy language is defined in this mixin."},{"target":"Process / Workflow Orchestration model (sibling; not yet registered)","type":"references","note":"Workflow tasks drive transitions but the declarative state machine, not the task graph, is the authority on legal states."},{"target":"Temporal Reference & Calendar model (sibling; not yet registered)","type":"references","note":"Interval algebra, temporal reference systems and calendar arithmetic are supplied there; this mixin consumes them for validity intervals."},{"target":"Event Record model (sibling; not yet registered)","type":"references","note":"A lifecycle transition is a constrained event subtype; general event payloads and correlation belong to the event model."},{"target":"ISO 19135-1:2015 register item status (RE_ItemStatus: notValid, valid, superseded, retired) and proposal disposition","type":"aligned","note":"Alignment target for register-style lifecycles, including the requirement that retired, superseded and invalid items remain resolvable. Alignment only; no conformance is claimed."},{"target":"ISO/IEC 11179-6:2023 registration status (lifecycle versus documentation status categories, single registration authority)","type":"aligned","note":"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."},{"target":"HL7 FHIR R5 PublicationStatus value set (draft | active | retired | unknown)","type":"aligned","note":"Alignment target for a minimal normative governance axis, including an explicit code for indeterminate status."},{"target":"W3C PROV-O (generation, invalidation, revision, attribution)","type":"aligned","note":"Alignment target for transition provenance, invalidation instants and revision links."},{"target":"W3C Verifiable Credentials Data Model 2.0 and Bitstring Status List v1.0","type":"aligned","note":"Alignment target for the separation of validity period from status, and for reversible suspension versus irreversible revocation with published status lists."},{"target":"IETF RFC 5280 certificate validity and CRLReason enumeration","type":"aligned","note":"Alignment target for validity boundaries, no-expiry conventions, reason codes with consequences, hold-and-release reversibility and invalidity dating."},{"target":"IETF RFC 3339 and RFC 9557 timestamp semantics","type":"aligned","note":"Normative alignment for every timestamp in the model: explicit offset or Z, second precision, and IANA zone annotation for future-dated boundaries."},{"target":"W3C SCXML and OMG UML 2.5.1 behavioural state machines","type":"aligned","note":"Alignment target for the state-machine formalism: states, transitions, triggers, guards, effects, regions, history and deterministic conflict resolution."},{"target":"SQL:2011-style application-time and system-versioned period tables","type":"aligned","note":"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."},{"target":"DCMI Metadata Terms and DCAT 3 / ADMS versioning and status properties","type":"aligned","note":"Alignment target for validity dates and supersession links in catalogue and metadata contexts."},{"target":"ISO 15489-1:2016 disposition authorities and NARA General Records Schedules","type":"aligned","note":"Alignment target for lifecycle-triggered retention: authorities that are authorised, dated, implemented and reviewed, issued and versioned externally."},{"target":"Regulation (EU) 2016/679 Articles 5(1)(e), 17 and 30","type":"aligned","note":"Legal constraint alignment for storage limitation, erasure and processing records, which bounds the append-only history where personal data is involved."},{"target":"schema.org EventStatusType","type":"aligned","note":"Alignment target for widely deployed public status vocabularies, and a recorded counterexample of conflating lifecycle state with modality change."},{"target":"Provenance & Lineage model","type":"neighbor","note":"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."},{"target":"Versioning & Change Control model","type":"neighbor","note":"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."},{"target":"Records Retention & Disposition model","type":"neighbor","note":"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."},{"target":"Authorization & Access Control model","type":"neighbor","note":"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."},{"target":"Process / Workflow Orchestration model","type":"neighbor","note":"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."},{"target":"Temporal Reference & Calendar model","type":"neighbor","note":"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."},{"target":"Classification / Code List Registry model","type":"neighbor","note":"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."},{"target":"Credential / Certificate model","type":"neighbor","note":"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."},{"target":"Event Record model","type":"neighbor","note":"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."}],"interaction":{"identity":{"applicability":"required","items":["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."]},"properties":{"applicability":"not-applicable","items":[]},"recognition":{"applicability":"optional","items":["Lifecycle fields carry a state, a definition reference, validity times and a transition history.","Often confused with workflow task status, version history and access rights."]},"capabilities":{"applicability":"required","items":["Resolve effective state: 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.","Evaluate transition legality: 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.","Apply transition: 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.","Assert or adjust validity period: Set or adjust the real-world validity interval of a state or assertion independently of the status value, honouring boundary and precision conventions.","Supersede subject: 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.","Deprecate subject with sunset: Mark a subject as discouraged for new use, publish the sunset date, migration target and compatibility position, without changing its formal semantics.","Revoke or suspend subject: Apply an invalidation with an explicit reversibility class, reason code, invalidity instant and retroactivity ruling, and queue it for publication to relying parties.","Reinstate subject: 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.","Correct or amend a past record: Issue a correction, clarification, amendment or retraction of an earlier assertion without editing it in place, preserving the earlier belief for as-at reconstruction.","Validate lifecycle conformance: 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.","Evaluate disposition trigger: 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.","Execute disposition: Carry out the due disposition action — destroy, transfer, retain permanently or re-appraise — and leave the required tombstone and evidence.","Publish status projection: Produce and distribute the current status projection for a population of subjects, with its publication instant, maximum staleness, integrity proof and privacy sizing.","Map external status: Translate a state between the local vocabulary and a named external vocabulary version, returning the mapping strength and any information lost.","Bind lifecycle mixin: Attach a lifecycle binding to a host with a governing machine, code system, pattern family and identifiers.","Mark entered in error: Set error or entered-in-error without deleting the host, record the correction, and apply any redaction or notification policy.","Restore history configuration: On re-entry of a compound state, apply stored shallow or deep history instead of the default child."]},"hazards":{"applicability":"required","items":["Acting on a stale status, such as accepting a revoked credential.","Illegal transitions leave records in impossible states.","Lost history breaks audit and proof of past status."]},"interfaces":{"applicability":"required","items":["RFC 3339 and RFC 9557 timestamps.","RFC 5280 certificate and CRL status model.","ISO 15489-1 records management.","W3C PROV-O.","OMG SysML or UML state machine notation."]},"context":{"applicability":"required","items":["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."]}},"sources":[{"title":"RFC 3339: Date and Time on the Internet: Timestamps","url":"https://www.rfc-editor.org/rfc/rfc3339","note":"Internet Engineering Task Force (IETF)"},{"title":"RFC 9557: Date and Time on the Internet: Timestamps with Additional Information","url":"https://www.rfc-editor.org/rfc/rfc9557.html","note":"Internet Engineering Task Force (IETF)"},{"title":"RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile","url":"https://www.rfc-editor.org/rfc/rfc5280","note":"Internet Engineering Task Force (IETF)"},{"title":"PROV-O: The PROV Ontology","url":"https://www.w3.org/TR/prov-o/","note":"World Wide Web Consortium (W3C)"},{"title":"Verifiable Credentials Data Model v2.0","url":"https://www.w3.org/TR/vc-data-model-2.0/","note":"World Wide Web Consortium (W3C)"},{"title":"Bitstring Status List v1.0","url":"https://www.w3.org/TR/vc-bitstring-status-list/","note":"World Wide Web Consortium (W3C)"},{"title":"State Chart XML (SCXML): State Machine Notation for Control Abstraction","url":"https://www.w3.org/TR/scxml/","note":"World Wide Web Consortium (W3C)"},{"title":"Time Ontology in OWL","url":"https://www.w3.org/TR/owl-time/","note":"World Wide Web Consortium (W3C)"},{"title":"Data Catalog Vocabulary (DCAT) - Version 3","url":"https://www.w3.org/TR/vocab-dcat-3/","note":"World Wide Web Consortium (W3C)"},{"title":"OWL 2 Web Ontology Language Structural Specification and Functional-Style Syntax (Second Edition)","url":"https://www.w3.org/TR/owl2-syntax/","note":"World Wide Web Consortium (W3C)"},{"title":"Asset Description Metadata Schema (ADMS)","url":"https://www.w3.org/TR/vocab-adms/","note":"World Wide Web Consortium (W3C)"},{"title":"FHIR ValueSet: PublicationStatus","url":"https://hl7.org/fhir/valueset-publication-status.html","note":"Health Level Seven International (HL7)"},{"title":"FHIR Data Types (Period, instant, dateTime)","url":"https://hl7.org/fhir/datatypes.html","note":"Health Level Seven International (HL7)"},{"title":"FHIR Resource: Provenance","url":"https://hl7.org/fhir/provenance.html","note":"Health Level Seven International (HL7)"},{"title":"DCMI Metadata Terms","url":"https://www.dublincore.org/specifications/dublin-core/dcmi-terms/","note":"Dublin Core Metadata Initiative (DCMI)"},{"title":"ISO 19135-1:2015 Geographic information — Procedures for item registration — Part 1: Fundamentals","url":"https://www.iso.org/standard/54721.html","note":"International Organization for Standardization (ISO)"},{"title":"ISO 15489-1:2016 Information and documentation — Records management — Part 1: Concepts and principles","url":"https://www.iso.org/standard/62542.html","note":"International Organization for Standardization (ISO)"},{"title":"ISO/IEC 11179-6:2023 Information technology — Metadata registries (MDR) — Part 6: Registration","url":"https://www.iso.org/standard/78916.html","note":"ISO/IEC JTC 1/SC 32"},{"title":"Unified Modeling Language (UML), version 2.5.1","url":"https://www.omg.org/spec/UML/2.5.1/About-UML/","note":"Object Management Group (OMG)"},{"title":"Regulation (EU) 2016/679 (General Data Protection Regulation)","url":"https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng","note":"European Parliament and Council of the European Union"},{"title":"General Records Schedules (GRS)","url":"https://www.archives.gov/records-mgmt/grs","note":"U.S. National Archives and Records Administration (NARA)"},{"title":"UK Government Linked Data Registry vocabulary (registryVocab.ttl)","url":"https://raw.githubusercontent.com/ukgovld/registry-core/master/src/main/vocabs/registryVocab.ttl","note":"UK Government Linked Data Working Group (UKGovLD)"},{"title":"schema.org EventStatusType","url":"https://schema.org/EventStatusType","note":"Schema.org Community Group"},{"title":"MariaDB Server documentation: Temporal Tables","url":"https://mariadb.com/docs/server/reference/sql-structure/temporal-tables","note":"MariaDB"},{"title":"FHIR Life Cycle Page (Resource Status, Current Lists, Entered in Error)","url":"https://www.hl7.org/fhir/lifecycle.html","note":"Health Level Seven International (HL7)"},{"title":"CodeSystem http://hl7.org/fhir/resource-status — Canonical Status Codes for FHIR Resources","url":"https://hl7.org/fhir/codesystem-resource-status.html","note":"Health Level Seven International (HL7)"},{"title":"ISO 19108:2002 Geographic information — Temporal schema","url":"https://www.iso.org/standard/26013.html","note":"International Organization for Standardization (ISO/TC 211)"},{"title":"Precise Semantics of UML State Machines (PSSM) Version 1.0","url":"https://www.omg.org/spec/PSSM/1.0/PDF","note":"Object Management Group (OMG)"},{"title":"HL7 FHIR R5 Period datatype (StructureDefinition)","url":"https://www.hl7.org/fhir/R5/period.profile.json","note":"Health Level Seven International (HL7)"}],"openQuestions":["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.","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."],"resources":{"spec":"/models/wm-xct-021-lifecycle-status/spec.yaml","agents":"/models/wm-xct-021-lifecycle-status/AGENTS.md","source":"https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-xct-021"},"provenance":{"origin":"world-models research","builtFrom":["models/wm-xct-021-lifecycle-status/spec.yaml","ver-cy/world-models/card-supplements/wm-xct-021-lifecycle-status.json"],"providers":["Claude","Grok"],"researchStatus":"reviewable-draft","generatedAt":"2026-08-22T22:18:03Z","builder":"tools/build_cards.py@1.0.0"},"completeness":{"sections":{"classifiers":"filled","whatItIs":"filled","purpose":"filled","distinguishingFeatures":"filled","structure":"filled","agentConduct":"filled","ethics":"filled","owners":"filled","relations":"filled","interaction.identity":"filled","interaction.properties":"not-applicable","interaction.recognition":"filled","interaction.capabilities":"filled","interaction.hazards":"filled","interaction.interfaces":"filled","interaction.context":"filled","sources":"filled"},"notes":{"interaction.properties":"Institutional or informational subject: no invented physical properties.","_supplement":"Sections authored in card supplement 1.0.0 by Claude (Opus 5.5) (2026-10-05, unreviewed). Written from the published specification and established practice in the field; no new sources were read. Unreviewed."},"score":1.0}}