Registry · Corrections & Continuity

Satoshium Registry Corrections

Registry Corrections define how Registry improves Registry-owned information while preserving source authority, transparent version history, and long-term institutional continuity.

A correction may change the SREG. It does not silently rewrite the authoritative source record, its institutional meaning, or the authority of the institution that created it.

Constitutional Position

Registry Corrections operate beneath Satoshium Suite Standards, Suite Methodology, and Suite Interoperability. Corrections must preserve controlled terminology, version distinctions, governance history, source attribution, and institutional separation.

Suite Standards → Registry Policy → Registry Procedure → SREG Correction → Preserved History
Registry corrects Registry-owned information. The Source Institution remains authoritative for changes to the Source Record.

Why Corrections Exist

SREGs may require correction because of inaccurate metadata, broken references, classification errors, version mismatches, incomplete relationships, schema nonconformance, or changes reported by the Source Institution.

Correction Authority

Registry may correct identifiers, classifications, references, relationships, Registry status, lifecycle information, Registry versions, dates, and other Registry-owned metadata.

Source Authority

Registry does not alter the content, outcome, status, or meaning of an Authoritative Source Record. Source changes must be attributed to the originating institution and reflected as source-reported metadata.

Transparency

Material corrections should disclose what changed, why it changed, when it changed, which SREG version was affected, and which version replaced it.

Continuity

Corrections should improve current accuracy without unnecessarily erasing prior versions, references, relationships, or the historical record of the change.

Schema Compliance

Corrections may restore compliance with the Registry Schema Specification, SREG Base Schema, applicable Record-Type Profile, controlled terminology, and published validation requirements.

What Registry May Correct

  • Registry Identifier formatting or assignment errors.
  • Registry Record Type or subtype classification.
  • Titles, recognized names, descriptions, and Registry-authored summaries.
  • Source Institution attribution.
  • Source-System Identifier transcription.
  • Canonical URLs, repository paths, and public references.
  • Registry relationships and relationship types.
  • Registry Status and Registry Lifecycle State.
  • Registry Entry Version and schema-version metadata.
  • Registration, update, supersession, revocation, and archival dates.
  • Machine-readable structure, required fields, and validation errors.
  • Human-readable presentation where meaning must remain unchanged.
A Registry correction may describe a source-record change, but it must not represent that source change as though Registry created or controlled it.

What Registry Does Not Correct

  • Certification Outcomes controlled by Certifier.
  • Certification Status controlled by Certifier.
  • Attestation conclusions controlled by Attestor.
  • Historical event content controlled by Chronicle.
  • Integrity determinations controlled by Anchor.
  • Discovery signals controlled by Beacon.
  • Jurisdiction intelligence controlled by Atlas.
  • Workflow definitions controlled by Navigator.
  • Third-party ownership, legal rights, or external-source content.
When the authoritative source changes, Registry updates the SREG reference, source-reported metadata, relationships, or lifecycle history as appropriate.

Correction Classes

Editorial Correction

A non-substantive correction to spelling, punctuation, formatting, or display that does not alter institutional meaning.

Metadata Correction

A correction to Registry-owned descriptive fields, dates, identifiers, classifications, references, or relationships.

Structural Correction

A correction required to restore schema compliance, machine readability, field organization, or Record-Type Profile conformity.

Source-Reference Correction

A correction to the source location, Source-System Identifier, source version, source status, or Source Institution attribution.

Material Correction

A correction that changes how the SREG is identified, classified, interpreted, related, versioned, or maintained within Registry.

Administrative Correction

A correction to Registry publication, processing, or maintenance metadata that does not change the substance of the Source Record.

Correction Workflow

Registry uses a documented correction process aligned with Suite Methodology Principles.

Issue Identified → Authority Determined → Impact Reviewed → Correction Prepared → Schema Validated → Version Assigned → History Documented → Published

1. Issue Identified

A potential error, omission, broken reference, classification problem, source change, or schema issue is identified.

2. Authority Determined

Registry determines whether the matter belongs to Registry or to the Source Institution.

3. Impact Reviewed

The effect on identifiers, references, relationships, versions, lifecycle, interoperability, and public presentation is evaluated.

4. Correction Prepared

The corrected Registry-owned information is prepared without altering source authority.

5. Schema Validated

The corrected SREG is validated against the applicable schema and Record-Type Profile.

6. Version Assigned

A new SREG version is assigned when the correction is material or otherwise requires versioned publication.

7. History Documented

The correction record preserves the reason, date, affected version, replacement version, and responsible Registry action.

8. Published

Updated human-readable and machine-readable artifacts are published consistently.

Minor Corrections

Minor corrections may include typographical changes, formatting repairs, non-substantive link repairs, or presentation improvements that do not change Registry meaning.

Minor corrections may not require a new semantic version, but they should remain traceable through repository history or another approved audit mechanism.

Major Corrections

Major corrections may include identifier reassignment, Record Type changes, structural revisions, entry merges, entry splits, material relationship changes, or correction of a source-authority error.

Major corrections require explicit documentation, a new SREG version, preserved prior history, and publication reconciliation across all Registry formats.

Versioning and Correction History

Registry distinguishes among SREG version, schema version, Record-Type Profile version, Registry specification version, and Source-Record version.

A correction to the SREG does not necessarily change the Source-Record version. A change to the Source Record does not necessarily change the Registry schema.

Every material correction should preserve: prior SREG version → correction record → replacement SREG version.

Corrections, Supersession, Revocation, and Archival

Not every problem should be handled as a simple correction.

  • Correction improves Registry-owned information.
  • Supersession replaces a SREG or version with a newer one.
  • Revocation withdraws a SREG from active Registry recognition for a documented reason.
  • Archival preserves a SREG that is no longer active.
The selected action should reflect the institutional condition of the SREG and preserve the clearest possible historical record.

Publication Consistency

Corrections must be applied consistently across all official representations of the same SREG.

  • Human-readable Registry Entry page.
  • Machine-readable SREG record.
  • Catalog indexes.
  • Relationship indexes.
  • Version and correction history.
  • Interoperability references.
A correction is incomplete when official Registry formats disagree about the identity, classification, status, version, or source of the same SREG.

Correction Principle

Registry corrections exist to improve Registry accuracy without erasing provenance or assuming source authority.

The objective is not merely to make the current entry appear correct. The objective is to preserve a trustworthy record of what changed and why.

Correct the Registry Entry. Preserve the prior version. Attribute the source. Document the change. Maintain the path back to authority.
Back to Registry → Open Lifecycle → Open Status →
Correction improves the record. Version history preserves the truth of the change.