Registry · Canonical Registration / Public Catalog

Satoshium Registry

Satoshium Registry is the Suite institution responsible for Canonical Registration / Public Catalog. It creates and governs Satoshium Registry Entries (SREGs) that identify, classify, reference, and preserve discoverability of authoritative source records.

Registry catalogs authoritative records without taking authority away from the institutions that created them. Its canonical operational object is the Satoshium Registry Entry, or SREG.

Institutional Position

Registry is one of the eight current sovereign Suite institutions. Suite Standards provide shared expectations, Suite Methodology provides shared implementation principles where applicable, and Suite Interoperability governs exchange while remaining subordinate to settled architecture. Registry governs its own institutional implementation within that constitutional boundary.

Registry → Canonical Registration / Public Catalog → Satoshium Registry Entry (SREG)

Authority follows the governed subject. Source Institutions retain authority over their Source Records. Registry retains authority over the SREG, its Registry Identifier, classification, Registry-owned metadata, relationships, versions, status, lifecycle, publication, Catalog presentation, Corrections, and History.

Suite constraint ≠ Suite ownership. Reference ≠ authority transfer.

Institutional Foundation

These pages define why Registry exists, what it governs, the vocabulary it uses, and the institutional controls that govern Registry-owned work.

Foundation

Purpose

Defines why Registry exists, the public-record problem it addresses, and its institutional mission.

Open Purpose →

Foundation

Scope

Defines what Registry may govern, register, publish, preserve, and what remains outside Registry authority.

Open Scope →

Foundation

Definitions

Establishes the canonical vocabulary and distinctions used across every Registry framework and record.

Open Definitions →

Public Guidance

FAQ

Answers common questions about SREG identity, source authority, registrability, schemas, Validation, Publication, Lifecycle, interoperability, and Registry operations.

Open FAQ →

Foundation

Rules

Defines binding Registry requirements for identity, authority, classification, continuity, and preservation.

Open Rules →

Foundation

Policies

Defines governed institutional principles, decision criteria, and operating conditions beneath Registry Rules.

Open Policies →

Foundation

Procedures

Defines the repeatable operational sequences through which Registry performs its authorized work.

Open Procedures →

Foundation

Governance

Defines Registry-owned authority, roles, approvals, decision rights, exceptions, conflicts, and institutional accountability. Constitutional changes remain governed by Suite Governance.

Open Governance →

Foundation

Controlled Values

Defines the governed codes, labels, statuses, outcomes, relationship types, and other approved values.

Open Controlled Values →

Canonical Records and Structure

These pages define the SREG, its classifications, schemas, authority references, identifiers, relationships, and provenance.

Records

Explains SREGs, supporting Registry Records, Source Records, and the larger Registry record architecture.

Open Records →

Records

Entry Model

Defines the SREG as Registry’s canonical operational object and its relationship to authoritative sources.

Open Entry Model →

Records

Record Types

Defines the governed classifications assigned to SREGs and the boundaries of each Registry record class.

Open Record Types →

Records

Schemas

Defines the SREG Base Schema, Registry Schema Specification, and Record-Type Profile architecture. Schema ≠ canonical object.

Open Schemas →

Authority

Source Authority

Defines how Registry identifies and preserves the authority responsible for each Source Record.

Open Source Authority →

Admission

Registrability

Defines how Registry determines whether a specific object qualifies for registration as a SREG.

Open Registrability →

Identity

Identifiers

Defines permanent Registry Identifiers, Source-System Identifiers, namespaces, states, and resolution.

Open Identifiers →

Context

Relationships

Defines typed, directed, governed connections among SREGs, sources, institutions, versions, and artifacts.

Open Relationships →

Context

Provenance

Defines origin, Source Institution, custody, derivation, generation, integrity, and preservation lineage.

Open Provenance →

Operational Control

These pages govern how SREGs are validated, published, versioned, corrected, and maintained through Registry Status and Lifecycle.

Control

Validation

Defines Registry validation of SREG conformance to Rules, Policies, schemas, profiles, and Controlled Values. Registry validation does not establish source validity or source authority.

Open Validation →

Control

Publication

Defines official human-readable and machine-readable release, readiness, notices, restrictions, and resolution.

Open Publication →

Control

Versioning

Defines Registry Entry Versions and their separation from Source-Record, schema, profile, and Catalog versions.

Open Versioning →

Control

Corrections

Defines transparent correction of Registry-owned records while preserving prior states and source authority.

Open Corrections →

Control

Status

Defines the current Registry condition of a SREG and its distinction from source and institutional statuses.

Open Status →

Control

Lifecycle

Defines the stages and permitted transitions through which a SREG moves during its institutional life.

Open Lifecycle →

Public Discovery and Institutional Memory

These pages make Registry records discoverable, historically accountable, transparent, and interoperable across the Suite.

Public Directory

Registered Items

Provides the public directory of completed Satoshium Registry Entries and resolves each listed item to its canonical SREG package.

Open Registered Items →

Public Layer

Catalog

Defines how published SREGs are browsed, searched, filtered, resolved, related, and historically presented.

Open Catalog →

Institutional Memory

History

Defines the chronological, versioned, attributable, and resolvable history of Registry objects and Registry-owned decisions while preserving current-vs-historical status.

Open History →

Accountability

Transparency

Defines how Registry makes authority, conditions, limitations, Corrections, versions, and history visible.

Open Transparency →

Suite Connection

Integration

Defines how Registry exchanges and references records across Suite institutions without merging authority. Interoperability may constrain exchange; it does not reallocate authority.

Open Integration →

Governance Boundary

Registry governs Registry-owned subjects within its settled institutional authority. Institution-owned material changes remain with Registry, subject to Suite coherence review where applicable. Changes to institutional role, canonical ownership, Suite membership, authority allocation, or constitutional position require Suite Governance / Architecture Reconciliation.

CHANGE WITHIN AUTHORITY → may remain institutional.
CHANGE TO AUTHORITY → requires Suite Governance.
NEW CAPABILITY ≠ NEW INSTITUTION.

Interoperability Boundary

Registry may participate in exercised production lineages, but those relationships do not create a mandatory Suite pipeline.

CONCEPTUAL SEQUENCE ≠ MANDATORY PIPELINE.
EXERCISED LINEAGE ≠ MANDATORY ARCHITECTURE.
PRODUCTION-PROVEN ≠ CONSTITUTIONALLY REQUIRED.
INTEROPERABILITY FAILURE ≠ SOURCE INVALIDITY.
COMPATIBILITY REVIEW ≠ GOVERNANCE VETO.

Canonical Operational Hierarchy

Registry development centers on a four-layer model that preserves institutional separation while creating a durable public catalog.

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

Registry owns the SREG and Registry-controlled representation. The Source Institution retains authority over the Authoritative Source Record. Shared structure, references, or interoperability do not create shared ownership.

Registry Method

Registry applies applicable Suite Methodology principles through its own repeatable institutional process for review, machine readability, interoperability, preservation, and maintenance.

Identify or receive source → confirm Source Authority → determine Scope and Registrability → assign Record Type and Registry Identifier → preserve Source-System Identifier → establish provenance and relationships → construct and validate SREG → publish → maintain versions, Status, Lifecycle, Corrections, Catalog presence, History, and Transparency.

Suite Relationship

Registry strengthens Satoshium Suite by connecting authoritative institutional objects without replacing the institutions that created them.

Atlas provides Authoritative Intelligence through Jurisdiction Intelligence Packages.
Certifier performs Operational Certification and owns Certification Packages.
Registry performs Canonical Registration / Public Catalog and owns SREGs.
Chronicle performs Historical Preservation through Chronicle Entries.
Anchor performs Integrity Preservation through Integrity References.
Beacon performs Discovery & Signals through Discovery Signals; Discovery Metadata remains supporting structure.
Attestor performs Governed Attestation & Rule-Constrained Evaluation and owns Attestations and Trust Statements.
Navigator performs Workflow Definition / Orchestration and owns Navigator Workflow Definitions.