Registry · Versioning

Satoshium Registry Versioning

Satoshium Registry Versioning defines how Registry identifies, separates, increments, validates, publishes, and preserves the distinct version domains that govern SREGs and their Authoritative Source Records.

Versioning allows Registry to show what changed, when it changed, which requirements applied, and which prior states remain historically discoverable.

Constitutional Position

Versioning operates across the complete Registry lifecycle and applies to records, schemas, profiles, rules, policies, procedures, standards, and methodology.

Source Record → SREG Construction → Registry Entry Version → Validation → Publication History
Registry Identifier preserves continuing identity. Versioning preserves the changing states of that identity.

Why Versioning Matters

A SREG may change because its source changes, Registry metadata changes, schemas evolve, relationships are corrected, statuses transition, or publication requirements mature.

The Core Question

Versioning asks:

What changed, which version domain changed, why did it change, and how can prior states still be found?

Registry's Responsibility

Registry must assign and preserve Registry Entry Versions, distinguish them from source and governance versions, and publish clear version history.

Registry's Limitation

Registry does not control Source-Record Versions, Certification Package Versions, Attestation Versions, or other institution-owned version domains.

Canonical Version Distinction

Registry Identifier ≠ Registry Entry Version ≠ Source-Record Version

The Registry Identifier identifies the continuing SREG. The Registry Entry Version identifies one published state of that SREG. The Source-Record Version identifies one state of the Authoritative Source Record.

Version Domains

  • Registry Entry Version — version of the SREG.
  • Source-Record Version — version assigned by the Source Institution.
  • SREG Base Schema Version — version of the base SREG structure.
  • Record-Type Profile Version — version of the applicable Record-Type Profile.
  • Registry Schema Specification Version — version of Registry schema architecture.
  • Registry Rules Version — version of the governing Registry Rules.
  • Registry Policy Version — version of an applicable Registry policy.
  • Registry Procedure Version — version of an operational procedure.
  • Controlled-Value Set Version — version of approved enumerations.
  • Validation Workflow Version — version of the validation method or checklist.
  • Suite Standards Version — version of applicable Suite Standards.
  • Suite Methodology Version — version of applicable Suite Methodology.
  • Suite Interoperability Version — version of applicable interoperability requirements.
A change in one version domain does not automatically require a change in every other domain.

Record Version

Identifies one state of a SREG or Source Record.

Schema Version

Identifies the structural requirements used to express a record.

Profile Version

Identifies Record-Type-specific requirements applied to the SREG.

Governance Version

Identifies the rules, policies, procedures, standards, and methodology in effect.

Registry Entry Version

Every published SREG should declare a Registry Entry Version.

Registry Identifier: SREG-JUR-2026-0001 Registry Entry Version: 1.2.0

The Registry Entry Version changes when the published Registry object changes materially.

Source-Record Version

Registry should preserve the Source-Record Version exactly as assigned by the Source Institution whenever available.

Registry should not:

  • replace the Source-Record Version with the Registry Entry Version;
  • invent a source version that was never assigned;
  • normalize source version syntax without preserving the original value;
  • assume a source change occurred merely because Registry changed;
  • assume Registry must change merely because a source version label changed.

Illustrative Version Relationship

Registry Identifier: SREG-CERT-2026-0001 Registry Entry Version: 1.1.0 Source-System Identifier: SC-CERT-2026-0001 Source-Record Version: 1.0.0 SREG Base Schema Version: 1.0.0 Certification Profile Version: 1.0.0
Each value belongs to a different version or identifier domain and must be preserved independently.

Version Increment Model

Registry may use semantic versioning for Registry Entry Versions:

MAJOR.MINOR.PATCH
  • MAJOR — materially changes the structure, identity interpretation, or institutional meaning of the SREG.
  • MINOR — adds or materially updates Registry information without replacing the continuing SREG identity.
  • PATCH — corrects or clarifies non-structural information without materially changing institutional meaning.
Final increment rules remain subject to Registry governance and may vary when migration or compatibility requirements require a different model.

Major Change

May involve incompatible structure, a material redefinition, or a governance-directed migration.

Minor Change

Adds or materially updates metadata, relationships, provenance, or publication content.

Patch Change

Corrects typographical, formatting, link, or other limited defects.

No Version Change

May apply to non-substantive deployment changes that do not alter the official SREG.

Potential Major-Version Triggers

  • incompatible SREG structure;
  • material change to identity interpretation;
  • migration to a new identifier architecture;
  • material Record-Type reclassification requiring reconstruction;
  • governance-directed reset of version lineage;
  • replacement of the canonical source object while retaining controlled continuity;
  • substantial publication architecture change affecting machine compatibility.

Potential Minor-Version Triggers

  • new relationship;
  • new provenance information;
  • source version update reflected in Registry;
  • Registry Status change;
  • Registry Lifecycle transition;
  • material metadata addition;
  • new archival reference;
  • new integrity reference;
  • profile migration that remains backward compatible;
  • material publication notice.

Potential Patch-Version Triggers

  • typographical correction;
  • formatting correction;
  • broken-link repair that does not change source identity;
  • clarifying note;
  • non-material metadata correction;
  • accessibility improvement that does not alter record meaning;
  • machine-readable formatting correction without field-value change.

Version Assignment Authority

Registry assigns Registry Entry Versions.

Source Institutions assign Source-Record Versions within their own systems.

Governance authorities assign versions to:

  • schemas;
  • Record-Type Profiles;
  • Rules;
  • Policies;
  • Procedures;
  • controlled-value sets;
  • Suite Standards;
  • Suite Methodology;
  • Suite Interoperability requirements.

Version Assignment Record

Every material Registry Entry Version should preserve:

  • Registry Identifier;
  • new Registry Entry Version;
  • prior Registry Entry Version;
  • version date;
  • version authority or workflow;
  • change classification;
  • change summary;
  • changed fields;
  • reason for change;
  • Source-Record Version, when applicable;
  • schema and profile versions applied;
  • validation result;
  • publication record;
  • correction or supersession reference.

Version History

Version history should preserve:

  • every published Registry Entry Version;
  • release date;
  • change summary;
  • validation result;
  • applicable schema and profile versions;
  • Source-Record Version;
  • status and lifecycle at publication;
  • correction references;
  • supersession relationships;
  • archival access;
  • canonical publication path;
  • downloadable historical artifacts.

Current and Historical Versions

One version should be designated as the current published Registry Entry Version.

Prior versions should remain:

  • identifiable;
  • resolvable;
  • dated;
  • linked to the current version;
  • clearly marked as historical;
  • available with applicable notices and restrictions.
Current publication identifies the latest valid state. Historical publication preserves how that state was reached.

Version Relationships

Version lineage may use typed relationships such as:

  • version of;
  • previous version;
  • next version;
  • derived from;
  • corrects;
  • corrected by;
  • supersedes;
  • superseded by;
  • migrated from;
  • migrated to;
  • compatible with;
  • incompatible with.

Final labels and controlled values remain subject to Registry governance.

Version and Correction Distinction

Every material correction may create a new Registry Entry Version.

Not every new Registry Entry Version represents a correction.

Correction → New Version but New Version ≠ Correction

Version and Supersession Distinction

A new Registry Entry Version updates the continuing SREG.

Supersession may replace one SREG with a different SREG and Registry Identifier.

Versioning preserves states within one identity. Supersession connects separate identities.

Schema and Profile Migration

When schemas or profiles change, Registry should determine whether existing SREGs require:

  • no change;
  • validation against the new version;
  • targeted migration;
  • new Registry Entry Version;
  • major Registry Entry Version;
  • deprecation notice;
  • continued publication under the prior schema;
  • compatibility bridge;
  • governance exception.

Backward Compatible

Existing records remain valid without structural reconstruction.

Migration Required

Existing SREGs must be updated to satisfy the new schema or profile.

Deprecated

Prior structure remains historically supported but should not be used for new SREGs.

Unsupported

Prior structure is no longer accepted for current operational publication.

Controlled-Value Versioning

Registry should version controlled-value sets for:

  • Record Types;
  • Registry Status values;
  • Registry Lifecycle States;
  • relationship types;
  • relationship statuses;
  • validation outcomes;
  • publication readiness outcomes;
  • authority-review outcomes;
  • Registrability outcomes;
  • correction categories;
  • notice types.

A removed or renamed value should remain interpretable in historical SREGs.

Version Validation

Validation should confirm:

  • Registry Entry Version is declared;
  • version syntax is valid;
  • prior version exists when required;
  • increment classification matches the change;
  • Source-Record Version remains separate;
  • schema and profile versions are declared;
  • governance versions are identifiable;
  • current and historical versions are not confused;
  • supersession does not overwrite version lineage;
  • human-readable and machine-readable version fields agree;
  • version history is complete;
  • historical artifacts remain attributable.

Invalid Version Conditions

  • missing Registry Entry Version;
  • invalid version syntax;
  • version rollback without governance approval;
  • duplicate version number for different published states;
  • Registry Entry Version used as Source-Record Version;
  • Source-Record Version overwritten;
  • undeclared schema or profile version;
  • major change represented as patch;
  • silent version replacement;
  • historical version presented as current;
  • prior version made undiscoverable;
  • human-readable and machine-readable mismatch.

Version Rollback

Registry should not silently restore an earlier version as though later versions never existed.

A rollback should preserve:

  • version being withdrawn;
  • version being restored or recreated;
  • rollback date;
  • rollback authority;
  • reason;
  • validation result;
  • publication record;
  • continued access to intervening versions;
  • new Registry Entry Version when required.

Relationship to Publication

Every material publication should identify the Registry Entry Version being released.

Publication should expose:

  • current version;
  • prior versions;
  • release dates;
  • change summaries;
  • validation outcomes;
  • schema and profile versions;
  • Source-Record Version;
  • correction and supersession references.

Relationship to Provenance

Version history is part of Registry Provenance.

Provenance should preserve how each version was created, validated, published, corrected, superseded, or archived.

Relationship to Lifecycle

Version changes and Lifecycle transitions are related but distinct.

  • An update may create a new version while the SREG remains Active.
  • Supersession may create a final version and point to a successor SREG.
  • Revocation may create a new version carrying the revocation notice.
  • Archival transition may create a final archival publication version.

Relationship to Source Institutions

Registry must preserve source-owned version values without taking control of them.

Atlas

Atlas controls versions of Atlas resources, jurisdiction records, packages, manifests, and source artifacts.

Certifier

Certifier controls Certification Package, SCPR, SCR, SCRD, and certification framework versions.

Attestor

Attestor controls versions of attestations, trust statements, and Attestor-owned schemas.

Registry

Registry controls Registry Entry Versions, SREG schemas, Record-Type Profiles, Registry Rules, Policies, and Procedures.

What Versioning Does Not Establish

  • It does not create Source Authority.
  • It does not certify the Source Record.
  • It does not make a newer version substantively better.
  • It does not make prior versions invalid automatically.
  • It does not convert a source version into a Registry version.
  • It does not eliminate correction requirements.
  • It does not replace supersession relationships.
  • It does not permit historical erasure.
  • It does not guarantee backward compatibility.
  • It does not transfer version authority from another institution.

Versioning Principle

Registry Versioning should preserve one stable Registry identity while making every material state, governing requirement, and historical change explicit.

Identity remains stable. Versions record change. History preserves accountability.
Back to Registry → Open Identifiers → Open Publication →
A durable Registry preserves not only what a record is, but every accountable state through which it passed.