Registry · Institutional Interoperability

Satoshium Registry Integration

Registry Integration defines how Satoshium Registry receives, validates, catalogs, references, and maintains authoritative records created by other Satoshium Suite institutions.

Registry creates the SREG. The originating institution retains authority over the Source Record.

Constitutional Position

Registry Integration operates beneath Satoshium Suite Standards, Suite Methodology, and Suite Interoperability.

Suite Standards → Suite Methodology → Suite Interoperability → Registry Integration → SREG
Interoperability connects institutional objects. It does not merge institutional responsibilities or transfer source authority to Registry.

Purpose

Registry Integration establishes how Registry receives or identifies Authoritative Source Records, confirms source attribution, creates a SREG, and preserves durable public references and relationships.

Primary Principle

Each institution owns its own canonical object and remains authoritative for the records it creates.

Atlas creates intelligence. Certifier creates certifications. Registry creates SREGs. Chronicle creates historical events. Anchor creates integrity references. Beacon creates discovery signals. Attestor creates trust statements. Navigator creates workflow definitions.

Registry Responsibility

Registry is responsible for the SREG, its Registry Identifier, classification, Registry Status, lifecycle, relationships, versions, corrections, and public catalog presentation.

Source Responsibility

The Source Institution remains responsible for Source Record content, Source-System Identifier, source version, source status, institutional meaning, and any outcome or determination contained in the record.

Canonical Integration Model

Source Institution → Authoritative Source Record → Registry Intake → SREG → Public Catalog

Registry may receive a Source Record directly through an institutional handoff, discover it through an approved public reference, or process it through a Navigator-coordinated workflow.

Regardless of intake method, Registry must preserve the identity of the Source Institution and the authority of the Source Record.

Registry Intake Method

Identify or Receive Source Record → Confirm Source Institution and Authority → Determine Registrability → Assign Record Type → Assign Registry Identifier → Create References and Relationships → Construct SREG → Validate → Publish

1. Identify or Receive

Registry identifies or receives an Authoritative Source Record through an approved institutional, repository, public-reference, or workflow channel.

2. Confirm Source Institution

Registry confirms which institution created and maintains the Source Record.

3. Determine Registrability

Registry determines whether the Source Record fits an approved Record Type and satisfies applicable policy, reference, provenance, and schema requirements.

4. Create SREG

Registry assigns a Registry Identifier, records source identifiers and references, creates relationships, and constructs the SREG.

5. Validate and Publish

Registry validates the SREG against applicable schemas and publishes consistent human-readable and machine-readable forms.

Certifier Integration

After Certifier completes a certification, it produces the Certification Package and related certification artifacts.

Atlas Resource → Certifier Evaluation → Certification Package → SCRD → SREG

The Certification Package remains Certifier's canonical certification object. The SCRD remains a Certifier-owned certified record. Registry creates an independent SREG that catalogs and references the certification record.

Certification Package

Certifier's canonical certification object containing the authoritative certification architecture and related artifacts.

SCPR

The Certification Process Report documenting the evaluation process and supporting institutional review.

SCR

The Certification Receipt documenting certification issuance and public reference information.

SCRD

The structured Certified Record produced and owned by Certifier and suitable for Registry cataloging.

SREG

The Registry-owned entry that catalogs the certification Source Record and preserves its source references, classification, status, versions, and relationships.

Authority Boundary

Certifier controls certification meaning and status. Registry controls the SREG and Registry-owned metadata.

Atlas Integration

Atlas creates jurisdiction intelligence, canonical jurisdiction records, evidence resources, generation manifests, and machine-readable packages.

Registry may create Jurisdiction, Tool, Media, or other applicable SREGs that catalog Atlas Source Records.

Atlas remains authoritative for jurisdiction intelligence. Registry remains authoritative for the SREG.

Chronicle Integration

Chronicle creates and preserves historical events and institutional chronology.

Registry may catalog Chronicle events or create relationships between SREGs and Chronicle records.

Chronicle preserves historical meaning. Registry preserves catalog identity and discoverability.

Anchor Integration

Anchor creates and preserves integrity references, hashes, timestamps, signatures, and durable verification points.

Registry may reference Anchor records within a SREG or catalog them through an applicable Record Type.

Anchor owns integrity references. Registry preserves their relationship to the SREG.

Beacon Integration

Beacon creates discovery signals and discovery metadata that help institutional records be found, interpreted, and distributed.

Registry may reference Beacon outputs or expose Registry metadata for discovery.

Beacon enables discovery. Registry maintains the authoritative catalog entry.

Attestor Integration

Attestor creates trust statements, attestations, validations, and supporting verification references.

Registry may catalog Attestor records through Attestation SREGs or preserve typed relationships between SREGs and Attestor objects.

Attestor creates the trust statement. Registry creates the catalog entry.

Navigator Integration

Navigator creates workflow definitions and coordinates cross-system operational activity.

Registry may receive records through a Navigator workflow, report Registry processing status, or catalog Workflow Definitions.

Navigator coordinates the workflow. Registry performs the registration action.

Integration Responsibilities

  • Confirm the Source Institution.
  • Preserve the Source-System Identifier.
  • Preserve the canonical source reference.
  • Determine registrability.
  • Assign the Registry Record Type.
  • Assign the Registry Identifier.
  • Construct and validate the SREG.
  • Create typed relationships.
  • Separate Registry Status from Source-Record Status.
  • Preserve applicable versions.
  • Publish human-readable and machine-readable forms.
  • Maintain lifecycle, corrections, and archival continuity.

Identifier Mapping

Registry integration must preserve both Registry and source identifiers.

Registry Identifier identifies the SREG. Source-System Identifier identifies the Authoritative Source Record.

These identifiers must not be collapsed into a single value.

Status Mapping

Registry Status and Source-Record Status remain separate across integrations.

Certification Outcome: Certified · Certification Status: Revoked · Registry Status: Active

Registry may preserve an active historical SREG while accurately reporting that the Source Record has been revoked, retired, expired, or superseded.

Version Mapping

Registry integration must distinguish among:

  • Registry Entry Version;
  • SREG schema version;
  • Record-Type Profile version;
  • Registry specification version;
  • Source-Record version;
  • Source Institution publication version.
A Source Record may change without the SREG schema changing. A SREG may be corrected without the Source Record changing.

Validation Boundaries

Registry validates Registry structure and integration requirements.

Registry may confirm:

  • the Source Record exists or is historically documented;
  • the Source Institution is identified;
  • the Source-System Identifier is preserved when available;
  • the Record Type is valid;
  • required references exist;
  • relationships are structurally valid;
  • the SREG conforms to the applicable schema.
Registry validation does not replace certification, attestation, integrity verification, historical interpretation, or source authority.

Publication Consistency

Integration is incomplete when official Registry representations disagree.

Human-readable and machine-readable forms of the same SREG must agree on:

  • Registry Identifier;
  • Record Type;
  • Source Institution;
  • Source-System Identifier;
  • Source Record;
  • Registry Status;
  • Source-Record Status;
  • versions;
  • relationships;
  • public references.

Integration Does Not

  • allow Registry to certify;
  • allow Registry to create attestations;
  • allow Registry to rewrite Source Records;
  • allow Registry to replace Source-System Identifiers;
  • allow Registry to absorb institutional authority;
  • allow one institution to operate another institution's canonical object;
  • convert registration into endorsement, verification, or legal recognition.
Integration connects responsibilities. It does not erase boundaries.

Integration Principle

Registry Integration is successful when authoritative records remain owned by their source institutions while becoming consistently identifiable, classifiable, referenceable, related, and discoverable through SREGs.

The Source Institution creates authority. Registry creates the SREG. Interoperability preserves the relationship between them.
Back to Registry → Open Entry Model → Open Suite Interoperability →
Interoperability connects authority without absorbing it.