Registry · Provenance

Satoshium Registry Provenance

Satoshium Registry Provenance defines how every SREG preserves a traceable, attributable, version-aware path back to its Authoritative Source Record and the institution responsible for that source.

Provenance allows Registry users to understand where a record came from, how it entered Registry, what changed, and which source remains authoritative.

Constitutional Position

Provenance operates across the complete SREG lifecycle, beginning with Source Authority and continuing through registration, validation, publication, updates, corrections, supersession, retirement, and archival preservation.

Source Institution → Authoritative Source Record → Source References → SREG → Registry History
Authority identifies who controls the source. Provenance preserves the path from the SREG back to it.

Why Provenance Matters

A Registry Entry without provenance may identify a record but fail to explain its origin, custody, source version, publication history, or relationship to the institution that created it.

The Core Question

Provenance asks:

Where did this SREG come from, what source supports it, and how can its history be traced?

Registry's Responsibility

Registry must preserve enough structured evidence and references to reconstruct the identity, source, versions, custody, publication, and maintenance history of the SREG.

Registry's Limitation

Provenance demonstrates traceability. It does not by itself certify the truth, legality, accuracy, completeness, or institutional merit of the Source Record.

Canonical Provenance Path

SREG → Registry Source Reference → Authoritative Source Record → Source Institution

Supporting layers may include source versions, publication locations, repositories, manifests, archival copies, integrity references, workflow records, and correction history.

Core Provenance Requirements

  • Source Institution;
  • Authoritative Source Record;
  • Source-System Identifier;
  • canonical source reference;
  • source object type;
  • source version;
  • source publication or issuance date;
  • source effective date;
  • Source-Record Status;
  • repository, publisher, or platform;
  • acquisition or registration context;
  • authority-review reference;
  • Registrability review reference;
  • identifier-assignment reference;
  • validation and publication references;
  • correction, version, and lifecycle history.

Origin Provenance

Identifies where the Source Record originated and which institution created or issued it.

Custody Provenance

Preserves how the Source Record moved through repositories, publishers, archives, custodians, or successor institutions.

Version Provenance

Connects the SREG to the relevant Source-Record Version and Registry Entry Version.

Publication Provenance

Preserves where, when, and in what form the source and SREG were published.

Operational Provenance

Preserves reviews, workflows, validations, corrections, and maintenance actions.

Historical Provenance

Preserves prior states, supersession, withdrawal, retirement, archival custody, and successor relationships.

Source Provenance

Source Provenance should preserve:

  • Source Institution name and identifier;
  • Source-System Identifier;
  • canonical source title;
  • canonical source location;
  • source object type;
  • source version;
  • publication date;
  • effective date;
  • source status;
  • publisher or repository;
  • rights or licensing reference;
  • known mirrors or derivatives;
  • known predecessor or successor sources.

Registration Provenance

Registry should preserve how the Source Record became a proposed and then operational SREG.

Source Identified → Authority Reviewed → Registrability Determined → Identifier Assigned → SREG Constructed

Registration provenance should include review outcomes, dates, authorities, workflow references, conditions, and supporting evidence.

Publication Provenance

Publication provenance should preserve:

  • first publication date;
  • canonical human-readable URL;
  • canonical machine-readable URL;
  • publication version;
  • publication authority;
  • validation result;
  • schema and profile versions;
  • downloadable artifact references;
  • integrity references, when available;
  • prior publication paths and redirects.

Version Provenance

Version Provenance should distinguish among:

  • Registry Entry Version;
  • Source-Record Version;
  • SREG Base Schema Version;
  • Record-Type Profile Version;
  • Registry Schema Specification Version;
  • Registry Rules Version;
  • Registry Policy Version;
  • Suite Standards Version;
  • Suite Methodology Version.
A change in one version domain does not automatically imply a change in another.

Custody Provenance

A Source Record may move between:

  • institutional repositories;
  • public websites;
  • package structures;
  • publication platforms;
  • archives;
  • successor institutions;
  • preservation services;
  • controlled-access environments.

Registry should preserve custody changes without implying that every custodian becomes the Source Institution.

Custody identifies who holds or preserves a record. Authority identifies who controls its institutional meaning.

Original Custody

The Source Institution directly publishes or stores the Source Record.

Delegated Custody

Another platform or repository hosts the record on behalf of the Source Institution.

Archival Custody

An archive preserves the record after active publication changes or ends.

Successor Custody

A successor institution assumes preservation or maintenance responsibility.

Derived and Generated Records

Provenance must distinguish original Source Records from derived or generated artifacts.

Examples include:

  • Certification Package and generated SCPR, SCR, and SCRD artifacts;
  • canonical Markdown and derived JSON;
  • canonical jurisdiction JSON and generation manifest;
  • source media and derived thumbnails;
  • source evidence and generated summaries;
  • original record and archived snapshot;
  • source data and machine-readable export.
Derived artifacts may be authoritative representations within their own defined role, but they must preserve the path back to the canonical source.

Provenance Relationships

Provenance may use typed relationships such as:

  • sourced from;
  • produced by;
  • derived from;
  • generated from;
  • published by;
  • hosted by;
  • preserved by;
  • archived as;
  • version of;
  • supersedes;
  • superseded by;
  • successor to;
  • predecessor of;
  • validated by;
  • anchored by;
  • documented by.

Final labels and controlled values remain subject to Registry governance.

Provenance Evidence

Supporting evidence may include:

  • institutional metadata;
  • repository history;
  • release records;
  • publication manifests;
  • generation manifests;
  • version-control history;
  • signed artifacts;
  • hashes and integrity references;
  • Chronicle events;
  • Attestor statements;
  • Certifier artifacts;
  • archival snapshots;
  • governance decisions;
  • correction records.

Machine-Readable Provenance

Machine-readable SREGs should preserve provenance through structured fields rather than narrative text alone.

source_institution: "Satoshium Atlas" source_identifier: "atlas-jurisdiction-el-salvador" source_version: "1.0.0" canonical_source: "https://satoshium.us/atlas/..." derived_artifact: "jurisdiction.json" generation_manifest: "manifest.json" registry_identifier: "SREG-JUR-2026-0001"
Final field names and structures remain subject to the SREG Base Schema and Registry Schema Specification.

Human-Readable Provenance

Human-readable SREGs should present provenance clearly enough for a visitor to identify:

  • who created the Source Record;
  • what the authoritative source is;
  • where the source can be found;
  • which version applies;
  • when it was published or became effective;
  • how Registry acquired or registered it;
  • what derived artifacts exist;
  • what changed over time;
  • where prior versions or archival copies can be found.

Unavailable Sources

When a Source Record becomes unavailable, Registry should preserve:

  • last known Source Institution;
  • last known canonical source reference;
  • Source-System Identifier;
  • last known source version;
  • last known Source-Record Status;
  • archival references;
  • integrity references;
  • date availability changed;
  • reason for unavailability, when known;
  • successor or replacement source, when applicable.
Source unavailability changes access. It does not erase provenance.

Historical Provenance

Historical Provenance should preserve:

  • prior Source Institutions;
  • prior canonical URLs;
  • prior Source-System Identifiers;
  • prior source versions;
  • prior Registry Entry Versions;
  • superseded and revoked relationships;
  • withdrawal, retirement, and archival events;
  • custody transfers;
  • correction history;
  • Chronicle event references;
  • successor and predecessor records.

Provenance Corrections

Provenance may require correction when:

  • Source Institution was misidentified;
  • Source-System Identifier was incorrect;
  • canonical source reference was wrong;
  • source version was misstated;
  • publication date was incorrect;
  • custody was confused with authority;
  • a mirror was presented as canonical;
  • a derivative was presented as original;
  • a historical source was presented as current;
  • a generation path was incomplete.

Correction Without Erasure

Provenance corrections should preserve:

  • prior provenance value;
  • corrected provenance value;
  • correction reason;
  • correction date;
  • correction authority;
  • supporting evidence;
  • affected Registry Entry Version;
  • affected relationship or reference;
  • public Correction Record.
Corrected provenance should improve traceability without deleting the history of the original Registry assertion.

Provenance Validation

Validation should confirm:

  • Source Institution is identified;
  • Authoritative Source Record is identifiable;
  • Source-System Identifier is preserved when available;
  • canonical source reference is attributable;
  • source and Registry versions are distinguishable;
  • custody and authority are not conflated;
  • derived artifacts identify their source;
  • archival references are labeled accurately;
  • corrections preserve prior values;
  • human-readable and machine-readable provenance agree;
  • historical records are not presented as current;
  • required supporting references exist.

Invalid Provenance Conditions

  • missing Source Institution;
  • missing Source Record reference;
  • unsupported source attribution;
  • mirror presented as canonical source;
  • derivative presented as original;
  • custodian presented as Source Institution without support;
  • Source-System Identifier replaced by Registry Identifier;
  • source and Registry versions collapsed;
  • historical source presented as current;
  • unavailable source removed without archival context;
  • silent provenance correction;
  • human-readable and machine-readable mismatch.

Relationship to Source Authority

Source Authority determines who controls the Source Record.

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

Authority answers who. Provenance explains how the record can be traced.

Relationship to Relationships

Provenance relies on typed relationships to connect:

  • SREG to Source Record;
  • Source Record to Source Institution;
  • derived artifact to canonical source;
  • current version to prior version;
  • active source to archival source;
  • record to integrity reference;
  • SREG to review, correction, and publication history.
Provenance explains origin. Relationships explain context.

Relationship to Validation

Provenance validation confirms that Registry can support and reconstruct its source attribution and history.

It does not certify the substantive truth of the Source Record.

Relationship to Publication

Provenance should be visible and consistent across:

  • human-readable SREG;
  • machine-readable SREG;
  • canonical Registry page;
  • downloadable records;
  • version history;
  • correction records;
  • archival presentation;
  • relationship objects.

Suite Provenance Examples

Atlas

Provenance may connect canonical Markdown, jurisdiction JSON, generation manifest, repository path, Atlas package, and resulting Jurisdiction SREG.

Certifier

Provenance may connect Certification Package, SCPR, SCR, SCRD HTML, SCRD JSON, certification subject, evidence, and Certification SREG.

Attestor

Provenance may connect an Attestation Record to the issuing authority, subject, evidence, certification, integrity reference, and Attestation SREG.

Anchor

Provenance may connect a record version to hashes, signatures, timestamps, commitments, and durable integrity references.

What Provenance Does Not Establish

  • It does not certify the Source Record.
  • It does not verify every substantive claim.
  • It does not create Source Authority.
  • It does not create legal ownership.
  • It does not grant licensing rights.
  • It does not establish endorsement or affiliation.
  • It does not guarantee current availability.
  • It does not make every archived copy canonical.
  • It does not replace relationship validation.
  • It does not erase prior errors when corrected.

Provenance Principle

Every SREG should preserve enough structured history to explain where it came from, what source it represents, which institution controls that source, and how the Registry record changed over time.

Authority begins at the source. Provenance preserves the path. Registry keeps that path discoverable.
Back to Registry → Open Source Authority → Open Relationships →
A durable record preserves not only identity, but the path by which that identity became known.