Versioning defines when change remains part of the same Integrity Reference and when change is material enough to require a new Integrity Reference with a new Anchor Identifier.
The central decision is not whether something changed. It is whether the integrity subject remains the same.
This rule preserves stable identity without allowing materially different integrity subjects to hide behind the same Anchor Identifier.
Version assigned by the Source Institution to its own authoritative artifact.
External AuthorityVersion of the Anchor-owned Integrity Reference while the underlying integrity subject remains the same.
Anchor AuthorityVersion of the machine-readable schema used to structure and validate the Integrity Reference.
Schema AuthorityVersion of a cryptographic algorithm or implementation where the Version materially affects reproducibility or Verification.
Method MetadataVersion of an external or composite commitment procedure, such as a timestamping, Merkle, transparency, or future Bitcoin commitment method.
Method MetadataVersion of the transformation or serialization rules used to construct the Canonical Representation where those rules are Versioned.
Representation MetadataThese Versions may change independently.
The integrity subject is the combination of Source identity and governed representation that the Integrity Reference exists to preserve.
The Integrity Method supports preservation of the subject. It does not define the subject by itself.
A new Anchor Version is appropriate when the Integrity Reference remains about the same integrity subject but Anchor-owned record content changes.
Likely examples include:
A new Integrity Reference is appropriate when the integrity subject itself changes.
Likely examples include:
A new Integrity Reference receives a new Anchor Identifier.
A Source Version change does not automatically answer the Anchor Versioning question.
If the Source Version is merely metadata and the Canonical Representation remains identical, a new Integrity Reference may not be necessary.
If the Source Version changes the canonical content being preserved, the normal outcome should be a new Integrity Reference.
A material Representation Boundary change normally creates a new integrity subject.
Even if both boundaries come from the same Source Artifact, they may represent different integrity claims and therefore require separate Integrity References.
A canonicalization change requires careful analysis.
Production procedure should test whether the generated integrity subject remains equivalent.
Changing the Integrity Method does not automatically create a new integrity subject.
For the same Canonical Representation, Anchor may add:
If the subject remains unchanged, this may be represented as a new Anchor Version or additional method evidence.
A cryptographic algorithm may become deprecated while the integrity subject remains the same.
Historical algorithm evidence must remain preserved.
Schema migration alone should not create a new Integrity Reference when the underlying integrity subject and institutional meaning remain unchanged.
A schema migration may produce a new Anchor Version if it changes the canonical Anchor record representation.
Corrections usually operate through a new Anchor Version when the Integrity Reference identity remains valid.
If the error means the original record referenced the wrong integrity subject entirely, a new Integrity Reference may be required.
Anchor should preserve every production Version.
Later Versions must not silently erase earlier production states.
The Base Schema currently models:
Initial production architecture therefore adopts simple sequential integer Anchor Versions:
Semantic Versioning is not necessary for the Integrity Reference itself unless later production proves otherwise.
Initial Version Model FrozenThe first production form of an Integrity Reference is:
Draft iterations before production assignment do not require permanent production Version history unless production procedure later establishes otherwise.
A production Anchor Version should increment only for a governed change to the Anchor-owned Integrity Reference representation.
Purely external or derived changes may not require Versioning if they do not alter the canonical Anchor record.
Publication architecture should define which representations are canonical.
If the answer to #4 is yes, use Versioning where appropriate. If the answer to #4 is no, create a new Integrity Reference.
A new Anchor Version and a superseding Integrity Reference are different.
Version and Lifecycle remain separate.
A new Version may remain active. A lifecycle change may occur without a new Version if the canonical record is not Versioned by that event.
Publication should expose which Anchor Version is currently canonical while preserving access to prior Versions.
Versioning should preserve continuity without disguising a new integrity subject as an update to an old one.