Registry · Relationships

Satoshium Registry Relationships

Satoshium Registry Relationships define how SREGs connect to Authoritative Source Records, Suite institutions, other SREGs, certifications, attestations, signals, historical events, integrity references, workflows, dependencies, successors, and archival records.

Relationships make Registry more than a collection of isolated entries. They preserve the institutional context surrounding each record.

Constitutional Position

Relationships operate within the SREG model after identity and classification are established.

Source Authority → Registrability → Registry Identifier → SREG → Typed Relationships
Relationships connect Registry objects without transferring authority between the institutions or records they reference.

Why Relationships Matter

Records rarely exist in isolation. A certification concerns a subject. An attestation refers to an artifact. A signal announces a milestone. An Anchor reference preserves integrity. A Chronicle event records change.

The Core Question

Relationships ask:

How is this SREG connected to other records, institutions, artifacts, events, and systems?

Registry's Responsibility

Registry must preserve relationships as structured, typed, directional, attributable, version-aware, and historically traceable objects.

Registry's Limitation

Registry records a relationship. It does not create the underlying institutional authority, substantive meaning, legal effect, certification outcome, attestation statement, or historical event.

Canonical Relationship Model

Source Identifier → Relationship Type → Target Identifier

A complete Registry relationship should also preserve direction, identifier domains, authority, effective date, version context, status, and supporting references.

Relationship Requirements

Every governed relationship should identify:

  • relationship identifier, when required;
  • source Registry Identifier or external identifier;
  • source identifier domain;
  • target Registry Identifier or external identifier;
  • target identifier domain;
  • relationship type;
  • direction;
  • relationship authority;
  • effective date;
  • end date, when applicable;
  • version context;
  • relationship status;
  • supporting reference;
  • creation or assertion date;
  • correction and history references.

Typed

Every relationship uses an approved controlled relationship type.

Directional

The relationship identifies a source and target rather than implying an undefined association.

Attributable

The authority or process responsible for asserting the relationship is preserved.

Version-Aware

The relationship may apply to one SREG version, one source version, or a continuing record.

Time-Aware

Effective dates, end dates, and historical conditions may be preserved.

Correctable

Relationship changes must preserve prior values and documented history.

Initial Controlled Relationship Types

  • sourced from
  • source of
  • produced by
  • produces
  • references
  • referenced by
  • concerns
  • concerned by
  • certifies
  • certified by
  • attests to
  • attested by
  • anchored by
  • integrity reference for
  • documents
  • documented by
  • announces
  • announced by
  • parent jurisdiction
  • child jurisdiction
  • depends on
  • dependency of
  • integrates with
  • coordinated through
  • supersedes
  • superseded by
  • successor to
  • predecessor of
  • derivative of
  • has derivative
  • version of
  • archived as
  • archival representation of
Final controlled values, labels, inverses, and usage requirements remain subject to Registry governance.

Source Relationships

Connect a SREG to its Authoritative Source Record, Source Institution, repository, package, or canonical publication.

Institutional Relationships

Connect SREGs to Suite institutions or external institutions responsible for creation, maintenance, publication, verification, or preservation.

Operational Relationships

Connect tools, services, workflows, dependencies, inputs, outputs, and integrations.

Historical Relationships

Connect predecessors, successors, prior versions, superseded entries, archival records, and Chronicle events.

Trust Relationships

Connect certifications, attestations, evidence, integrity references, and verification artifacts.

Discovery Relationships

Connect Beacon signals, media, announcements, public pages, and discovery metadata.

Direction and Inverse Relationships

Relationships should be directional even when an inverse form is also published.

SREG-CERT-2026-0001 certified by SC-CERT-2026-0001 SC-CERT-2026-0001 certifies SREG-JUR-2026-0001

Each direction should use a controlled type appropriate to the source and target.

A relationship may have a defined inverse. It should not be treated as automatically symmetrical.

Symmetrical Relationships

Some relationships may be symmetrical, such as certain forms of integrates with or related to.

Symmetry should be explicitly defined by the controlled relationship type. Registry should not assume symmetry merely because two objects reference each other.

Relationship Authority

Every material relationship should identify who is authorized to assert it.

Potential authorities include:

  • Registry, for Registry-owned catalog relationships;
  • Source Institution, for source-controlled relationships;
  • Certifier, for certification relationships;
  • Attestor, for attestation relationships;
  • Chronicle, for Chronicle-created historical event relationships;
  • Anchor, for integrity-reference relationships;
  • Beacon, for signal and announcement relationships;
  • Navigator, for workflow and coordination relationships;
  • approved external institutions, for external source relationships.
Registry may publish a relationship asserted by another institution while preserving that institution as the relationship authority.

Registry-Asserted

Registry creates the relationship as part of catalog organization or institutional maintenance.

Source-Asserted

The Source Institution states or controls the relationship.

Derived

The relationship is derived from structured evidence or interoperable source data.

Provisional

The relationship is published with explicit uncertainty or pending review.

Relationship Status

Potential relationship conditions may include:

  • Active — relationship currently applies.
  • Historical — relationship applied previously and remains preserved.
  • Superseded — relationship has been replaced by a newer relationship.
  • Revoked — asserting authority withdrew the relationship.
  • Disputed — competing claims or interpretations remain unresolved.
  • Provisional — relationship is pending additional evidence or review.
  • Invalid — relationship was erroneous or structurally defective.

Relationship Status must remain separate from Registry Status, Registry Lifecycle State, and Source-Record Status.

Version Context

A relationship may apply to:

  • the continuing SREG;
  • one Registry Entry Version;
  • one Source-Record Version;
  • one artifact version;
  • one schema version;
  • one historical time period;
  • all future versions until withdrawn.
Registry should not assume that a relationship applying to one version automatically applies to every later version.

Temporal Relationships

Relationships may change over time.

Registry may preserve:

  • assertion date;
  • effective date;
  • end date;
  • withdrawal date;
  • supersession date;
  • historical applicability;
  • future effective date;
  • review date.

Relationship Evidence

Material relationships should preserve supporting evidence or references.

Evidence may include:

  • Source Record metadata;
  • Certification Package references;
  • attestation statements;
  • Chronicle events;
  • Anchor integrity references;
  • Beacon announcements;
  • workflow records;
  • repository metadata;
  • version history;
  • governance decisions;
  • public institutional statements.

Relationship Object

Registry may represent material relationships as embedded structures or as independently identifiable relationship objects.

relationship_type: "certified_by" source_identifier: "SREG-JUR-2026-0001" source_domain: "satoshium-registry" target_identifier: "SC-CERT-2026-0001" target_domain: "satoshium-certifier" authority: "Satoshium Certifier" status: "active"
The final machine-readable field names and controlled values remain subject to the SREG Base Schema and Registry Schema Specification.

Source Record Relationships

Every SREG should preserve a primary relationship to its Authoritative Source Record.

SREG → sourced from → Authoritative Source Record

Supporting relationships may connect the SREG to:

  • Source Institution;
  • repository;
  • canonical HTML page;
  • canonical JSON record;
  • generation manifest;
  • supporting evidence;
  • archived snapshot;
  • integrity reference.

Certification Relationships

Certification Subject → Certification Package → SCPR → SCR → SCRD → Certification SREG

Registry should preserve Certifier as the authority for the Certification Package, Certification Outcome, Certification Status, and generated artifacts.

Attestation Relationships

Attestation relationships may connect:

  • Attestation SREG to Attestor-owned Attestation Record;
  • attestation to subject;
  • attestation to evidence;
  • attestation to certification;
  • attestation to integrity reference;
  • attestation to historical event;
  • attestation to issuing institution.

Attestor remains authoritative for the attestation statement.

Jurisdiction Relationships

Jurisdiction relationships may include:

  • parent jurisdiction;
  • child jurisdiction;
  • part of;
  • contains;
  • predecessor jurisdiction;
  • successor jurisdiction;
  • merged into;
  • split from;
  • boundary changed by;
  • governed by;
  • recognized by.

Atlas remains authoritative for Atlas jurisdiction intelligence and source-domain jurisdiction relationships.

Tool and Workflow Relationships

Tool SREGs may preserve:

  • depends on;
  • dependency of;
  • integrates with;
  • produces;
  • consumes;
  • operated by;
  • implements;
  • coordinated through;
  • validated by;
  • published by;
  • replaced by;
  • version of.

Navigator remains authoritative for Navigator-created workflow definitions and coordination records.

Historical and Archival Relationships

Registry should preserve relationships among:

  • prior and current versions;
  • predecessors and successors;
  • superseded and successor SREGs;
  • original and archival copies;
  • active and historical records;
  • withdrawn sources and preserved snapshots;
  • SREGs and Chronicle events;
  • records and integrity references.
Historical relationships preserve continuity without implying that prior records remain current.

Relationship Corrections

A relationship correction may be required when:

  • source or target identifier was incorrect;
  • identifier domain was incorrect;
  • relationship type was misclassified;
  • direction was reversed;
  • authority was misidentified;
  • effective date was incorrect;
  • version context was omitted or misstated;
  • a duplicate relationship was created;
  • a provisional relationship was incorrectly presented as confirmed.

Correction Without Erasure

Corrected relationships should preserve:

  • prior source identifier;
  • prior target identifier;
  • prior relationship type;
  • corrected values;
  • correction reason;
  • correction date;
  • correction authority;
  • affected Registry Entry Version;
  • supporting evidence;
  • replacement or supersession relationship.

Relationship Validation

Validation should confirm:

  • source identifier exists or is a valid external reference;
  • target identifier exists or is a valid external reference;
  • identifier domains are declared;
  • relationship type is approved;
  • direction is valid;
  • authority is identified;
  • effective dates are coherent;
  • version context is explicit when required;
  • inverse relationship is correct when published;
  • duplicate relationships are prevented;
  • status is valid;
  • supporting references are preserved;
  • human-readable and machine-readable forms agree.

Invalid Relationship Conditions

  • unrecognized relationship type;
  • missing source or target identifier;
  • undeclared identifier domain;
  • reversed or ambiguous direction;
  • unsupported authority claim;
  • impossible or contradictory dates;
  • incorrect inverse relationship;
  • duplicate relationship;
  • relationship applied to the wrong version;
  • historical relationship presented as current;
  • provisional relationship presented as confirmed;
  • human-readable and machine-readable mismatch.

Relationship to Provenance

Provenance preserves the path from a SREG back to the Source Record and Source Institution.

Relationships connect that path to other institutional objects and events.

Provenance explains origin. Relationships explain context.

Relationship to Publication

Official SREG publication should expose relationships consistently across:

  • human-readable SREG;
  • machine-readable SREG;
  • relationship summaries;
  • linked record pages;
  • version history;
  • correction records;
  • supersession notices;
  • archival presentation.

What Relationships Do Not Establish

  • They do not transfer Source Authority.
  • They do not certify records.
  • They do not create attestations.
  • They do not create legal ownership.
  • They do not establish endorsement or affiliation unless explicitly supported.
  • They do not make every relationship permanent.
  • They do not make inverse relationships automatically valid.
  • They do not make historical records current.
  • They do not replace provenance.
  • They do not eliminate the need for validation.

Relationship Principle

Registry relationships should make institutional context visible without collapsing the independent authority of the records and institutions they connect.

Relationships connect identity, authority, history, and interoperability. They do not absorb them.
Back to Registry → Open Identifiers → Open Integration →
Registry becomes meaningful when identity is preserved together with context.