Registry · Policies

Satoshium Registry Policies

Satoshium Registry Policies define the durable institutional decisions that govern how Registry accepts sources, constructs SREGs, assigns identifiers, preserves provenance, validates records, publishes official forms, manages versions, applies corrections, and protects historical continuity.

Policies establish what Registry requires and permits. Procedures define how those policies are carried out.

Constitutional Position

Registry Policies operate beneath Suite Standards and Suite Methodology and above Registry Procedures and operational workflows.

Suite Standards → Suite Methodology → Registry Rules → Registry Policies → Registry Procedures → Operational Actions
Rules define binding Registry requirements. Policies define durable institutional decisions. Procedures define repeatable implementation.

Why Policies Matter

Policies provide consistent institutional decisions where individual records, source conditions, access limitations, corrections, and exceptions may vary.

The Core Question

Policies ask:

What durable position should Registry apply consistently across comparable cases?

Registry's Responsibility

Registry must publish, version, apply, review, and preserve its policies in a manner consistent with Suite authority and Registry governance.

Registry's Limitation

Registry Policies govern Registry conduct. They do not override Source Institutions, external law, rights holders, or other Suite institutions within their own authority domains.

Policy Framework

Policy Need → Authority Review → Policy Draft → Governance Approval → Publication → Implementation → Review and Versioning

Core Policy Domains

  • Source Authority Policy;
  • Registrability Policy;
  • Identifier Policy;
  • Record-Type Policy;
  • Relationship Policy;
  • Provenance Policy;
  • Validation Policy;
  • Publication Policy;
  • Versioning Policy;
  • Correction Policy;
  • Status Policy;
  • Lifecycle Policy;
  • Restricted-Access Policy;
  • External-Source Policy;
  • Preservation and Archival Policy;
  • Exception Policy;
  • Transparency Policy;
  • Policy Governance Policy.

Normative

Establishes what Registry must, must not, should, or may do.

Durable

Applies beyond a single record or isolated operational decision.

Versioned

Preserves effective versions, prior versions, amendments, and supersession.

Governed

Requires documented authority, approval, publication, and review.

Policy Language

Registry Policies should use consistent normative terms:

  • Must — mandatory requirement.
  • Must Not — prohibited action or condition.
  • Should — expected practice unless documented circumstances justify departure.
  • Should Not — generally prohibited practice unless documented circumstances justify departure.
  • May — permitted action or option.
Normative language should be interpreted consistently across policy, procedure, validation, and governance materials.

Source Authority Policy

  • Registry must identify the Source Institution for every operational SREG.
  • Registry must preserve the Authoritative Source Record when identifiable.
  • Registry must not treat custody, mirroring, or hosting as Source Authority without evidence.
  • Registry must preserve authority changes, succession, and archival custody.
  • Registry must not absorb source-domain authority through registration.
  • Registry may publish external-source SREGs when authority and provenance are sufficiently documented.

Registrability Policy

  • Registry must determine Registrability before assigning an operational Registry Identifier.
  • Registrability must consider authority, identity, scope, Record Type, minimum metadata, provenance, and durable relevance.
  • Registry must not register records that cannot be distinguished from duplicates, fragments, or unsupported claims.
  • Conditional or provisional registration must preserve visible limitations.
  • Restricted records may be registrable even when full public access is not permitted.

Identifier Policy

  • Every operational SREG must receive one permanent Registry Identifier.
  • Registry Identifiers must be unique and must not be reused.
  • Registry Identifier and Source-System Identifier must remain distinct.
  • Aliases must not replace the canonical Registry Identifier.
  • Superseded and archived identifiers must remain resolvable.
  • Identifier corrections must preserve prior values and public history.

Record-Type Policy

  • Every SREG must receive one approved primary Registry Record Type.
  • Record Type must describe the Registry classification, not redefine the Source Record.
  • Record-Type Profiles must define type-specific requirements.
  • Registry must not force a record into an inaccurate type for convenience.
  • Reclassification must preserve prior classifications and version history.

Relationship Policy

  • Material relationships must be typed, directional, and attributable.
  • Identifier domains must be explicit.
  • Inverse relationships must be governed rather than assumed.
  • Symmetry must be explicitly defined.
  • Relationships must not imply ownership, endorsement, affiliation, or authority transfer unless supported.
  • Historical and corrected relationships must remain discoverable.

Provenance Policy

  • Every SREG must preserve a traceable path to its Authoritative Source Record and Source Institution.
  • Registry must distinguish original, derived, mirrored, and archived records.
  • Custody and authority must remain separate.
  • Derived artifacts must identify their canonical source.
  • Unavailable sources must retain archival and last-known context.
  • Provenance corrections must preserve prior assertions.

Validation Policy

  • Production SREGs must be validated before official publication.
  • Validation must apply declared rules, schemas, profiles, policies, and controlled values.
  • Validation must distinguish blocking errors, warnings, exceptions, and informational findings.
  • Human-readable and machine-readable forms must agree.
  • Material changes must trigger appropriate revalidation.
  • Validation must not be represented as certification of the Source Record.

Publication Policy

  • Official publication must follow required Validation.
  • Every published SREG must expose stable canonical resolution.
  • Human-readable and machine-readable forms must represent the same Registry object.
  • Publication notices must make material limitations visible.
  • Corrections and supersession must not erase prior publication states.
  • Revoked and archived SREGs should remain historically discoverable unless access must be restricted.

Versioning Policy

  • Every published SREG must declare a Registry Entry Version.
  • Registry Entry Version and Source-Record Version must remain separate.
  • Version increments must reflect the scale and meaning of change.
  • Prior Registry Entry Versions must remain discoverable.
  • Rollbacks must be recorded as accountable events.
  • Schema, profile, policy, procedure, and controlled-value versions must be identifiable.

Correction Policy

  • Material errors must be corrected transparently.
  • Corrections must preserve prior values, reasons, dates, authority, and affected versions.
  • Corrections must be reflected across official publication forms.
  • Silent correction of material Registry content is prohibited.
  • Correction records should remain publicly discoverable when publication is public.
  • Correction must not be used to erase historical accountability.

Status Policy

  • Registry Status must use approved controlled values.
  • Registry Status must remain separate from Source-Record Status.
  • Certification Status and Attestation Status must remain institution-owned.
  • Status changes must be dated and attributable.
  • Historical statuses must remain discoverable.
  • Public presentation must reflect the current Registry Status accurately.

Lifecycle Policy

  • Registry Lifecycle State must use approved controlled values.
  • Lifecycle transitions must follow approved rules.
  • Supersession must identify successor records when applicable.
  • Revocation, retirement, and archival transitions must preserve history.
  • Lifecycle changes may require new Registry Entry Versions and revalidation.
  • Lifecycle State must not be collapsed into Registry Status.

Restricted-Access Policy

Registry may restrict access when required by:

  • privacy;
  • rights or licensing;
  • safety;
  • security;
  • contractual obligation;
  • controlled-source conditions;
  • lawful authority;
  • institutional policy.

Restriction should be limited to what is necessary and should preserve public metadata and accountable history when appropriate.

External-Source Policy

  • External ownership and Source Institution attribution must be explicit.
  • Registry must not imply endorsement or affiliation without support.
  • External identifiers and Registry identifiers must remain distinct.
  • Rights and reuse conditions must be preserved.
  • Source availability should be periodically reviewable.
  • External-source records may be restricted, archived, or marked unavailable without erasing provenance.

Preservation and Archival Policy

  • Registry should preserve prior versions and material publication states.
  • Archived SREGs should remain resolvable when lawful and appropriate.
  • Unavailable Source Records should retain last-known references and archival context.
  • Preservation copies must be identified as archival, mirrored, or derived.
  • Archival custody must not be represented as original Source Authority.
  • Material loss of access should be documented.

Exception Policy

An exception may be approved only when:

  • the governing requirement is identified;
  • the reason is documented;
  • the approving authority is identified;
  • scope is limited;
  • duration or review date is defined;
  • risk and impact are considered;
  • the exception is visible in Validation and Publication when material;
  • the exception does not exceed Registry authority.
Exceptions permit governed departures. They do not silently rewrite policy.

Transparency Policy

  • Registry should publish its current policies.
  • Material policy changes should include effective dates and change summaries.
  • Prior policy versions should remain discoverable.
  • Public SREGs should expose material warnings, restrictions, corrections, and historical conditions.
  • Governance exceptions should be disclosed when they materially affect interpretation.
  • Registry should distinguish current requirements from historical requirements.

Policy Document Requirements

Every formal Registry policy should identify:

  • policy title;
  • policy identifier;
  • policy version;
  • authority;
  • approval date;
  • effective date;
  • scope;
  • purpose;
  • normative requirements;
  • exceptions;
  • related Rules;
  • related Procedures;
  • review date;
  • superseded policy reference;
  • change history.

Illustrative Policy Record

policy_identifier: "SREG-POL-PUBLICATION" policy_title: "Registry Publication Policy" policy_version: "1.0.0" authority: "Satoshium Registry" effective_date: "2026-08-02" status: "active"
Final policy identifiers, field names, and controlled values remain subject to Registry governance.

Policy Lifecycle

Draft → Review → Approved → Active → Amended → Superseded or Retired → Archived

Policy lifecycle values should remain separate from SREG Lifecycle States, although comparable governance patterns may apply.

Draft

Proposed policy not yet approved for operational use.

Active

Current approved policy governing applicable Registry activity.

Superseded

Replaced by a newer policy while remaining historically discoverable.

Retired

No longer operational and not replaced by a direct successor.

Policy Versioning

Policy changes should preserve:

  • prior policy version;
  • new policy version;
  • change date;
  • effective date;
  • approval authority;
  • change summary;
  • affected Procedures;
  • affected schemas and profiles;
  • migration or transition requirements;
  • supersession reference;
  • historical publication.

Policy Review

Policies should be reviewed when:

  • Suite Standards or Methodology change;
  • Registry Rules change;
  • new Record Types are introduced;
  • operational gaps become visible;
  • exceptions recur;
  • Validation identifies systemic defects;
  • legal, rights, privacy, safety, or security conditions change;
  • interoperability requirements change;
  • source or publication architecture changes materially;
  • scheduled review date arrives.

Policy Validation

Before approval or republication, a policy should be checked for:

  • authority;
  • scope;
  • consistency with Suite Standards and Methodology;
  • consistency with Registry Rules;
  • consistency with other Registry Policies;
  • clear normative language;
  • defined exceptions;
  • implementable Procedures;
  • version and effective date;
  • publication readiness;
  • historical continuity.

Policy Conflicts

When policies conflict, Registry should:

  • identify the conflicting provisions;
  • determine governing authority and hierarchy;
  • apply the more specific policy when appropriate;
  • apply the newer approved policy when supersession is clear;
  • escalate unresolved conflicts to Governance;
  • document interim treatment;
  • correct or supersede the conflicting policy;
  • preserve the historical record.

Relationship to Rules

Registry Rules establish binding requirements for Registry operation.

Policies interpret and organize durable institutional positions within those Rules.

Rules establish requirements. Policies establish consistent institutional decisions.

Relationship to Procedures

Procedures convert policies into repeatable operational steps.

Policy → Required Institutional Position → Procedure → Operational Action

A Procedure may implement a Policy but should not silently expand or contradict it.

Relationship to Governance

Registry Governance should control:

  • policy authority;
  • approval;
  • versioning;
  • effective dates;
  • exceptions;
  • conflict resolution;
  • review cycles;
  • supersession;
  • retirement;
  • publication;
  • historical preservation.

What Policies Do Not Establish

  • They do not override Suite Standards or Methodology.
  • They do not replace Registry Rules.
  • They do not replace operational Procedures.
  • They do not transfer Source Authority.
  • They do not certify Source Records.
  • They do not create attestations.
  • They do not override lawful authority or rights restrictions.
  • They do not permit silent exceptions.
  • They do not erase prior policy versions.
  • They do not expand Registry authority beyond its institutional scope.

Policy Principle

Registry Policies should translate enduring Registry principles into consistent, reviewable, versioned institutional decisions that can be implemented through clear Procedures.

Standards define expectations. Methodology defines implementation. Rules establish requirements. Policies establish durable decisions. Procedures carry them out.
Back to Registry → Open Rules → Open Procedures →
Durable institutions turn principles into consistent decisions before those decisions become operational actions.