Satoshium Registry Publication

Canonical Publication Model

Official publication should preserve one consistent Registry object across all supported forms.

Reusable SREG Publication Package

A normal production SREG is published through a reusable four-file package using the Registry Identifier as the directory name.

• index.html — Registration Overview;
• registry-entry.html — canonical human-readable SREG;
• record.json — canonical machine-readable SREG;
• README.md — directory-level documentation.

Publication Requirements

• successful Validation outcome;
• permanent Registry Identifier;
• canonical human-readable URL;
• canonical machine-readable URL;
• declared Registry Entry Version;
• declared Record Type;
• Source Institution attribution;
• Source-System Identifier, when available;
• canonical source reference;
• Registry Status;
• Registry Lifecycle State;
• provenance information;
• relationship information;
• version and correction references;
• publication date;
• validation result and date;
• consistent official forms;
• complete reusable four-file SREG package;
• discovery through Registered Items.

Human-Readable SREG

The public SREG page should make the following information easy to identify:

• Registry Identifier;
• title;
• Registry Record Type;
• Source Institution;
• Authoritative Source Record;
• Source-System Identifier;
• canonical source link;
• Registry Status;
• Registry Lifecycle State;
• Source-Record Status, when available;
• Registry Entry Version;
• Source-Record Version, when available;
• provenance summary;
• relationships;
• validation result;
• correction and history references;
• downloadable machine-readable form.

Machine-Readable SREG

The machine-readable form should:

• conform to the declared SREG Base Schema;
• conform to the applicable Record-Type Profile;
• declare schema and profile versions;
• use approved controlled values;
• preserve identifier domains;
• preserve source attribution;
• preserve provenance and relationships;
• preserve status and lifecycle distinctions;
• preserve correction and version history;
• parse successfully;
• agree with the human-readable form.

Cross-Format Publication Consistency

Official forms should agree on all canonical fields.

• Registry Identifier;
• title;
• Record Type;
• Source Institution;
• Source-System Identifier;
• canonical source reference;
• Registry Status;
• Registry Lifecycle State;
• Registry Entry Version;
• Source-Record Version;
• relationships;
• provenance;
• validation outcome;
• publication and correction dates.

Canonical URLs

Every published SREG should have a stable canonical Registry location that resolves through Registered Items.

The canonical human-readable SREG and machine-readable SREG are published within the same Registry Identifier directory.

Identifier Resolution

A Registry Identifier should resolve to:

• the current canonical SREG;
• the current Registry Entry Version;
• the current Registry Status;
• the current Registry Lifecycle State;
• the machine-readable form;
• the Authoritative Source Record;
• prior versions;
• correction records;
• supersession or successor notices;
• archival references when the entry is no longer active.

Operational Publication Sequence

Publication is operationally complete when the validated SREG package resolves through its production Registry location and is discoverable through Registered Items.

Publication Readiness

A SREG should be considered publication-ready only when:

• required validation is complete;
• blocking defects are resolved;
• conditions and warnings are documented;
• canonical fields are complete;
• official formats agree;
• source references are attributable;
• relationships and provenance are coherent;
• status and lifecycle notices are accurate;
• version fields are declared;
• publication artifacts are generated;
• canonical URLs are assigned;
• publication authority is identified.

Publication Authority

Registry is authoritative for publishing SREGs and Registry-owned metadata.

Publication authority should be documented through:

• publication workflow;
• responsible Registry role or process;
• publication date;
• validated Registry Entry Version;
• release or deployment reference;
• governing rules and policy versions;
• applicable restrictions or notices.

Publication Record

Every material publication should preserve:

• Registry Identifier;
• Registry Entry Version;
• publication date and time;
• publication authority;
• canonical human-readable URL;
• canonical machine-readable URL;
• published artifact references;
• validation outcome;
• validation date;
• status and lifecycle at publication;
• schema and profile versions;
• release notes or change summary;
• superseded publication reference, when applicable.

Publication Notices

Public notices should be used when material context affects interpretation.

Potential notices include:

• provisional publication;
• restricted source access;
• source unavailable;
• validation warning;
• correction issued;
• superseded entry;
• revoked entry;
• archived entry;
• historical record;
• disputed relationship;
• external-source disclaimer;
• rights or reuse limitation.

Restricted Publication

A SREG may require restricted publication when full release would conflict with:

• privacy requirements;
• intellectual-property rights;
• licensing restrictions;
• safety concerns;
• security requirements;
• contractual obligations;
• controlled-access source conditions;
• institutional policy.

Restricted publication may expose public metadata while withholding or limiting access to the Source Record or selected Registry fields.

External Source Publication

Publication of an external-source SREG should clearly distinguish:

• Registry ownership of the SREG;
• external ownership of the Source Record;
• Source Institution attribution;
• external identifier domains;
• rights and reuse limitations;
• absence of endorsement or affiliation unless explicitly supported;
• availability and access conditions;
• date Registry last verified the source reference.

Publication Updates

A material SREG update should create a new Registry Entry Version and a new publication record.

Updates may be triggered by:

• Source Record version change;
• metadata correction;
• relationship change;
• provenance update;
• Registry Status change;
• Registry Lifecycle transition;
• schema or profile migration;
• canonical source change;
• publication-path change;
• new archival or integrity reference.

Publication Corrections

A correction should preserve:

• prior published value;
• corrected value;
• correction reason;
• correction date;
• correction authority;
• affected Registry Entry Version;
• new Registry Entry Version;
• public correction notice;
• updated machine-readable form;
• historical access to the prior state.

Supersession and Successor Publication

When a SREG is superseded:

• the prior Registry Identifier remains resolvable;
• the prior page displays a supersession notice;
• the successor Registry Identifier is linked;
• the supersession date is preserved;
• the reason or governing event is documented;
• prior versions remain accessible;
• machine-readable relationships are updated;
• the successor does not overwrite the prior identity.

Revoked and Archived Publication

Revoked or archived SREGs should remain discoverable unless publication itself must be restricted or removed under applicable policy.

Their pages should preserve:

• Registry Identifier;
• title;
• historical Registry Entry Version;
• revoked or archived condition;
• effective date;
• reason, when public;
• successor reference, when applicable;
• correction and history references;
• archival source and provenance information.

Publication Withdrawal

Registry may restrict or withdraw public access when required by:

• lawful authority;
• rights violation;
• privacy harm;
• security risk;
• safety risk;
• material deception;
• publication defect;
• governance decision.

Withdrawal should preserve an internal and, when appropriate, public record of:

• Registry Identifier;
• withdrawal date;
• withdrawal authority;
• reason or reason category;
• affected versions;
• replacement or correction path;
• historical resolution behavior.

Publication History

Publication history should preserve:

• first publication;
• every Registry Entry Version;
• release dates;
• change summaries;
• validation outcomes;
• corrections;
• supersession;
• revocation;
• retirement;
• archival transition;
• URL changes;
• withdrawal events;
• republication events.

Publication Validation

Before release, Registry should confirm:

• Validation outcome permits publication;
• canonical URLs are correct;
• Registry Identifier resolves correctly;
• human-readable and machine-readable forms agree;
• required artifacts are available;
• source links are accurate;
• status and lifecycle notices are correct;
• version fields are visible;
• correction and history references are present;
• restricted information is not exposed;
• metadata and canonical tags are correct;
• publication record is complete;
• the SREG is discoverable through Registered Items.

Invalid Publication Conditions

• publication before required Validation;
• missing Registry Identifier;
• incorrect canonical URL;
• unresolved production identifier;
• missing machine-readable form;
• human-readable and machine-readable mismatch;
• incorrect Source Institution attribution;
• broken canonical source reference;
• incorrect Registry Status or Lifecycle State;
• missing version information;
• missing required notice;
• restricted information exposed publicly;
• silent correction or replacement;
• prior identity overwritten during supersession.

Relationship to Validation

Validation determines whether a SREG conforms to Registry requirements.

Publication releases the validated SREG through official Registry channels.

Relationship to Identifiers

Publication resolves the Registry Identifier through stable public locations.

URL changes may require redirects or publication updates, but they must not change the permanent Registry Identifier.

Relationship to Provenance

Publication should expose enough provenance for users and systems to trace the SREG back to the Authoritative Source Record and Source Institution.

Historical publication records become part of Registry Provenance.

Relationship to Lifecycle

Publication presentation should reflect the current Registry Lifecycle State.

• Pending entries should not be presented as active SREGs.
• Active entries should resolve normally.
• Updated entries should expose current and prior versions.
• Superseded entries should identify successors.
• Revoked entries should display revocation notices.
• Archived entries should remain historically discoverable.

Relationship to Chronicle

Material publication events may be recorded through Chronicle when they have institutional or historical significance.

Examples include:

• first public SREG publication;
• major Registry release;
• material correction;
• supersession;
• revocation;
• archival transition;
• publication-policy change.

Relationship to Beacon

Beacon may create signals announcing newly published or materially updated Registry records.

Registry remains authoritative for the SREG. Beacon remains authoritative for its own discovery signal.

What Publication Does Not Establish

• It does not create Source Authority.
• It does not certify the Source Record.
• It does not create an attestation.
• It does not establish legal ownership.
• It does not grant licensing rights.
• It does not establish governmental approval.
• It does not create endorsement or affiliation.
• It does not guarantee permanent source availability.
• It does not make every published field immutable.
• It does not permit silent correction or historical erasure.

Publication Principle

Registry Publication should make validated SREGs discoverable through stable, consistent, version-aware, and historically responsible public forms.