Registry · Institutional Lifecycle

Satoshium Registry Lifecycle

Registry Lifecycle defines the institutional states, permitted transitions, version events, correction events, and preservation rules governing a Satoshium Registry Entry, or SREG.

Lifecycle describes the condition of the SREG within Registry. It does not replace the lifecycle or status of the Authoritative Source Record.

Constitutional Position

Registry Lifecycle operates beneath Satoshium Suite Standards, Suite Methodology, and Suite Interoperability.

Suite Standards → Registry Policy → Registry Procedure → SREG Lifecycle → Preserved History
Lifecycle changes must remain documented, version-aware, schema-valid, attributable, and consistent across human-readable and machine-readable records.

Purpose

Registry Lifecycle provides a controlled model for understanding the institutional condition of a SREG over time.

Lifecycle Is Not Status

Lifecycle describes the stage or condition of the SREG. Registry Status is the current operational designation assigned to the SREG. The two concepts may relate, but they are not interchangeable.

Lifecycle Is Not Synchronization

Synchronization describes technical alignment between systems. Lifecycle describes the institutional condition of the Registry Entry.

Source Lifecycle Is Separate

The Source Record may be active, expired, revoked, retired, or superseded while the SREG remains active as a current or historical catalog entry.

Version Awareness

Lifecycle events must preserve which SREG version is current, which versions were corrected or replaced, and which versions remain historically significant.

Preservation

Registry does not erase prior history merely because an entry changes. Lifecycle preserves continuity across updates, corrections, supersession, revocation, and archival.

Lifecycle Model

A SREG may move among defined lifecycle states according to documented policy. The states do not form one mandatory linear sequence.

Pending Registration → Registered → Active

Active → Updated → Active

Active → Superseded → Archived

Active → Revoked → Archived

Registered → Revoked

The valid transition depends on the reason for change, the condition of the SREG, and the condition of the Authoritative Source Record.

Pending Registration

The proposed entry has been identified or received but has not yet completed Registry intake, validation, identifier assignment, and publication.

Registered

The SREG has been formally created and assigned a Registry Identifier but may not yet be designated as the current active public representation.

Active

The SREG is the current discoverable Registry representation of the referenced Source Record.

Updated

The SREG has undergone a documented change to Registry-owned information or has been revised to reflect a source-record change.

Superseded

The SREG or a specific SREG version has been replaced by a newer Registry object while remaining preserved for succession and historical continuity.

Revoked

The SREG has been withdrawn from active Registry recognition because of invalid registration, material error, loss of source authority, reversal, or another documented reason.

Archived

The SREG is no longer in active operational use but remains preserved as part of the historical Registry record.

Archived does not mean deleted. It means preserved outside active operational use.

Transition Principles

  • Every transition must have an identified reason.
  • Every material transition should be attributable and dated.
  • Every material transition should preserve the affected SREG version.
  • Transitions must remain consistent across HTML, JSON, indexes, and history.
  • Source-record changes and Registry lifecycle changes must remain distinguishable.
  • Terminal or historical states should not erase prior Registry identity.
  • Invalid transitions should fail validation.

Permitted Transition Examples

Pending Registration → Registered

Occurs when intake is complete, the Registry Identifier is assigned, required fields are present, and the SREG is formally created.

Registered → Active

Occurs when the SREG is approved for current public catalog use and published in its required official forms.

Active → Updated → Active

Occurs when the SREG is corrected or revised and the replacement version becomes the current active entry.

Active → Superseded

Occurs when a newer SREG or version replaces the current one.

Active → Revoked

Occurs when Registry withdraws the SREG from active recognition for a documented reason.

Superseded → Archived

Occurs when the superseded entry remains preserved as a historical object.

Revoked → Archived

Occurs when the revoked entry is preserved outside active use while retaining the revocation record and prior references.

Update Events

Updated may function as an event recorded between active versions rather than as a long-term terminal state.

An update may be triggered by:

  • corrected metadata;
  • new or repaired public references;
  • new relationships;
  • a source-record version change;
  • a source-record status change;
  • schema migration;
  • Record Type refinement;
  • publication reconciliation.
Prior Active Version → Updated Event → Replacement Active Version

Corrections and Lifecycle

A correction may create a new SREG version without changing the underlying Source Record.

A source change may require a SREG update without constituting a Registry correction.

Correction applies to Registry-owned information. Source update reflects a Source Institution change.

Registry should preserve which event occurred and why.

Supersession

Supersession preserves succession between Registry objects or versions.

A superseded SREG should preserve:

  • its Registry Identifier;
  • its final SREG version;
  • the replacement Registry Identifier or version;
  • the supersession date;
  • the reason for supersession;
  • prior source references;
  • relationship history.
Supersession means replaced, not invalid.

Revocation

Revocation withdraws the SREG from active Registry recognition.

A revocation record should preserve:

  • the affected Registry Identifier;
  • the affected SREG version;
  • the revocation reason;
  • the revocation date;
  • the responsible Registry action;
  • the Source Record impact, if any;
  • the resulting Registry Status;
  • the archival or replacement path.
Revocation preserves accountability. It does not require deletion.

Archival

Archival preserves a SREG outside active operational use.

Archived entries should remain discoverable through appropriate historical, supersession, revocation, or archival indexes.

Archival should preserve:

  • Registry identity;
  • prior versions;
  • source attribution;
  • source references;
  • relationships;
  • correction history;
  • supersession or revocation history;
  • archival date and reason.

Registry Lifecycle and Source Lifecycle

Registry Lifecycle and Source-Record Lifecycle must remain separate.

Source-Record Status: Revoked
Registry Lifecycle State: Active
Registry Status: Active Historical Entry

In this example, Registry preserves the active public catalog entry while accurately reporting that the Source Record has been revoked.

Lifecycle and Versions

Registry distinguishes among:

  • Registry Entry Version;
  • SREG schema version;
  • Record-Type Profile version;
  • Registry specification version;
  • Source-Record version;
  • Source Institution publication version.

Lifecycle events should preserve the version state before and after the transition.

SREG Version 1.0.0 Active → Update Event → SREG Version 1.1.0 Active

Lifecycle Record Requirements

A material lifecycle event should preserve, at minimum:

  • Registry Identifier;
  • prior lifecycle state;
  • new lifecycle state;
  • prior Registry Status;
  • new Registry Status;
  • event date;
  • event reason;
  • affected SREG version;
  • replacement version or entry, if applicable;
  • Source Record impact;
  • related correction, supersession, revocation, or archival record.

Validation Requirements

Registry should validate lifecycle events against approved transition rules.

Validation may confirm:

  • the prior state is valid;
  • the proposed next state is permitted;
  • the reason is documented;
  • required version metadata exists;
  • required references remain preserved;
  • human-readable and machine-readable records agree;
  • source status and Registry status remain separate;
  • the lifecycle event satisfies the applicable schema.

Publication Consistency

Lifecycle changes must be applied consistently across:

  • human-readable Registry Entry pages;
  • machine-readable SREG records;
  • catalog indexes;
  • relationship indexes;
  • version history;
  • correction history;
  • supersession, revocation, and archival records;
  • interoperability references.
A lifecycle transition is incomplete when official Registry formats disagree about the current condition of the same SREG.

Lifecycle Principle

Registry Lifecycle exists to preserve the institutional condition of the SREG without erasing its identity, provenance, versions, or source relationships.

State changes. Identity persists. History remains discoverable.
Back to Registry → Open Status → Open Corrections →
Registry does not erase the past. It preserves the state and history of the SREG.