Registry · History

Satoshium Registry History

Satoshium Registry History defines how Registry preserves the chronological, versioned, attributable, and resolvable history of SREGs, Catalog releases, corrections, lifecycle transitions, governance decisions, and institutional change.

History allows Registry to show not only what a record is now, but how it became what it is.

Constitutional Position

Registry History operates across the complete Registry lifecycle and preserves the institutional record created by Source Authority review, Registrability, identifier assignment, SREG construction, Validation, Publication, Versioning, Corrections, Governance, and archival action.

Registry Action → Versioned Record → Historical Event → Preserved Timeline → Current and Prior States
Current state explains what Registry recognizes now. History explains how that state was reached.

Why History Matters

Registry decisions, versions, corrections, and lifecycle transitions become trustworthy only when their sequence and authority remain reconstructable.

The Core Question

History asks:

What changed, when did it change, who or what authorized it, and what prior state must remain discoverable?

Registry's Responsibility

Registry must preserve its own historical actions, published states, decisions, version lineages, correction records, and lifecycle transitions.

Registry's Limitation

Registry History does not replace Source-System history or Chronicle event records. It preserves the Registry's own institutional history and references external history where appropriate.

Canonical History Model

Registry Object or Decision → Material Change → History Record → Chronological Placement → Resolvable Prior State

History Domains

  • SREG history;
  • Registry Identifier history;
  • Source Authority review history;
  • Registrability decision history;
  • Record-Type assignment history;
  • relationship history;
  • provenance history;
  • Validation history;
  • Publication history;
  • Registry Entry Version history;
  • Correction history;
  • Registry Status history;
  • Registry Lifecycle history;
  • Catalog history;
  • Policy and Procedure history;
  • Governance Decision history;
  • controlled-value history;
  • schema and profile history;
  • restriction and withdrawal history;
  • archival and preservation history.

Chronological

Events and states are placed in a clear temporal sequence.

Attributable

Material changes identify authority, process, date, and supporting record.

Resolvable

Prior states remain accessible through stable identifiers and historical paths.

Non-Destructive

New states do not erase prior states or material institutional decisions.

History Record Requirements

A formal Registry History Record should identify:

  • history-record identifier;
  • Registry Identifier or institutional object affected;
  • event type;
  • event date and time;
  • effective date, when different;
  • authority or responsible process;
  • prior state;
  • new state;
  • reason or change summary;
  • affected fields or domains;
  • Registry Entry Version;
  • Source-Record Version, when relevant;
  • related Validation record;
  • related Publication record;
  • related Correction or Governance record;
  • supporting evidence;
  • canonical historical resolution path.

Illustrative History Record

history_record_identifier: "SREG-HIST-2026-0001" registry_identifier: "SREG-JUR-2026-0001" event_type: "registry_entry_updated" event_date: "2026-08-02" prior_registry_entry_version: "1.0.0" new_registry_entry_version: "1.1.0" authority: "Satoshium Registry"
Final identifiers, field names, event types, and controlled values remain subject to Registry Governance.

History Event Types

Initial History Event Types may include:

  • source received;
  • Source Authority reviewed;
  • Registrability determined;
  • Registry Identifier reserved;
  • Registry Identifier assigned;
  • SREG constructed;
  • Validation completed;
  • SREG first published;
  • SREG updated;
  • Registry Entry Version released;
  • correction issued;
  • relationship added, amended, disputed, or removed;
  • provenance updated;
  • Registry Status changed;
  • Registry Lifecycle State changed;
  • SREG superseded;
  • SREG revoked;
  • SREG retired;
  • SREG archived;
  • publication restricted;
  • publication withdrawn;
  • source became unavailable;
  • Catalog Version published;
  • Policy approved or amended;
  • Procedure approved or revised;
  • Governance Decision issued;
  • schema or profile version changed;
  • controlled value added, amended, deprecated, or retired.

SREG History

Every operational SREG should preserve a chronological record of material changes.

SREG History may include:

  • creation;
  • first Validation;
  • first Publication;
  • each Registry Entry Version;
  • source-version changes reflected in Registry;
  • relationship changes;
  • provenance changes;
  • status transitions;
  • lifecycle transitions;
  • corrections;
  • restrictions;
  • supersession;
  • revocation;
  • retirement;
  • archival preservation.

Identifier History

Registry Identifier history should preserve:

  • reservation date;
  • assignment date;
  • assignment authority;
  • identifier state changes;
  • aliases;
  • corrections;
  • canonical URL changes;
  • supersession relationships;
  • archival resolution;
  • non-reuse evidence.
The Registry Identifier remains stable even when its publication paths, versions, statuses, or lifecycle conditions change.

Source Authority History

Source Authority history should preserve:

  • initial authority assessment;
  • supporting evidence;
  • review outcome;
  • conditions or limitations;
  • delegation;
  • succession;
  • conflicting claims;
  • authority changes;
  • archival custody changes;
  • reconsideration or correction.

Registrability History

Registrability history should preserve:

  • review date;
  • requirements applied;
  • outcome;
  • conditions;
  • duplicate or conflict findings;
  • Record-Type determination;
  • restriction basis;
  • reconsideration;
  • final disposition.

Relationship History

Relationship history should preserve:

  • relationship creation;
  • source and target identifiers;
  • relationship type;
  • Relationship Authority;
  • Relationship Status;
  • effective period;
  • version context;
  • supporting evidence;
  • amendment;
  • dispute;
  • supersession;
  • revocation or invalidation.

Provenance History

Provenance history should preserve changes in:

  • Source Institution attribution;
  • canonical source reference;
  • Source-System Identifier;
  • Source-Record Version;
  • custody;
  • archival location;
  • generation manifest;
  • integrity reference;
  • source availability;
  • derived-artifact lineage;
  • provenance corrections.

Validation History

Validation history should preserve:

  • Registry Entry Version validated;
  • validation date;
  • Rules, Policies, schemas, profiles, and controlled-value versions applied;
  • Validation Outcome;
  • blocking errors;
  • warnings;
  • exceptions;
  • informational findings;
  • revalidation triggers;
  • subsequent correction or publication action.

Publication History

Publication history should preserve:

  • first-publication date;
  • every material republication;
  • Registry Entry Version published;
  • canonical human-readable URL;
  • canonical machine-readable URL;
  • publication authority;
  • Validation Outcome;
  • notices and restrictions;
  • correction publication;
  • withdrawal;
  • supersession;
  • revocation;
  • retirement;
  • archival publication.

Version History

Version history should preserve:

  • every Registry Entry Version;
  • prior and next version relationships;
  • change classification;
  • change summary;
  • changed fields;
  • schema and Profile Versions;
  • Source-Record Version;
  • Validation result;
  • Publication record;
  • historical artifact resolution.

Correction History

Correction history should preserve:

  • suspected error;
  • review date;
  • affected version;
  • prior value;
  • corrected value;
  • reason;
  • correction authority;
  • supporting evidence;
  • new Registry Entry Version;
  • revalidation;
  • public Correction Record or notice.
A correction improves the current record. History preserves the prior state and the fact that correction occurred.

Status and Lifecycle History

Registry should preserve every material Status and Lifecycle transition, including:

  • prior value;
  • new value;
  • transition date;
  • effective date;
  • authority;
  • reason;
  • supporting evidence;
  • related Registry Entry Version;
  • publication notice;
  • successor or archival reference.

Catalog History

Catalog history should preserve:

  • every Catalog Version;
  • generation date;
  • included SREGs;
  • added records;
  • updated records;
  • records removed from current views;
  • search and filter changes;
  • collection changes;
  • Catalog schema changes;
  • integrity references;
  • prior Catalog Version.

Governance History

Governance history should preserve:

  • Governance Decision Records;
  • Rules approval and amendment;
  • Policy approval and amendment;
  • Procedure approval and revision;
  • schema and Profile approvals;
  • controlled-value changes;
  • delegations;
  • exceptions;
  • conflict resolutions;
  • appeals and reconsiderations;
  • emergency actions;
  • supersession and retirement.

History Timeline

A public or internal Registry timeline may organize events by:

  • event date;
  • effective date;
  • Registry Identifier;
  • History Event Type;
  • Record Type;
  • Source Institution;
  • Registry Entry Version;
  • Registry Status;
  • Registry Lifecycle State;
  • Governance authority;
  • public visibility.

Current and Historical Resolution

Registry should distinguish:

  • current canonical SREG;
  • current Registry Entry Version;
  • historical Registry Entry Versions;
  • historical Catalog entries;
  • superseded SREGs;
  • revoked SREGs;
  • retired SREGs;
  • archived SREGs;
  • withdrawn publication states;
  • historical Governance materials.
Historical material should be clearly marked as historical while remaining linked to its current context.

Historical Artifacts

Registry may preserve historical artifacts such as:

  • prior human-readable SREG pages;
  • prior machine-readable SREG files;
  • prior Catalog indexes;
  • Validation records;
  • Publication records;
  • Correction Records;
  • Governance Decision Records;
  • prior schemas and Profiles;
  • prior Rules, Policies, and Procedures;
  • controlled-value set versions;
  • generation manifests;
  • integrity references;
  • archival snapshots.

Historical Integrity

Historical artifacts should preserve:

  • original publication context;
  • artifact identity;
  • artifact version;
  • creation or publication date;
  • custody;
  • integrity reference, when available;
  • relationship to current materials;
  • restriction or rights conditions;
  • known incompleteness or damage.

Source-System History

Registry may reference Source-System history but should not represent that history as Registry-owned when it is controlled by the Source Institution.

Registry should preserve:

  • source-version references;
  • source publication dates;
  • source status changes when known;
  • source archival references;
  • source correction references;
  • date Registry last verified the source history.

Relationship to Chronicle

Registry History and Chronicle are related but distinct.

  • Registry History preserves the institutional history of Registry objects and decisions.
  • Chronicle creates and preserves historical event records within Chronicle's own authority.
  • Material Registry events may be represented in Chronicle.
  • Chronicle references may point back to Registry History Records.
Registry owns Registry History. Chronicle owns Chronicle event records.

History Visibility

History may be:

  • Public — fully visible through Registry publication.
  • Public Summary — public event metadata with restricted supporting detail.
  • Restricted — accessible only under defined conditions.
  • Internal — preserved for institutional operation and review.
  • Withdrawn from Public View — retained historically but not publicly exposed.

Visibility should follow privacy, rights, safety, security, legal, and institutional requirements.

History Validation

Validation should confirm:

  • History Record identifies the correct Registry object;
  • event type is approved;
  • event date and effective date are valid;
  • prior and new states are preserved when applicable;
  • authority is identified;
  • Registry Entry Versions are accurate;
  • related Validation, Publication, Correction, or Governance records resolve;
  • historical and current states are not confused;
  • restricted history is not exposed;
  • human-readable and machine-readable history agree;
  • chronology is internally coherent;
  • prior states remain discoverable.

Invalid History Conditions

  • missing affected Registry object;
  • missing event date;
  • unrecognized event type;
  • missing authority;
  • prior state overwritten;
  • historical version presented as current;
  • current version presented as historical without context;
  • broken historical resolution;
  • Correction Record omitted from history;
  • Status or Lifecycle transition omitted;
  • restricted history exposed;
  • chronological contradiction;
  • Registry history represented as Source-System history;
  • human-readable and machine-readable mismatch.

History Correction

A History Record may itself require correction.

History correction should preserve:

  • original History Record;
  • identified error;
  • corrected History Record;
  • reason;
  • correction authority;
  • correction date;
  • new History Record Version, when applicable;
  • continued resolution of the prior state.
Correcting history must not erase the fact that the historical record was corrected.

History Governance

Registry Governance should control:

  • History Event Types;
  • History Record requirements;
  • public and restricted visibility;
  • historical resolution patterns;
  • artifact-preservation requirements;
  • History Record versioning;
  • History correction;
  • Chronicle integration;
  • retention and archival rules;
  • integrity references;
  • exception handling;
  • historical withdrawal.

Relationship to Versioning

Versioning identifies distinct states of a Registry object.

History places those versions within an attributable chronological sequence.

Versioning records state. History records sequence and context.

Relationship to Publication

Publication creates public Registry states.

History preserves each material Publication event, prior public state, notice, restriction, correction, withdrawal, and archival transition.

Relationship to Catalog

Catalog History preserves how the public Registry collection changed over time.

Historical Catalog views may expose prior SREG inclusion, former classifications, prior versions, former status, and records removed from current views.

Relationship to Provenance

History is part of Registry Provenance.

Provenance explains origin and custody. History explains sequence, change, and institutional action.

What History Does Not Establish

  • It does not create Source Authority.
  • It does not certify Source Records.
  • It does not create attestations.
  • It does not replace Source-System history.
  • It does not replace Chronicle event records.
  • It does not make every change publicly visible.
  • It does not permit historical erasure.
  • It does not make a prior state current.
  • It does not remove rights, privacy, safety, or security restrictions.
  • It does not transfer authority from another institution.

History Principle

Registry History should preserve every material institutional change as an attributable, version-aware, chronologically coherent, and resolvable part of the Registry's enduring record.

Current state shows what the Registry recognizes. History shows how the Registry arrived there. Preservation keeps both accountable.
Back to Registry → Open Versioning → Open Catalog →
A durable institution remembers not only its conclusions, but the path by which each conclusion became part of the record.