Registry · Transparency

Satoshium Registry Transparency

Satoshium Registry Transparency defines how Registry makes its authority, rules, policies, procedures, schemas, decisions, validation outcomes, publication conditions, corrections, versions, history, limitations, and institutional boundaries visible and accountable.

Transparency allows users and systems to understand not only what Registry publishes, but how Registry reached, maintained, qualified, corrected, or limited that publication.

Constitutional Position

Transparency operates across the entire Registry architecture and connects Governance, Policies, Procedures, Validation, Publication, Versioning, Corrections, Catalog, and History.

Authority and Rules → Decisions and Procedures → Validation and Publication → Notices, Corrections, and History → Public Accountability
Transparency reveals Registry conduct. It does not require disclosure of information that must remain restricted.

Why Transparency Matters

Registry trust depends on visible authority, clear rules, accurate notices, preserved history, and honest disclosure of limitations and uncertainty.

The Core Question

Transparency asks:

What must Registry make visible so that its records, decisions, limitations, and changes can be understood and evaluated?

Registry's Responsibility

Registry must publish or preserve sufficient information to explain the authority, structure, condition, history, and limitations of its records and operations.

Registry's Limitation

Transparency must respect privacy, rights, safety, security, contractual, lawful, and institutional restrictions.

Canonical Transparency Model

Registry Action or Record → Required Disclosure → Public or Restricted Presentation → Resolvable Evidence and History

Transparency Domains

  • institutional authority;
  • Registry scope and limitations;
  • Rules;
  • Policies;
  • Procedures;
  • Governance Decisions;
  • schemas and Record-Type Profiles;
  • Controlled Values;
  • Source Authority review;
  • Registrability decisions;
  • identifier assignment and resolution;
  • relationships and provenance;
  • Validation outcomes;
  • Publication conditions;
  • Corrections;
  • Versioning;
  • Registry Status and Lifecycle;
  • Catalog inclusion and filtering;
  • History and archival preservation;
  • exceptions, conflicts, restrictions, and withdrawals.

Visible

Material Registry authority, conditions, and changes should be discoverable.

Attributable

Decisions and actions should identify the responsible authority or process.

Qualified

Warnings, restrictions, uncertainty, and limitations should be disclosed.

Historically Preserved

Current presentation should not erase prior states or material institutional history.

Transparency Requirements

A transparent Registry should make visible, where appropriate:

  • who controls the Registry object;
  • who controls the Source Record;
  • which Rules, Policies, Procedures, schemas, and profiles apply;
  • which versions apply;
  • what Validation occurred;
  • what limitations or warnings remain;
  • what changed from the prior version;
  • what corrections were issued;
  • what relationships and provenance support the record;
  • what restrictions affect publication or access;
  • what historical states remain resolvable;
  • what Registry does not claim.

Institutional Authority Transparency

Registry should make clear:

  • that Registry owns SREGs and Registry-controlled metadata;
  • that Source Institutions retain authority over their Source Records;
  • that Certifier controls certification outcomes and artifacts;
  • that Attestor controls attestations and trust statements;
  • that Chronicle controls Chronicle-created event records;
  • that other Suite institutions retain authority within their domains;
  • that registration does not transfer ownership or authority.

Scope and Limitation Transparency

Registry should clearly disclose:

  • what Registry records;
  • what Registry does not record;
  • what Registry validates;
  • what Registry does not certify;
  • what Registry publication establishes;
  • what Registry publication does not establish;
  • where Source Authority remains external;
  • where source availability is uncertain;
  • where rights, privacy, safety, or security limit disclosure.

Rules, Policies, and Procedures Transparency

Registry should publish or preserve access to:

  • current Registry Rules;
  • current Registry Policies;
  • current Registry Procedures;
  • versions and effective dates;
  • change summaries;
  • superseded versions;
  • applicable exceptions;
  • review and amendment history.
Current requirements explain present operation. Prior versions explain historical treatment.

Governance Transparency

Material Governance should expose:

  • decision identifier;
  • decision title;
  • authority;
  • decision date;
  • effective date;
  • scope;
  • decision summary;
  • affected Registry materials;
  • conditions or exceptions;
  • superseded decision references;
  • implementation status;
  • historical record.

Schema and Controlled-Value Transparency

Registry should make discoverable:

  • SREG Base Schema Version;
  • Record-Type Profile Version;
  • required fields;
  • optional fields;
  • Controlled-Value Set Versions;
  • canonical codes and labels;
  • definitions;
  • deprecated values;
  • retired values;
  • migration requirements;
  • compatibility limitations.

Source Authority Transparency

A published SREG should make clear:

  • Source Institution;
  • Authoritative Source Record;
  • Source-System Identifier;
  • source version, when available;
  • canonical source location;
  • authority-review outcome;
  • authority conditions or conflicts;
  • custody or archival distinctions;
  • date Registry last verified the source reference.

Registrability Transparency

Registry may disclose:

  • Registrability Outcome;
  • conditions;
  • provisional status;
  • restriction basis;
  • duplicate or conflict findings;
  • Record-Type determination;
  • review date;
  • reconsideration or final disposition.

Internal evidence may remain restricted where disclosure would create legitimate harm.

Identifier Transparency

Registry should make clear:

  • Registry Identifier;
  • Source-System Identifier;
  • identifier domain;
  • identifier state;
  • canonical resolution path;
  • aliases;
  • prior canonical paths;
  • supersession relationships;
  • archival resolution;
  • identifier corrections.

Relationship Transparency

Material relationships should expose:

  • source and target identifiers;
  • identifier domains;
  • Relationship Type;
  • direction;
  • Relationship Authority;
  • Relationship Status;
  • version and temporal context;
  • supporting evidence, when public;
  • disputes, corrections, or supersession.

Provenance Transparency

Registry should expose enough provenance to trace a SREG to:

  • Source Institution;
  • Authoritative Source Record;
  • Source-System Identifier;
  • source version;
  • source publication date;
  • canonical source reference;
  • custody or archive;
  • derived-artifact lineage;
  • generation manifest or integrity reference;
  • source availability condition.

Validation Transparency

Registry should disclose:

  • Registry Entry Version validated;
  • validation date;
  • Validation Outcome;
  • blocking errors, when unresolved;
  • warnings;
  • approved exceptions;
  • material informational findings;
  • schema and Profile Versions applied;
  • revalidation status;
  • Validation limitations.
Validation transparency should not imply that Registry has certified the Source Record.

Publication Transparency

Published SREGs should disclose:

  • publication date;
  • publication authority;
  • Registry Entry Version;
  • canonical human-readable URL;
  • canonical machine-readable URL;
  • Publication Readiness Outcome;
  • notices and restrictions;
  • Correction references;
  • supersession or archival references;
  • publication history.

Version Transparency

Registry should distinguish and expose:

  • Registry Entry Version;
  • Source-Record Version;
  • SREG Base Schema Version;
  • Record-Type Profile Version;
  • Rules, Policy, and Procedure Versions;
  • Controlled-Value Set Versions;
  • change classification;
  • change summary;
  • prior and next versions;
  • rollback or migration history.

Correction Transparency

Material Corrections should disclose:

  • affected Registry Identifier;
  • affected Registry Entry Version;
  • prior value;
  • corrected value;
  • reason;
  • Correction Authority;
  • correction date;
  • supporting evidence, when public;
  • new Registry Entry Version;
  • Correction Record or notice.
Material Corrections must not be silent.

Status and Lifecycle Transparency

Registry should expose:

  • current Registry Status;
  • current Registry Lifecycle State;
  • prior Status and Lifecycle values;
  • transition date;
  • transition authority;
  • reason;
  • effective date;
  • successor or archival references;
  • related notices;
  • historical resolution.

Catalog Transparency

Registry should explain:

  • Catalog inclusion requirements;
  • searchable fields;
  • filters and Controlled Values;
  • ordering rules;
  • current and historical views;
  • restricted indexing;
  • featured or highlighted conditions;
  • Catalog Version;
  • records removed from current views;
  • machine-readable Catalog publication.
Catalog ordering or prominence must not imply endorsement, quality, rank, or substantive importance unless explicitly governed and disclosed.

History Transparency

Registry should preserve appropriate visibility into:

  • material History Records;
  • current and prior states;
  • History Event Types;
  • chronological sequence;
  • authority and effective dates;
  • historical artifacts;
  • Corrections to History Records;
  • restricted historical conditions;
  • Chronicle references, when applicable.

Exception Transparency

Material Governance exceptions should disclose:

  • governing requirement;
  • exception scope;
  • reason;
  • approval authority;
  • effective date;
  • expiration or review date;
  • conditions;
  • compensating controls;
  • effect on Validation or Publication;
  • current exception status.

Restricted supporting detail may remain internal when necessary.

Conflict and Dispute Transparency

Material conflicts or disputes should disclose, when appropriate:

  • affected Registry object or requirement;
  • nature of the conflict;
  • current interim treatment;
  • authority reviewing the matter;
  • public limitations;
  • resolution status;
  • final decision;
  • Correction, amendment, or supersession resulting from the resolution.

Restriction Transparency

When access or publication is restricted, Registry should disclose as much as safely possible:

  • that a restriction exists;
  • restriction category;
  • general authority or basis;
  • scope of restriction;
  • public metadata that remains available;
  • review or expiration condition;
  • whether the restriction affects source access, Registry fields, artifacts, or history.
Transparency about a restriction does not require disclosure of the restricted information itself.

Withdrawal Transparency

When publication is withdrawn, Registry should preserve:

  • Registry Identifier;
  • withdrawal date;
  • withdrawal authority;
  • reason or reason category;
  • affected versions;
  • replacement or correction path;
  • historical resolution behavior;
  • public notice, when appropriate.

Public, Restricted, and Internal Transparency

Transparency may be expressed through:

  • Public Disclosure — fully visible through Registry publication.
  • Public Summary — general facts visible while sensitive details remain restricted.
  • Controlled Access — available under defined authorization.
  • Internal Record — preserved for institutional operation, audit, and review.
  • Non-Disclosure — withheld when disclosure would create unlawful or material harm.

The chosen level should be proportionate to the information, risk, authority, and public need.

Transparency Record

Registry may preserve a Transparency Record identifying:

  • subject of disclosure;
  • disclosure level;
  • public fields;
  • restricted fields;
  • restriction basis;
  • decision authority;
  • effective date;
  • review date;
  • related Publication or Governance records;
  • change history.

Illustrative Transparency Record

transparency_record_identifier: "SREG-TRANS-2026-0001" subject: "SREG-JUR-2026-0001" disclosure_level: "public" effective_date: "2026-08-02" authority: "Satoshium Registry" status: "active"
Final identifiers, field names, disclosure levels, and Controlled Values remain subject to Registry Governance.

Transparency Validation

Validation should confirm:

  • required public fields are present;
  • authority and institutional boundaries are clear;
  • limitations and notices are visible;
  • current and historical versions are distinguishable;
  • Corrections are disclosed;
  • exceptions and disputes are represented when material;
  • restricted fields are not exposed;
  • public summaries do not mislead;
  • human-readable and machine-readable disclosures agree;
  • historical transparency records remain discoverable;
  • disclosure levels match Governance decisions.

Invalid Transparency Conditions

  • material limitation omitted;
  • Source Authority misrepresented;
  • Registry Validation represented as certification;
  • Correction applied without notice;
  • historical version presented as current;
  • restriction hidden while affecting interpretation;
  • restricted information exposed;
  • public summary materially misleading;
  • decision authority omitted;
  • superseded Rule, Policy, Procedure, or record presented as current;
  • Catalog prominence presented as institutional rank;
  • human-readable and machine-readable disclosure mismatch.

Transparency Correction

Transparency materials may themselves require Correction.

A Transparency Correction should preserve:

  • prior disclosure;
  • identified error or omission;
  • corrected disclosure;
  • Correction Authority;
  • correction date;
  • reason;
  • affected Registry objects or pages;
  • continued resolution of the prior disclosure when historically relevant.

Transparency Governance

Registry Governance should control:

  • required disclosure fields;
  • disclosure levels;
  • public-summary requirements;
  • restricted-information handling;
  • exception and dispute disclosure;
  • Correction transparency;
  • historical transparency preservation;
  • Transparency Record requirements;
  • Validation requirements;
  • review cycles;
  • withdrawal and emergency disclosure;
  • human-readable and machine-readable alignment.

Relationship to Governance

Governance determines what Registry may decide.

Transparency determines what must be disclosed about those decisions, their authority, their conditions, and their effects.

Governance makes decisions accountable. Transparency makes that accountability visible.

Relationship to Publication

Publication is the primary public delivery mechanism for Registry transparency.

Public SREG pages, machine-readable records, notices, Correction Records, version histories, Catalog views, and Governance materials should carry the transparency appropriate to their function.

Relationship to History

Transparency makes current and prior Registry actions visible.

History preserves those actions through time.

Transparency explains the record. History preserves the explanation.

Relationship to Catalog

The Catalog should make material status, lifecycle, notice, version, source, and historical conditions visible at the point of discovery.

Users should not need to infer whether a SREG is restricted, disputed, superseded, revoked, retired, archived, corrected, or historical.

Relationship to Chronicle

Chronicle may preserve historically significant transparency events, such as:

  • major Governance decisions;
  • material public Corrections;
  • major restrictions or withdrawals;
  • publication-policy changes;
  • new transparency frameworks;
  • institutional accountability milestones.

Registry remains authoritative for Registry Transparency Records. Chronicle remains authoritative for Chronicle-created event records.

What Transparency Does Not Establish

  • It does not create Source Authority.
  • It does not certify Source Records.
  • It does not create attestations.
  • It does not require disclosure of restricted information.
  • It does not override privacy, rights, safety, security, or lawful restrictions.
  • It does not make every internal operational detail public.
  • It does not replace Governance, Validation, Publication, or History.
  • It does not make public summaries equivalent to full evidence.
  • It does not erase prior disclosures or Corrections.
  • It does not expand Registry authority.

Transparency Principle

Registry Transparency should make every material authority, condition, limitation, decision, change, and historical state visible to the degree necessary for responsible public understanding without violating legitimate restrictions.

Authority must be clear. Limitations must be visible. History must remain discoverable.
Back to Registry → Open Governance → Open History →
Trust grows when an institution makes its authority, limits, decisions, and history visible without pretending that everything can or should be disclosed.