Registry · Institutional Purpose

Satoshium Registry Purpose

Satoshium Registry exists to create and maintain durable, structured, publicly discoverable Registry Entries for authoritative records produced across the Satoshium Suite.

Registry preserves identity, classification, source references, relationships, versions, status, lifecycle, and the path back to the institution that holds authority.

Constitutional Position

Registry operates beneath the Satoshium Suite constitutional hierarchy.

Suite Standards Suite Methodology Suite Interoperability Registry Institutional Implementation SREG
Standards define expectations. Methodology defines implementation. Interoperability preserves institutional boundaries. Registry applies those foundations through the SREG.

Why Registry Exists

The Suite creates many authoritative records: jurisdiction resources, certifications, historical events, integrity references, discovery signals, trust statements, workflow definitions, media, and institutional artifacts.

Without a dedicated catalog institution, those records may remain scattered across repositories, websites, packages, schemas, and public pages.

The Institutional Problem

Creation alone does not guarantee long-term discoverability.

As the Suite grows, users must still be able to determine what exists, who created it, where the authoritative source is located, which version is current, what its Registry condition is, and how it relates to other records.

The Mission

Registry's mission is to maintain the public catalog layer of the Satoshium Suite through durable, attributable, version-aware, relationship-aware SREGs.

The Canonical Object

Registry's canonical operational object is the Satoshium Registry Entry, or SREG.

The SREG is the structured Registry object through which an Authoritative Source Record becomes identifiable and discoverable within the Registry.

Canonical Operational Hierarchy

Satoshium Registry Registry Entry (SREG) Registry Record Type Authoritative Source Record

Registry is the institution. The SREG is its canonical operational object. The Record Type classifies the SREG. The Source Record remains owned by the institution that created it.

Core Questions Registry Answers

  • What authoritative record exists?
  • Which institution created and maintains it?
  • What Registry Record Type applies?
  • What Registry Identifier identifies the SREG?
  • What Source-System Identifier identifies the Source Record?
  • Where can the Source Record be found?
  • What is the current Registry Status?
  • What is the current Registry Lifecycle State?
  • What is the reported Source-Record Status?
  • Which versions apply?
  • What other records are related?
  • How can prior states remain discoverable?

Identity

Registry assigns and preserves stable Registry Identifiers for SREGs.

Classification

Registry assigns approved Record Types and controlled classifications.

Source Attribution

Registry identifies the Source Institution and preserves the Source-System Identifier and canonical source reference.

Relationships

Registry preserves typed relationships among SREGs, Source Records, institutions, certifications, events, integrity references, attestations, and workflows.

Status and Lifecycle

Registry preserves the current institutional condition of the SREG while keeping it separate from the status of the Source Record.

Versions and Corrections

Registry preserves versions, documented updates, corrections, supersession, revocation, and archival history.

Publication

Registry publishes consistent human-readable and machine-readable forms of the SREG.

Preservation

Registry preserves identity, provenance, relationships, and discoverability after records change or leave active use.

Authority Boundary

Registry is authoritative for the SREG and Registry-owned information.

Registry is not authoritative for the substantive content or institutional meaning of the Source Record.

The Source Institution creates authority. Registry creates the structured public path back to it.

Relationship to Suite Institutions

Atlas

Creates jurisdiction intelligence, canonical jurisdiction records, evidence resources, and machine-readable Atlas packages.

Certifier

Creates Certification Packages, process reports, receipts, and certified records.

Registry

Creates SREGs that catalog and connect authoritative institutional records.

Chronicle

Creates and preserves historical events and institutional chronology.

Anchor

Creates and preserves integrity references, hashes, timestamps, signatures, and durable verification points.

Beacon

Creates discovery signals and metadata that help records be found.

Attestor

Creates trust statements, attestations, validations, and supporting references.

Navigator

Creates workflow definitions and coordinates cross-system operational activity.

Interoperability Purpose

Registry allows Suite institutions to remain independent while their records become consistently identifiable, referenceable, related, and discoverable.

Interoperability connects authority without absorbing it.

Registry does not operate another institution's canonical object. It creates the Registry object that catalogs that source.

First Operational Path

Atlas Resource → Certifier Evaluation → Certification Package → SCRD → SREG

The Certification Package remains Certifier's canonical certification object. The SCRD remains a Certifier-owned certified record. Registry creates the SREG that catalogs and references that certification record.

This is one interoperability path. Registry may catalog records from every approved Suite institution.

Long-Term Purpose

Registry exists so records remain understandable even when:

  • public pages move;
  • repositories change;
  • schemas evolve;
  • Source Records receive new versions;
  • status changes;
  • institutions mature;
  • records are superseded, revoked, retired, or archived;
  • new Suite systems are introduced.

Registry preserves the durable identity and structured context needed to find and interpret those records later.

What Registry Does Not Do

  • Registry does not certify subjects.
  • Registry does not create Certification Outcomes.
  • Registry does not create attestations.
  • Registry does not rewrite Source Records.
  • Registry does not replace Source-System Identifiers.
  • Registry does not create ownership or legal rights.
  • Registry does not create regulatory approval.
  • Registry does not establish truth merely by registration.
  • Registry does not absorb institutional authority.
  • Registry does not require blockchain publication.
Registration creates a Registry Entry. It does not create the authority of the source.

Purpose Principle

Registry exists to preserve the public structure around authoritative records: their identity, source, classification, relationships, versions, institutional condition, and long-term discoverability.

The source holds authority. The SREG preserves the path back to it.
Back to Registry → Open Entry Model → Open Integration →

Registry preserves identity, context, and the path back to authority.