# Vercy AI instruction - YAML 1.2 (JSON-compatible) { "vercy": "1.0-draft", "publication": { "status": "published", "adjudicationStatus": "reviewable-draft", "publishableCanonical": false, "generatedAt": "2026-08-22T23:20:50Z", "synthesisSha256": "e97a0b44f1ed30c2c7d32a68123f5ec4b814ff5c283ea733ea9038f1ee4073a9", "providerMode": "dual-provider", "providers": [ "Claude", "Grok" ], "waivedProviders": [] }, "metaModel": { "id": "WM-XCT-022", "registryId": "vr.wm-xct-022", "name": "Version / Change History", "version": "0.3.0-research.2", "previousVersions": [ { "version": "0.3.0-research.1", "url": "/models/wm-xct-022-version-change-history/versions/0.3.0-research.1/" } ], "entryKind": "mixin", "family": "World Models", "category": "Cross-cutting context", "industry": [ "Cross-industry" ], "domain": [ "XCT.VER" ], "tags": [ "version", "change", "history", "xct.ver" ], "status": "published" }, "canonicalUrl": "https://ver.cy/models/wm-xct-022-version-change-history/", "sourceUrl": "https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-xct-022", "model": { "registry_id": "vr.wm-xct-022", "model_id": "WM-XCT-022", "name": "Version / Change History", "entry_kind": "mixin", "purpose": "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.", "scope_statement": "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" ], "boundary_notes": [ { "neighbor": "Provenance / lineage model (PROV-style agents, activities, derivations)", "distinction": "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.", "source_refs": [ "SRC-001", "SRC-014" ] }, { "neighbor": "Audit trail / event log model", "distinction": "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.", "source_refs": [ "SRC-017", "SRC-022" ] }, { "neighbor": "Records retention and disposition model", "distinction": "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.", "source_refs": [ "SRC-026", "SRC-017" ] }, { "neighbor": "Release, build and deployment model", "distinction": "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.", "source_refs": [ "SRC-002", "SRC-018" ] }, { "neighbor": "Access interface / protocol model", "distinction": "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.", "source_refs": [ "SRC-005", "SRC-025", "SRC-004" ] }, { "neighbor": "Storage layout model", "distinction": "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.", "source_refs": [ "SRC-012" ] }, { "neighbor": "Digital signature and integrity model", "distinction": "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.", "source_refs": [ "SRC-020", "SRC-022" ] }, { "neighbor": "Approval / change-governance workflow model", "distinction": "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.", "source_refs": [ "SRC-022", "SRC-017" ] }, { "neighbor": "Identifier and namespace governance model", "distinction": "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.", "source_refs": [ "SRC-016", "SRC-008", "SRC-014" ] }, { "neighbor": "Temporal / effective-dating model", "distinction": "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.", "source_refs": [ "SRC-011", "SRC-015" ] } ] }, "sources": [ { "id": "SRC-001", "title": "PROV-O: The PROV Ontology", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/prov-o/", "version_or_date": "W3C Recommendation, 30 April 2013", "source_type": "ontology", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T08:05:00Z", "relevance": "Normative definitions of prov:wasRevisionOf ('the derived Entity contains substantial content from the original'), wasDerivedFrom, specializationOf, alternateOf, generatedAtTime, invalidatedAtTime and wasAttributedTo. Anchors the revision-versus-derivation boundary and attribution." }, { "id": "SRC-002", "title": "Semantic Versioning 2.0.0", "organization": "Semantic Versioning (semver.org)", "url": "https://semver.org/", "version_or_date": "2.0.0", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-23T08:06:00Z", "relevance": "Normative MUST clauses on the X.Y.Z form, immutability of a released version ('the contents of that version MUST NOT be modified'), major/minor/patch increment semantics tied to a declared public API, pre-release identifiers, and the rule that build metadata MUST be ignored for precedence." }, { "id": "SRC-003", "title": "RFC 5829: Link Relation Types for Simple Version Navigation between Web Resources", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc5829.html", "version_or_date": "RFC 5829, Informational, April 2010", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-23T08:07:00Z", "relevance": "Defines version-history, latest-version, predecessor-version, successor-version, working-copy and working-copy-of, and states explicitly that multiple predecessor relations may exist for merged branches and multiple latest versions under branching." }, { "id": "SRC-004", "title": "RFC 7089: HTTP Framework for Time-Based Access to Resource States -- Memento", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc7089.html", "version_or_date": "RFC 7089, Informational, December 2013", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-23T08:08:00Z", "relevance": "Original Resource, Memento, TimeGate and TimeMap; datetime negotiation via Accept-Datetime; the Memento-Datetime response header as a promise that the reflected state 'will no longer change'. Anchors as-of retrieval and history enumeration." }, { "id": "SRC-005", "title": "RFC 9110: HTTP Semantics", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc9110.html", "version_or_date": "RFC 9110, Internet Standard STD 97, June 2022", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T08:09:00Z", "relevance": "ETag strong and weak validators, Last-Modified, conditional requests If-Match / If-None-Match / If-Unmodified-Since and 412 Precondition Failed. Anchors optimistic concurrency control and the distinction between a validator and a content digest." }, { "id": "SRC-006", "title": "RFC 6902: JavaScript Object Notation (JSON) Patch", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc6902.html", "version_or_date": "RFC 6902, Standards Track, April 2013", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T08:10:00Z", "relevance": "Ordered operation list (add, remove, replace, move, copy, test), the test precondition operation, media type application/json-patch+json, and the requirement that a failing patch document SHALL NOT be deemed successfully applied. Anchors change-set representation and atomicity." }, { "id": "SRC-007", "title": "RFC 3339: Date and Time on the Internet: Timestamps", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc3339.html", "version_or_date": "RFC 3339, Standards Track, July 2002", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T08:11:00Z", "relevance": "Mandatory explicit offset to UTC, the meaning of Z, the -00:00 unknown-local-offset convention, leap-second value 60 and optional fractional seconds. Anchors every timestamp rule in the model." }, { "id": "SRC-008", "title": "RFC 9562: Universally Unique IDentifiers (UUIDs)", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc9562.html", "version_or_date": "RFC 9562, Standards Track, May 2024 (obsoletes RFC 4122)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T08:12:00Z", "relevance": "UUIDv4, v6, v7 and v8; UUIDv7 48-bit Unix-epoch millisecond timestamp, lexicographic sortability, and the recommendation to prefer UUIDv7 for new time-ordered identifiers. Anchors tier-3 identity assignment by the adopting Dimension." }, { "id": "SRC-009", "title": "RFC 8785: JSON Canonicalization Scheme (JCS)", "organization": "Internet Engineering Task Force (IETF) / Independent Submission", "url": "https://www.rfc-editor.org/rfc/rfc8785.html", "version_or_date": "RFC 8785, Informational, June 2020", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-23T08:13:00Z", "relevance": "Deterministic serialisation for hashing and signing: recursive lexicographic property sorting, string and ECMAScript number serialisation. Anchors the canonicalisation-before-digest rule that makes fixity and delta verification reproducible." }, { "id": "SRC-010", "title": "Data Catalog Vocabulary (DCAT) - Version 3", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/vocab-dcat-3/", "version_or_date": "W3C Recommendation, 22 August 2024", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T08:14:00Z", "relevance": "dcat:version, dcat:hasVersion, dcat:previousVersion, dcat:hasCurrentVersion and adms:versionNotes, the statement that the notion of version is limited to revisions occurring as part of a resource life-cycle, the previousVersion 'version chain of snapshots' usage note, and dcat:DatasetSeries." }, { "id": "SRC-011", "title": "DCMI Metadata Terms", "organization": "Dublin Core Metadata Initiative (DCMI Usage Board)", "url": "https://www.dublincore.org/specifications/dublin-core/dcmi-terms/", "version_or_date": "DCMI Recommendation, 2020-01-20", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T08:15:00Z", "relevance": "Definitions of hasVersion / isVersionOf, replaces / isReplacedBy, created / modified / issued, valid (date or range of validity) and provenance (changes in ownership and custody significant for authenticity and integrity). Anchors series relations and the effective-period boundary." }, { "id": "SRC-012", "title": "Oxford Common File Layout Specification", "organization": "OCFL Editorial Group", "url": "https://ocfl.io/1.1/spec/", "version_or_date": "Version 1.1.1, 7 November 2024", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-23T08:16:00Z", "relevance": "Forward-delta versioning, sequential version numbering that MUST start at 1 and be continuous with no missing integers, the head key pointing at the highest version, immutability of created version directories, mandatory sha512 or sha256 content addressing, and a fixity block for legacy digest migration." }, { "id": "SRC-013", "title": "FHIR RESTful API (FHIR Release 5)", "organization": "Health Level Seven International (HL7)", "url": "https://hl7.org/fhir/R5/http.html", "version_or_date": "FHIR R5, v5.0.0", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T08:17:00Z", "relevance": "Resource.meta.versionId as an opaque version identifier mapped to a weak ETag, meta.lastUpdated mapped to Last-Modified, the vread and _history interactions, version-aware update with If-Match returning 412 on mismatch, and history entries for deletions carrying no resource content." }, { "id": "SRC-014", "title": "Data on the Web Best Practices", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/dwbp/", "version_or_date": "W3C Recommendation, 31 January 2017", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T08:18:00Z", "relevance": "Best Practice 7 (provide a version indicator) and Best Practice 8 (provide version history, including a changelog stating precisely how each version differs from its predecessor), plus BP5 provenance and BP9/BP10 persistent URIs. The most direct normative statement of the requirement this model serves." }, { "id": "SRC-015", "title": "Decentralized Identifiers (DIDs) v1.0", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/did-core/", "version_or_date": "W3C Recommendation, 19 July 2022", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T08:19:00Z", "relevance": "versionId and versionTime resolution options ('the DID document that was valid for a DID at a certain time') and DID document metadata created, updated, deactivated, nextUpdate, versionId, nextVersionId, equivalentId and canonicalId. Anchors as-of resolution and deactivation-versus-deletion." }, { "id": "SRC-016", "title": "OWL 2 Web Ontology Language Structural Specification and Functional-Style Syntax (Second Edition)", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/owl2-syntax/", "version_or_date": "W3C Recommendation, 11 December 2012", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T08:20:00Z", "relevance": "The ontology IRI / version IRI pair, the ontology series concept, the uniqueness rule that two different ontologies should not share an ontology IRI plus version IRI, and owl:versionInfo, owl:priorVersion, owl:backwardCompatibleWith, owl:incompatibleWith and owl:deprecated." }, { "id": "SRC-017", "title": "21 CFR Part 11 - Electronic Records; Electronic Signatures", "organization": "U.S. Government Publishing Office / U.S. Food and Drug Administration", "url": "https://www.govinfo.gov/content/pkg/CFR-2023-title21-vol1/xml/CFR-2023-title21-vol1-part11.xml", "version_or_date": "CFR 2023 edition, revised as of 1 April 2023", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T08:21:00Z", "relevance": "11.10(e) requires secure, computer-generated, time-stamped audit trails that independently record operator entries and actions creating, modifying or deleting records, without obscuring previously recorded information; 11.10(c) requires accurate and ready retrieval throughout the retention period; 11.10(k) requires revision and change control of systems documentation." }, { "id": "SRC-018", "title": "PEP 440 - Version Identification and Dependency Specification", "organization": "Python Software Foundation / Python Packaging Authority", "url": "https://peps.python.org/pep-0440/", "version_or_date": "PEP 440, Status: Final, created 18 March 2013", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-23T08:22:00Z", "relevance": "A normatively different version grammar: epoch, arbitrary-length release segment, pre-release, post-release, developmental release and local version, with the ordering .devN < aN < bN < rcN < final < .postN. Direct counterexample to assuming Semantic Versioning universally." }, { "id": "SRC-019", "title": "Apache Avro Specification 1.12.0", "organization": "Apache Software Foundation", "url": "https://avro.apache.org/docs/1.12.0/specification/", "version_or_date": "Version 1.12.0", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-23T08:23:00Z", "relevance": "Schema Resolution: reader/writer schema matching, defaults for fields present only in the reader, ignoring fields present only in the writer, an error when a reader field has no default, aliases, and permitted type promotions. Anchors directional compatibility rules and migration defaults." }, { "id": "SRC-020", "title": "Content Credentials: C2PA Technical Specification", "organization": "Coalition for Content Provenance and Authenticity (C2PA)", "url": "https://spec.c2pa.org/specifications/specifications/2.1/specs/C2PA_Specification.html", "version_or_date": "Version 2.1, September 2024", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-23T08:24:00Z", "relevance": "Manifest, active manifest, ingredients, c2pa.actions (created, edited, opened), hard bindings, claim signatures, preservation of prior provenance on each change, and the rule that assertions may be redacted by subsequent claims but cannot be modified once claimed. Anchors tamper evidence and redaction of immutable history." }, { "id": "SRC-021", "title": "gitglossary - A Git Glossary", "organization": "Git project", "url": "https://git-scm.com/docs/gitglossary", "version_or_date": "Git 2.54.0, last updated 2026-04-20", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 3, "accessed_at": "2026-08-23T08:25:00Z", "relevance": "Commit objects hold a possibly empty list of parents; merge commits have the tips of merged branches as parents; commit objects form a directed acyclic graph. Empirical counterexample to modelling history as a linear chain." }, { "id": "SRC-022", "title": "NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations", "organization": "National Institute of Standards and Technology (NIST)", "url": "https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final", "version_or_date": "Revision 5, September 2020, updated 10 December 2020 (control release 5.2.0, 27 August 2025)", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T08:26:00Z", "relevance": "CM-2 baseline configuration and CM-3 configuration change control (proposal, impact analysis, approval, documentation of changes); AU-3 content of audit records and AU-10 non-repudiation. Anchors change authority, impact assessment and non-repudiable attribution." }, { "id": "SRC-023", "title": "RFC 3253: Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc3253.html", "version_or_date": "RFC 3253, Standards Track, March 2002", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T08:27:00Z", "relevance": "Version-controlled resource, version resource, version history resource, checkout/checkin, DAV:predecessor-set and DAV:successor-set, DAV:version-name, DAV:auto-version, the allocation of a distinct never-reused URL per version, and the rule that the content and dead properties of a version never change." }, { "id": "SRC-024", "title": "RFC 9745: The Deprecation HTTP Response Header Field", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc9745.html", "version_or_date": "RFC 9745, Standards Track, March 2025", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T08:28:00Z", "relevance": "The Deprecation structured-field date, the deprecation link relation pointing at human-readable deprecation documentation, and the normative rule that a Sunset timestamp MUST NOT be earlier than the Deprecation timestamp. Anchors the deprecation-then-sunset ordering constraint." }, { "id": "SRC-025", "title": "Link Relation Types (IANA registry)", "organization": "Internet Assigned Numbers Authority (IANA)", "url": "https://www.iana.org/assignments/link-relations/link-relations.xhtml", "version_or_date": "Registry, last updated 2026-06-12", "source_type": "registry", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T08:29:00Z", "relevance": "Authoritative registration of version-history, latest-version, predecessor-version, successor-version, working-copy, working-copy-of, memento, timegate, timemap, original, deprecation and sunset with their defining RFCs. The normative registry for interoperable exposure of version navigation." }, { "id": "SRC-026", "title": "Regulation (EU) 2016/679 (General Data Protection Regulation)", "organization": "European Union (EUR-Lex)", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679", "version_or_date": "OJ L 119, 4 May 2016", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T08:30:00Z", "relevance": "Article 16 rectification, Article 17(1) erasure and 17(3) exceptions, and Article 5(1)(e) storage limitation. Establishes the genuine legal conflict with absolute immutability of change history containing personal data." }, { "id": "SRC-027", "title": "Keep a Changelog", "organization": "Keep a Changelog (Olivier Lacan, community project)", "url": "https://keepachangelog.com/en/1.1.0/", "version_or_date": "Version 1.1.0, 15 February 2019", "source_type": "secondary", "primary_source": false, "authority_tier": 4, "accessed_at": "2026-08-23T08:31:00Z", "relevance": "Widely adopted community convention for change-note categories (Added, Changed, Deprecated, Removed, Fixed, Security), release dates in ISO 8601 form and an Unreleased section. Used only to surface a de facto category vocabulary; explicitly not a standard and marked as such." }, { "id": "SRC-028", "title": "DCMI Metadata Terms", "organization": "Dublin Core Metadata Initiative (DCMI)", "url": "https://www.dublincore.org/specifications/dublin-core/dcmi-terms/2020-01-20/", "version_or_date": "2020-01-20", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T18:30:00Z", "relevance": "dcterms:hasVersion, isVersionOf, replaces, isReplacedBy; version means substantive content change, not format; issued, modified, identifier." }, { "id": "SRC-029", "title": "PAV - Provenance, Authoring and Versioning", "organization": "Massachusetts General Hospital / Harvard Medical School and University of Manchester (pav-ontology)", "url": "https://pav-ontology.github.io/pav/", "version_or_date": "2.3.1, last modified 2015-03-16 22:21:00 UTC, version IRI http://purl.org/pav/2.3", "source_type": "ontology", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-23T18:30:00Z", "relevance": "pav:version, previousVersion, hasEarlierVersion, hasVersion, hasCurrentVersion; mutable resource versus snapshot; DCAT equivalent properties; previousVersion used as a functional direct-ancestor link." }, { "id": "SRC-030", "title": "DataCite Versioning", "organization": "DataCite e.V.", "url": "https://support.datacite.org/docs/versioning", "version_or_date": "Guidance current as of 2026-08 (page updated about 2026-08-08); relation types from DataCite Metadata Schema 4.7 (released 2026-03-03)", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-23T18:30:00Z", "relevance": "Minor change may keep the same DOI with updated Version; major change SHOULD mint a new DOI; IsPreviousVersionOf/IsNewVersionOf; HasVersion/IsVersionOf; canonical DOI for all versions; steward defines major versus minor." }, { "id": "SRC-031", "title": "ADMS Vocabulary", "organization": "European Commission SEMIC / Interoperable Europe (namespace http://www.w3.org/ns/adms#)", "url": "https://www.w3.org/ns/adms", "version_or_date": "ADMS 2.00, SEMIC Recommendation 2024-02-01", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-23T18:30:00Z", "relevance": "adms:versionNotes, adms:status, adms:last, adms:next, adms:prev; identifier class; note that DCAT 3 replaced ADMS version-navigation properties with dcat:previousVersion and related terms." }, { "id": "SRC-032", "title": "RFC 6902: JavaScript Object Notation (JSON) Patch", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc6902", "version_or_date": "RFC 6902, Standards Track, April 2013", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-23T18:30:00Z", "relevance": "Format-neutral mixin still needs a migration artefact type: sequential add/remove/replace/move/copy/test operations, error handling, and If-Match concurrency precondition. JSON is a projection; the operations model the delta." } ], "structure": { "bundles": [ { "id": "revision-identity", "name": "Revision Identity and Designation", "description": "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.", "rationale": "No predecessor link, delta, compatibility claim or migration statement can be resolved unless each revision carries an immutable identifier and a declared designation scheme. OWL 2 separates ontology IRI from version IRI, RFC 3253 allocates a distinct never-reused URL per version, and OCFL requires a continuous version sequence with an explicit head — all three make revision identity the prerequisite structure.", "source_refs": [ "SRC-016", "SRC-023", "SRC-012", "SRC-002", "SRC-008", "SRC-010" ], "layers": [ { "id": "revision-addressing", "name": "Revision Identity and Addressing", "description": "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.", "source_refs": [ "SRC-016", "SRC-023", "SRC-013", "SRC-008", "SRC-010", "SRC-011" ], "findings": [ { "id": "revision-identity-assignment", "name": "Revision identifier assignment and immutability", "description": "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.", "source_refs": [ "SRC-023", "SRC-013", "SRC-012", "SRC-008", "SRC-005" ], "questions": [ { "id": "q-rev-issuer", "text": "Which system is the authoritative issuer of this revision identifier, and is it the same system that holds the host entity's master record?", "kind": "identity", "answer_data": [ "Issuing system identifier", "Issuing authority reference", "Scope within which the identifier is unique" ] }, { "id": "q-rev-id-form", "text": "What identifier form is used for the revision, and is it opaque or does it encode meaning?", "kind": "identity", "answer_data": [ "Identifier value", "Identifier scheme code (master-system id, governed IRI, UUIDv7, ULID)", "Opaque or meaningful flag" ] }, { "id": "q-rev-id-reuse", "text": "Is the revision identifier guaranteed never to be reused or re-pointed at different content, and what enforces that?", "kind": "constraint", "answer_data": [ "Immutability guarantee statement", "Enforcement mechanism code", "Known exceptions" ] }, { "id": "q-rev-id-vs-series", "text": "How does the revision identifier relate to the persistent identifier of the versioned entity itself?", "kind": "relationship", "answer_data": [ "Entity persistent identifier", "Composition rule (compound, derived, independent)", "Resolution rule from revision identifier to entity identifier" ] }, { "id": "q-rev-validator", "text": "Which validator may be derived from this revision for conditional access, and is it strong or weak?", "kind": "interoperability", "answer_data": [ "Validator value", "Strong or weak indicator", "Whether the validator equals the content digest" ] } ], "data_elements": [ { "id": "de-revision-id", "name": "Revision identifier", "description": "Immutable identifier of one revision, assigned per the identity priority of the adopting Dimension.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-023", "SRC-013", "SRC-008" ] }, { "id": "de-entity-persistent-id", "name": "Entity persistent identifier", "description": "Version-independent identifier of the host entity that this revision is a state of.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-016", "SRC-014" ] }, { "id": "de-revision-id-scheme", "name": "Revision identifier scheme", "description": "Declared scheme by which the revision identifier was assigned, recorded so consumers do not infer semantics from the string.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-008", "SRC-016" ] }, { "id": "de-revision-validator", "name": "Revision validator", "description": "Optional opaque validator exposed for conditional access, explicitly marked strong or weak; not a substitute for a content digest.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005", "SRC-013" ] } ], "artifacts": [ { "id": "a-revision-manifest", "name": "Revision manifest", "description": "The per-revision record binding the revision identifier, the entity identifier, the designation, the content digest and the version state, equivalent in role to an OCFL inventory entry or a FHIR resource meta block.", "media_or_form": [ "structured metadata record", "object inventory entry", "embedded metadata block" ], "serial": true, "identity_strategy": "Identified by entity persistent identifier plus revision identifier; the manifest itself carries a digest over its canonical form so that the manifest can be verified independently of the content it describes.", "source_refs": [ "SRC-012", "SRC-013", "SRC-009" ] } ], "inline_only_rationale": null }, { "id": "version-designation-scheme", "name": "Version designation scheme and its promise", "description": "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.", "source_refs": [ "SRC-002", "SRC-018", "SRC-012", "SRC-010", "SRC-016", "SRC-014" ], "questions": [ { "id": "q-scheme-declared", "text": "Which version designation grammar does this entity declare, and where is that declaration published?", "kind": "classification", "answer_data": [ "Scheme code (semantic, calendar, sequential integer, epoch-bearing, opaque)", "Scheme specification URL and version", "Declaration location" ] }, { "id": "q-scheme-promise", "text": "Does an increment in the designation carry a normative compatibility promise, or is the designation descriptive only?", "kind": "constraint", "answer_data": [ "Promise present flag", "Promise text", "Segment-to-impact mapping" ] }, { "id": "q-public-surface", "text": "Against which declared public surface is a breaking change judged?", "kind": "definition", "answer_data": [ "Public surface declaration reference", "Elements explicitly excluded from the surface", "Declaration revision identifier" ] }, { "id": "q-qualifier-ordering", "text": "How are pre-release, post-release, development, epoch and build or local qualifiers handled, and do they affect precedence?", "kind": "constraint", "answer_data": [ "Qualifier values", "Qualifiers participating in ordering", "Qualifiers explicitly ignored for ordering" ] } ], "data_elements": [ { "id": "de-version-label", "name": "Version designation label", "description": "The published version label for the revision, valid under the declared scheme.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-010", "SRC-014" ] }, { "id": "de-version-scheme", "name": "Version scheme code", "description": "Identifier of the grammar the label obeys, so that ordering and compatibility inference is never guessed.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-018", "SRC-012" ] }, { "id": "de-public-surface-ref", "name": "Public surface declaration reference", "description": "Reference to the declared API, schema or content surface against which breaking change is assessed.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-019" ] }, { "id": "de-designation-qualifiers", "name": "Designation qualifiers", "description": "Structured decomposition of epoch, pre-release, post-release, development and build or local segments carried by the label.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-018" ] } ], "artifacts": [ { "id": "a-versioning-policy", "name": "Versioning policy statement", "description": "The published statement of the designation grammar, the compatibility promise, the public surface and the deprecation regime that governs all revisions of the entity.", "media_or_form": [ "policy document", "machine-readable declaration" ], "serial": false, "identity_strategy": "One current policy per host model namespace, identified by the namespace IRI plus the policy's own revision identifier; superseded wholesale rather than amended in place.", "source_refs": [ "SRC-002", "SRC-014", "SRC-016" ] } ], "inline_only_rationale": null }, { "id": "series-and-abstract-entity", "name": "Series identity and resolution of the current version", "description": "The version-independent series identifier, the relations that bind a revision to its series, and how 'the latest' is defined when branches exist.", "source_refs": [ "SRC-016", "SRC-010", "SRC-011", "SRC-001", "SRC-003", "SRC-025" ], "questions": [ { "id": "q-series-exists", "text": "Does a version-independent identifier exist for the entity series, and what does dereferencing it yield?", "kind": "identity", "answer_data": [ "Series identifier", "Dereference behaviour code", "Whether the series identifier is itself versioned" ] }, { "id": "q-series-relations", "text": "Which relations assert that this revision is a version of the series and which assert the series' current version?", "kind": "relationship", "answer_data": [ "isVersionOf relation value", "hasCurrentVersion relation value", "Relation vocabulary and version used" ] }, { "id": "q-latest-under-branching", "text": "How is 'latest' defined when concurrent branches or contexts each have a most recent revision?", "kind": "decision", "answer_data": [ "Latest resolution rule", "Branch or context discriminator", "Whether multiple latest values are permitted" ] }, { "id": "q-citation-target", "text": "May the series identifier be used as an evidentiary citation target, or must citations pin a revision?", "kind": "evidence", "answer_data": [ "Citation policy code", "Required pinning level", "Exceptions and their justification" ] } ], "data_elements": [ { "id": "de-series-id", "name": "Series identifier", "description": "Version-independent identifier shared by all revisions of the entity.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016", "SRC-010" ] }, { "id": "de-is-version-of", "name": "Is-version-of relation", "description": "Assertion that this revision is a version, edition or adaptation of the identified series or abstract resource.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011", "SRC-010", "SRC-001" ] }, { "id": "de-latest-resolution-rule", "name": "Latest-version resolution rule", "description": "The rule by which a consumer determines the current revision for a given branch or context.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003", "SRC-010" ] } ], "artifacts": [], "inline_only_rationale": "Series membership and currency are identifier-level relation assertions carried inline on the revision record and on the series record; the navigable, retrievable expression of them is the version history document specified in history-retrieval-and-reconstruction, so this finding produces no artifact of its own." } ] }, { "id": "ordering-and-currency", "name": "Ordering, Precedence and Currency", "description": "How revisions are ordered relative to one another, which fields participate in comparison, and which revision is currently in force.", "source_refs": [ "SRC-002", "SRC-018", "SRC-012", "SRC-003", "SRC-015" ], "findings": [ { "id": "ordering-precedence-and-currency", "name": "Precedence rules and head pointer", "description": "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.", "source_refs": [ "SRC-002", "SRC-018", "SRC-012", "SRC-003", "SRC-015", "SRC-021" ], "questions": [ { "id": "q-order-kind", "text": "Is the order over revisions total or partial, and what produces partiality?", "kind": "constraint", "answer_data": [ "Order kind code", "Cause of partiality (branching, concurrent writers)", "Whether unordered pairs are reported to consumers" ] }, { "id": "q-order-fields", "text": "Which fields participate in precedence comparison and which are explicitly ignored?", "kind": "constraint", "answer_data": [ "Participating field list", "Explicitly ignored field list", "Comparison algorithm reference" ] }, { "id": "q-order-derivable", "text": "Can ordering be derived from the identifier or label alone, or must the predecessor graph be traversed?", "kind": "decision", "answer_data": [ "Derivability flag", "Required traversal depth", "Fallback rule when the label is opaque" ] }, { "id": "q-head-authority", "text": "Which revision is currently in force for each branch, and who may move that pointer?", "kind": "authority", "answer_data": [ "Head revision reference per branch", "Authorised role for head movement", "Atomicity guarantee for the move" ] }, { "id": "q-rollback", "text": "May the head move backwards to an earlier revision, and how is that recorded?", "kind": "lifecycle", "answer_data": [ "Rollback permitted flag", "Rollback recording mechanism", "Whether rollback mints a new revision" ] } ], "data_elements": [ { "id": "de-ordering-rule", "name": "Ordering rule", "description": "Declared comparison rule producing the order over revisions of the entity.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-018" ] }, { "id": "de-sequence-number", "name": "Sequence number", "description": "Monotonic integer position of the revision in its branch, starting at 1 and continuous without gaps where a sequence is used.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-head-revision", "name": "Head revision pointer", "description": "Mutable pointer naming the revision currently in force for a given branch or context.", "value_kind": "reference", "cardinality": "0..n", "required": true, "source_refs": [ "SRC-012", "SRC-003" ] }, { "id": "de-branch-name", "name": "Branch or context name", "description": "Scope discriminator under which a distinct head and ordering apply.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003", "SRC-021" ] }, { "id": "de-head-updated-at", "name": "Head update instant", "description": "Instant at which the head pointer was last moved, recorded so consumers can detect staleness.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007", "SRC-015" ] } ], "artifacts": [ { "id": "a-head-pointer-record", "name": "Currency pointer record", "description": "The mutable record naming the current revision per branch, kept separate from the immutable revision manifests precisely because it changes.", "media_or_form": [ "mutable pointer record", "resolution response" ], "serial": false, "identity_strategy": "Identified by entity persistent identifier plus branch or context name; the value is a revision identifier and the record carries its own last-update instant.", "source_refs": [ "SRC-012", "SRC-003", "SRC-015" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "lineage-topology", "name": "Change Lineage and Topology", "description": "The graph of predecessor and successor relations between revisions, the semantic type of each link, and lineage that crosses entity or organisational boundaries.", "rationale": "RFC 5829 and RFC 3253 define predecessor and successor as sets, not single pointers, and Git commit objects hold a possibly empty list of parents forming a directed acyclic graph. PROV-O separately distinguishes revision from derivation and from format variation. Lineage therefore needs its own bundle rather than being a field on the identity record.", "source_refs": [ "SRC-003", "SRC-023", "SRC-021", "SRC-001", "SRC-010", "SRC-020" ], "layers": [ { "id": "predecessor-successor", "name": "Predecessor and Successor Topology", "description": "The direct ancestry of a revision, including multi-parent merges, branch scoping and the completeness guarantee on the link set.", "source_refs": [ "SRC-003", "SRC-023", "SRC-021", "SRC-010", "SRC-025" ], "findings": [ { "id": "predecessor-set-and-topology", "name": "Predecessor set, merge topology and graph integrity", "description": "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.", "source_refs": [ "SRC-003", "SRC-023", "SRC-021", "SRC-010", "SRC-025", "SRC-013" ], "questions": [ { "id": "q-predecessor-set", "text": "Which revisions does this revision directly succeed, and is the predecessor set empty because it is the root?", "kind": "relationship", "answer_data": [ "Predecessor revision references", "Root revision flag", "Cardinality actually observed" ] }, { "id": "q-topology-kind", "text": "Does the history of this entity form a linear chain or a directed acyclic graph with merge nodes?", "kind": "composition", "answer_data": [ "Topology kind code", "Maximum observed parent count", "Branch inventory" ] }, { "id": "q-merge-strategy", "text": "When a revision has multiple predecessors, what merge strategy produced it and was any predecessor content discarded?", "kind": "process", "answer_data": [ "Merge strategy code", "Discarded content summary", "Conflict resolutions applied" ] }, { "id": "q-lineage-completeness", "text": "Is the predecessor set closed and verifiable, or may it be incomplete because of import, embargo or disposition?", "kind": "quality", "answer_data": [ "Completeness code", "Reason for incompleteness", "Earliest verifiable ancestor" ] }, { "id": "q-graph-validation", "text": "Are cycles, self-references and dangling predecessor references structurally prohibited and actually validated?", "kind": "validation", "answer_data": [ "Acyclicity check outcome", "Dangling reference count", "Validation timestamp" ] } ], "data_elements": [ { "id": "de-predecessor-refs", "name": "Predecessor references", "description": "Set of revisions that this revision directly succeeds; cardinality zero for a root and greater than one for a merge.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003", "SRC-023", "SRC-021" ] }, { "id": "de-successor-refs", "name": "Successor references", "description": "Computed set of revisions whose predecessor set contains this revision; may be plural under branching.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003", "SRC-023" ] }, { "id": "de-topology-kind", "name": "Topology kind", "description": "Declared shape of the entity's history: strict chain, tree, or directed acyclic graph with merges.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-021", "SRC-010" ] }, { "id": "de-merge-strategy", "name": "Merge strategy", "description": "The strategy applied when combining multiple predecessors into this revision.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-021", "SRC-003" ] }, { "id": "de-lineage-completeness", "name": "Lineage completeness", "description": "Statement of whether the ancestry is complete back to the root, and if not, where and why it stops.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-020", "SRC-026" ] } ], "artifacts": [ { "id": "a-lineage-graph-export", "name": "Lineage graph export", "description": "A serialised projection of the predecessor and successor edges over a stated revision range, usable for traversal and validation without access to revision content.", "media_or_form": [ "graph serialisation", "link set", "navigation link header set" ], "serial": false, "identity_strategy": "Identified by entity persistent identifier plus the revision range covered plus the generation instant; regenerated rather than amended, and never treated as authoritative over the per-revision predecessor sets.", "source_refs": [ "SRC-003", "SRC-025", "SRC-021" ] }, { "id": "a-merge-record", "name": "Merge record", "description": "Per-merge record capturing the strategy, the conflicts encountered, the resolutions chosen and any content deliberately discarded.", "media_or_form": [ "structured event record", "narrative resolution note" ], "serial": true, "identity_strategy": "Identified by the resulting revision identifier; one record per merge event, immutable once the resulting revision is released.", "source_refs": [ "SRC-021", "SRC-022" ] } ], "inline_only_rationale": null }, { "id": "replacement-supersession", "name": "Replacement and supersession", "description": "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.", "source_refs": [ "SRC-028", "SRC-010", "SRC-030" ], "questions": [ { "id": "replacement-supersession-q01", "text": "Which prior resource does this revision supplant, displace or supersede, and does the prior resource remain citable?", "kind": "relationship", "answer_data": [ "replaces_refs", "is_replaced_by_inverse", "prior_still_citable", "validity_rule" ] }, { "id": "replacement-supersession-q02", "text": "If persistent identifiers are used, is this identifier linked as IsNewVersionOf the previous edition and the previous as IsPreviousVersionOf this one?", "kind": "interoperability", "answer_data": [ "is_new_version_of_ref", "is_previous_version_of_ref", "related_identifier_type" ] }, { "id": "replacement-supersession-q03", "text": "Is only one version valid in this chain, as in successive drafts of a contract, or are historical snapshots still in force for citation?", "kind": "constraint", "answer_data": [ "single_valid_flag", "valid_version_ref", "citation_policy" ] }, { "id": "replacement-supersession-q04", "text": "Who authorised the replacement, and at what event time versus observation time?", "kind": "authority", "answer_data": [ "authorising_party_ref", "event_time", "observation_time", "instrument_ref" ] } ], "data_elements": [ { "id": "replacement-supersession-data01", "name": "Replaces", "description": "Resources this revision supplants (dcterms:replaces).", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-028", "SRC-010" ] }, { "id": "replacement-supersession-data02", "name": "Is replaced by", "description": "Resources that supplant this revision (dcterms:isReplacedBy).", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-028" ] }, { "id": "replacement-supersession-data03", "name": "Is new version of", "description": "DataCite relation: this is a new edition of the referenced resource.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-030" ] }, { "id": "replacement-supersession-data04", "name": "Single valid version in chain", "description": "True when the chain is a validity chain rather than a citable snapshot history.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-028" ] } ], "artifacts": [ { "id": "replacement-supersession-artifact01", "name": "Replacement or supersession notice", "description": "Statement that this revision displaces another, including remaining citation rights for the old identifier.", "media_or_form": [ "text/plain", "text/markdown", "application/ld+json" ], "serial": true, "identity_strategy": "Master-system notice identifier if issued; else governed IRI; else Dimension UUID.", "source_refs": [ "SRC-028", "SRC-030" ] } ], "inline_only_rationale": null } ] }, { "id": "derivation-semantics", "name": "Derivation Semantics and External Lineage", "description": "The typed meaning of a change link and the recording of upstream external versions consumed to produce a revision.", "source_refs": [ "SRC-001", "SRC-011", "SRC-020", "SRC-016" ], "findings": [ { "id": "revision-derivation-or-variant", "name": "Revision versus derivation versus format variant", "description": "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.", "source_refs": [ "SRC-001", "SRC-011", "SRC-010", "SRC-016" ], "questions": [ { "id": "q-link-type", "text": "Is this a revision of the same entity, a derivation into a new entity, or only a new format or rendition of unchanged content?", "kind": "classification", "answer_data": [ "Change relation type code", "Target entity identifier", "Vocabulary term used for the relation" ] }, { "id": "q-substantiality-test", "text": "What test distinguishes 'substantial content retained, therefore a revision' from 'a new entity'?", "kind": "definition", "answer_data": [ "Substantiality test statement", "Threshold or criterion", "Who applies the test" ] }, { "id": "q-identifier-change", "text": "Does a change of entity identifier accompany this change, and on what grounds?", "kind": "identity", "answer_data": [ "Identifier changed flag", "New identifier", "Justification" ] }, { "id": "q-alternate-specialization", "text": "Are the two records alternates of one another, or specialisations of a shared abstract entity?", "kind": "relationship", "answer_data": [ "Alternate-of assertions", "Specialization-of assertions", "Shared abstract entity identifier" ] } ], "data_elements": [ { "id": "de-change-relation-type", "name": "Change relation type", "description": "Typed relation asserted between the prior and the current record: revision, derivation, format variant, alternate or specialisation.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-011" ] }, { "id": "de-derived-from-refs", "name": "Derived-from references", "description": "Entities from which this record was derived when the relation is a derivation rather than a revision.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-format-variant-of", "name": "Format-variant-of reference", "description": "Reference to the substantially identical resource in another format, where only the rendition changed.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "de-substantiality-test", "name": "Substantiality test statement", "description": "The recorded criterion applied to classify the change, so that the classification is auditable rather than tacit.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-010" ] } ], "artifacts": [], "inline_only_rationale": "These are typed relation assertions carried inline on the revision record; the evidence supporting the classification decision lives in the change set, the impact assessment and the change note artifacts declared elsewhere in this model, so no separate artifact is warranted." }, { "id": "upstream-version-dependency", "name": "Upstream and ingredient version dependency", "description": "The external or upstream artefact versions consumed to produce a revision, whether those references are pinned, and how upstream withdrawal is detected.", "source_refs": [ "SRC-020", "SRC-019", "SRC-002", "SRC-012" ], "questions": [ { "id": "q-ingredients", "text": "Which external or upstream artefact versions were consumed to produce this revision?", "kind": "provenance", "answer_data": [ "Upstream artefact identifiers", "Upstream version labels", "Upstream registry or source references" ] }, { "id": "q-pinning", "text": "Is each upstream reference pinned to an immutable version and digest, or does it point at a moving target?", "kind": "constraint", "answer_data": [ "Pinned flag per reference", "Pinned digest values", "Justification for any unpinned reference" ] }, { "id": "q-upstream-withdrawal", "text": "How is an upstream version withdrawal, re-tagging or yank detected after this revision was produced?", "kind": "event", "answer_data": [ "Detection mechanism", "Last verification instant", "Action on detection" ] }, { "id": "q-upstream-unverifiable", "text": "What is recorded when upstream provenance is unavailable or cannot be verified?", "kind": "evidence", "answer_data": [ "Unverifiable marker", "Reason code", "Residual risk statement" ] } ], "data_elements": [ { "id": "de-ingredient-refs", "name": "Ingredient references", "description": "Upstream artefacts, with version and origin, incorporated into this revision.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-020", "SRC-019" ] }, { "id": "de-ingredient-pinned", "name": "Ingredient pinned flag", "description": "Whether each upstream reference is bound to an immutable version and content digest.", "value_kind": "boolean", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-012" ] }, { "id": "de-ingredient-digest", "name": "Ingredient content digest", "description": "Digest of the exact upstream content consumed, enabling later detection of substitution.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-020", "SRC-012" ] } ], "artifacts": [ { "id": "a-ingredient-manifest", "name": "Ingredient manifest", "description": "The record of upstream versions consumed by a revision, preserving the upstream provenance alongside the new change rather than replacing it.", "media_or_form": [ "structured record", "embedded manifest", "signed claim" ], "serial": true, "identity_strategy": "Identified by the consuming revision identifier; each entry keyed by upstream identifier plus upstream version plus content digest.", "source_refs": [ "SRC-020", "SRC-012" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "change-substance", "name": "Change Substance, Compatibility and Migration", "description": "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.", "rationale": "W3C DWBP Best Practice 8 requires not just a list of versions but a changelog stating precisely how each version differs from its predecessor. RFC 6902 supplies an atomic delta formalism, Avro supplies directional compatibility rules, Semantic Versioning ties breaking change to a declared surface, and RFC 9745 constrains deprecation before sunset. Together these make change substance a first-class concern distinct from lineage.", "source_refs": [ "SRC-014", "SRC-006", "SRC-019", "SRC-002", "SRC-024", "SRC-012" ], "layers": [ { "id": "change-content", "name": "Change Sets and Change Classification", "description": "The machine-readable delta, its significance, and the human-readable account of it.", "source_refs": [ "SRC-006", "SRC-012", "SRC-002", "SRC-014", "SRC-027", "SRC-020" ], "findings": [ { "id": "change-set-representation", "name": "Change set representation and verifiability", "description": "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.", "source_refs": [ "SRC-006", "SRC-012", "SRC-009", "SRC-020" ], "questions": [ { "id": "q-storage-strategy", "text": "Is this revision stored as a full state snapshot, as a forward delta against its predecessor, or as both?", "kind": "composition", "answer_data": [ "Storage strategy code", "Snapshot availability flag", "Delta base revision identifier" ] }, { "id": "q-delta-formalism", "text": "Which patch or diff formalism expresses the delta, and at what version?", "kind": "interoperability", "answer_data": [ "Formalism identifier and version", "Media type or equivalent", "Operation vocabulary used" ] }, { "id": "q-delta-atomicity", "text": "Are delta operations applied atomically, and what is the defined outcome when one operation fails?", "kind": "constraint", "answer_data": [ "Atomicity guarantee", "Failure outcome code", "Partial-application prohibition statement" ] }, { "id": "q-delta-verifiable", "text": "Can the delta be verified to reproduce the successor state exactly, and against which digest?", "kind": "validation", "answer_data": [ "Expected result digest", "Canonicalisation profile applied", "Verification outcome and instant" ] }, { "id": "q-delta-invertible", "text": "Is the delta invertible so that the predecessor state can be recomputed from the successor?", "kind": "constraint", "answer_data": [ "Invertibility flag", "Inverse patch reference", "Information lost under inversion" ] } ], "data_elements": [ { "id": "de-storage-strategy", "name": "Storage strategy", "description": "Whether the revision is materialised as a snapshot, a forward delta, or both.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-012", "SRC-006" ] }, { "id": "de-change-set-format", "name": "Change set format", "description": "Identifier and version of the patch or diff formalism used to express the delta.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "de-change-operations", "name": "Change operations", "description": "Ordered list of operations constituting the delta, including any precondition test operations.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "de-expected-result-digest", "name": "Expected result digest", "description": "Digest of the canonicalised successor state that a correctly applied delta must reproduce.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009", "SRC-012" ] } ], "artifacts": [ { "id": "a-change-set", "name": "Change set document", "description": "The stored delta between two revisions, expressed as an ordered operation list with preconditions, applied atomically.", "media_or_form": [ "patch document", "diff", "ordered operation list" ], "serial": true, "identity_strategy": "Identified by predecessor revision identifier plus successor revision identifier; the canonicalised patch carries its own digest and is never edited after publication.", "source_refs": [ "SRC-006", "SRC-009", "SRC-012" ] } ], "inline_only_rationale": null }, { "id": "change-classification-and-note", "name": "Change classification, significance and human-readable note", "description": "The categories, breaking status, semantic impact and severity of the change, together with the concise human-readable account required for a usable version history.", "source_refs": [ "SRC-002", "SRC-014", "SRC-027", "SRC-022", "SRC-020", "SRC-010" ], "questions": [ { "id": "q-change-categories", "text": "What categories of change does this revision contain?", "kind": "classification", "answer_data": [ "Category codes (added, changed, deprecated, removed, fixed, security)", "Category vocabulary identifier", "Per-category item list" ] }, { "id": "q-breaking", "text": "Is any change in this revision breaking for declared consumers of the declared public surface?", "kind": "constraint", "answer_data": [ "Breaking flag", "Affected surface elements", "Consumer classes affected" ] }, { "id": "q-semantic-impact", "text": "Does the change alter meaning, or only presentation, encoding or format?", "kind": "definition", "answer_data": [ "Semantic impact code", "Elements whose meaning changed", "Elements whose encoding only changed" ] }, { "id": "q-correction", "text": "Is this revision a correction of a previously published error, and does it supersede a published statement?", "kind": "quality", "answer_data": [ "Correction flag", "Superseded statement reference", "Error description" ] }, { "id": "q-change-note", "text": "What concise human-readable statement describes what changed and why, and in which languages is it maintained?", "kind": "definition", "answer_data": [ "Change note text", "Language tags", "Intended audience" ] }, { "id": "q-note-completeness", "text": "Is the human-readable note guaranteed complete with respect to the machine-readable delta?", "kind": "quality", "answer_data": [ "Completeness assertion", "Known omissions from the note", "Reviewer reference" ] } ], "data_elements": [ { "id": "de-change-categories", "name": "Change categories", "description": "Coded categories of change present in the revision, drawn from a declared vocabulary.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-027", "SRC-020" ] }, { "id": "de-breaking-change", "name": "Breaking change flag", "description": "Whether the revision introduces a backward-incompatible change to the declared public surface.", "value_kind": "boolean", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-019" ] }, { "id": "de-severity", "name": "Change severity", "description": "Severity or urgency attached to the change, used to drive consumer action such as expedited upgrade.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-027", "SRC-022" ] }, { "id": "de-change-note-text", "name": "Change note text", "description": "Human-readable description of what changed and why, per language.", "value_kind": "text", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-014", "SRC-010" ] }, { "id": "de-change-reason", "name": "Change reason", "description": "The stated reason or driver for the change, distinct from the description of the change itself.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-022", "SRC-017" ] }, { "id": "de-release-status", "name": "Release status of the change note", "description": "Whether the note describes a released revision or an accumulating unreleased set.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-027" ] } ], "artifacts": [ { "id": "a-changelog", "name": "Changelog / release note", "description": "The human-readable, per-revision account of differences from the predecessor, required by DWBP Best Practice 8 and conventionally organised by change category with a release date.", "media_or_form": [ "human-readable document", "structured entry list", "published notice" ], "serial": true, "identity_strategy": "One entry per released revision, keyed by revision identifier and version label with an RFC 3339 release date; the aggregate document is identified by the entity persistent identifier and is append-only at the top.", "source_refs": [ "SRC-014", "SRC-027", "SRC-010" ] }, { "id": "a-change-impact-assessment", "name": "Change impact assessment", "description": "The recorded pre-approval analysis of the security, compatibility and operational impact of a proposed change.", "media_or_form": [ "assessment record", "review note" ], "serial": true, "identity_strategy": "Identified by change request identifier plus assessment instant plus assessing role; bound to the resulting revision identifier once the change is released.", "source_refs": [ "SRC-022", "SRC-002" ] } ], "inline_only_rationale": null } ] }, { "id": "compatibility-and-migration", "name": "Compatibility, Migration and Deprecation", "description": "What a consumer must know and do to move between versions, and how the retirement of a version is announced and timed.", "source_refs": [ "SRC-019", "SRC-016", "SRC-002", "SRC-024", "SRC-025", "SRC-012" ], "findings": [ { "id": "compatibility-declaration", "name": "Compatibility declaration and its evidence", "description": "With which prior versions this revision is declared compatible or incompatible, in which direction, and what evidence supports the claim.", "source_refs": [ "SRC-016", "SRC-019", "SRC-002" ], "questions": [ { "id": "q-compat-targets", "text": "With which prior versions is this revision declared backward compatible, and with which incompatible?", "kind": "constraint", "answer_data": [ "Backward-compatible-with version references", "Incompatible-with version references", "Unassessed version references" ] }, { "id": "q-compat-direction", "text": "Is compatibility asserted for readers of newer data, for writers producing older data, or in both directions?", "kind": "definition", "answer_data": [ "Direction code", "Reader schema assumptions", "Writer schema assumptions" ] }, { "id": "q-compat-evidence", "text": "What evidence supports the compatibility claim, and can it be re-executed?", "kind": "evidence", "answer_data": [ "Evidence reference (test suite, resolution check, review)", "Execution instant and outcome", "Re-execution instructions" ] }, { "id": "q-default-handling", "text": "How are optional and defaulted elements treated when an older consumer reads data produced under this revision?", "kind": "interoperability", "answer_data": [ "Default value policy", "Ignored-element behaviour", "Error conditions for missing required elements" ] } ], "data_elements": [ { "id": "de-backward-compatible-with", "name": "Backward-compatible-with", "description": "Prior versions with which this revision is declared compatible.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-016", "SRC-019" ] }, { "id": "de-incompatible-with", "name": "Incompatible-with", "description": "Prior versions with which this revision is declared incompatible.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-016", "SRC-002" ] }, { "id": "de-compatibility-direction", "name": "Compatibility direction", "description": "Whether the claim is backward, forward, full or none.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-019" ] }, { "id": "de-compatibility-evidence", "name": "Compatibility evidence reference", "description": "Reference to the test, resolution check or review that substantiates the compatibility claim.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-019", "SRC-022" ] } ], "artifacts": [ { "id": "a-compatibility-matrix", "name": "Compatibility matrix", "description": "The published mapping of which producer versions are readable by which consumer versions, with the direction and evidence for each cell.", "media_or_form": [ "matrix table", "machine-readable declaration" ], "serial": false, "identity_strategy": "Identified by entity persistent identifier plus the revision range covered plus a matrix revision identifier; re-issued as a whole rather than amended in place.", "source_refs": [ "SRC-019", "SRC-016" ] } ], "inline_only_rationale": null }, { "id": "migration-procedure", "name": "Migration procedure between versions", "description": "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.", "source_refs": [ "SRC-019", "SRC-006", "SRC-012", "SRC-022", "SRC-002" ], "questions": [ { "id": "q-migration-required", "text": "Is a migration required to adopt this revision, or is adoption transparent to existing instances and consumers?", "kind": "requirement", "answer_data": [ "Migration required flag", "Affected instance classes", "Transparent-adoption justification" ] }, { "id": "q-migration-procedure", "text": "What procedure moves an instance from the predecessor version to this revision, and in what order are its steps executed?", "kind": "process", "answer_data": [ "Ordered step list", "Executable transform reference", "Pre-flight validation steps" ] }, { "id": "q-migration-reversible", "text": "Is the migration reversible, and what is the documented rollback path?", "kind": "lifecycle", "answer_data": [ "Reversibility flag", "Rollback procedure reference", "Point of no return" ] }, { "id": "q-migration-idempotent", "text": "Is the migration idempotent and safe to re-run after a partial failure?", "kind": "constraint", "answer_data": [ "Idempotence flag", "Resume semantics", "Detection of already-migrated state" ] }, { "id": "q-migration-loss", "text": "What data loss, precision loss or semantic loss is expected and accepted by this migration?", "kind": "quality", "answer_data": [ "Expected loss description", "Accepting authority", "Elements irrecoverably dropped" ] }, { "id": "q-migration-owner", "text": "Who is responsible for executing the migration, and by when must it complete?", "kind": "ownership", "answer_data": [ "Responsible role or party reference", "Deadline date", "Consequence of non-completion" ] } ], "data_elements": [ { "id": "de-migration-required", "name": "Migration required flag", "description": "Whether adopting this revision requires an explicit migration of existing instances or consumers.", "value_kind": "boolean", "cardinality": "1", "required": true, "source_refs": [ "SRC-019", "SRC-002" ] }, { "id": "de-migration-steps", "name": "Migration steps", "description": "Ordered, executable or procedural steps that transform predecessor-version state into this revision's state.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006", "SRC-012" ] }, { "id": "de-migration-reversible", "name": "Migration reversibility", "description": "Whether the migration can be reversed and by what path.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006", "SRC-012" ] }, { "id": "de-migration-deadline", "name": "Migration deadline", "description": "Date by which consumers must complete migration, typically aligned with the sunset instant.", "value_kind": "date", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-024" ] }, { "id": "de-known-loss", "name": "Known migration loss", "description": "Explicit statement of data, precision or semantics not preserved by the migration.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-019", "SRC-012" ] } ], "artifacts": [ { "id": "a-migration-plan", "name": "Migration plan and transform", "description": "The procedure document plus any executable transform or mapping table that carries state from one version to another, retained so that historical migrations remain auditable and repeatable.", "media_or_form": [ "procedure document", "executable transform", "mapping table" ], "serial": true, "identity_strategy": "Identified by source revision identifier plus target revision identifier; each executable transform carries its own content digest and is immutable once a migration has been executed against it.", "source_refs": [ "SRC-019", "SRC-012", "SRC-022" ] } ], "inline_only_rationale": null }, { "id": "deprecation-and-sunset", "name": "Deprecation and sunset of a version", "description": "The announcement that a revision, element or endpoint is deprecated, the instant it stops being served, and the replacement a consumer should adopt.", "source_refs": [ "SRC-024", "SRC-025", "SRC-016", "SRC-015", "SRC-027" ], "questions": [ { "id": "q-deprecated", "text": "Is this revision, or an element within it, deprecated, and from which instant does the deprecation take effect?", "kind": "state", "answer_data": [ "Deprecated flag", "Deprecation effective instant", "Scope of deprecation (whole revision or named elements)" ] }, { "id": "q-sunset", "text": "At which instant will the deprecated revision or endpoint stop being served, and is that instant at or after the deprecation instant?", "kind": "temporal", "answer_data": [ "Sunset instant", "Ordering check outcome", "Post-sunset response behaviour" ] }, { "id": "q-replacement", "text": "What replacement is recommended, and where is the migration guidance published?", "kind": "decision", "answer_data": [ "Replacement revision or element reference", "Guidance document URL", "Guidance revision identifier" ] }, { "id": "q-deprecation-signal", "text": "How is the deprecation signalled to consumers that only interact through the access interface?", "kind": "interoperability", "answer_data": [ "Signalling mechanism (header, metadata property, link relation)", "Link relation used", "Signal activation instant" ] } ], "data_elements": [ { "id": "de-deprecated", "name": "Deprecated flag", "description": "Whether the revision or element is deprecated.", "value_kind": "boolean", "cardinality": "1", "required": true, "source_refs": [ "SRC-016", "SRC-024" ] }, { "id": "de-deprecation-effective-at", "name": "Deprecation effective instant", "description": "Instant from which the deprecation takes effect, in RFC 3339 form.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-024", "SRC-007" ] }, { "id": "de-sunset-at", "name": "Sunset instant", "description": "Instant at which the deprecated revision or endpoint is expected to become unavailable; must not precede the deprecation instant.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-024", "SRC-025" ] }, { "id": "de-replacement-ref", "name": "Replacement reference", "description": "The revision or element that consumers should adopt instead.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011", "SRC-024" ] }, { "id": "de-deprecation-notice-uri", "name": "Deprecation documentation identifier", "description": "Resolvable identifier of human-readable deprecation and migration documentation.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-024", "SRC-025" ] } ], "artifacts": [ { "id": "a-deprecation-notice", "name": "Deprecation and sunset notice", "description": "The published notice binding a deprecated revision to its effective instant, sunset instant, replacement and migration guidance.", "media_or_form": [ "notice document", "interface metadata signal", "link relation target" ], "serial": true, "identity_strategy": "Identified by the deprecated revision or endpoint identifier plus the deprecation effective instant; superseded only by a notice with a later effective instant, never silently withdrawn.", "source_refs": [ "SRC-024", "SRC-025" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "temporal-and-state", "name": "Temporal Frame and Revision Lifecycle", "description": "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.", "rationale": "RFC 3339 requires an explicit offset on every instant; PROV-O bounds entity existence with generatedAtTime and invalidatedAtTime; DID Core distinguishes created, updated, nextUpdate and deactivated; RFC 3253 defines checkout and checkin states; FHIR records deletions as history entries without content. Time and state are therefore separable, sourced concerns rather than fields on the identity record.", "source_refs": [ "SRC-007", "SRC-001", "SRC-015", "SRC-023", "SRC-013", "SRC-011" ], "layers": [ { "id": "time-model", "name": "Time Model of a Revision", "description": "The distinct instants attached to a revision and the periods over which its content is asserted to be true.", "source_refs": [ "SRC-007", "SRC-001", "SRC-004", "SRC-011", "SRC-015", "SRC-017" ], "findings": [ { "id": "revision-timestamps", "name": "Change-event time, record time and publication time", "description": "The separate instants at which the change occurred, was recorded, and was published, together with their clock source, precision and monotonicity guarantees.", "source_refs": [ "SRC-007", "SRC-001", "SRC-013", "SRC-017", "SRC-022", "SRC-008" ], "questions": [ { "id": "q-event-vs-record-time", "text": "At what instant did the change event occur, and at what separate instant was it recorded by the system of record?", "kind": "temporal", "answer_data": [ "Change event instant", "Record or ingestion instant", "Publication instant where different" ] }, { "id": "q-clock-authority", "text": "Which clock and which offset are authoritative for the recorded instants, and is the timestamp computer-generated?", "kind": "provenance", "answer_data": [ "Clock source identifier", "Offset used or Z", "Computer-generated flag" ] }, { "id": "q-time-monotonic", "text": "Is the recorded time monotonic across the revision sequence, and what is done when it is not?", "kind": "exception", "answer_data": [ "Monotonicity guarantee", "Observed inversions", "Resolution rule using sequence rather than time" ] }, { "id": "q-time-precision", "text": "What temporal precision is guaranteed, and is an independently attested timestamp required?", "kind": "measurement", "answer_data": [ "Precision code", "Fractional-second digits recorded", "Trusted timestamp requirement and authority" ] } ], "data_elements": [ { "id": "de-change-event-time", "name": "Change event instant", "description": "RFC 3339 instant at which the change actually occurred, with seconds and an explicit offset or Z.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-007", "SRC-001" ] }, { "id": "de-recorded-at", "name": "Record instant", "description": "RFC 3339 instant at which the system of record captured the revision, kept separate from the event instant.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-007", "SRC-013", "SRC-017" ] }, { "id": "de-published-at", "name": "Publication instant", "description": "Instant of formal issuance of the revision to consumers, where this differs from the record instant.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011", "SRC-004" ] }, { "id": "de-time-source", "name": "Time source", "description": "Identifier of the clock or time authority that produced the instants.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017", "SRC-022" ] }, { "id": "de-timestamp-precision", "name": "Timestamp precision", "description": "Guaranteed precision of recorded instants, including fractional-second digits.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] } ], "artifacts": [ { "id": "a-timestamp-attestation", "name": "Timestamp attestation", "description": "Optional independently issued attestation binding a revision digest to an instant, used where a secure, computer-generated time-stamped record and non-repudiation are required.", "media_or_form": [ "signed token", "attestation record" ], "serial": true, "identity_strategy": "Identified by revision identifier plus attested instant plus attesting authority identifier; retained for at least the retention period of the revision it attests.", "source_refs": [ "SRC-017", "SRC-022" ] } ], "inline_only_rationale": null }, { "id": "effective-period-and-retroactivity", "name": "Effective period, supersession and retroactive correction", "description": "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.", "source_refs": [ "SRC-011", "SRC-015", "SRC-004", "SRC-001", "SRC-010" ], "questions": [ { "id": "q-effective-period", "text": "Over which period is the content of this revision asserted to be true in the world, as distinct from when it was recorded?", "kind": "temporal", "answer_data": [ "Effective-from instant", "Effective-to instant or open end", "Whether the period is asserted or inferred" ] }, { "id": "q-retroactive", "text": "Does this revision correct the record for a past period, or does it apply only forward from its effective instant?", "kind": "decision", "answer_data": [ "Retroactive flag", "Corrected period", "Records invalidated by the correction" ] }, { "id": "q-superseded-at", "text": "At which instant did the predecessor revision cease to be the record of truth?", "kind": "state", "answer_data": [ "Supersession instant", "Superseding revision reference", "Whether supersession and effective-from coincide" ] }, { "id": "q-asof-resolution", "text": "When an as-of query is issued, is it resolved against record time or effective time, and how is the choice signalled?", "kind": "process", "answer_data": [ "Default resolution axis", "Parameter for selecting the axis", "Behaviour when the two axes disagree" ] } ], "data_elements": [ { "id": "de-effective-from", "name": "Effective-from instant", "description": "Instant from which the revision's content is asserted to hold in the world.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011", "SRC-015" ] }, { "id": "de-effective-to", "name": "Effective-to instant", "description": "Instant at which the revision's assertion ceases to hold, open-ended while current.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011", "SRC-001" ] }, { "id": "de-superseded-at", "name": "Supersession instant", "description": "Instant at which this revision ceased to be the current record, bounding the end of its existence as the operative state.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-015" ] }, { "id": "de-retroactive", "name": "Retroactive correction flag", "description": "Whether the revision changes the recorded truth for a period already elapsed.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011", "SRC-013" ] }, { "id": "de-as-of-axis", "name": "As-of resolution axis", "description": "Which temporal axis an as-of query is resolved against by default.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-015" ] } ], "artifacts": [], "inline_only_rationale": "Effective-period and supersession assertions are inline temporal attributes of the revision record; their queryable projection is the as-of retrieval interface specified in history-retrieval-and-reconstruction, and the cited primary sources supply properties (dcterms:valid, versionTime, Memento-Datetime) rather than a distinct stored artifact. This finding is flagged in coverage as having only partial primary support for full bitemporal period semantics." } ] }, { "id": "revision-lifecycle", "name": "Revision Lifecycle and Withdrawal", "description": "The states a revision may occupy, the point at which it becomes immutable, and how retraction, deletion and deactivation are represented.", "source_refs": [ "SRC-023", "SRC-013", "SRC-015", "SRC-002", "SRC-012" ], "findings": [ { "id": "revision-state-machine", "name": "Revision lifecycle states and legal transitions", "description": "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.", "source_refs": [ "SRC-023", "SRC-002", "SRC-012", "SRC-013", "SRC-022" ], "questions": [ { "id": "q-states", "text": "What lifecycle states may a revision occupy, and which transitions between them are legal?", "kind": "lifecycle", "answer_data": [ "State vocabulary", "Legal transition pairs", "Terminal states" ] }, { "id": "q-immutability-point", "text": "At which state does the revision become immutable, and what enforces immutability from that point?", "kind": "constraint", "answer_data": [ "Immutability onset state", "Enforcement mechanism", "Consequence of an attempted post-release edit" ] }, { "id": "q-promotion-authority", "text": "Who may promote a working copy or draft to a released revision?", "kind": "authority", "answer_data": [ "Authorised role", "Required approvals", "Delegation rules" ] }, { "id": "q-unrelease", "text": "May a released revision return to draft, and if not, what is the substitute mechanism?", "kind": "exception", "answer_data": [ "Un-release permitted flag", "Substitute mechanism (supersede, withdraw, yank)", "Recording requirement" ] }, { "id": "q-abandoned-checkout", "text": "What happens to a working copy or checkout that is never checked in?", "kind": "state", "answer_data": [ "Expiry policy", "Reclaim procedure", "Whether abandoned work is retained or discarded" ] } ], "data_elements": [ { "id": "de-revision-state", "name": "Revision state", "description": "Current lifecycle state of the revision.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-023", "SRC-013" ] }, { "id": "de-state-changed-at", "name": "State change instant", "description": "RFC 3339 instant of the most recent state transition.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007", "SRC-015" ] }, { "id": "de-working-copy-of", "name": "Working-copy-of reference", "description": "For a working copy, the versioned resource from which it was obtained.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003", "SRC-023" ] }, { "id": "de-checkout-holder", "name": "Checkout holder", "description": "Agent currently holding a checkout or working copy, where a checkout model is in use.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-023" ] } ], "artifacts": [ { "id": "a-state-transition-record", "name": "Revision state transition record", "description": "Per-transition record of the state change, its instant, its effecting agent and its authority, forming the lifecycle portion of the change history.", "media_or_form": [ "structured event record" ], "serial": true, "identity_strategy": "Identified by revision identifier plus a transition sequence number starting at 1 and continuous, plus the transition instant.", "source_refs": [ "SRC-023", "SRC-017", "SRC-022" ] } ], "inline_only_rationale": null }, { "id": "withdrawal-and-tombstone", "name": "Withdrawal, tombstoning and deletion in history", "description": "How retraction, deactivation and deletion are represented so that a consumer can distinguish 'removed' from 'never existed', and whether reinstatement is possible.", "source_refs": [ "SRC-013", "SRC-015", "SRC-020", "SRC-026", "SRC-017" ], "questions": [ { "id": "q-withdrawal-kind", "text": "How is a withdrawal, retraction, deactivation or deletion represented in the history?", "kind": "event", "answer_data": [ "Withdrawal kind code", "History entry form (entry without content, status flag)", "Instant of withdrawal" ] }, { "id": "q-withdrawal-scope", "text": "Does the withdrawal remove content, remove availability, or only mark status?", "kind": "definition", "answer_data": [ "Scope code", "Content destroyed flag", "Metadata retained after withdrawal" ] }, { "id": "q-tombstone", "text": "Is a tombstone published so that consumers can distinguish a deleted revision from one that never existed?", "kind": "interoperability", "answer_data": [ "Tombstone published flag", "Tombstone content fields", "Response behaviour for withdrawn revisions" ] }, { "id": "q-reinstatement", "text": "Can a withdrawn revision be reinstated, and under whose authority?", "kind": "authority", "answer_data": [ "Reinstatement permitted flag", "Authorising role", "Whether reinstatement mints a new revision" ] }, { "id": "q-withdrawal-reason", "text": "What reason is recorded for the withdrawal, and is that reason itself disclosable?", "kind": "privacy", "answer_data": [ "Reason text or code", "Disclosure classification of the reason", "Redacted reason placeholder" ] } ], "data_elements": [ { "id": "de-withdrawal-kind", "name": "Withdrawal kind", "description": "Whether the revision was retracted, deactivated, superseded or destroyed.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013", "SRC-015" ] }, { "id": "de-withdrawn-at", "name": "Withdrawal instant", "description": "RFC 3339 instant at which the withdrawal took effect.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007", "SRC-013" ] }, { "id": "de-tombstone-published", "name": "Tombstone published flag", "description": "Whether a tombstone entry is exposed in place of the withdrawn revision.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013", "SRC-015" ] }, { "id": "de-withdrawal-reason", "name": "Withdrawal reason", "description": "Recorded reason for the withdrawal, subject to its own disclosure classification.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-026", "SRC-017" ] } ], "artifacts": [ { "id": "a-tombstone", "name": "Withdrawal / tombstone record", "description": "The history entry that records a withdrawal or deletion, carrying status, instant and authority but no withdrawn content, so lineage and ordering remain intact.", "media_or_form": [ "status record", "history entry without content" ], "serial": true, "identity_strategy": "Identified by the withdrawn revision identifier; survives destruction of the withdrawn content and is itself immutable.", "source_refs": [ "SRC-013", "SRC-026", "SRC-017" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "authority-and-integrity", "name": "Change Authority, Attribution and Record Integrity", "description": "Who made a change, under what authority, and what makes the resulting history verifiable and tamper-evident.", "rationale": "21 CFR 11.10(e) requires audit trails that independently record who created, modified or deleted a record without obscuring prior entries; NIST SP 800-53 CM-3 requires proposal, impact analysis and approval of changes and AU-10 requires non-repudiation; C2PA requires signed claims whose assertions cannot be modified once made. Attribution and integrity are therefore normative requirements, not optional metadata.", "source_refs": [ "SRC-017", "SRC-022", "SRC-020", "SRC-001", "SRC-012", "SRC-009" ], "layers": [ { "id": "agency-and-authorization", "name": "Agency and Change Authority", "description": "The agent that performed the change and the authority or approval under which it was permitted.", "source_refs": [ "SRC-001", "SRC-017", "SRC-022" ], "findings": [ { "id": "change-agent-attribution", "name": "Attribution of the change to an agent", "description": "Which agent performed the change, on whose behalf, whether that agent is a person, organisation or software, and how the attribution is substantiated.", "source_refs": [ "SRC-001", "SRC-017", "SRC-022", "SRC-020" ], "questions": [ { "id": "q-agent", "text": "Which agent performed the change, and on whose behalf did they act?", "kind": "ownership", "answer_data": [ "Agent identifier", "On-behalf-of party identifier", "Role at time of change" ] }, { "id": "q-agent-kind", "text": "Is the agent a person, an organisation or a software agent, and is that distinction recorded explicitly?", "kind": "classification", "answer_data": [ "Agent kind code", "Software agent version where applicable", "Human oversight indicator for automated changes" ] }, { "id": "q-agent-verification", "text": "Is the identity of the agent verified, and by what means?", "kind": "evidence", "answer_data": [ "Authentication method code", "Verification evidence reference", "Assurance level" ] }, { "id": "q-generating-activity", "text": "Which activity, process or job produced this revision?", "kind": "provenance", "answer_data": [ "Activity identifier", "Activity start and end instants", "Activity type" ] } ], "data_elements": [ { "id": "de-change-agent-ref", "name": "Change agent reference", "description": "Resolvable reference to the agent that performed the change; resolves into the party/agent sibling model.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-017" ] }, { "id": "de-agent-kind", "name": "Agent kind", "description": "Whether the agent is a person, an organisation or a software agent.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-001" ] }, { "id": "de-on-behalf-of", "name": "On-behalf-of reference", "description": "Party on whose behalf the agent acted, where responsibility is delegated.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-generating-activity", "name": "Generating activity reference", "description": "Reference to the activity or process that generated the revision.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-020" ] } ], "artifacts": [ { "id": "a-attribution-record", "name": "Attribution record", "description": "The per-revision record binding agent, delegation, role and verification method to the revision, forming the 'who' half of the audit trail.", "media_or_form": [ "structured record", "signed statement" ], "serial": true, "identity_strategy": "Identified by revision identifier plus agent identifier plus role; agent identifiers must resolve to the party/agent sibling model rather than being free text.", "source_refs": [ "SRC-017", "SRC-022", "SRC-001" ] } ], "inline_only_rationale": null }, { "id": "change-authorization", "name": "Change authorisation and approval", "description": "The authority under which the change was permitted, the approval decision bound to it, and the declared meaning of any signature applied.", "source_refs": [ "SRC-022", "SRC-017", "SRC-020" ], "questions": [ { "id": "q-authority-basis", "text": "Under what authority was this change permitted to be made?", "kind": "authority", "answer_data": [ "Authority basis code", "Policy or delegation reference", "Scope limits of the authority" ] }, { "id": "q-approval", "text": "Was formal approval required before release, who approved it, and at what instant?", "kind": "decision", "answer_data": [ "Approval required flag", "Approver references", "Decision instants and outcomes" ] }, { "id": "q-change-request", "text": "What request, ticket or justification triggered the change?", "kind": "process", "answer_data": [ "Change request identifier", "Requesting party", "Justification text" ] }, { "id": "q-signature-meaning", "text": "What is the declared meaning of any signature applied to this revision?", "kind": "evidence", "answer_data": [ "Signature meaning code (authorship, review, approval, responsibility)", "Signer identifier", "Signature instant" ] }, { "id": "q-impact-analysis", "text": "Was an impact analysis performed before approval, and is its outcome retained?", "kind": "requirement", "answer_data": [ "Impact analysis performed flag", "Analysis reference", "Analysis outcome summary" ] } ], "data_elements": [ { "id": "de-authorization-basis", "name": "Authorisation basis", "description": "The policy, delegation or standing authority under which the change was made.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-022", "SRC-017" ] }, { "id": "de-approval-refs", "name": "Approval references", "description": "References to approval decisions bound to this revision.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-022" ] }, { "id": "de-change-request-ref", "name": "Change request reference", "description": "Reference to the request or ticket that triggered the change.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-022" ] }, { "id": "de-signature-meaning", "name": "Signature meaning", "description": "Declared meaning attached to a signature applied to the revision.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-017", "SRC-020" ] } ], "artifacts": [ { "id": "a-change-authorization-record", "name": "Change authorisation record", "description": "The record of the decision that permitted the change, retained independently of the workflow system that produced it.", "media_or_form": [ "approval record", "signed decision", "workflow outcome record" ], "serial": true, "identity_strategy": "Identified by change request identifier plus approving authority identifier plus decision instant; linked to the resulting revision identifier once released.", "source_refs": [ "SRC-022", "SRC-017" ] } ], "inline_only_rationale": null } ] }, { "id": "integrity-and-verification", "name": "Integrity, Fixity and Tamper Evidence", "description": "What fixes the content of a revision, what binds history entries to one another, and how redaction is performed without destroying verifiability.", "source_refs": [ "SRC-012", "SRC-009", "SRC-020", "SRC-017", "SRC-022", "SRC-026" ], "findings": [ { "id": "content-integrity-and-fixity", "name": "Content fixity and canonicalisation", "description": "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.", "source_refs": [ "SRC-012", "SRC-009", "SRC-020", "SRC-005" ], "questions": [ { "id": "q-digest", "text": "What digest, computed over what canonical byte sequence, fixes the content of this revision?", "kind": "validation", "answer_data": [ "Digest value", "Digest algorithm identifier", "Byte sequence scope covered" ] }, { "id": "q-canonicalisation", "text": "Which canonicalisation rules are applied before digesting, and which fields are excluded from the digest scope?", "kind": "constraint", "answer_data": [ "Canonicalisation profile identifier", "Excluded field list", "Unicode normalisation form" ] }, { "id": "q-digest-migration", "text": "How is a change of digest algorithm handled without invalidating historical fixity?", "kind": "process", "answer_data": [ "Legacy digest retention rule", "Dual-digest transition period", "Superseded algorithm inventory" ] }, { "id": "q-fixity-checking", "text": "Who re-verifies fixity, how often, and what happens when verification fails?", "kind": "quality", "answer_data": [ "Responsible role", "Verification interval", "Failure handling rule" ] }, { "id": "q-validator-vs-digest", "text": "Is any exposed access-interface validator distinct from the content digest, and is that distinction documented?", "kind": "interoperability", "answer_data": [ "Validator value and strength", "Digest value", "Explicit statement that a weak validator is not fixity" ] } ], "data_elements": [ { "id": "de-content-digest", "name": "Content digest", "description": "Digest over the canonicalised content of the revision.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-012", "SRC-009" ] }, { "id": "de-digest-algorithm", "name": "Digest algorithm", "description": "Identifier of the digest algorithm in force for content addressing.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-012" ] }, { "id": "de-canonicalisation-profile", "name": "Canonicalisation profile", "description": "Identifier of the deterministic serialisation profile applied before digesting.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "de-legacy-fixity", "name": "Legacy fixity entries", "description": "Supplementary digests under superseded or additional algorithms, retained so historical verification remains possible.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-last-fixity-check-at", "name": "Last fixity verification instant", "description": "RFC 3339 instant of the most recent successful fixity verification.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012", "SRC-007" ] } ], "artifacts": [ { "id": "a-fixity-block", "name": "Fixity block", "description": "The digest map for a revision, including any supplementary legacy digests, kept so that integrity can be checked without re-deriving the content.", "media_or_form": [ "digest map", "inventory section" ], "serial": true, "identity_strategy": "Identified by revision identifier; entries keyed by digest algorithm identifier and digest value, with the primary algorithm distinguished from supplementary ones.", "source_refs": [ "SRC-012", "SRC-009" ] } ], "inline_only_rationale": null }, { "id": "history-tamper-evidence", "name": "Tamper evidence and redaction of history", "description": "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.", "source_refs": [ "SRC-017", "SRC-020", "SRC-022", "SRC-026", "SRC-012" ], "questions": [ { "id": "q-append-only", "text": "Is the change history append-only, and what technical and organisational controls enforce that?", "kind": "security", "answer_data": [ "Append-only assertion", "Enforcement controls", "Roles capable of bypassing the controls" ] }, { "id": "q-entry-alteration", "text": "Can a history entry be altered or removed, and does any such alteration itself leave a record that does not obscure the previous entry?", "kind": "security", "answer_data": [ "Alteration permitted flag", "Meta-entry recording mechanism", "Guarantee that prior entries are not obscured" ] }, { "id": "q-redaction", "text": "How is redaction of sensitive content in past revisions performed without destroying verifiability of the remaining history?", "kind": "exception", "answer_data": [ "Redaction mechanism", "Redaction marker retained in place", "Effect on digests and signatures" ] }, { "id": "q-entry-chaining", "text": "What cryptographically binds each history entry to its predecessor?", "kind": "evidence", "answer_data": [ "Chaining digest value", "Chaining algorithm", "Anchor or notarisation point" ] }, { "id": "q-forgery-threat", "text": "Who is technically capable of forging or suppressing a history entry, and which controls detect it?", "kind": "security", "answer_data": [ "Threat actor roles", "Detection controls", "Residual risk statement" ] } ], "data_elements": [ { "id": "de-append-only", "name": "Append-only assertion", "description": "Whether the history is maintained append-only, with prior entries never obscured.", "value_kind": "boolean", "cardinality": "1", "required": true, "source_refs": [ "SRC-017", "SRC-020" ] }, { "id": "de-entry-chain-digest", "name": "Entry chain digest", "description": "Digest binding this history entry to its predecessor entry, making insertion or removal detectable.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-020", "SRC-012" ] }, { "id": "de-signature-ref", "name": "History entry signature reference", "description": "Reference to the signature covering the canonicalised history entry.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-020", "SRC-022" ] }, { "id": "de-redaction-records", "name": "Redaction records", "description": "Records of assertions or fields redacted from past revisions, retained in place as markers.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-020", "SRC-026" ] }, { "id": "de-tamper-check-outcome", "name": "Tamper check outcome", "description": "Outcome of the most recent verification of the history chain.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012", "SRC-022" ] } ], "artifacts": [ { "id": "a-signed-history-claim", "name": "Signed history claim", "description": "A signed claim covering the canonicalised digest of one or more history entries, providing non-repudiable evidence that the recorded history has not been altered.", "media_or_form": [ "signed claim", "cryptographic manifest" ], "serial": true, "identity_strategy": "Identified by the covered revision identifier plus signer certificate identifier plus signing instant; assertions within a claim are immutable and may only be redacted by a subsequent claim, never edited.", "source_refs": [ "SRC-020", "SRC-022", "SRC-009" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "access-retention-interop", "name": "History Access, Retention and Interoperability", "description": "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.", "rationale": "Memento defines datetime negotiation and TimeMaps for reaching prior states; FHIR defines history and vread interactions with If-Match preconditions and 412 responses; 21 CFR 11.10(c) requires accurate and ready retrieval throughout the retention period while GDPR Articles 16 and 17 impose rectification and erasure duties; the IANA registry fixes the relations by which version navigation is exchanged. Access, retention and interoperability therefore form a distinct governed concern.", "source_refs": [ "SRC-004", "SRC-013", "SRC-005", "SRC-017", "SRC-026", "SRC-025" ], "layers": [ { "id": "history-access", "name": "Access to and Reconstruction of History", "description": "Enumeration, as-of retrieval, reconstruction from deltas, concurrency control and the visibility of history entries.", "source_refs": [ "SRC-004", "SRC-013", "SRC-005", "SRC-023", "SRC-026" ], "findings": [ { "id": "history-retrieval-and-reconstruction", "name": "History enumeration, as-of retrieval and state reconstruction", "description": "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.", "source_refs": [ "SRC-004", "SRC-013", "SRC-012", "SRC-015", "SRC-025" ], "questions": [ { "id": "q-enumerate", "text": "How does a consumer enumerate the revisions of an entity, and is the enumeration complete, stably ordered and pageable?", "kind": "access", "answer_data": [ "History resource reference", "Ordering guarantee", "Pagination and completeness guarantees" ] }, { "id": "q-asof-retrieval", "text": "How is the state of the entity as of a given instant retrieved?", "kind": "temporal", "answer_data": [ "As-of parameter or negotiation mechanism", "Instant supplied and instant returned", "Behaviour when no revision covers the instant" ] }, { "id": "q-reconstruction", "text": "How is a historical state reconstructed when only forward deltas are stored?", "kind": "process", "answer_data": [ "Reconstruction method", "Nearest snapshot reference", "Verification digest for the reconstructed state" ] }, { "id": "q-history-cost", "text": "What are the cost and latency bounds of retrieving deep history, and is any part cold-stored?", "kind": "measurement", "answer_data": [ "Retrieval latency class per depth", "Cold storage boundary", "Rehydration procedure" ] } ], "data_elements": [ { "id": "de-history-resource-ref", "name": "History resource reference", "description": "Resolvable reference to the enumeration of revisions for the entity.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-013", "SRC-025" ] }, { "id": "de-as-of-parameter", "name": "As-of parameter", "description": "The mechanism by which a consumer requests the state at a given instant.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-015" ] }, { "id": "de-reconstruction-method", "name": "Reconstruction method", "description": "Method by which a prior state is rebuilt from stored snapshots and deltas.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-history-entry-count", "name": "History entry count", "description": "Number of history entries known for the entity, used to detect truncated enumerations.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013", "SRC-004" ] } ], "artifacts": [ { "id": "a-history-document", "name": "Version history document", "description": "The retrievable enumeration of an entity's revisions with their instants and identifiers, equivalent in role to a TimeMap or a history bundle, satisfying the requirement to publish version history.", "media_or_form": [ "enumerated list resource", "time map", "history bundle" ], "serial": false, "identity_strategy": "Identified by the entity persistent identifier plus a generation instant; each entry cites a revision identifier and its datetime, and the document is regenerated rather than edited.", "source_refs": [ "SRC-004", "SRC-013", "SRC-014" ] } ], "inline_only_rationale": null }, { "id": "concurrency-and-conflict", "name": "Concurrency control and conflict outcome", "description": "How simultaneous revision attempts on one entity are reconciled, what precondition an update must carry, and what happens when the precondition fails.", "source_refs": [ "SRC-005", "SRC-013", "SRC-023", "SRC-021", "SRC-006" ], "questions": [ { "id": "q-lost-update", "text": "How is a lost update prevented when two agents revise the same entity concurrently?", "kind": "constraint", "answer_data": [ "Concurrency model code (optimistic, pessimistic, none)", "Precondition mechanism", "Enforcement point" ] }, { "id": "q-precondition", "text": "What precondition must an update carry, and what is returned when the precondition is not met?", "kind": "process", "answer_data": [ "Expected current revision value", "Failure outcome code", "Retry guidance" ] }, { "id": "q-conflict-resolution", "text": "How are conflicting concurrent revisions detected and resolved?", "kind": "exception", "answer_data": [ "Detection mechanism", "Resolution strategy", "Whether both branches are preserved" ] }, { "id": "q-lock-model", "text": "Is there an explicit lock or checkout model, and what happens to abandoned locks?", "kind": "state", "answer_data": [ "Lock model code", "Lock holder reference", "Lock expiry instant and reclaim rule" ] } ], "data_elements": [ { "id": "de-concurrency-model", "name": "Concurrency model", "description": "The declared model by which concurrent revision attempts are reconciled.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-005", "SRC-013", "SRC-023" ] }, { "id": "de-expected-current-revision", "name": "Expected current revision", "description": "The revision the writer believed to be current when submitting a change, used as the update precondition.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005", "SRC-013" ] }, { "id": "de-conflict-outcome", "name": "Conflict outcome", "description": "Recorded outcome of a precondition failure or conflict, including whether a branch was created.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005", "SRC-021" ] }, { "id": "de-lock-expiry", "name": "Lock expiry instant", "description": "Instant at which a held checkout or lock expires and may be reclaimed.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-023", "SRC-007" ] } ], "artifacts": [ { "id": "a-conflict-report", "name": "Conflict and precondition failure report", "description": "The record of a rejected or conflicting revision attempt, retained so that suppressed changes are visible rather than silently lost.", "media_or_form": [ "error record", "reconciliation note" ], "serial": true, "identity_strategy": "Identified by target entity identifier plus the attempted revision identifier plus the failure instant.", "source_refs": [ "SRC-005", "SRC-013", "SRC-022" ] } ], "inline_only_rationale": null }, { "id": "history-visibility", "name": "History visibility, disclosure and embargo", "description": "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.", "source_refs": [ "SRC-026", "SRC-022", "SRC-017", "SRC-020" ], "questions": [ { "id": "q-history-audience", "text": "Is the change history visible to the same audience as the current state of the entity?", "kind": "access", "answer_data": [ "History visibility class", "Divergence from current-state class", "Justification for divergence" ] }, { "id": "q-sensitive-fields", "text": "Which parts of a history entry may reveal personal data, security detail or confidential rationale?", "kind": "privacy", "answer_data": [ "Sensitive field inventory", "Sensitivity class per field", "Minimisation applied" ] }, { "id": "q-embargo", "text": "Can a past revision be embargoed so that its existence is visible but its content is not?", "kind": "exception", "answer_data": [ "Embargo permitted flag", "Embargo-until instant", "Fields disclosed during embargo" ] }, { "id": "q-agent-disclosure", "text": "Who may read agent identities, approval records and change reasons within the history?", "kind": "security", "answer_data": [ "Authorised reader roles", "Pseudonymisation rules", "Regulatory access exceptions" ] } ], "data_elements": [ { "id": "de-history-visibility-class", "name": "History visibility class", "description": "Access classification applied to history entries, which may differ from that of the current state.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-026", "SRC-022" ] }, { "id": "de-entry-sensitivity", "name": "Entry sensitivity", "description": "Per-field sensitivity classification within a history entry.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-026" ] }, { "id": "de-embargo-until", "name": "Embargo-until instant", "description": "Instant until which a revision's content is withheld while its existence remains disclosed.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007", "SRC-026" ] } ], "artifacts": [], "inline_only_rationale": "Visibility is expressed as classification attributes attached to history entries and fields; the policy that interprets them and the enforcement point both belong to the access-control sibling model, so this finding contributes classification metadata rather than a distinct artifact of its own." } ] }, { "id": "retention-and-exchange", "name": "Retention, Disposition and External Alignment", "description": "How long history is kept, how it may lawfully be reduced, and how its semantics are exchanged with external vocabularies and interfaces.", "source_refs": [ "SRC-017", "SRC-026", "SRC-025", "SRC-010", "SRC-011", "SRC-001" ], "findings": [ { "id": "history-retention-and-disposition", "name": "Retention, compaction and lawful disposition of history", "description": "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.", "source_refs": [ "SRC-017", "SRC-026", "SRC-012", "SRC-020", "SRC-022" ], "questions": [ { "id": "q-retention-period", "text": "How long must each revision and its history entry be retained, and on what basis?", "kind": "retention", "answer_data": [ "Retention period", "Retention basis (regulatory, contractual, business)", "Retention clock start event" ] }, { "id": "q-compaction", "text": "May history be compacted, squashed or pruned, and what must survive compaction?", "kind": "decision", "answer_data": [ "Compaction permitted flag", "Surviving elements (identifiers, digests, instants)", "Authorising role" ] }, { "id": "q-erasure-reconciliation", "text": "How is a lawful erasure or rectification request reconciled with an append-only, digest-chained history?", "kind": "exception", "answer_data": [ "Reconciliation mechanism (redaction marker, tombstone, key destruction)", "Effect on chain verification", "Legal basis relied upon for any retained data" ] }, { "id": "q-disposition-evidence", "text": "Who authorises disposition and what evidence of the disposition is retained afterwards?", "kind": "authority", "answer_data": [ "Disposition authority reference", "Disposition certificate reference", "Retention period of the certificate itself" ] }, { "id": "q-legal-hold", "text": "Does a legal hold suspend disposition, and how is a held entry marked?", "kind": "requirement", "answer_data": [ "Legal hold flag", "Hold reference and issuing authority", "Release condition" ] } ], "data_elements": [ { "id": "de-retention-period", "name": "Retention period", "description": "Duration for which the revision and its history entry must be retained.", "value_kind": "duration", "cardinality": "1", "required": true, "source_refs": [ "SRC-017", "SRC-026" ] }, { "id": "de-retention-basis", "name": "Retention basis", "description": "The regulatory, contractual or business ground for the retention obligation.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017", "SRC-026" ] }, { "id": "de-disposition-action", "name": "Disposition action", "description": "The action applied at end of retention: destroy, redact, anonymise, transfer or extend.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-026", "SRC-020" ] }, { "id": "de-legal-hold", "name": "Legal hold flag", "description": "Whether disposition is suspended by a hold.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017", "SRC-026" ] }, { "id": "de-disposition-certificate-ref", "name": "Disposition certificate reference", "description": "Reference to the record evidencing that disposition was executed.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017", "SRC-022" ] } ], "artifacts": [ { "id": "a-disposition-record", "name": "Disposition and erasure record", "description": "The record evidencing that a revision or history entry was destroyed, redacted or anonymised, deliberately outliving the content it describes so that gaps in the history remain accountable.", "media_or_form": [ "disposition certificate", "structured record" ], "serial": true, "identity_strategy": "Identified by the disposed revision or range identifier plus disposition authority identifier plus execution instant; retained after the content itself is destroyed and never itself disposed with the content.", "source_refs": [ "SRC-017", "SRC-026", "SRC-022" ] } ], "inline_only_rationale": null }, { "id": "external-alignment-and-exchange", "name": "External alignment, crosswalks and exchange", "description": "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.", "source_refs": [ "SRC-001", "SRC-010", "SRC-011", "SRC-013", "SRC-025", "SRC-012", "SRC-016" ], "questions": [ { "id": "q-alignment-targets", "text": "To which external vocabularies are the version fields of this model aligned, and at which version of each?", "kind": "interoperability", "answer_data": [ "Target vocabulary identifiers", "Target vocabulary versions", "Mapped property pairs" ] }, { "id": "q-alignment-vs-conformance", "text": "Is each mapping claimed as an alignment or as conformance, and what evidence supports a conformance claim?", "kind": "evidence", "answer_data": [ "Claim kind per target", "Conformance evidence reference", "Test or validation outcome" ] }, { "id": "q-alignment-conflicts", "text": "Where do external models conflict with this model's semantics, and how is the conflict handled?", "kind": "exception", "answer_data": [ "Conflict description", "Affected properties", "Handling rule (do not map, map with caveat, map lossily)" ] }, { "id": "q-interface-exposure", "text": "How are version relations exposed over an access interface that carries only links, headers or metadata properties?", "kind": "interoperability", "answer_data": [ "Link relation types emitted", "Header or property names used", "Registry reference for each relation" ] }, { "id": "q-alignment-loss", "text": "Which alignments are lossy, and precisely what is lost in each direction?", "kind": "quality", "answer_data": [ "Lossy mapping list", "Lost elements per direction", "Mitigation or compensating field" ] } ], "data_elements": [ { "id": "de-alignment-target", "name": "Alignment target", "description": "External vocabulary or specification to which a version field is mapped, with its version.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-010", "SRC-011" ] }, { "id": "de-alignment-kind", "name": "Alignment kind", "description": "Whether the relationship is an alignment, a lossy mapping or an evidenced conformance claim.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-016", "SRC-019" ] }, { "id": "de-exposed-link-relations", "name": "Exposed link relations", "description": "Registered link relation types emitted to expose version navigation and time-based access.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-025", "SRC-003", "SRC-004" ] }, { "id": "de-alignment-loss", "name": "Alignment loss statement", "description": "Explicit statement of what is not preserved when mapping to or from a target vocabulary.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010", "SRC-001" ] } ], "artifacts": [ { "id": "a-alignment-crosswalk", "name": "Alignment crosswalk", "description": "The published mapping between this model's version fields and the corresponding properties of each external vocabulary, annotated with direction, loss and claim kind.", "media_or_form": [ "mapping table", "machine-readable crosswalk" ], "serial": false, "identity_strategy": "Identified by this model identifier plus target vocabulary identifier plus target vocabulary version; re-issued as a new revision whenever either side changes, and never silently updated in place.", "source_refs": [ "SRC-001", "SRC-010", "SRC-011", "SRC-025" ] } ], "inline_only_rationale": null } ] } ] } ] }, "functions": [ { "id": "mint-revision", "name": "Mint a revision", "description": "Create a new immutable revision of a host entity, binding identity, designation, predecessor set, agent, instants and content digest.", "inputs": [ "Host entity persistent identifier", "Proposed content or change set", "Change agent reference", "Change event instant", "Predecessor revision references" ], "outputs": [ "Revision identifier", "Revision manifest", "Content digest", "Assigned version designation" ], "preconditions": [ "The declared version designation scheme and public surface are published", "The predecessor references resolve and the expected current revision precondition holds", "An attributable agent and a change event instant are supplied" ], "effects": [ "A new immutable revision manifest exists", "The predecessor set of the new revision is fixed and the successor set of each predecessor gains an entry", "The history gains an append-only entry with record instant" ], "source_refs": [ "SRC-023", "SRC-012", "SRC-013", "SRC-002", "SRC-017" ] }, { "id": "assign-designation", "name": "Assign a version designation", "description": "Derive or validate the version label for a revision under the declared scheme and its compatibility promise.", "inputs": [ "Revision identifier", "Declared scheme code", "Breaking change flag", "Predecessor designation" ], "outputs": [ "Version designation label", "Validation outcome" ], "preconditions": [ "A version scheme is declared for the entity", "The breaking change assessment has been completed" ], "effects": [ "The revision carries a scheme-valid designation", "A breaking change is reflected in the designation where the scheme carries a compatibility promise" ], "source_refs": [ "SRC-002", "SRC-018", "SRC-012", "SRC-010" ] }, { "id": "link-predecessor", "name": "Assert a predecessor link", "description": "Record that a revision directly succeeds one or more identified revisions, including multi-parent merges.", "inputs": [ "Successor revision identifier", "Predecessor revision identifiers", "Merge strategy where multiple predecessors are supplied" ], "outputs": [ "Predecessor set assertion", "Updated successor sets", "Merge record where applicable" ], "preconditions": [ "All predecessor identifiers resolve to released revisions", "The resulting graph remains acyclic" ], "effects": [ "The lineage graph gains directed edges", "Acyclicity is re-validated and the outcome recorded" ], "source_refs": [ "SRC-003", "SRC-023", "SRC-021", "SRC-025" ] }, { "id": "compute-change-set", "name": "Compute a change set", "description": "Produce the ordered, atomically applicable delta between two revisions, with the digest that a correct application must reproduce.", "inputs": [ "Predecessor revision reference", "Successor revision reference", "Canonicalisation profile" ], "outputs": [ "Change set document", "Expected result digest", "Invertibility determination" ], "preconditions": [ "Both revisions are retrievable in canonicalised form", "A patch formalism is declared" ], "effects": [ "A change set artifact is stored and bound to the revision pair", "The delta becomes independently verifiable" ], "source_refs": [ "SRC-006", "SRC-009", "SRC-012" ] }, { "id": "assess-change-impact", "name": "Assess change impact", "description": "Classify the change by category, semantic impact, severity and breaking status against the declared public surface, before approval.", "inputs": [ "Change set document", "Declared public surface reference", "Consumer inventory" ], "outputs": [ "Change categories", "Breaking change flag", "Impact assessment record" ], "preconditions": [ "A public surface is declared", "The change set is available" ], "effects": [ "An impact assessment is recorded and bound to the change request", "The designation increment and compatibility declaration become determinable" ], "source_refs": [ "SRC-022", "SRC-002", "SRC-019" ] }, { "id": "evaluate-compatibility", "name": "Evaluate compatibility between two versions", "description": "Determine whether data or consumers produced under one version can be read under another, in a stated direction, and record the supporting evidence.", "inputs": [ "Reader version reference", "Writer version reference", "Direction" ], "outputs": [ "Compatibility verdict", "Evidence reference", "Compatibility matrix update" ], "preconditions": [ "Both version definitions are retrievable", "Default and alias rules are declared for the schema in use" ], "effects": [ "A compatibility declaration is recorded with its evidence", "Any incompatibility is propagated to the designation and deprecation decisions" ], "source_refs": [ "SRC-019", "SRC-016", "SRC-002" ] }, { "id": "plan-migration", "name": "Plan a migration", "description": "Produce the ordered procedure that carries state or consumers from a source version to a target version, with reversibility, idempotence and accepted loss stated.", "inputs": [ "Source revision reference", "Target revision reference", "Compatibility verdict", "Affected instance inventory" ], "outputs": [ "Migration plan", "Reversibility determination", "Expected loss statement", "Migration deadline" ], "preconditions": [ "A compatibility evaluation exists for the version pair", "An accepting authority for any expected loss is identified" ], "effects": [ "A migration plan artifact is bound to the version pair", "Consumers gain an actionable, dated upgrade path" ], "source_refs": [ "SRC-019", "SRC-006", "SRC-022", "SRC-024" ] }, { "id": "apply-migration", "name": "Apply a migration", "description": "Execute a migration transform against an instance or store and record the outcome, including partial failure and resume state.", "inputs": [ "Migration plan reference", "Target instance or store reference", "Execution agent reference" ], "outputs": [ "Migration execution record", "Resulting revision reference", "Verification digest" ], "preconditions": [ "The migration plan is released and its transform digest verifies", "A rollback path or an explicit acceptance of irreversibility is recorded" ], "effects": [ "Instance state is transformed to the target version", "An execution record is appended to the history and the outcome is verifiable" ], "source_refs": [ "SRC-019", "SRC-012", "SRC-022" ] }, { "id": "resolve-as-of", "name": "Resolve the revision in force at an instant", "description": "Return the revision that was current at a supplied instant along the declared temporal axis.", "inputs": [ "Entity persistent identifier", "Target instant", "Temporal axis selector", "Branch or context" ], "outputs": [ "Revision reference", "Instant actually reflected", "Axis used" ], "preconditions": [ "Revision instants are recorded in RFC 3339 form with explicit offsets", "A resolution rule is declared for the case where record time and effective time disagree" ], "effects": [ "The consumer obtains a pinned revision rather than a moving pointer", "The response states which instant and axis it reflects" ], "source_refs": [ "SRC-004", "SRC-015", "SRC-013", "SRC-007" ] }, { "id": "reconstruct-state", "name": "Reconstruct a historical state", "description": "Rebuild the full state of a revision from the nearest snapshot plus intervening deltas and verify it against the recorded digest.", "inputs": [ "Target revision reference", "Nearest snapshot reference", "Intervening change sets" ], "outputs": [ "Reconstructed state", "Verification outcome" ], "preconditions": [ "The delta chain from snapshot to target is complete", "The canonicalisation profile of the target revision is known" ], "effects": [ "A prior state is materialised without mutating any stored revision", "A mismatch marks the chain unverified rather than overwriting it" ], "source_refs": [ "SRC-012", "SRC-006", "SRC-009" ] }, { "id": "enumerate-history", "name": "Enumerate version history", "description": "List the revisions of an entity with their identifiers, instants and states, in a stable order and with a completeness statement.", "inputs": [ "Entity persistent identifier", "Range or page token", "Requester authorisation context" ], "outputs": [ "History document", "Completeness statement", "Next page token" ], "preconditions": [ "The requester is authorised for the history visibility class of the entries returned" ], "effects": [ "The consumer can traverse the history without reading revision content", "Withheld or disposed entries are represented as tombstones rather than omitted silently" ], "source_refs": [ "SRC-004", "SRC-013", "SRC-014", "SRC-025" ] }, { "id": "enforce-update-precondition", "name": "Enforce an update precondition", "description": "Reject a revision attempt whose expected current revision does not match the actual head, and record the rejection.", "inputs": [ "Target entity identifier", "Expected current revision", "Proposed change" ], "outputs": [ "Acceptance or precondition failure outcome", "Conflict report on failure" ], "preconditions": [ "A concurrency model is declared for the entity", "The head pointer is readable atomically" ], "effects": [ "Lost updates are prevented", "Rejected attempts are recorded rather than silently discarded" ], "source_refs": [ "SRC-005", "SRC-013", "SRC-023" ] }, { "id": "verify-history-integrity", "name": "Verify history integrity", "description": "Re-check content fixity and the entry chain across a revision range and record the verification outcome.", "inputs": [ "Entity persistent identifier", "Revision range", "Digest algorithm inventory" ], "outputs": [ "Verification outcome per revision", "Chain verification outcome", "Unverified entry list" ], "preconditions": [ "Digest values and the canonicalisation profile are recorded for each revision in range", "Superseded digest algorithms remain resolvable" ], "effects": [ "Fixity check instants are updated", "Failures are marked as unverified and escalated, never resolved by deletion" ], "source_refs": [ "SRC-012", "SRC-020", "SRC-009", "SRC-022" ] }, { "id": "deprecate-revision", "name": "Deprecate and schedule sunset", "description": "Mark a revision, element or endpoint deprecated from a stated instant, publish the replacement and migration guidance, and schedule its sunset.", "inputs": [ "Target revision or element reference", "Deprecation effective instant", "Sunset instant", "Replacement reference" ], "outputs": [ "Deprecation notice", "Interface deprecation signal", "Updated compatibility matrix" ], "preconditions": [ "The sunset instant is not earlier than the deprecation instant", "A replacement or an explicit statement that none exists is available" ], "effects": [ "Consumers receive a dated deprecation signal and migration guidance", "The deprecated revision remains retrievable until its sunset instant" ], "source_refs": [ "SRC-024", "SRC-025", "SRC-016", "SRC-015" ] }, { "id": "withdraw-revision", "name": "Withdraw or deactivate a revision", "description": "Record a retraction, deactivation or deletion as a history entry that preserves ordering and lineage while removing content or availability as authorised.", "inputs": [ "Target revision reference", "Withdrawal kind", "Authorising role reference", "Reason" ], "outputs": [ "Tombstone record", "Updated head pointer where the withdrawn revision was current" ], "preconditions": [ "The withdrawal is authorised and its authority is recorded", "Retention and legal-hold constraints have been evaluated" ], "effects": [ "The revision ceases to be served according to the withdrawal kind", "A tombstone remains so that deletion is distinguishable from never having existed" ], "source_refs": [ "SRC-013", "SRC-015", "SRC-026", "SRC-017" ] }, { "id": "execute-disposition", "name": "Execute retention disposition on history", "description": "Apply the scheduled disposition action to revisions or history entries whose retention period has elapsed and no hold applies, retaining evidence of the disposition.", "inputs": [ "Revision or range reference", "Retention schedule reference", "Disposition authority reference" ], "outputs": [ "Disposition record", "Redaction markers or tombstones", "Updated chain verification status" ], "preconditions": [ "The retention period has elapsed and no legal hold applies", "The effect on digest chains and signatures has been assessed" ], "effects": [ "Content is destroyed, redacted or anonymised as authorised", "Identifiers, instants and disposition evidence survive so the history gap is accountable" ], "source_refs": [ "SRC-017", "SRC-026", "SRC-020", "SRC-022" ] }, { "id": "project-alignment", "name": "Project version semantics onto an external vocabulary", "description": "Emit this model's version fields as the corresponding properties, link relations or headers of a target vocabulary or interface, annotating loss.", "inputs": [ "Revision manifest", "Target vocabulary identifier and version", "Alignment crosswalk" ], "outputs": [ "Projected representation", "Loss annotation", "Claim kind statement" ], "preconditions": [ "A crosswalk exists for the target vocabulary version", "Conflicts have been recorded and a handling rule chosen" ], "effects": [ "Version relations become consumable by external systems", "Every projection carries an explicit alignment-not-conformance statement unless conformance evidence is attached" ], "source_refs": [ "SRC-001", "SRC-010", "SRC-011", "SRC-025", "SRC-013" ] }, { "id": "compare-version-precedence", "name": "Compare version precedence", "description": "Order two version indicators under SemVer precedence, or under a declared alternative scheme.", "inputs": [ "two version indicators", "declared scheme" ], "outputs": [ "ordering result", "precedence keys", "incomparability flag if schemes differ" ], "preconditions": [ "Both indicators use the same declared scheme, or an explicit mapping exists." ], "effects": [ "Build metadata is ignored under SemVer.", "Pre-release is lower than the associated normal version." ], "source_refs": [ "SRC-002" ] }, { "id": "publish-as-current", "name": "Publish as current version", "description": "Designate a snapshot as hasCurrentVersion / adms:last and, under OWL conventions, make it retrievable at the series IRI while leaving prior version IRIs in place.", "inputs": [ "series identifier", "snapshot revision", "publisher" ], "outputs": [ "hasCurrentVersion pointer", "series IRI resolution update", "prior versions still listed" ], "preconditions": [ "Snapshot is a version of the series.", "Publisher is authorised." ], "effects": [ "Exactly one current pointer is stored unless a documented branch exception applies.", "Prior versions remain accessible at version identifiers." ], "source_refs": [ "SRC-010", "SRC-016", "SRC-029", "SRC-031" ] }, { "id": "supersede-revision", "name": "Supersede revision", "description": "Assert dcterms:replaces / isReplacedBy and, where DOIs are used, IsNewVersionOf / IsPreviousVersionOf, optionally minting a new identifier for a major change.", "inputs": [ "new revision", "old revision", "steward major-or-minor decision", "identifier policy" ], "outputs": [ "replaces links", "related identifier pairs", "optional new DOI or version IRI" ], "preconditions": [ "Steward has decided whether the change is major.", "Identifier policy for reuse versus minting is known." ], "effects": [ "Validity and citation rules for the old identifier are updated.", "Both identifiers remain recorded." ], "source_refs": [ "SRC-028", "SRC-030", "SRC-010" ] }, { "id": "freeze-released-revision", "name": "Freeze released revision", "description": "Mark a revision as released so its content MUST NOT be modified; further change requires a new version.", "inputs": [ "revision identity", "content or distribution digest", "release steward" ], "outputs": [ "released flag", "generated or issued time", "frozen release manifest" ], "preconditions": [ "Revision identity exists.", "If SemVer is declared, public API is identified for 1.0.0 and later." ], "effects": [ "In-place content mutation is forbidden.", "Checksum evidence is bound to the revision.", "Subsequent edits must create a successor revision." ], "source_refs": [ "SRC-002", "SRC-010", "SRC-001" ] } ], "composition": [ { "target": "Any Vercy world-model entry whose instances change over time (entity, event, aggregate or registry model)", "relation": "MIX-IN", "purpose": "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.", "required": true, "source_refs": [ "SRC-016", "SRC-010", "SRC-014" ] }, { "target": "Provenance / Lineage model (PROV-style agents, activities and derivations) — sibling identifier to be assigned by the registry", "relation": "REFERENCE", "purpose": "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.", "required": true, "source_refs": [ "SRC-001", "SRC-014" ] }, { "target": "Audit Trail / Event Log model — sibling identifier to be assigned by the registry", "relation": "REFERENCE", "purpose": "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.", "required": true, "source_refs": [ "SRC-017", "SRC-022" ] }, { "target": "Party / Agent model — sibling identifier to be assigned by the registry", "relation": "REFERENCE", "purpose": "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.", "required": true, "source_refs": [ "SRC-001", "SRC-022" ] }, { "target": "Identifier and Namespace Governance model — sibling identifier to be assigned by the registry", "relation": "REFERENCE", "purpose": "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.", "required": true, "source_refs": [ "SRC-016", "SRC-008", "SRC-014" ] }, { "target": "Retention and Disposition model — sibling identifier to be assigned by the registry", "relation": "REFERENCE", "purpose": "Retention schedules, legal holds and disposition authority are authored elsewhere; this model consumes them and records the disposition applied to each history entry.", "required": true, "source_refs": [ "SRC-017", "SRC-026" ] }, { "target": "Access Control and Classification model — sibling identifier to be assigned by the registry", "relation": "REFERENCE", "purpose": "History entries carry visibility and sensitivity classifications, but policy interpretation and enforcement belong to the access sibling.", "required": true, "source_refs": [ "SRC-026", "SRC-022" ] }, { "target": "Change Set / Patch structure (owned by this model, projected as a nested structure)", "relation": "COMPOSE", "purpose": "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.", "required": true, "source_refs": [ "SRC-006", "SRC-012", "SRC-009" ] }, { "target": "Approval / Change Governance Workflow model — sibling identifier to be assigned by the registry", "relation": "REFERENCE", "purpose": "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.", "required": false, "source_refs": [ "SRC-022", "SRC-017" ] }, { "target": "Digital Signature and Integrity model — sibling identifier to be assigned by the registry", "relation": "REFERENCE", "purpose": "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.", "required": false, "source_refs": [ "SRC-020", "SRC-022" ] }, { "target": "Temporal / Effective-Dating model — sibling identifier to be assigned by the registry", "relation": "REFERENCE", "purpose": "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.", "required": false, "source_refs": [ "SRC-011", "SRC-015" ] }, { "target": "W3C PROV-O revision and attribution vocabulary", "relation": "ALIGN", "purpose": "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.", "required": false, "source_refs": [ "SRC-001" ] }, { "target": "DCAT 3 and DCMI Metadata Terms versioning properties", "relation": "ALIGN", "purpose": "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.", "required": false, "source_refs": [ "SRC-010", "SRC-011" ] }, { "target": "IANA Link Relation Types registry (version navigation and time-based access)", "relation": "ALIGN", "purpose": "Declared mapping of history enumeration, predecessor, successor, latest, working copy, memento, timegate, timemap, deprecation and sunset onto registered link relation types for interface exposure.", "required": false, "source_refs": [ "SRC-025", "SRC-003", "SRC-004", "SRC-024" ] }, { "target": "HL7 FHIR resource meta versioning and history interaction", "relation": "ALIGN", "purpose": "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.", "required": false, "source_refs": [ "SRC-013", "SRC-005" ] }, { "target": "OCFL object versioning, inventory and fixity", "relation": "ALIGN", "purpose": "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.", "required": false, "source_refs": [ "SRC-012" ] }, { "target": "Semantic Versioning 2.0.0 and PEP 440 designation grammars", "relation": "ALIGN", "purpose": "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.", "required": false, "source_refs": [ "SRC-002", "SRC-018" ] }, { "target": "C2PA manifest, ingredient and action model for media assets", "relation": "ALIGN", "purpose": "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.", "required": false, "source_refs": [ "SRC-020" ] } ], "serviceLayers": { "dimension": { "owner_package_requirements": [ "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.", "The owner package MUST publish the version designation scheme, its grammar reference and the declared public surface before the first revision is minted, because a designation asserted without a declared surface carries no compatibility meaning.", "The owner package MUST declare the digest algorithm and canonicalisation profile in force, and MUST keep every superseded algorithm resolvable so that historical fixity remains verifiable after an algorithm migration.", "The owner package MUST declare the retention schedule, disposition authority and legal-hold regime applying to history entries, and MUST state how erasure and rectification obligations are reconciled with append-only history.", "The owner package MUST list the host models into which this mixin is composed and state, per host, whether change history is mandatory or optional and which findings are mandatory in that context.", "The owner package MUST record every alignment to an external vocabulary as an alignment with an explicit loss statement, and MUST NOT publish a conformance claim without attached, re-executable validation evidence." ], "namespace_guidance": "Version and change-history terms are minted in a namespace controlled by the adopting Dimension and are themselves versioned using the same series-plus-version pattern this model prescribes: a stable series IRI identifies the term set across time, and a distinct version IRI identifies each published state, with the rule that no two different published states share the same series IRI and version IRI. Term IRIs are never re-pointed to different meanings; a changed meaning requires a new term and a deprecation of the old one. Local extension terms are minted in a sub-namespace clearly separated from terms borrowed from external vocabularies, and borrowed terms are always cited with their source vocabulary version so that a later change upstream is detectable.", "registry_links": [ "The Vercy model registry entry vr.wm-xct-022 (WM-XCT-022) records this model's status, review state and relations, and is the authoritative pointer to its current specification revision.", "The IANA Link Relation Types registry is the normative source for relation types used to expose version navigation and time-based access over link-carrying interfaces.", "The adopting Dimension maintains a registry of declared version designation schemes, their grammar references and their ordering rules, so that no consumer infers ordering from an undeclared label format.", "The adopting Dimension maintains a registry of digest algorithms and canonicalisation profiles, including superseded entries retained for historical verification." ] }, "canon_and_patch": { "canonicalization_rules": [ "Before any digest is computed or signature applied, the record is serialised deterministically: object members sorted recursively by name, no insignificant whitespace, a declared Unicode normalisation form, and a declared numeric serialisation, so that two systems independently produce identical bytes.", "Volatile fields MUST be excluded from the digest scope and the exclusion list MUST be published: transport metadata, the mutable head pointer, fixity-check timestamps, cached successor sets and pagination tokens are excluded because they change without any change of content.", "All instants inside the canonical form are normalised to RFC 3339 with seconds and an explicit offset or Z before digesting; an implementation MUST NOT silently substitute Z for an unknown local offset, for which -00:00 is the correct representation.", "Where the record is projected into RDF, a declared RDF canonicalisation algorithm is used instead of the JSON rule, and the profile identifier recorded on the revision states which was applied, because the two produce different digests over the same information.", "The canonicalisation profile identifier is stored on each revision. Changing the profile is itself a versioned change to the owner package and requires dual-digest retention over a stated transition period." ], "patch_rules": [ "A change set is an ordered list of operations applied sequentially, where each operation's result is the input to the next; the list MAY begin with precondition test operations that assert the expected predecessor state.", "A change set applies atomically: if any operation fails or any precondition test is not satisfied, evaluation terminates and the change set MUST NOT be treated as partially applied.", "Every change set is identified by the predecessor revision identifier plus the successor revision identifier and carries the expected result digest of the canonicalised successor state, so that correct application is independently verifiable.", "A published change set is immutable. A defective change set is corrected by publishing a superseding change set and a corresponding revision, never by editing the original.", "Invertibility is declared explicitly. Where a change set is not invertible, the information lost under inversion MUST be stated so that rollback expectations are not inferred incorrectly." ], "compatibility_rules": [ "Compatibility is declared directionally: backward (a newer reader accepts older data), forward (an older reader accepts newer data), full, or none. An undirected claim of 'compatible' is not accepted.", "Adding an optional element carrying a default is backward compatible; removing or renaming a required element without an alias, narrowing a type, or tightening a constraint is breaking and MUST be declared incompatible with the affected prior versions.", "A breaking change MUST be reflected in the designation where the declared scheme carries a compatibility promise, and MUST in all cases set an explicit incompatible-with assertion, because not every legitimate scheme encodes compatibility in the label.", "Deprecation precedes removal: an element is marked deprecated with an effective instant and a replacement before it is removed, and a sunset instant MUST NOT be earlier than the deprecation instant.", "A compatibility claim without re-executable evidence is recorded as an assertion, not as a verified property, and is surfaced to consumers as such." ] }, "artifact_rules": { "identity_priority": [ "First, the identifier issued by the authoritative master system that owns the host entity's record, where such a system exists and its identifiers are stable and non-reusable.", "Second, a governed global identifier or IRI minted in a controlled namespace, following the series-plus-version pattern in which the series IRI is stable across revisions and the version IRI is unique to one revision.", "Third, a UUID or ULID assigned by the adopting Dimension, preferring a time-ordered UUID form so that identifiers sort in generation order as opaque bytes.", "A date, a version label, a sequence number or a content digest is NOT an identifier: a date is not unique under concurrent writes, a label may repeat across branches or schemes, and a digest is a validator that collides for identical content produced independently and changes whenever the canonicalisation profile changes.", "A weak access-interface validator (for example a weak entity tag) MUST NOT be used as a revision identifier or as a fixity value, because it asserts semantic equivalence rather than byte identity." ], "timestamp_rule": "All instants are recorded as RFC 3339 date-time values with seconds and an explicit UTC offset or Z. Change-event time and record or ingestion time are stored as separate fields and are never conflated; publication time is stored separately again where it differs. The -00:00 form is used only where the local offset is genuinely unknown and MUST NOT be substituted for Z. Fractional-second precision is declared rather than assumed, leap-second values are accepted on input and their handling documented, and where instants are stored as Unix epoch milliseconds internally the loss of offset and leap-second information is recorded as a known projection loss.", "serial_naming_rule": "Serial artifacts are named as entity-persistent-identifier, then revision-identifier, then artifact-kind, in that order. Where a numeric sequence is used it starts at 1 and MUST be continuous with no missing integers; the zero-padding convention is fixed at first use for a given entity and MUST NOT change thereafter, and the same convention MUST be used for every serial artifact of that entity. A sequence number identifies position within a branch, never global order across branches.", "integrity_rule": "Every serial artifact carries a digest over its canonical form using the declared primary algorithm, with SHA-512 preferred and SHA-256 permitted; supplementary digests under superseded algorithms are retained in a fixity block so that historical verification survives algorithm migration. History entries additionally carry a chaining digest binding each entry to its predecessor, so that insertion, removal or reordering is detectable. Verification failure marks the artifact and the affected chain segment as unverified and raises an escalation; it MUST NOT be resolved by deleting or rewriting the entry, and any redaction is recorded in place as a redaction marker rather than as a silent removal." }, "policies": [ "Released revisions are immutable: content bound to a released revision identifier MUST NOT be modified, and a revision identifier MUST NOT be reused or re-pointed. Corrections are issued as new revisions that supersede, never as edits.", "Change history is append-only: entries are added and never edited in place, and no new entry may obscure the information recorded in a previous entry. A correction to a history entry is itself recorded as a further entry.", "No revision is published without an attributable agent, a change-event instant and a separate record instant. An anonymous or timeless revision is rejected at mint time.", "Every published revision carries a change classification and a human-readable note stating how it differs from its predecessor; a version list without difference statements does not satisfy the version-history requirement.", "Compatibility and conformance claims require attached, re-executable evidence. Mappings to external standards are recorded as alignments with explicit loss statements and are never presented as conformance without such evidence.", "Deprecation precedes removal, and a sunset instant MUST NOT be earlier than the corresponding deprecation instant. A revision remains retrievable until its sunset instant unless withdrawn under a recorded authority.", "Erasure and rectification obligations over personal data are satisfied by destroying or redacting content in place while retaining non-identifying tombstones, digests and a disposition record, so that lineage, ordering and remaining verifiability survive an accountable gap.", "'Latest' is never an evidentiary citation target. Any reference used as evidence, in an audit, or in a signed claim MUST pin a revision identifier, because multiple latest versions may exist under branching.", "Released revisions are immutable; corrections are new revisions with predecessor links.", "Every non-initial revision SHOULD have a previousVersion or an explicit first-version flag.", "Backward-compatibility issues SHOULD be described in adms:versionNotes.", "Prior versions remain resolvable at version identifiers until the retention rule allows tombstone; silent deletion of released history is forbidden.", "Format variants, translations and series members are not recorded as versions.", "Version history is readable under the host's access policy; unreleased revisions and embargoed snapshots are restricted by default." ], "crud": { "read": [ "Retrieve a revision by its identifier, returning content plus the manifest that fixes its identity, instants and digest.", "Enumerate the version history of an entity in a stable order with an explicit completeness statement, including tombstones for withdrawn or disposed entries.", "Resolve the revision in force at a supplied instant along a stated temporal axis, and report which instant and axis the response reflects.", "Compute or retrieve the difference between two named revisions, including the expected result digest.", "Verify content fixity and history chain integrity over a stated revision range without mutating any stored record." ], "create": [ "Mint a new revision, which requires a resolvable host entity identifier, a predecessor set (possibly empty for a root), an attributable agent, a change-event instant and a record instant.", "Create a change set bound to an ordered predecessor and successor revision pair, carrying its expected result digest.", "Open a working copy or checkout against a named base revision, recording the holder and an expiry instant.", "Publish a deprecation and sunset notice bound to a revision or element, with a replacement reference or an explicit statement that none exists.", "Record an approval, attribution, impact assessment or timestamp attestation bound to a revision identifier." ], "update": [ "Move the head or currency pointer to a different revision, atomically, by an authorised role, recording the move instant and whether it constitutes a rollback.", "Change deprecation status and sunset scheduling, subject to the constraint that a sunset instant is never set earlier than the deprecation instant.", "Append fixity and chain verification outcomes, which add observations without altering the verified content.", "Set retention, legal-hold and disposition-scheduling flags on history entries.", "Content, instants, agent, predecessor set and digest of a released revision are NOT updatable; any attempt is rejected and the rejection recorded." ], "delete": [ "Content destruction occurs only under a recorded disposition authority or a lawful erasure obligation, never as an ordinary operation and never to resolve a verification failure.", "Every deletion leaves a tombstone that preserves the revision identifier, its instants and its position in the lineage, so that a deleted revision is distinguishable from one that never existed.", "Redaction removes sensitive content in place and leaves a redaction marker; the effect on covering digests and signatures is assessed and recorded before execution.", "A disposition record evidencing the destruction is created before the content is destroyed and is retained beyond the retention period of the content it describes.", "Compaction or squashing of history, where permitted at all, MUST preserve revision identifiers, instants, digests and predecessor edges of the compacted range, and MUST be recorded as an authorised disposition." ] }, "roles": [ { "name": "Version Owner", "responsibilities": [ "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." ] }, { "name": "Change Author", "responsibilities": [ "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." ] }, { "name": "Change Approver", "responsibilities": [ "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." ] }, { "name": "History Custodian", "responsibilities": [ "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." ] }, { "name": "Records and Retention Officer", "responsibilities": [ "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." ] }, { "name": "Registry Steward", "responsibilities": [ "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." ] }, { "name": "Consumer / Integrator", "responsibilities": [ "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." ] } ], "access": { "default_rule": "Structural history metadata — revision identifier, version label, instants, predecessor and successor links, state and content digest — inherits the access classification of the current state of the host entity. Interpretive and attributive content — change reason, human-readable note, agent identity, approval records, impact assessments and conflict reports — defaults to a more restricted classification and is not disclosed to holders of current-state read access without a separate grant, because it can reveal personal data, internal decision-making and security detail that the current state does not.", "scopes": [ "bundle", "layer", "finding", "artifact" ], "exceptions": [ "Regulated audit-trail content must remain available for inspection by authorised regulators and internal auditors for the full retention period, overriding the default restriction on attributive content.", "An embargoed revision exposes its existence, identifier, instants and digest while withholding content until the embargo instant, so that lineage and ordering remain verifiable during the embargo.", "Redacted assertions remain listed as redacted with their redaction markers; the existence of a redaction is never itself concealed.", "Erasure under a lawful obligation removes content but retains a non-identifying tombstone and a disposition record, which remain accessible to the retention officer and auditors.", "Security-severity change notes may be withheld from general consumers until a coordinated disclosure instant, while the existence of the revision and its digest remain visible.", "Where the host entity is public data, structural history metadata is published openly in line with the requirement to provide a version indicator and version history, even if attributive content stays restricted.", "Embargoed unpublished versions remain hidden until issue time.", "Yanked or invalidated versions stay in lineage but MUST NOT be designated current.", "Legal hold blocks tombstone.", "Personal-data redaction may replace a snapshot payload via a new revision rather than editing history.", "If-Match failure is a denied write, not a delete." ], "audit_requirements": [ "Every append to history is logged with the acting agent, the record instant, the revision identifier affected and the authorisation basis.", "Every read of restricted history content — attributive fields, embargoed revisions, redacted entries — is logged with the requesting actor, the instant, the scope requested and the decision.", "Every fixity and chain verification run is logged with its range, outcome and instant, and every unverified result raises a tracked escalation.", "Every rejected revision attempt, precondition failure and conflict is logged, so that suppressed changes are visible rather than silently lost.", "Every disposition, redaction or erasure execution is logged with its authority, scope, instant and effect on digests and signatures, and the log is retained beyond the retention period of the disposed content.", "Every movement of the head or currency pointer is logged with the acting role, the prior and new revision identifiers, and whether the move was a rollback.", "Record who assigned, froze, designated current, deprecated, superseded, patched or invalidated a revision, with event time and observation time.", "Record digest mismatches as integrity incidents.", "Do not treat this audit as a substitute for a security event log." ] }, "agents_bootstrap": { "filename": "AGENTS.md", "required_fields": [ "Name", "Type", "Specification URL", "Storage type URL", "Interface URL", "Processes URL", "Version designation scheme and its specification URL", "Canonicalisation profile and digest algorithm in force", "Retention schedule and disposition authority", "Accountable owner (resolvable agent identifier)", "Alignment crosswalk URL with target vocabulary versions", "History access and visibility defaults" ], "read_order": [ "Read AGENTS.md first and resolve Name and Type to confirm that this package is the Version / Change History mixin and not a host model that merely embeds it.", "Follow the Specification URL to obtain the current specification revision, and record its revision identifier before acting on any of its rules.", "Follow the Storage type URL to learn how revisions, change sets and history entries are materialised in this deployment, remembering that storage is a projection and not the semantics.", "Follow the Interface URL to learn how history is enumerated, how as-of retrieval is requested, and which precondition mechanism is required on updates.", "Follow the Processes URL for the mint, approve, migrate, deprecate, withdraw and dispose procedures and their required authorisations.", "Read the declared version designation scheme, canonicalisation profile and digest algorithm before computing, comparing or verifying any digest or ordering.", "Read the retention schedule, disposition authority and history visibility defaults before reading, exporting or deleting any history content." ] } }, "coverage": { "claim": "The merged plan covers the decision surface of a composable version/change-history mixin as evidenced by the two packs: revision identity and designation, ordering and currency, predecessor/successor topology including merges, derivation typing, replacement and supersession, change sets and classification, compatibility and migration, deprecation and sunset, record/event/effective time, revision lifecycle and withdrawal, attribution and change authority, fixity and tamper evidence, history access, concurrency, visibility, retention and disposition, and declared external alignment. Completeness is not claimed: preservation-event semantics (PREMIS/OAIS), configuration- and records-management standards (ISO 10007/15489), and standardised bitemporal valid-time (SQL:2011) were not retrievable in either pack, leadered-less multi-writer convergence is excluded, and all external mappings are declared alignments rather than conformance.", "confidence": "medium", "checklist": [ { "dimension": "identity", "status": "covered", "notes": "Revision identifier assignment, issuer authority, non-reuse guarantee, series versus revision identity, and an explicit identity priority that rejects dates, labels and digests as identifiers. Grounded in RFC 3253 (distinct never-reused URL per version), OWL 2 (ontology IRI plus version IRI uniqueness), RFC 9562 and FHIR versionId." }, { "dimension": "lifecycle", "status": "covered", "notes": "States from working copy and checkout through release, supersession, deprecation, withdrawal and deactivation, with the immutability onset point and legal transitions. Grounded in RFC 3253 checkout/checkin, SemVer immutability of released versions, DID Core deactivated, FHIR delete-as-history-entry." }, { "dimension": "relationships", "status": "covered", "notes": "Predecessor and successor as sets rather than pointers, multi-parent merges, branch scoping, acyclicity validation, and typed distinction between revision, derivation and format variant. Grounded in RFC 5829, RFC 3253 DAV:predecessor-set, the Git commit DAG, PROV-O and DCMI Terms." }, { "dimension": "temporal", "status": "covered", "notes": "Change-event time, record time and publication time held separately, RFC 3339 with explicit offsets, monotonicity handling, supersession instants, and as-of resolution. Effective/valid period is present but with weaker primary support — see the migration and temporal entries in known omissions." }, { "dimension": "provenance", "status": "covered", "notes": "Attribution to person, organisation or software agent, on-behalf-of delegation, generating activity, upstream ingredient versions with pinning and digests, and the boundary that non-revision provenance belongs to the provenance sibling. Grounded in PROV-O, C2PA ingredients and DWBP BP5." }, { "dimension": "ownership", "status": "covered", "notes": "Accountable owner as a resolvable agent identifier at package level, change author, approver, custodian, retention officer, registry steward and consumer roles, plus migration responsibility and deadline. Grounded in NIST CM-3 and 21 CFR 11.10(k)." }, { "dimension": "validation", "status": "covered", "notes": "Canonicalisation before digesting, expected result digest for delta verification, fixity re-checking with declared interval and failure handling, acyclicity and dangling-reference checks, and the rule that a weak validator is not fixity. Grounded in RFC 8785, OCFL, RFC 6902 and RFC 9110." }, { "dimension": "access", "status": "covered", "notes": "Structural metadata inherits the host classification while attributive content defaults to more restricted; embargo, redaction visibility, regulator access and coordinated disclosure are handled as explicit exceptions with audit requirements at bundle, layer, finding and artifact scope." }, { "dimension": "retention and deletion", "status": "covered", "notes": "Retention period and basis, legal hold, compaction constraints, tombstones, redaction in place, disposition records that outlive their content, and an explicit reconciliation of append-only history with erasure and rectification duties. Grounded in 21 CFR 11.10(c), GDPR Articles 5(1)(e), 16 and 17, and C2PA redaction." }, { "dimension": "interoperability", "status": "covered", "notes": "Declared alignment (never conformance without evidence) to PROV-O, DCAT 3, DCMI Terms, FHIR meta and history, OCFL, C2PA, SemVer and PEP 440, plus exposure through IANA-registered link relations and HTTP conditional and datetime-negotiation mechanisms, with loss statements and recorded conflicts." }, { "dimension": "authority", "status": "covered", "notes": "Authorisation basis, approval decisions bound to revisions, declared signature meaning and pre-approval impact analysis, separated from the workflow sibling that routes the approval. Grounded in NIST CM-3 and 21 CFR Part 11." }, { "dimension": "classification", "status": "covered", "notes": "Change categories, breaking status, semantic versus presentational impact, correction flag and severity, with the category vocabulary declared rather than assumed because the widely used category set is a community convention, not a standard." }, { "dimension": "process and events", "status": "covered", "notes": "Mint, link, compute delta, assess impact, evaluate compatibility, plan and apply migration, resolve as-of, reconstruct, enumerate, enforce precondition, verify, deprecate, withdraw, dispose and project — each with preconditions and effects." }, { "dimension": "measurement", "status": "covered", "notes": "Timestamp precision, retrieval latency and cold-storage boundaries for deep history, history entry counts for truncation detection, and severity grading. Weakest of the covered dimensions: no cited primary source prescribes history retrieval performance bounds." }, { "dimension": "evidence and quality", "status": "covered", "notes": "Compatibility evidence, note completeness against the machine-readable delta, lineage completeness statements, unverifiable-upstream markers, and the rule that unevidenced claims are surfaced as assertions." }, { "dimension": "security", "status": "covered", "notes": "Append-only enforcement, entry chaining, signed history claims, forgery threat modelling, and non-repudiation. Grounded in 21 CFR 11.10(e), NIST AU-3 and AU-10, and C2PA claim signatures." }, { "dimension": "privacy", "status": "covered", "notes": "Sensitive-field inventory within history entries, pseudonymisation rules for agent identities, disclosure classification of withdrawal reasons, and reconciliation of erasure with immutability. Grounded in GDPR Articles 16, 17 and 5(1)(e)." }, { "dimension": "concurrency", "status": "covered", "notes": "Optimistic precondition model with expected-current-revision, precondition-failure outcomes, conflict detection and branch preservation, and lock or checkout expiry. Grounded in RFC 9110 conditional requests, FHIR If-Match with 412, and RFC 3253 checkout." }, { "dimension": "migration and compatibility", "status": "covered", "notes": "Directional compatibility with evidence, migration plan with reversibility, idempotence, accepted loss, owner and deadline, and deprecation-before-sunset ordering. Grounded in Avro schema resolution, SemVer, OWL 2 compatibility annotations and RFC 9745." }, { "dimension": "spatial", "status": "not-applicable", "notes": "Version and change history carries no intrinsic geospatial semantics. Where a host entity's revisions differ geographically — jurisdictional variants, regional editions — that is modelled as branch or context scoping in this model plus the host model's own spatial attributes, not as a spatial dimension here." } ], "known_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." ], "conflicts": [ "Semantic Versioning mandates the X.Y.Z form with compatibility semantics attached to each position, while PEP 440 permits an epoch segment, an arbitrary-length release segment, post-releases and development releases and attaches no semantic promise. A single 'version' field cannot carry both orderings, so the designation scheme must be declared per entity rather than assumed.", "Semantic Versioning states that build metadata MUST be ignored when determining precedence, whereas PEP 440 local version identifiers do participate in ordering. 'Ignore the suffix' is therefore not a portable comparison rule.", "RFC 5829 and RFC 3253 model predecessors as sets and explicitly anticipate merged branches and multiple latest versions, and Git commit objects carry a list of parents forming a DAG; DCAT 3 describes dcat:previousVersion as specifying a version chain of snapshots. A strict chain cannot represent a merge, so mapping this model onto DCAT is lossy at merge nodes and that loss must be declared.", "PROV-O treats prov:wasRevisionOf as a derivation between two distinct entities with distinct identifiers, while FHIR, DeltaV and OCFL treat versions as successive states of one identified resource addressed by a compound identifier. Any alignment must first decide whether each revision is a first-class entity; the two readings are not interchangeable.", "Immutability requirements — SemVer item 3, RFC 3253's rule that the content and dead properties of a version never change, OCFL version-directory immutability, and C2PA's rule that claimed assertions cannot be modified — conflict directly with GDPR Article 16 rectification and Article 17 erasure where history contains personal data. C2PA's redaction-by-subsequent-claim and tombstoning are partial mitigations, not a general resolution; the residual conflict is real and is handled by policy, not by pretending it does not exist.", "HTTP entity tags are opaque and may be weak, and FHIR maps meta.versionId to a weak ETag. A weak validator asserts semantic equivalence rather than byte identity, so it cannot serve as a fixity value, yet both appear in the same position in many implementations. The model separates validator from digest explicitly.", "RFC 3339 permits a leap-second value of 60 and distinguishes -00:00 from Z, while UUIDv7 and most epoch-millisecond stores can represent neither. Round-tripping instants through such stores is lossy, and the loss must be recorded rather than silently accepted.", "W3C DWBP requires a version history with a changelog stating precisely how each version differs from its predecessor, but prescribes no format; the widely used category vocabulary (Added, Changed, Deprecated, Removed, Fixed, Security) comes from a community convention that explicitly disclaims standard status. Category vocabularies are therefore declared, not assumed interoperable.", "ADMS last/next/prev versus DCAT previousVersion/hasCurrentVersion: ADMS 2.00 notes that DCAT replaced ADMS version-navigation properties; both remain as alignments.", "dcat:prev (series order) versus dcat:previousVersion (snapshot lineage) share informal wording but are disjoint in DCAT.", "dcterms:hasVersion includes editions and adaptations; dcat:hasVersion / pav:hasVersion are limited to life-cycle snapshots.", "SemVer forbids modifying a released version; DataCite allows the same DOI with an updated Version for steward-defined minor changes.", "DataCite major versus minor is steward-defined; SemVer major is an incompatible public-API change.", "PAV previousVersion is normally one direct ancestor; merge revisions need multiple parents.", "OWL 2 expects exactly one current version per series IRI; product branches may need several currents.", "owl:backwardCompatibleWith is identifier-interpretation compatibility for ontologies, not SemVer public-API compatibility." ], "regional_assumptions": [ "21 CFR Part 11 audit-trail and record-retention requirements apply to US FDA-regulated activity. The analogous EU GMP Annex 11 expectations were not retrieved during this research and are assumed similar but are not cited; adopters in EU-regulated manufacturing must verify independently.", "GDPR rectification and erasure duties assume an EU/EEA processing nexus. UK GDPR, sectoral US regimes, LGPD, PIPL and others may impose different reconciliations with immutable history, and the model deliberately parameterises the reconciliation rather than fixing it.", "Retention periods and disposition authorities are jurisdiction-, sector- and contract-specific. This model requires that a retention period and basis be declared; it fixes no durations.", "Time handling assumes the proleptic Gregorian calendar with UTC offsets per RFC 3339. Non-Gregorian calendar presentation, and jurisdictions where a legally effective date is defined in local civil time rather than an instant, are rendering and interpretation concerns the host model must address.", "Canonical change notes are assumed to be maintained in at least one declared language with explicit language tags; no assumption is made that English is the canonical or only language, and translation lag is a declared quality concern.", "The identity priority assumes that an adopting Dimension can either point at an authoritative master system or control a namespace. Federations with no single authoritative issuer per entity fall outside the assumptions of the identity findings.", "Status concepts are not fixed; EU ADMS-SKOS or a local SKOS scheme may be used.", "DataCite DOI practice is centred on research outputs; it is an alignment for other domains, not a requirement.", "SemVer is software-API-centred and is optional for datasets and documents.", "RFC 3339 timestamps with explicit offset or Z are required in this Dimension regardless of local date formats.", "JSON Patch is the normative sequential-delta alignment; non-JSON hosts must record an equivalent form." ], "adversarial_checks": [ "Tested whether a timestamp alone can serve as the revision identifier: rejected. RFC 3339 instants are not unique under concurrent writes, clock skew and leap seconds break monotonic ordering, and the -00:00 convention means two textually different instants can denote the same moment. The identity priority explicitly forbids a date as an identifier.", "Tested whether a content digest can serve as the sole revision identifier: rejected. A digest is a validator, not an identifier — identical content produced independently by different agents at different times collides, and re-canonicalisation changes the digest with no change of content. The digest is retained as fixity alongside a separate identifier.", "Tested whether a single predecessor pointer suffices: rejected. RFC 5829 and RFC 3253 define predecessor *sets*, and Git commit objects hold a list of parents forming a directed acyclic graph. Predecessor cardinality is 0..n and merge topology is first-class, not an edge case.", "Tested whether Semantic Versioning could be mandated model-wide: rejected. PEP 440, calendar versioning and OCFL's plain continuous integer sequence are all legitimate and mutually incompatible in both grammar and ordering. The scheme is declared per entity, and no compatibility meaning is inferred from an undeclared label.", "Tested whether version history and audit trail are the same finding: rejected. 21 CFR 11.10(e) requires audit trails to record operator entries and actions including those that produce no new revision, and NIST AU-3 governs audit-record content generally. The audit model is a sibling that consumes revision events, not a superset or subset of this model.", "Tested whether general provenance could absorb this model: rejected. PROV-O covers activities, plans, usage and agents far beyond revision events, and prov:wasRevisionOf is one specialisation of derivation. Folding version history into provenance would either bloat the provenance model or lose the designation, compatibility and migration semantics that have no PROV counterpart.", "Tested whether history can be assumed immutable as a matter of law: rejected. GDPR Articles 16 and 17 create rectification and erasure duties over personal data held inside history, and Article 5(1)(e) limits storage. The model therefore carries tombstone, redaction-marker and disposition structure instead of asserting absolute immutability, and records the residual conflict explicitly.", "Tested whether ETag with If-Match fully defines concurrency: only partially. RFC 9110 supplies the mechanism and the 412 outcome but no conflict-resolution policy, and a weak validator cannot distinguish semantically equivalent representations that differ byte-wise. A separate conflict-outcome field and a declared resolution strategy are therefore required.", "Tested whether 'latest' is a safe citation or evidence target: rejected. RFC 5829 states that systems supporting branching may have multiple latest versions, and DCAT's hasCurrentVersion carries the same ambiguity. Evidentiary references must pin a revision identifier.", "Searched for a retrievable normative source for bitemporal valid-time semantics to anchor the effective-period finding: not found within this research (ISO/IEC 9075-2 and ISO 10007 blocked or paywalled; the SIGMOD Record SQL:2011 paper returned unparseable binary). That finding is anchored instead on dcterms:valid, DID document metadata and Memento datetime negotiation, and is marked as partial support rather than presented as canonical.", "Tested whether a version label can be relied upon to derive ordering without traversing the graph: rejected for the general case. Opaque identifiers (FHIR versionId, DeltaV DAV:version-name, which is explicitly for display rather than programmatic use) carry no order, so the model requires an explicit ordering rule and a sequence or graph traversal fallback.", "Tested whether change-note text can be treated as the authoritative record of what changed: rejected. DWBP requires the changelog but the machine-readable delta is what verifies; the model therefore requires an explicit completeness assertion of the note against the change set rather than assuming the two agree.", "Reject treating a format or encoding change as a new version (DCMI content-versus-format rule).", "Reject storing dataset-series dcat:prev in the previousVersion slot.", "Reject mutating bytes of a SemVer-released revision and only bumping dcterms:modified.", "Reject using a date, catalog-record id, or filename as the revision identifier.", "Reject claiming SemVer conformance when no public API is declared.", "Reject collapsing dcterms:hasVersion adaptations into a DCAT snapshot chain.", "Reject dropping prior version IRIs when publishing a new current version.", "Reject applying RFC 6902 without If-Match to a moving mutable permalink and calling the result the same frozen version.", "Reject modelling translations (DataCite IsTranslationOf) as IsNewVersionOf.", "Reject a single functional predecessor when the evidence is a merge, without flagging the DAG gap." ] }, "researchAdjudication": { "providerMode": "dual-provider", "activeProviders": [ "claude", "grok" ], "waivedProviders": [], "providerPolicy": {}, "boundaryDecision": { "entry_kind": "mixin", "status": "accepted", "rationale": "Both providers independently classified WM-XCT-022 as a mixin attached to a host entity rather than a standalone entity, and both exclude the host's own domain attributes. The base pack additionally states storage-neutrality (JSON, Git, OCFL, MCP, MongoDB as projections) and names ten sibling models — provenance, audit, retention, release pipeline, access interface, storage layout, signature, approval workflow, identifier governance, temporal — with source-backed distinctions, so the boundary is settled before any node is accepted. No split, merge or reclassification is warranted." }, "decisions": [ { "concept": "Base provider selection", "disposition": "Claude adopted as base", "rationale": "Decided on boundary completeness, not size: the base states storage-neutrality explicitly, lists twelve out-of-scope items and ten source-referenced sibling distinctions, and separates record time from effective time, validator from digest, and version history from audit trail. The alternative pack's boundaries are vocabulary-precise but silent on authority, integrity, retention, concurrency and history access." }, { "concept": "Entry kind and model boundary", "disposition": "Accepted as mixin without split or reclassification", "rationale": "Both packs independently reached mixin and both exclude the host entity's domain attributes, so the boundary question is settled by agreement rather than adjudication and node acceptance can proceed." }, { "concept": "Replacement and supersession relation (dcterms:replaces, DataCite IsNewVersionOf)", "disposition": "Accepted into predecessor-successor", "rationale": "Only genuinely missing structural concept. The base covers the supersession instant but not the replacement relation or the only-one-valid versus all-citable distinction, which changes how a consumer decides which revision is in force." }, { "concept": "Grok snapshot-versus-abstract (specialisation of an abstract resource)", "disposition": "Rejected as duplicative", "rationale": "prov:specializationOf and alternateOf are already asked in the base finding revision-derivation-or-variant (q-alternate-specialization), and series existence plus dereference behaviour are asked in series-and-abstract-entity. The residual value — dcterms:hasVersion being broader than dcat:hasVersion — is an alignment-loss statement for the crosswalk, not a new finding." }, { "concept": "Grok version-indicator and version-iri-and-series-iri", "disposition": "Rejected as duplicative", "rationale": "Fully absorbed by base findings revision-identity-assignment, version-designation-scheme and series-and-abstract-entity, which additionally cover non-reuse enforcement, qualifier ordering and the validator-versus-identifier distinction. The DataCite new-DOI decision is covered by q-identifier-change and by the base's explicit exclusion of identifier minting policy." }, { "concept": "Grok previous-version-chain", "disposition": "Rejected; base predecessor-set-and-topology retained", "rationale": "The base models predecessors as sets with multi-parent merges, acyclicity validation and lineage-completeness statements, which strictly dominates a functional previousVersion chain. The one distinct item — confusing dcat:prev series order with dcat:previousVersion snapshot lineage — is routed to the alignment crosswalk as a declared mapping hazard rather than admitted as structure." }, { "concept": "Grok compatibility-declaration", "disposition": "Rejected as duplicative and ID-colliding", "rationale": "The base already owns a finding with this identifier covering targets, direction, evidence and default handling; change class and 0.y.z instability are covered by version-designation-scheme and change-classification-and-note. Admitting it would create a duplicate node under a colliding ID." }, { "concept": "Grok deprecation-and-status", "disposition": "Rejected as duplicative", "rationale": "Deprecation instant, replacement pointer, sunset ordering and interface signalling are in deprecation-and-sunset; workflow status, transition legality and status authority are in revision-state-machine. The remaining nuance that deprecating a public contract forces a minor increment belongs to the declared scheme, not to a new node." }, { "concept": "Grok migration-patch", "disposition": "Rejected as duplicative", "rationale": "RFC 6902 is already a base source under change-set-representation, which covers formalism, atomicity, verification digest and invertibility, while ordered procedure, reversibility, idempotence, accepted loss and owner are covered by migration-procedure." }, { "concept": "Grok functions compare-version-precedence, publish-as-current, supersede-revision, freeze-released-revision", "disposition": "Accepted", "rationale": "Each closes an executable gap where the base declares the state or the artifact but supplies no operation: precedence comparison, moving the currency pointer, asserting displacement, and effecting the draft-to-released transition at which immutability attaches." }, { "concept": "Grok functions assign-version-identity, link-predecessor, declare-compatibility, apply-migration-patch, deprecate-revision, record-version-notes, invalidate-revision", "disposition": "Rejected as duplicative", "rationale": "Each maps onto an existing base function — mint-revision plus assign-designation, link-predecessor, evaluate-compatibility, apply-migration, deprecate-revision, the changelog produced under change-classification-and-note, and withdraw-revision respectively — and two would collide on identifier." }, { "concept": "Source identifier remapping for accepted additions", "disposition": "Required before merge", "rationale": "The accepted nodes carry source-pack IDs that mean different documents in the base pack: DCMI Terms SRC-004 maps to base SRC-011, DCAT 3 SRC-001 to base SRC-010, SemVer SRC-005 to base SRC-002, OWL 2 SRC-003 to base SRC-016. DataCite, PAV and ADMS have no base equivalent and must be admitted as new source entries or the additions will cite the wrong documents." }, { "concept": "DataCite, PAV and ADMS as newly admitted sources", "disposition": "Admitted as alignment evidence only", "rationale": "All three are tier-2 and the DataCite versioning page is living guidance rather than a pinned specification, so they may support declared alignment but must not be rendered as conformance, consistent with the base rule that conformance requires re-executable evidence." }, { "concept": "Effective period and bitemporal semantics", "disposition": "Retained with the base's partial-support flag intact", "rationale": "Neither pack retrieved a normative bitemporal source; the finding rests on dcterms:valid, DID document metadata and Memento datetime negotiation. The flag must survive synthesis rather than be smoothed away by the merge." }, { "concept": "Merge-node lossiness against chain-shaped vocabularies", "disposition": "Retained as a declared alignment loss", "rationale": "Both packs independently reached the same conclusion — DCAT and PAV describe a chain while RFC 5829, RFC 3253 and Git commit objects define predecessor sets — so this is corroborated, not contradictory, and belongs in the crosswalk loss statement." }, { "concept": "Catalog-record versus resource revision boundary", "disposition": "Deferred to a boundary-note refinement on the base", "rationale": "The alternative pack's distinction that DCAT CatalogRecord listing and modification dates describe the catalog entry rather than the versioned resource is a real neighbour the base boundary set does not name, but the plan admits findings and functions only, so it is carried as deferred work rather than forced into a node." } ], "publicationHolds": [ "Live-source verification is outstanding for all 27 base sources and for the three newly admitted alternative sources (DataCite versioning, PAV 2.3.1, ADMS 2.00). Recency-sensitive pins must be re-checked at publication time: the IANA link-relations registry, the Git glossary build, the NIST SP 800-53 control release, and the DataCite guidance page, which is living documentation rather than a dated specification.", "Domain-profile validation has not been performed. The pack asserts applicability across regulated manufacturing, research data, software packaging, records management and web-resource publishing, but only US FDA 21 CFR Part 11 was actually retrieved; EU GMP Annex 11 is assumed similar and uncited. At least two contrasting profiles must be exercised before publication.", "Every external mapping must be rendered as declared alignment, never conformance, and the accepted DataCite, PAV and ADMS additions must carry that label explicitly along with their loss statements.", "Documented evidence gaps must appear in the published draft rather than be omitted: PREMIS 3.0 and OAIS returned HTTP 403, ISO 10007 and ISO 15489 are paywalled and unverified, and no normative bitemporal source was obtained, so the effective-period finding must ship marked as partial support.", "Source identifier remapping for the accepted findings and functions must be applied and re-checked before render, since the two packs use overlapping SRC identifiers for different documents." ], "deferredResearch": [ "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." ] }, "statistics": { "sources": 32, "bundles": 6, "layers": 12, "findings": 26, "questions": 119, "artifacts": 24, "functions": 21 } }