Registry · Institutional Rules

Satoshium Registry Rules

Registry Rules establish the foundational institutional requirements governing how Satoshium Registry Entries, or SREGs, are identified, classified, related, versioned, corrected, published, maintained, and preserved.

Rules define Registry obligations and authority boundaries. Policies and procedures implement those rules through repeatable operational controls.

Constitutional Position

Suite Standards → Suite Methodology → Suite Interoperability → Registry Rules → Registry Policies → Registry Procedures → Published SREG
Registry Rules are subordinate to Suite Standards and Suite Methodology. They govern Registry implementation without redefining Suite-wide authority.

Rule 1 — Registry Governs the SREG

Registry is authoritative for the Satoshium Registry Entry and Registry-owned information.

Registry authority includes:

  • Registry Identifier;
  • Registry Record Type;
  • Registry Status;
  • Registry Lifecycle State;
  • Registry Entry Version;
  • Registry relationships;
  • Registry corrections;
  • Registry publication;
  • Registry archival history.

Rule 2 — Source Authority Must Be Preserved

The Source Institution retains authority over the Authoritative Source Record, its content, Source-System Identifier, source version, source status, institutional meaning, ownership, and rights.

Rule 3 — The SREG Must Not Replace the Source

A SREG catalogs an Authoritative Source Record. It must not silently become a substitute for a missing, inaccessible, or undefined Source Record.

Rule 4 — Every SREG Must Be Identifiable

Every operational SREG must have a unique Registry Identifier, title, Record Type, source attribution, status, lifecycle state, version, and public reference context.

Rule 5 — Identifiers Must Remain Distinct

The Registry Identifier identifies the SREG. The Source-System Identifier identifies the Authoritative Source Record. One must not replace or overwrite the other.

Rule 6 — Every SREG Must Have One Primary Record Type

Each operational SREG must receive one approved primary Registry Record Type. Secondary classifications may supplement but must not conflict with it.

Rule 7 — Record Types Require Governance

New Record Types must be approved through documented Registry governance and should have a corresponding Record-Type Profile before operational use.

Rule 8 — Relationships Must Be Typed

Relationships among SREGs, Source Records, institutions, certifications, events, attestations, signals, workflows, and integrity references must use approved types and preserve direction where applicable.

Rule 9 — Status Domains Must Remain Separate

Registry Status must remain distinct from Source-Record Status, Certification Status, attestation status, tool status, and other source-controlled status domains.

Rule 10 — Lifecycle Domains Must Remain Separate

Registry Lifecycle State describes the condition of the SREG. It must not replace the lifecycle or institutional condition of the Source Record.

Rule 11 — Versions Must Be Independently Traceable

Registry Entry, Source Record, schema, profile, specification, Standards, and Methodology versions must remain distinguishable and traceable.

Rule 12 — Official Forms Must Agree

Human-readable and machine-readable forms of the same SREG must agree on identity, classification, source, status, lifecycle, versions, references, relationships, and dates.

Rule 13 — Registrability Must Be Determined

Registry may create a SREG only when:

  • the Source Institution is identifiable;
  • the Authoritative Source Record is identifiable;
  • sufficient provenance exists;
  • an approved Record Type applies;
  • required references and relationships can be established;
  • the SREG can satisfy the applicable schema and profile;
  • no unresolved authority conflict prevents publication.
Registrability is a Registry determination. It is not certification, attestation, endorsement, ownership, or legal recognition.

Rule 14 — Provenance Must Be Preserved

Every operational SREG must preserve sufficient information to identify where the Source Record came from, who controls it, and how the public can locate it.

Rule 15 — References Must Be Durable

Canonical source references, public pages, repository paths, machine-readable records, archival locations, and supporting institutional artifacts should be preserved whenever available.

Rule 16 — History Must Not Be Silently Erased

Material prior versions, corrections, updates, supersession, revocation, retirement, and archival history must remain discoverable unless law, privacy, safety, or security requires removal.

Rule 17 — Updates and Corrections Must Remain Distinct

Updates reflect new or changed information. Corrections repair Registry-owned errors. One must not be used to conceal the other.

Rule 18 — Retirement Must Not Mean Disappearance

Superseded, revoked, retired, or archived SREGs should remain historically discoverable with replacement, successor, or archival references where applicable.

Rule 19 — Deletion Is Exceptional

Registry should normally prefer correction, update, supersession, revocation, retirement, archival, or redaction over deletion.

Rule 20 — Validation Is Required

Operational SREGs must satisfy the SREG Base Schema, applicable Record-Type Profile, approved controlled values, relationship rules, version requirements, and publication consistency checks.

Rule 21 — Registration Does Not Create Authority

Registration does not create certification, attestation, ownership, rights, governmental recognition, verification, endorsement, affiliation, or truth.

Schema Rule

Suite Schema Standard → Registry Schema Specification → SREG Base Schema → Record-Type Profile → Published SREG

Registry Record Types must extend one shared SREG architecture through controlled profiles rather than create unrelated record models.

Operational Rule

Identify or Receive Source Record → Confirm Source Authority → Determine Registrability → Assign Record Type → Assign Registry Identifier → Establish References and Relationships → Construct SREG → Validate → Publish → Maintain Lifecycle, Versions, Corrections, and History

Policies define how these rules apply to creation, update, correction, and retirement. Procedures define the repeatable steps used to carry them out.

Interoperability Rule

Registry must connect Suite institutions without absorbing their authority.

Atlas, Certifier, Chronicle, Anchor, Beacon, Attestor, and Navigator retain authority over their own canonical objects. Registry creates the SREG that catalogs and relates those objects.

Interoperability connects authority. It does not collapse it.

Rule Governance

Registry Rules should be reviewed when:

  • Suite Standards change;
  • Suite Methodology changes;
  • Suite Interoperability changes;
  • Registry authority boundaries change;
  • new Record Types are introduced;
  • schemas change materially;
  • identifier architecture changes;
  • lifecycle or status frameworks change;
  • repeated policy conflicts reveal ambiguity;
  • new Suite institutions are introduced.

Prior rule versions should remain preserved and discoverable.

Registry Rule Philosophy

Registry Rules exist to preserve institutional coherence.

Preserve source authority. Create durable SREG identity. Keep identifiers, statuses, lifecycles, versions, and responsibilities distinct. Preserve history. Publish consistently.
Back to Registry → Open Policies → Open Procedures →
Preserve authority. Preserve identity. Preserve history. Publish consistently.