Registry · Scope

Satoshium Registry Scope

Satoshium Registry Scope defines the institutional, operational, technical, and authority boundaries of the Registry.

It establishes what Registry may identify, classify, register, publish, relate, correct, version, preserve, and govern—and what must remain under Source Institution or other Suite authority.

Constitutional Position

Registry Scope operates beneath Suite Standards, Suite Methodology, and Suite Interoperability. It limits Registry implementation to the responsibilities properly assigned to the Registry institution.

Suite Standards → Suite Methodology → Suite Interoperability → Registry Scope → Registry Operations

Purpose explains why Registry exists. Scope defines where Registry authority begins, what it covers, and where it ends.

Why Scope Matters

Clear scope prevents Registry from becoming a general authority over every object, record, institution, decision, or source it references.

The Core Question

Registry Scope asks:

Is this object, action, field, decision, or responsibility properly within Registry authority?

Registry's Responsibility

Registry must govern SREG identity, classification, Registry-owned metadata, lifecycle, publication, correction, history, and Catalog presentation.

Registry's Limitation

Registry must not absorb Source Authority, certification authority, attestation authority, Chronicle authority, or the authority of another Suite or external institution.

Canonical Scope Model

Registry Institution → SREG → Registry-Owned Fields and Actions → Source and Institutional Boundaries

Registry Scope Includes

determining whether an object is registrable;
assigning a permanent Registry Identifier;
preserving Source-System Identifiers;
assigning a Registry Record Type;
constructing and maintaining SREGs;
governing Registry-owned metadata;
recording Source Institution and Source Authority references;
recording provenance and custody distinctions;
creating typed Registry Relationships;
validating SREG conformance;
publishing human-readable and machine-readable SREGs;
assigning Registry Entry Versions;
issuing Registry Corrections;
managing Registry Status and Registry Lifecycle State;
maintaining the Registry Catalog;
preserving Registry History;
publishing Registry transparency materials;
governing Registry Rules, Policies, Procedures, schemas, profiles, and Controlled Values.

Registry Scope Excludes

creating Source Authority;
changing Source-Record meaning;
changing Source-Record ownership;
changing Source-Record rights or licensing;
assigning Source-Record outcomes;
issuing certifications;
issuing attestations;
creating Chronicle event records;
creating Anchor integrity records;
creating Beacon signals;
owning Navigator workflow definitions or execution records;
replacing external legal, regulatory, governmental, or institutional authority;
determining substantive truth outside Registry conformance;
treating registration as endorsement, approval, affiliation, or ownership.

Institutional Scope

Defines which responsibilities belong to the Registry institution.

Object Scope

Defines which objects and Source Records may become SREGs.

Field Scope

Defines which fields are Registry-owned and which remain source-owned.

Action Scope

Defines which decisions and operations Registry may perform.

Institutional Scope

Satoshium Registry is the Suite institution responsible for canonical registration, Registry identity, classification, Registry relationships, Registry publication, Registry lifecycle, Registry correction, Registry history, and public Catalog presentation.

Registry is not the general authority over every institution represented in its records.

Object Scope

Registry may register objects that:

have identifiable institutional or source context;
have sufficient Source Authority or provenance;
fit an approved Registry Record Type;
have durable identity or historical value;
support Registry discovery, interoperability, preservation, or accountability;
can be represented without violating applicable restrictions;
meet Registry Registrability requirements.

Potentially Registrable Objects

Objects within Registry scope may include:

tools;
jurisdictions;
media resources;
certification records and packages;
attestation records;
signals;
events;
integrity references;
workflow records;
institutions;
schemas;
Policies;
Procedures;
Governance Decisions;
other objects approved through Registry Governance.

Being a recognized object type does not automatically make a specific object registrable.

Objects Outside Registry Scope

Objects may remain outside Registry scope when they:

lack identifiable Source Authority or provenance;
lack durable identity;
do not fit an approved Record Type;
are purely temporary operational data without Registry value;
cannot be represented without material deception;
cannot be represented without violating rights, privacy, safety, security, or law;
duplicate an existing SREG without a valid distinct identity;
belong entirely to another institution's internal operational domain;
are prohibited by Registry Rules, Policies, or Governance.

Field Scope

Registry-owned fields may include:

Registry Identifier;
Registry Record Type;
Registry Status;
Registry Lifecycle State;
Registry Entry Version;
Registry Relationships;
Registry publication metadata;
Registry correction metadata;
Registry history metadata;
Catalog metadata;
Registry notices and restrictions;
Registry validation metadata.

Source-owned fields may include:

Source-System Identifier;
Source-Record Version;
Source-Record Status;
substantive source content;
source-domain outcomes;
source-domain rights;
source-domain classifications;
source-domain lifecycle conditions.

Action Scope

Registry may:

accept or decline registration;
assign Registry identity;
classify a SREG;
publish Registry-owned representations;
validate Registry conformance;
correct Registry-owned fields;
change Registry Status;
change Registry Lifecycle State;
supersede, revoke, retire, restrict, or archive a SREG;
preserve prior Registry states;
govern Catalog inclusion and presentation;
publish transparency and history records.

Registry may not perform a source-domain action merely because a Source Record is represented by a SREG.

Source Authority Boundary

Registry may identify, preserve, and disclose Source Authority.

Registry may not create or transfer Source Authority through registration.

Source Institution owns Source Record → represented by → SREG owned by Registry

Representation is not ownership. Registration is not authority transfer.

Certification Boundary

Registry may register and catalog:

Certification Packages;
SCPRs;
SCRs;
SCRDs;
certification-related metadata;
relationships between certifications and certified subjects.

Certifier remains authoritative for:

certification methodology application;
certification evidence review;
certification outcomes;
certification scope;
certification artifacts;
certification status and validity.

Registry records certification. Certifier performs certification.

Attestation Boundary

Registry may register and catalog Attestor-created attestations and trust statements.

Attestor remains authoritative for:

attestation creation;
attestation meaning;
attestation authority;
attestation status;
attestation revocation;
trust-statement interpretation.

Chronicle Boundary

Registry History preserves Registry-owned actions, states, versions, and decisions.

Chronicle creates and preserves Chronicle event records.

Registry owns Registry History. Chronicle owns Chronicle-created events.

Anchor Boundary

Registry may reference and catalog Anchor-created integrity records.

Anchor remains authoritative for:

integrity-reference creation;
anchoring methods;
anchored-artifact relationships;
verification procedures;
Anchor record status.

Beacon Boundary

Registry may register and catalog Beacon signals and use them for discovery.

Beacon remains authoritative for:

signal creation;
signal type;
signal timing;
signal status;
signal distribution;
Beacon-created discovery metadata.

Navigator Boundary

Navigator may coordinate Registry workflows such as:

Source Authority review;
Registrability review;
Validation;
Publication;
Correction;
Governance review;
Version migration;
recurring review.

Registry remains authoritative for Registry decisions and records. Navigator remains authoritative for Navigator-created workflow definitions and execution records.

Atlas Boundary

Registry may register and catalog Atlas jurisdiction resources.

Atlas remains authoritative for:

jurisdiction intelligence;
Atlas resource content;
Atlas identifiers;
Atlas resource versions;
Atlas generation manifests;
Atlas source-domain methodology.

Catalog Scope

Catalog scope includes:

published SREG discovery;
Registry Identifier resolution;
browse collections;
search indexes;
governed filters;
relationship navigation;
current and historical Catalog views;
Catalog Versioning;
notices, restrictions, and historical conditions.

Catalog presentation must not imply institutional rank, endorsement, affiliation, ownership, or source-domain quality unless explicitly supported.

Validation Scope

Registry Validation may determine whether:

a SREG conforms to the SREG Base Schema;
a SREG conforms to its Record-Type Profile;
required fields are present;
Controlled Values are valid;
identifiers are properly formed;
relationships are properly represented;
provenance is sufficient;
Publication requirements are met;
human-readable and machine-readable forms agree.

Registry Validation does not determine whether the Source Record is substantively true, certified, legally valid, endorsed, or complete outside Registry requirements.

Publication Scope

Registry Publication may establish:

official Registry recognition of a SREG;
canonical Registry resolution;
current Registry Entry Version;
public Registry metadata;
Registry Status and Lifecycle presentation;
notices, restrictions, Corrections, and history;
Catalog inclusion.

Registry Publication does not establish:

Source-Record ownership;
Source-Record truth;
certification;
attestation;
endorsement;
governmental or regulatory approval;
permanent source availability.

Correction Scope

Registry may correct:

Registry identifiers and references;
Registry classifications;
Registry relationships;
Registry provenance representations;
Registry Status or Lifecycle fields;
Registry publication metadata;
Registry Catalog metadata;
Registry history records;
other Registry-owned fields.

Registry may not silently alter Source-Record content. Source-domain Corrections remain under Source Institution authority.

History Scope

Registry History includes:

Registry actions;
Registry decisions;
SREG versions;
Registry Status and Lifecycle transitions;
Corrections;
Publication events;
Catalog releases;
Governance changes;
schema, profile, Policy, Procedure, and Controlled-Value history.

Source-System history may be referenced but remains source-owned.

Transparency Scope

Registry Transparency should reveal:

Registry authority;
Source Institution boundaries;
applicable requirements;
versions;
Validation outcomes;
Publication conditions;
notices and limitations;
Corrections;
historical states;
what Registry does not claim.

Transparency remains limited by legitimate privacy, rights, safety, security, contractual, legal, and institutional restrictions.

Geographic Scope

Registry is not inherently limited to one jurisdiction or geographic region.

Geographic applicability may depend on:

the Source Institution;
the Source Record;
the Registry Record Type;
jurisdictional rights and restrictions;
applicable legal conditions;
publication and access requirements;
Registry Governance decisions.

Temporal Scope

Registry may represent:

current operational objects;
historical Source Records;
superseded Registry records;
revoked Registry records;
retired Registry records;
archived Registry records;
prior versions;
historical institutions and authorities;
events and artifacts whose current operational relevance has ended.

Historical inclusion preserves context. It does not make a prior state current.

Technical Scope

Registry technical scope may include:

human-readable HTML pages;
machine-readable JSON records;
schemas and Record-Type Profiles;
Controlled-Value Sets;
Catalog indexes;
generation manifests;
integrity references;
canonical URLs;
downloadable artifacts;
interoperability mappings;
historical and archival representations.

Technical implementation must remain subordinate to institutional authority and semantic meaning.

Restricted Scope

Registry may register or preserve objects whose public disclosure is limited.

Restricted scope may apply when:

privacy must be protected;
rights limit reuse or disclosure;
safety concerns exist;
security concerns exist;
contractual limits apply;
lawful authority restricts access;
Source Institution conditions apply;
historical preservation is permitted but public exposure is not.

A restriction limits access or publication. It does not necessarily place the object outside Registry scope.

Scope Determination

A formal scope determination should consider:

What is the proposed object or responsibility?
Which institution owns its authoritative meaning?
Does Registry have a legitimate registration or catalog function?
Does the object fit an approved Record Type?
Are Source Authority and provenance sufficient?
Can Registry represent the object without authority confusion?
Can Registry satisfy applicable rights and restrictions?
Would inclusion duplicate or displace another institutional responsibility?
Does inclusion comply with Registry Rules, Policies, and Governance?

Scope Determination Outcomes

Within Scope — the object or responsibility properly belongs within Registry authority.
Within Scope with Conditions — Registry may proceed under documented limitations.
Shared or Coordinated Scope — Registry has a defined role while another institution retains related authority.
Restricted Scope — Registry may preserve or register the object with access or publication limits.
Outside Scope — the object or responsibility does not properly belong to Registry.
Indeterminate — additional authority, provenance, Governance, or legal review is required.

Illustrative Scope Record

scope_record_identifier: "SREG-SCOPE-2026-0001"
subject: "Certification Package registration"
scope_outcome: "shared_or_coordinated_scope"
registry_role: "register and catalog the source record"
source_authority: "Satoshium Certifier"
authority: "Satoshium Registry"
status: "active"
  

Final identifiers, field names, and Scope Outcomes remain subject to Registry Governance.

Scope Conflict

A scope conflict exists when:

two institutions claim authority over the same decision;
Registry representation is mistaken for source ownership;
a Registry field duplicates or overrides a source-owned field;
a workflow attempts to perform an action beyond Registry authority;
publication implies certification, attestation, endorsement, or approval;
a Catalog classification changes source-domain meaning;
an external legal or institutional requirement contradicts Registry operation.

Material scope conflicts should pause affected action until Governance resolves the authority boundary.

Scope Validation

Validation should confirm:

the object falls within an approved Registry function;
the Record Type is within Registry scope;
Registry-owned and source-owned fields remain distinct;
Source Institution authority is preserved;
another Suite institution's authority is not absorbed;
Registry action is authorized;
restrictions are represented correctly;
publication claims remain within Registry authority;
human-readable and machine-readable materials express the same boundary;
scope conditions remain visible.

Invalid Scope Conditions

Registry claims ownership of a Source Record;
Registry changes a source-owned outcome;
Registry Validation is represented as Certification;
Registry publication is represented as endorsement;
Catalog inclusion is represented as affiliation;
Registry creates an Attestor or Chronicle record under Registry authority;
source-owned fields are silently replaced;
another institution's status or lifecycle is treated as Registry-owned;
restriction conditions are ignored;
an object is registered without adequate Source Authority or provenance;
human-readable and machine-readable scope statements conflict.

Scope Governance

Registry Governance should control:

Registry institutional boundaries;
approved Record Types;
Registry-owned field definitions;
Source Institution boundaries;
shared or coordinated responsibilities;
Scope Outcomes;
scope exceptions;
scope conflicts;
restricted-scope conditions;
new institutional integrations;
scope review and amendment;
historical preservation of prior scope decisions.

Scope Review Triggers

Registry Scope should be reviewed when:

Suite Standards change;
Suite Methodology changes;
Suite Interoperability changes;
a new Suite institution is created;
a new Registry Record Type is proposed;
a new Source Institution is integrated;
authority conflicts recur;
new legal, privacy, rights, safety, or security conditions arise;
new technical publication methods change Registry capabilities;
Registry operations begin performing responsibilities not clearly authorized.

Relationship to Purpose

Purpose explains why Satoshium Registry exists.

Scope defines the responsibilities and boundaries through which that Purpose may be implemented.

Purpose gives direction. Scope preserves discipline.

Relationship to Registrability

Scope determines whether the proposed object belongs within Registry's institutional domain.

Registrability determines whether the specific object satisfies the requirements for registration.

Scope asks whether Registry may register the kind of object. Registrability asks whether Registry should register this object.

Relationship to Governance

Scope limits Governance authority.

Governance may interpret, maintain, and amend Registry Scope within Suite authority, but it may not use Registry Governance to absorb powers assigned elsewhere.

Relationship to Transparency

Transparency should make Registry Scope and its limitations publicly understandable.

Published records should clearly distinguish:

Registry authority;
Source Institution authority;
other Suite institution authority;
shared or coordinated responsibilities;
scope conditions and restrictions;
claims Registry does not make.

What Scope Does Not Establish

It does not automatically make an object registrable.
It does not create Source Authority.
It does not create certification or attestation authority.
It does not override Suite Standards or Methodology.
It does not override rights, privacy, safety, security, or law.
It does not make every in-scope object publicly accessible.
It does not convert shared responsibility into Registry ownership.
It does not permit Registry to redefine another institution's records.
It does not eliminate the need for Registrability, Validation, or Governance review.
It does not expand Registry authority through implication.

Scope Principle

Registry Scope should be broad enough to support durable identification, discovery, interoperability, preservation, and accountability, while remaining narrow enough to preserve Source Authority and the constitutional boundaries of every Suite institution.

A strong Registry knows what it governs. A trustworthy Registry also knows what it does not.

Back to Registry → Open Purpose → Open Registrability →