Published

Version / Change History

vr.wm-xct-022 · wm-xct-022-version-change-history

Give any Vercy world-model entry a composable, storage-neutral way to declare revision identity, ordered predecessor/successor lineage, the substance and authority of each change, and the migration path between versions, so an agent can identify which state it holds, reconstruct any prior state, and decide whether it must migrate.

World Models Cross-cutting context XCT.VER

Bundle → Layer → Finding → Questions Classifiers What it is Why it exists Distinguishing features What robots and AI may and may not do Moral aspects Owners Links to other meta-models Identity and identifiers Direct properties Recognition Capabilities and actions Hazards and failure modes Standards and interfaces Context of use Sources

Bundle → Layer → Finding → Questions Filled

6 bundles · 12 layers · 26 findings · 119 questions

Revision Identity and Designation How a single revision of a host entity is identified, labelled, ordered against its siblings, and distinguished from the version-independent identity of the entity itself.

Revision Identity and Addressing

The identifiers that fix one revision, the label humans and tooling see, and the relation between a revision and the entity series it belongs to.

Revision identifier assignment and immutability

Which system issues the identifier for a revision, what form it takes, and the guarantee that the identifier is never reused or re-pointed at different content.

Which system is the authoritative issuer of this revision identifier, and is it the same system that holds the host entity's master record? identity
What identifier form is used for the revision, and is it opaque or does it encode meaning? identity
Is the revision identifier guaranteed never to be reused or re-pointed at different content, and what enforces that? constraint
How does the revision identifier relate to the persistent identifier of the versioned entity itself? relationship
Which validator may be derived from this revision for conditional access, and is it strong or weak? interoperability

Version designation scheme and its promise

The human- and machine-facing version label attached to a revision, the grammar it obeys, and whether an increment carries a normative compatibility promise or is merely descriptive.

Which version designation grammar does this entity declare, and where is that declaration published? classification
Does an increment in the designation carry a normative compatibility promise, or is the designation descriptive only? constraint
Against which declared public surface is a breaking change judged? definition
How are pre-release, post-release, development, epoch and build or local qualifiers handled, and do they affect precedence? constraint

Series identity and resolution of the current version

The version-independent series identifier, the relations that bind a revision to its series, and how 'the latest' is defined when branches exist.

Does a version-independent identifier exist for the entity series, and what does dereferencing it yield? identity
Which relations assert that this revision is a version of the series and which assert the series' current version? relationship
How is 'latest' defined when concurrent branches or contexts each have a most recent revision? decision
May the series identifier be used as an evidentiary citation target, or must citations pin a revision? evidence

Ordering, Precedence and Currency

How revisions are ordered relative to one another, which fields participate in comparison, and which revision is currently in force.

Precedence rules and head pointer

The total or partial order over revisions, the fields that are deliberately excluded from comparison, and the mutable pointer that names the revision currently in force for each branch.

Is the order over revisions total or partial, and what produces partiality? constraint
Which fields participate in precedence comparison and which are explicitly ignored? constraint
Can ordering be derived from the identifier or label alone, or must the predecessor graph be traversed? decision
Which revision is currently in force for each branch, and who may move that pointer? authority
May the head move backwards to an earlier revision, and how is that recorded? lifecycle

Change Lineage and Topology The graph of predecessor and successor relations between revisions, the semantic type of each link, and lineage that crosses entity or organisational boundaries.

Predecessor and Successor Topology

The direct ancestry of a revision, including multi-parent merges, branch scoping and the completeness guarantee on the link set.

Predecessor set, merge topology and graph integrity

Which revisions this revision directly succeeds, whether the history is a linear chain or a directed acyclic graph with merges, and how completeness and acyclicity are guaranteed.

Which revisions does this revision directly succeed, and is the predecessor set empty because it is the root? relationship
Does the history of this entity form a linear chain or a directed acyclic graph with merge nodes? composition
When a revision has multiple predecessors, what merge strategy produced it and was any predecessor content discarded? process
Is the predecessor set closed and verifiable, or may it be incomplete because of import, embargo or disposition? quality
Are cycles, self-references and dangling predecessor references structurally prohibited and actually validated? validation

Replacement and supersession

dcterms:replaces / isReplacedBy record that one resource supplants, displaces or supersedes another and are used when only one version is valid. DataCite IsNewVersionOf / IsPreviousVersionOf link editions when one version supersedes another and both DOIs remain. DCAT points to section 11.1.2 for versions replaced by other ones. Replacement is not identical to previousVersion: a chain of historical snapshots may keep all versions citable while a replaces link marks which is valid.

Which prior resource does this revision supplant, displace or supersede, and does the prior resource remain citable? relationship
If persistent identifiers are used, is this identifier linked as IsNewVersionOf the previous edition and the previous as IsPreviousVersionOf this one? interoperability
Is only one version valid in this chain, as in successive drafts of a contract, or are historical snapshots still in force for citation? constraint
Who authorised the replacement, and at what event time versus observation time? authority

Derivation Semantics and External Lineage

The typed meaning of a change link and the recording of upstream external versions consumed to produce a revision.

Revision versus derivation versus format variant

The test that decides whether a change produces a new revision of the same entity, a derivation into a distinct entity, or merely a new rendition of unchanged content.

Is this a revision of the same entity, a derivation into a new entity, or only a new format or rendition of unchanged content? classification
What test distinguishes 'substantial content retained, therefore a revision' from 'a new entity'? definition
Does a change of entity identifier accompany this change, and on what grounds? identity
Are the two records alternates of one another, or specialisations of a shared abstract entity? relationship

Upstream and ingredient version dependency

The external or upstream artefact versions consumed to produce a revision, whether those references are pinned, and how upstream withdrawal is detected.

Which external or upstream artefact versions were consumed to produce this revision? provenance
Is each upstream reference pinned to an immutable version and digest, or does it point at a moving target? constraint
How is an upstream version withdrawal, re-tagging or yank detected after this revision was produced? event
What is recorded when upstream provenance is unavailable or cannot be verified? evidence

Change Substance, Compatibility and Migration What actually changed between two revisions, how significant it is, how it is described to humans, and what a consumer must do to move forward.

Change Sets and Change Classification

The machine-readable delta, its significance, and the human-readable account of it.

Change set representation and verifiability

Whether a revision is stored as a full snapshot, a forward delta or both, which patch formalism expresses the delta, and how a consumer proves the delta reproduces the successor state.

Is this revision stored as a full state snapshot, as a forward delta against its predecessor, or as both? composition
Which patch or diff formalism expresses the delta, and at what version? interoperability
Are delta operations applied atomically, and what is the defined outcome when one operation fails? constraint
Can the delta be verified to reproduce the successor state exactly, and against which digest? validation
Is the delta invertible so that the predecessor state can be recomputed from the successor? constraint

Change classification, significance and human-readable note

The categories, breaking status, semantic impact and severity of the change, together with the concise human-readable account required for a usable version history.

What categories of change does this revision contain? classification
Is any change in this revision breaking for declared consumers of the declared public surface? constraint
Does the change alter meaning, or only presentation, encoding or format? definition
Is this revision a correction of a previously published error, and does it supersede a published statement? quality
What concise human-readable statement describes what changed and why, and in which languages is it maintained? definition
Is the human-readable note guaranteed complete with respect to the machine-readable delta? quality

Compatibility, Migration and Deprecation

What a consumer must know and do to move between versions, and how the retirement of a version is announced and timed.

Compatibility declaration and its evidence

With which prior versions this revision is declared compatible or incompatible, in which direction, and what evidence supports the claim.

With which prior versions is this revision declared backward compatible, and with which incompatible? constraint
Is compatibility asserted for readers of newer data, for writers producing older data, or in both directions? definition
What evidence supports the compatibility claim, and can it be re-executed? evidence
How are optional and defaulted elements treated when an older consumer reads data produced under this revision? interoperability

Migration procedure between versions

The procedure that moves an instance, a store or a consumer from the predecessor version to this revision, including reversibility, idempotence, accepted loss and responsibility.

Is a migration required to adopt this revision, or is adoption transparent to existing instances and consumers? requirement
What procedure moves an instance from the predecessor version to this revision, and in what order are its steps executed? process
Is the migration reversible, and what is the documented rollback path? lifecycle
Is the migration idempotent and safe to re-run after a partial failure? constraint
What data loss, precision loss or semantic loss is expected and accepted by this migration? quality
Who is responsible for executing the migration, and by when must it complete? ownership

Deprecation and sunset of a version

The announcement that a revision, element or endpoint is deprecated, the instant it stops being served, and the replacement a consumer should adopt.

Is this revision, or an element within it, deprecated, and from which instant does the deprecation take effect? state
At which instant will the deprecated revision or endpoint stop being served, and is that instant at or after the deprecation instant? temporal
What replacement is recommended, and where is the migration guidance published? decision
How is the deprecation signalled to consumers that only interact through the access interface? interoperability

Temporal Frame and Revision Lifecycle When a change happened, when it was recorded, over what period the revision's content is asserted to hold, and which lifecycle state the revision occupies.

Time Model of a Revision

The distinct instants attached to a revision and the periods over which its content is asserted to be true.

Change-event time, record time and publication time

The separate instants at which the change occurred, was recorded, and was published, together with their clock source, precision and monotonicity guarantees.

At what instant did the change event occur, and at what separate instant was it recorded by the system of record? temporal
Which clock and which offset are authoritative for the recorded instants, and is the timestamp computer-generated? provenance
Is the recorded time monotonic across the revision sequence, and what is done when it is not? exception
What temporal precision is guaranteed, and is an independently attested timestamp required? measurement

Effective period, supersession and retroactive correction

The period over which a revision's content is asserted to hold in the world, when the predecessor ceased to be the record of truth, and how as-of queries are resolved when record time and effective time disagree.

Over which period is the content of this revision asserted to be true in the world, as distinct from when it was recorded? temporal
Does this revision correct the record for a past period, or does it apply only forward from its effective instant? decision
At which instant did the predecessor revision cease to be the record of truth? state
When an as-of query is issued, is it resolved against record time or effective time, and how is the choice signalled? process

Revision Lifecycle and Withdrawal

The states a revision may occupy, the point at which it becomes immutable, and how retraction, deletion and deactivation are represented.

Revision lifecycle states and legal transitions

The permitted states of a revision from working copy through release to supersession, the state at which immutability attaches, and who may effect each transition.

What lifecycle states may a revision occupy, and which transitions between them are legal? lifecycle
At which state does the revision become immutable, and what enforces immutability from that point? constraint
Who may promote a working copy or draft to a released revision? authority
May a released revision return to draft, and if not, what is the substitute mechanism? exception
What happens to a working copy or checkout that is never checked in? state

Withdrawal, tombstoning and deletion in history

How retraction, deactivation and deletion are represented so that a consumer can distinguish 'removed' from 'never existed', and whether reinstatement is possible.

How is a withdrawal, retraction, deactivation or deletion represented in the history? event
Does the withdrawal remove content, remove availability, or only mark status? definition
Is a tombstone published so that consumers can distinguish a deleted revision from one that never existed? interoperability
Can a withdrawn revision be reinstated, and under whose authority? authority
What reason is recorded for the withdrawal, and is that reason itself disclosable? privacy

Change Authority, Attribution and Record Integrity Who made a change, under what authority, and what makes the resulting history verifiable and tamper-evident.

Agency and Change Authority

The agent that performed the change and the authority or approval under which it was permitted.

Attribution of the change to an agent

Which agent performed the change, on whose behalf, whether that agent is a person, organisation or software, and how the attribution is substantiated.

Which agent performed the change, and on whose behalf did they act? ownership
Is the agent a person, an organisation or a software agent, and is that distinction recorded explicitly? classification
Is the identity of the agent verified, and by what means? evidence
Which activity, process or job produced this revision? provenance

Change authorisation and approval

The authority under which the change was permitted, the approval decision bound to it, and the declared meaning of any signature applied.

Under what authority was this change permitted to be made? authority
Was formal approval required before release, who approved it, and at what instant? decision
What request, ticket or justification triggered the change? process
What is the declared meaning of any signature applied to this revision? evidence
Was an impact analysis performed before approval, and is its outcome retained? requirement

Integrity, Fixity and Tamper Evidence

What fixes the content of a revision, what binds history entries to one another, and how redaction is performed without destroying verifiability.

Content fixity and canonicalisation

The digest that fixes a revision's content, the canonicalisation applied before digesting, how digest-algorithm change is handled, and who re-verifies fixity over time.

What digest, computed over what canonical byte sequence, fixes the content of this revision? validation
Which canonicalisation rules are applied before digesting, and which fields are excluded from the digest scope? constraint
How is a change of digest algorithm handled without invalidating historical fixity? process
Who re-verifies fixity, how often, and what happens when verification fails? quality
Is any exposed access-interface validator distinct from the content digest, and is that distinction documented? interoperability

Tamper evidence and redaction of history

How the append-only property of history is enforced and evidenced, what binds each entry to its predecessor, and how sensitive content is redacted from past revisions without destroying the ability to verify what remains.

Is the change history append-only, and what technical and organisational controls enforce that? security
Can a history entry be altered or removed, and does any such alteration itself leave a record that does not obscure the previous entry? security
How is redaction of sensitive content in past revisions performed without destroying verifiability of the remaining history? exception
What cryptographically binds each history entry to its predecessor? evidence
Who is technically capable of forging or suppressing a history entry, and which controls detect it? security

History Access, Retention and Interoperability How consumers reach and reconstruct history, how concurrent writers are reconciled, how long history is kept, and how version semantics are exchanged with other systems.

Access to and Reconstruction of History

Enumeration, as-of retrieval, reconstruction from deltas, concurrency control and the visibility of history entries.

History enumeration, as-of retrieval and state reconstruction

How a consumer lists the revisions of an entity, retrieves the state as of a given instant, and rebuilds a historical state when only deltas are stored.

How does a consumer enumerate the revisions of an entity, and is the enumeration complete, stably ordered and pageable? access
How is the state of the entity as of a given instant retrieved? temporal
How is a historical state reconstructed when only forward deltas are stored? process
What are the cost and latency bounds of retrieving deep history, and is any part cold-stored? measurement

Concurrency control and conflict outcome

How simultaneous revision attempts on one entity are reconciled, what precondition an update must carry, and what happens when the precondition fails.

How is a lost update prevented when two agents revise the same entity concurrently? constraint
What precondition must an update carry, and what is returned when the precondition is not met? process
How are conflicting concurrent revisions detected and resolved? exception
Is there an explicit lock or checkout model, and what happens to abandoned locks? state

History visibility, disclosure and embargo

Whether history is visible to the same audience as the current state, which parts carry heightened sensitivity, and how existence can be disclosed while content is withheld.

Is the change history visible to the same audience as the current state of the entity? access
Which parts of a history entry may reveal personal data, security detail or confidential rationale? privacy
Can a past revision be embargoed so that its existence is visible but its content is not? exception
Who may read agent identities, approval records and change reasons within the history? security

Retention, Disposition and External Alignment

How long history is kept, how it may lawfully be reduced, and how its semantics are exchanged with external vocabularies and interfaces.

Retention, compaction and lawful disposition of history

The retention obligation on each revision and history entry, whether history may be compacted or pruned, and how an erasure obligation is reconciled with an append-only, digest-chained record.

How long must each revision and its history entry be retained, and on what basis? retention
May history be compacted, squashed or pruned, and what must survive compaction? decision
How is a lawful erasure or rectification request reconciled with an append-only, digest-chained history? exception
Who authorises disposition and what evidence of the disposition is retained afterwards? authority
Does a legal hold suspend disposition, and how is a held entry marked? requirement

External alignment, crosswalks and exchange

Which external version vocabularies this model is mapped to, whether those mappings are claimed as alignment or as conformance, where the semantics conflict, and how version relations are exposed over interfaces that carry only links or headers.

To which external vocabularies are the version fields of this model aligned, and at which version of each? interoperability
Is each mapping claimed as an alignment or as conformance, and what evidence supports a conformance claim? evidence
Where do external models conflict with this model's semantics, and how is the conflict handled? exception
How are version relations exposed over an access interface that carries only links, headers or metadata properties? interoperability
Which alignments are lossy, and precisely what is lost in each direction? quality

Classifiers Filled

Family: World Models
Category: Cross-cutting context
Entry kind: mixin
Navigation path: NAV.XCT.VER
Domain: XCT.VER
Industry: Cross-industry
Tags: versionchangehistoryxct.ver

What it is Filled

This mixin owns the semantics of a versioned record: the immutable identity of one revision of an identified host entity, the designation scheme that labels it, the predecessor/successor topology that orders it, the delta and classification that describe what changed, the agent and authority that made and approved the change, the record time and effective time of the change, the integrity evidence that makes the history verifiable, and the compatibility and migration statements that let a consumer move from one revision to another. It is mixed into host models rather than instantiated alone, and it deliberately does not model the host entity's own attributes. It is independent of storage format and access interface: JSON, YAML, Markdown, HTML, Git, OCFL, MCP and MongoDB are projections of these semantics, not the semantics themselves.

In scope

Revision identity: the immutable identifier of one revision and its relation to the version-independent identifier of the host entity
Version designation schemes (semantic, calendar, sequential, opaque) and the compatibility promise, if any, that an increment carries
Precedence and ordering rules over revisions, including which fields are ignored for ordering
Predecessor and successor relations, including multi-parent merge topology and branch scoping
Distinction between revision, derivation into a new entity, and format/rendition variant
Change sets: snapshot versus forward delta, patch formalisms, invertibility and verifiability of a delta
Change classification: category, breaking versus non-breaking, semantic versus presentational, correction, severity
Human-readable change notes, release notes and unreleased-change tracking
Compatibility declarations (backward, forward, incompatible) and the evidence supporting them
Migration procedures between versions, including reversibility, idempotence, expected loss and deadlines
Deprecation and sunset of a revision, endpoint or element, and the replacement pointer
Record time versus change-event time versus effective/validity period, and supersession instants
Revision lifecycle states (working copy, checked out, released, superseded, deprecated, withdrawn, deactivated) and legal transitions
Attribution of the change to a person, organisation or software agent, and the authority or approval under which it was made
Content fixity, canonicalisation profile and tamper evidence for history entries, including redaction handling
Enumeration of history, as-of retrieval and reconstruction of a prior state
Concurrency control expectations (expected-current-revision preconditions) and conflict outcomes
Retention, compaction, tombstoning and lawful disposition of history entries
Declared alignment (not conformance) to external version vocabularies and link relations

Out of scope

The host entity's domain attributes; this mixin describes only how those attributes change over time
General provenance: activities, plans, usage and entity generation that are not revision events belong to the provenance sibling model
Operator audit logging of reads, failed logins, signature ceremonies and other actions that produce no new revision
Build, packaging, release engineering and deployment pipelines that produce an artefact bearing a version label
Key management, certificate issuance and signature-suite selection
Physical or logical storage layout, directory conventions, database schemas and serialisation formats
Access-control policy definition and enforcement (this model supplies classification inputs only)
Approval workflow routing, task assignment and notification mechanics
Retention schedule authoring and legal-hold adjudication (this model consumes the resulting schedule)
Identifier minting policy, namespace governance and persistence guarantees for the host entity identifier
Distributed convergence mechanics such as CRDTs, vector clocks and consensus protocols
Licensing and rights changes between versions

Why it exists Filled

Distinguishing features Filled

Treats each revision as an immutable identity with predecessor and successor links.
Records the change set, its classification and who made and approved it.
Differs from provenance, which covers derivation in general, and from audit logs, which record events.
Differs from release management, which publishes software versions to users.

What robots and AI may and may not do Filled

Must not

Edit a revision after it was minted.
Assign a designation that breaks the declared scheme, such as marking a breaking change as a patch.
Apply a migration without approval where the change governance requires it.
Drop history needed for audit or legal reconstruction.
Overwrite concurrent changes by skipping update preconditions.

Only with a human decision

Approving a breaking change.
Approving a data migration between versions.
Purging history under a retention or erasure decision.

May

Mint a revision and assign a designation under the declared scheme.
Compute a change set and classify its compatibility impact.
Resolve the revision in force at a given instant.
Enforce update preconditions such as matching the current revision.

Moral aspects Filled

Change history records who changed what; it should not be used to monitor individuals beyond its purpose.
Erasure rights must be balanced against integrity of the history.
Hidden changes to rules or records undermine trust.

Who is affected

Authors and approvers of changes
Users who depend on stable versions
Auditors who reconstruct past states

Owners Filled

Steward

The adopting Dimension MUST name a single accountable owner for the version and change-history package and record that owner as a resolvable agent identifier, not free text; the owner is accountable for the designation scheme, the compatibility promise and the deprecation regime.

Roles

Version Owner: Declare and publish the version designation scheme, the public surface and the compatibility promise for the host entity.; Approve deprecation and sunset schedules and ensure a replacement and migration guidance exist.; Own the versioning policy artifact and its own revision history.
Change Author: Propose and create revisions, supplying the change set, the change classification and the human-readable change note.; Declare breaking status against the published public surface and supply the reason for the change.; Ensure predecessor references are correct, including all parents of a merge.
Change Approver: Review the impact assessment and authorise or reject the change before release.; Apply signatures with an explicitly declared meaning and record the decision instant.; Confirm that migration guidance and compatibility declarations exist before a breaking change is released.
History Custodian: Enforce the append-only property and detect any attempt to edit or remove a history entry.; Run scheduled fixity and chain verification and escalate unverified entries without deleting them.; Manage digest-algorithm and canonicalisation-profile migrations, retaining superseded values for historical verification.
Records and Retention Officer: Apply the retention schedule to revisions and history entries and administer legal holds.; Authorise disposition, redaction and erasure, and ensure a disposition record survives the disposed content.; Reconcile erasure and rectification obligations with immutability requirements and record the basis for the chosen reconciliation.
Registry Steward: Maintain the namespace, the declared scheme registry and the alignment crosswalks with their target vocabulary versions.; Ensure alignments are published as alignments, with loss statements, and that conformance claims carry evidence.; Detect upstream changes in aligned vocabularies and re-issue crosswalks as new revisions.
Consumer / Integrator: Declare which revision is pinned in use and respond to deprecation signals before the sunset instant.; Execute migrations within the stated deadline and report outcomes and failures.; Supply the expected current revision as a precondition on every update to prevent lost updates.

Links to other meta-models Filled

composes

Any Vercy world-model entry whose instances change over time (entity, event, aggregate or registry model) - This model is not instantiated alone. It is mixed into a host model to give that model revision identity, lineage, change substance, temporal framing, authority and migration semantics without duplicating the host's domain attributes.
Change Set / Patch structure (owned by this model, projected as a nested structure) - The ordered, atomically applicable delta with its precondition operations and expected result digest is composed into each revision record rather than being an external model.

references

Provenance / Lineage model (PROV-style agents, activities and derivations) — sibling identifier to be assigned by the registry - Revision links are a specialisation of derivation. This model asserts the revision relation and references the provenance sibling for activities, plans, usage and non-revision derivations so the concepts are not duplicated.
Audit Trail / Event Log model — sibling identifier to be assigned by the registry - Regulated audit trails record operator actions that create no revision, including reads and failed attempts. This model contributes revision-producing events to that trail and references it for the wider action stream.
Party / Agent model — sibling identifier to be assigned by the registry - Change agent, on-behalf-of party, approver and signer are all references into a party model; this model records only the reference, the role and the verification method.
Identifier and Namespace Governance model — sibling identifier to be assigned by the registry - Revision identity depends on a governed minting, resolution and persistence policy. This model states the identity priority and immutability requirement and defers minting policy to the identifier sibling.
Retention and Disposition model — sibling identifier to be assigned by the registry - Retention schedules, legal holds and disposition authority are authored elsewhere; this model consumes them and records the disposition applied to each history entry.
Access Control and Classification model — sibling identifier to be assigned by the registry - History entries carry visibility and sensitivity classifications, but policy interpretation and enforcement belong to the access sibling.
Approval / Change Governance Workflow model — sibling identifier to be assigned by the registry - Configuration change control requires proposal, impact analysis and approval. The workflow sibling owns routing and task state; this model binds the resulting decision to a revision.
Digital Signature and Integrity model — sibling identifier to be assigned by the registry - Claim signatures, certificate validation and key lifecycle are owned by a signature sibling; this model records the signature reference, covered digest and declared signature meaning.
Temporal / Effective-Dating model — sibling identifier to be assigned by the registry - General valid-time modelling of domain assertions belongs elsewhere; this model owns record time and supersession and references effective periods only to disambiguate as-of queries.

aligned

W3C PROV-O revision and attribution vocabulary - Declared mapping of revision, derivation, specialisation, alternate, generation, invalidation and attribution to PROV-O terms. Alignment only; no conformance is claimed without an executed validation.
DCAT 3 and DCMI Metadata Terms versioning properties - Declared mapping of version label, series membership, previous version, current version, replacement, creation, modification, issuance and validity to dcat and dcterms properties, with the version-chain limitation recorded as a known conflict.
IANA Link Relation Types registry (version navigation and time-based access) - Declared mapping of history enumeration, predecessor, successor, latest, working copy, memento, timegate, timemap, deprecation and sunset onto registered link relation types for interface exposure.
HL7 FHIR resource meta versioning and history interaction - Declared mapping of revision identifier, record instant, history enumeration, as-of retrieval and update precondition onto versionId, lastUpdated, _history, vread and If-Match, noting that the FHIR ETag is a weak validator and not a content digest.
OCFL object versioning, inventory and fixity - Declared mapping of sequential version numbering, head pointer, forward deltas, content addressing and legacy fixity onto OCFL inventory structures, treated as one storage projection among several.
Semantic Versioning 2.0.0 and PEP 440 designation grammars - Declared, mutually exclusive designation grammars that a host entity may adopt; the model records which grammar is in force rather than assuming either, because their ordering rules conflict.
C2PA manifest, ingredient and action model for media assets - Declared mapping of upstream ingredient versions, edit actions, hard bindings and redaction onto C2PA manifests where the host entity is a media asset carrying embedded provenance.

neighbor

Provenance / lineage model (PROV-style agents, activities, derivations) - PROV-O covers activities, agents, plans and usage generally; prov:wasRevisionOf is one specialisation of prov:wasDerivedFrom. This mixin owns only the revision relation between successive states of one identified host entity plus designation, compatibility and migration. Anything about how work was performed, or about entities that are not revisions of one another, belongs to the provenance sibling.
Audit trail / event log model - 21 CFR 11.10(e) requires audit trails that independently record operator entries and actions including those that create no new revision, and NIST SP 800-53 AU-3 governs audit-record content generally. Version history records only state-producing changes; the audit sibling records the wider action stream and read access.
Records retention and disposition model - Retention schedules, legal-hold adjudication and disposition authority are owned by the retention sibling. This mixin carries the retention basis, the disposition action applied to a history entry, and the tombstone that survives it.
Release, build and deployment model - Semantic Versioning and PEP 440 define version grammars for released packages, but the act of building, signing, publishing and deploying is a pipeline concern. This mixin records the designation, the compatibility promise and the migration path, not the pipeline that produced them.
Access interface / protocol model - HTTP conditional requests, ETag validators, Accept-Datetime negotiation and IANA link relations are projections of this model's concurrency and navigation semantics onto one interface. The semantics must remain expressible without HTTP.
Storage layout model - OCFL prescribes version directory naming, inventory files and content addressing. Those are a storage projection; this mixin requires that a continuous version sequence, a head pointer and a fixity record exist, not that they be stored as directories.
Digital signature and integrity model - C2PA claim signatures and NIST AU-10 non-repudiation depend on key and certificate lifecycle management owned by a signature sibling. This mixin records the signature reference, the signer, the covered digest and the declared meaning of the signature.
Approval / change-governance workflow model - NIST SP 800-53 CM-3 places change proposal, review and approval in a change-control process. The workflow sibling owns routing and task state; this mixin binds the approval outcome, approver and decision instant to a revision identifier.
Identifier and namespace governance model - OWL 2 separates the ontology IRI (series) from the version IRI (revision), and RFC 9562 governs UUID construction. Minting policy, resolution and persistence guarantees belong to the identifier sibling; this mixin only requires that a revision identifier is immutable and never re-pointed.
Temporal / effective-dating model - General valid-time modelling of business facts (dcterms:valid ranges, effective periods on domain assertions) belongs to a temporal sibling. This mixin owns record time and supersession instants and only references the effective period so that as-of queries can be disambiguated.

What else AI and robots need to interact with it Filled

Sources Filled

PROV-O: The PROV Ontology - World Wide Web Consortium (W3C)
Semantic Versioning 2.0.0 - Semantic Versioning (semver.org)
RFC 5829: Link Relation Types for Simple Version Navigation between Web Resources - Internet Engineering Task Force (IETF)
RFC 7089: HTTP Framework for Time-Based Access to Resource States -- Memento - Internet Engineering Task Force (IETF)
RFC 9110: HTTP Semantics - Internet Engineering Task Force (IETF)
RFC 6902: JavaScript Object Notation (JSON) Patch - Internet Engineering Task Force (IETF)
RFC 3339: Date and Time on the Internet: Timestamps - Internet Engineering Task Force (IETF)
RFC 9562: Universally Unique IDentifiers (UUIDs) - Internet Engineering Task Force (IETF)
RFC 8785: JSON Canonicalization Scheme (JCS) - Internet Engineering Task Force (IETF) / Independent Submission
Data Catalog Vocabulary (DCAT) - Version 3 - World Wide Web Consortium (W3C)
DCMI Metadata Terms - Dublin Core Metadata Initiative (DCMI Usage Board)
Oxford Common File Layout Specification - OCFL Editorial Group
FHIR RESTful API (FHIR Release 5) - Health Level Seven International (HL7)
Data on the Web Best Practices - World Wide Web Consortium (W3C)
Decentralized Identifiers (DIDs) v1.0 - World Wide Web Consortium (W3C)
OWL 2 Web Ontology Language Structural Specification and Functional-Style Syntax (Second Edition) - World Wide Web Consortium (W3C)
21 CFR Part 11 - Electronic Records; Electronic Signatures - U.S. Government Publishing Office / U.S. Food and Drug Administration
PEP 440 - Version Identification and Dependency Specification - Python Software Foundation / Python Packaging Authority
Apache Avro Specification 1.12.0 - Apache Software Foundation
Content Credentials: C2PA Technical Specification - Coalition for Content Provenance and Authenticity (C2PA)
gitglossary - A Git Glossary - Git project
NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations - National Institute of Standards and Technology (NIST)
RFC 3253: Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning) - Internet Engineering Task Force (IETF)
RFC 9745: The Deprecation HTTP Response Header Field - Internet Engineering Task Force (IETF)
Link Relation Types (IANA registry) - Internet Assigned Numbers Authority (IANA)
Regulation (EU) 2016/679 (General Data Protection Regulation) - European Union (EUR-Lex)
Keep a Changelog - Keep a Changelog (Olivier Lacan, community project)
DCMI Metadata Terms - Dublin Core Metadata Initiative (DCMI)
PAV - Provenance, Authoring and Versioning - Massachusetts General Hospital / Harvard Medical School and University of Manchester (pav-ontology)
DataCite Versioning - DataCite e.V.
ADMS Vocabulary - European Commission SEMIC / Interoperable Europe (namespace http://www.w3.org/ns/adms#)
RFC 6902: JavaScript Object Notation (JSON) Patch - Internet Engineering Task Force (IETF)

Open questions

Retrieve PREMIS 3.0 preservation-event semantics and the OAIS reference model (ISO 14721 / CCSDS 650.0-M-2), currently blocked by HTTP 403, to model refreshment, replication, repackaging and transformation migration and the AIP version versus AIP edition distinction.
Obtain a retrievable normative source for bitemporal valid-time semantics (SQL:2011 application-time period tables and system-versioned tables) to replace the current partial anchoring of the effective-period finding on dcterms:valid, DID metadata and Memento datetime negotiation.
Acquire ISO 10007 configuration status accounting and ISO 15489 records-classification terminology, both paywalled, to test whether NIST SP 800-53 CM-3 remains an adequate substitute for change-control requirements.
Add a catalog-record / registry-entry history boundary note distinguishing DCAT CatalogRecord listing and modification dates from revisions of the versioned resource itself; the base boundary set does not currently name this neighbour.
Document the merge-node mapping hazard in the alignment crosswalk, including the dcat:prev series-order versus dcat:previousVersion snapshot-lineage confusion and the functional cardinality of pav:previousVersion against multi-parent merges.
Assess whether CalVer, package-manager yank and unpublish semantics, and content-addressed identity (Git SHA, IPFS CID, SWHID) as master identifiers warrant structure or remain declared omissions.
PREMIS 3.0 preservation-event semantics and the OAIS reference model (ISO 14721 / CCSDS 650.0-M-2) could not be retrieved during this research (HTTP 403 on loc.gov and ccsds.org). Consequently the preservation-specific distinctions between refreshment, replication, repackaging and transformation migration are not modelled, and the AIP version versus AIP edition distinction is absent. This is the largest single evidence gap for the migration half of the model's stated purpose.
ISO 10007 (configuration management) and ISO 15489 (records management) are paywalled and were not verified; configuration status accounting and records-classification terminology are therefore not adopted, and NIST SP 800-53 CM-3 is used as the accessible substitute for change-control requirements.
Strict bitemporal semantics as standardised in SQL:2011 (application-time period tables, system-versioned tables, automatic row closure) could not be cited from a retrievable primary source. The effective-period finding rests on dcterms:valid, DID document metadata and Memento datetime negotiation and is explicitly flagged as partial support.
Distributed convergence — CRDTs, vector clocks, causal ordering without a central issuer — is not modelled. The model assumes an authoritative issuing system or a declared branch owner per entity; genuinely leaderless multi-writer histories would need an additional sibling model.
Blockchain or distributed-ledger anchoring is treated as one implementation of tamper evidence rather than modelled separately; the model states the required property (detectable insertion, removal and reordering) without prescribing a mechanism.
Content-specific versioning for time-based media beyond the C2PA manifest model — edit decision lists, non-destructive edit stacks, streaming manifest versioning — is not modelled.
Localisation and translation versioning is only partially modelled: change notes carry language tags, but the independent revision lifecycle of a translation relative to its source is not developed.
Cost, effort and risk estimation for migrations is out of scope; the model records deadlines, responsibility and accepted loss but not resourcing.
Signature suite selection, certificate lifecycle and revocation handling are deferred entirely to the signature sibling; a revoked signing certificate's effect on historical claim validity is therefore unresolved here.
Rights and licence changes across versions are deferred to a rights sibling; a licence change without a content change is a real case that this model would classify only as a non-semantic revision.
Git-style merge and octopus-merge predecessor DAGs; PAV previousVersion is normally functional and DCAT describes a chain, not a DAG.
Calendar Versioning (CalVer) and other non-SemVer, non-OWL identifier grammars.
Package-manager yank/unpublish/retract semantics (npm, crates.io) as distinct from PROV invalidation.
FHIR meta.versionId / If-Match resource versioning, MediaWiki revision ids, and Software Heritage SWHID as primary identifiers.
Schema-evolution compatibility (Avro, Protocol Buffers) as a specialised contract.
Content-addressed identity (git SHA, IPFS CID) as the master identifier; checksums are evidence here.
Parallel current branches as first-class OWL-incompatible series.
Legal corrigendum versus new edition in legislation and ISO document control.
Automated semantic-release and changelog-generation tool contracts.
Embargo clocks beyond a simple unreleased/released flag.

Machine files

Card as JSON Specification AGENTS.md Source Card backlog vercy.card/1

Provenance

world-models research · reviewable-draft

Built from: models/wm-xct-022-version-change-history/spec.yaml, ver-cy/world-models/card-supplements/wm-xct-022-version-change-history.json