Registry · Validation

Satoshium Registry Validation

Satoshium Registry Validation defines how Registry confirms that a constructed SREG satisfies the structural, institutional, identifier, provenance, relationship, version, lifecycle, status, and publication requirements governing Registry records.

Validation confirms that Registry represented the source correctly according to Registry rules. It does not certify the substantive truth of the Source Record.

Constitutional Position

Validation occurs after SREG construction and before publication or material republication.

Source Authority → Registrability → Identifier Assignment → SREG Construction → Validation → Publication
Registrability determines whether Registry should create the SREG. Validation determines whether the constructed SREG is ready to publish.

Why Validation Matters

Even a registrable source may be represented incorrectly if identifiers, source references, versions, relationships, statuses, or publication forms are incomplete or inconsistent.

The Core Question

Validation asks:

Does this SREG accurately and consistently implement the applicable Registry requirements?

Registry's Responsibility

Registry must validate its own object, fields, classifications, references, relationships, versions, and publication forms.

Registry's Limitation

Registry Validation does not certify the subject, confirm every claim, establish legal ownership, grant approval, or replace Source Institution review.

Canonical Validation Model

Rules + Schema + Record-Type Profile + Institutional Requirements → Validation Result

Validation applies the current approved requirements to one defined SREG version.

Validation Domains

  • Source Authority validation;
  • Registrability validation;
  • Identifier validation;
  • schema validation;
  • Record-Type Profile validation;
  • provenance validation;
  • relationship validation;
  • version validation;
  • Registry Status validation;
  • Registry Lifecycle validation;
  • correction validation;
  • publication validation;
  • human-readable and machine-readable consistency validation.

Structural Validation

Confirms required fields, data types, formats, cardinality, and schema conformance.

Institutional Validation

Confirms that Registry authority, source authority, scope, and institutional boundaries are represented correctly.

Referential Validation

Confirms identifiers, source references, relationships, URLs, and linked records resolve or are intentionally historical.

Semantic Validation

Confirms controlled values and fields are used according to their defined meaning.

Temporal Validation

Confirms dates, versions, effective periods, supersession, and lifecycle order remain coherent.

Publication Validation

Confirms official human-readable and machine-readable forms are complete, aligned, and publication-ready.

Validation Inputs

A Registry validation should identify the exact requirements being applied.

  • SREG Base Schema Version;
  • applicable Record-Type Profile Version;
  • Registry Schema Specification Version;
  • Registry Rules Version;
  • Registry Policy Version;
  • Registry Procedure Version;
  • Suite Standards Version;
  • Suite Methodology Version;
  • Suite Interoperability requirements;
  • controlled-value set versions;
  • validation workflow or checklist version.
A validation result is meaningful only when the governing requirement versions are known.

Source Authority Validation

Validation should confirm:

  • Source Institution is identified;
  • Authoritative Source Record is identifiable;
  • authority evidence or review reference exists;
  • custody is not misrepresented as authority;
  • mirrors and derivatives are not presented as canonical sources;
  • authority changes are historically preserved;
  • Registry does not claim source-domain authority.

Registrability Validation

Validation should confirm:

  • positive Registrability outcome exists;
  • conditions or limitations are preserved;
  • approved Record Type applies;
  • minimum metadata requirements were satisfied;
  • duplicate and conflict review was performed;
  • the SREG remains within Registry scope;
  • restricted publication requirements are honored.

Identifier Validation

Identifier validation should confirm:

  • Registry Identifier matches the approved pattern;
  • Registry Identifier is unique;
  • identifier has not been reused;
  • assignment record exists;
  • identifier namespace is valid;
  • Registry Identifier and Source-System Identifier remain distinct;
  • aliases are not represented as canonical identifiers;
  • resolution target exists or is intentionally historical;
  • supersession and replacement relationships are preserved.

Schema Validation

Schema validation should confirm:

  • required fields are present;
  • field names match the approved schema;
  • data types are correct;
  • required formats are valid;
  • cardinality requirements are satisfied;
  • controlled values are approved;
  • required objects and arrays are structured correctly;
  • deprecated fields are absent or handled according to migration rules;
  • schema version is declared;
  • machine-readable representation parses successfully.

Record-Type Profile Validation

Record-Type Profile validation should confirm:

  • one approved primary Record Type is assigned;
  • the correct Profile Version is declared;
  • profile-specific required fields are present;
  • profile-specific controlled values are valid;
  • record-type relationships are represented correctly;
  • record-type publication requirements are satisfied;
  • the SREG is not forced into an inaccurate classification.

Provenance Validation

Provenance validation should confirm:

  • Source Institution is attributable;
  • Source Record is traceable;
  • Source-System Identifier is preserved when available;
  • canonical source reference is present;
  • source and Registry versions remain separate;
  • derived artifacts identify their source;
  • archival references are labeled accurately;
  • historical provenance remains discoverable;
  • corrections preserve prior provenance values.

Relationship Validation

Relationship validation should confirm:

  • source and target identifiers exist or are valid external references;
  • identifier domains are declared;
  • relationship type is approved;
  • direction is valid;
  • relationship authority is identified;
  • version and temporal context are coherent;
  • inverse relationships are correct when published;
  • duplicate relationships are prevented;
  • relationship status is valid;
  • supporting references exist when required.

Version Validation

Version validation should confirm:

  • Registry Entry Version is declared;
  • Source-Record Version is preserved when available;
  • schema and profile versions are declared;
  • version changes follow approved increment rules;
  • prior versions remain discoverable;
  • current and historical versions are not confused;
  • supersession does not overwrite prior identity;
  • human-readable and machine-readable versions agree.

Status and Lifecycle Validation

Validation should confirm:

  • Registry Status uses an approved value;
  • Registry Lifecycle State uses an approved value;
  • Source-Record Status remains separate;
  • Certification or Attestation Status remains source-owned;
  • status and lifecycle dates are coherent;
  • transitions follow approved rules;
  • superseded, revoked, retired, and archived states preserve history;
  • public notices match the current Registry condition.

Correction Validation

Correction validation should confirm:

  • prior value is preserved;
  • corrected value is identified;
  • correction reason is documented;
  • correction date and authority are preserved;
  • affected Registry Entry Version is identified;
  • supporting evidence exists;
  • public correction notice is published when required;
  • human-readable and machine-readable corrections agree;
  • correction does not erase historical traceability.

Publication Validation

Publication validation should confirm:

  • canonical title is correct;
  • Registry Identifier is visible;
  • canonical URL is declared;
  • human-readable SREG is complete;
  • machine-readable SREG is complete;
  • downloadable artifacts are available when required;
  • Source Record and Source Institution links are present;
  • status and lifecycle notices are accurate;
  • version information is visible;
  • relationships and provenance are represented consistently;
  • metadata and page content agree;
  • redirects and historical references are preserved.

Cross-Format Consistency

Registry should compare human-readable and machine-readable forms field by field.

Consistency review should include:

  • Registry Identifier;
  • title;
  • Record Type;
  • Source Institution;
  • Source-System Identifier;
  • canonical source reference;
  • Registry Status;
  • Registry Lifecycle State;
  • Registry Entry Version;
  • Source-Record Version;
  • relationships;
  • provenance;
  • correction references;
  • publication dates.
A SREG is not fully validated when its official formats disagree.

Automated Validation

Applies schemas, controlled values, identifier rules, required fields, formats, cardinality, and machine-readable consistency checks.

Institutional Review

Confirms authority boundaries, meaning, classification, exceptions, provenance, relationships, and publication readiness.

Cross-Artifact Review

Compares HTML, JSON, downloadable records, packages, manifests, and source references.

Historical Review

Confirms corrections, supersession, archived versions, and prior states remain traceable.

Validation Workflow

Prepare SREG → Run Structural Checks → Review Authority and Provenance → Validate Relationships and Versions → Compare Publication Formats → Record Result → Publish or Return for Correction

Validation Record

Every material validation should preserve:

  • Registry Identifier;
  • Registry Entry Version;
  • validation date;
  • validation authority or workflow;
  • requirements and versions applied;
  • checks performed;
  • findings;
  • warnings;
  • exceptions;
  • result;
  • required corrections;
  • revalidation date, when applicable;
  • supporting report or artifact reference.

Operational Validation Implementation

Registry Validation is preserved within the canonical machine-readable SREG through the registry_validation object and reflected in the corresponding human-readable Registry publication.

The inaugural production implementation, SREG-2026-0001, demonstrates this model and has been successfully validated against:

  • SREG Base Schema v1.0;
  • Certification Record-Type Profile v1.0;
  • applicable Registry Controlled Values;
  • Source Authority and Provenance requirements;
  • Registry Relationship requirements;
  • Registry Version requirements;
  • human-readable and machine-readable publication consistency.
A separate validation artifact is not required when the canonical SREG preserves the complete material Validation Record. Registry may publish a separate validation report when additional findings, exceptions, evidence, or operational complexity justify one.
Open Reference Implementation →

Validation Outcomes

  • Valid — all required checks pass.
  • Valid with Warnings — required checks pass, but non-blocking concerns remain documented.
  • Conditionally Valid — publication may proceed only under explicit approved conditions.
  • Invalid — one or more blocking requirements fail.
  • Indeterminate — available evidence or system capability is insufficient to determine validity.
  • Not Evaluated — validation has not yet been completed.
Validation outcome describes the Registry object's conformance. It does not certify the Source Record's substantive truth.

Blocking Error

Prevents publication or continued presentation as a valid operational SREG.

Warning

Identifies a non-blocking concern that should remain visible and reviewable.

Exception

Documents an approved departure from a requirement under defined governance.

Informational Finding

Records context that does not affect validation outcome.

Invalid Conditions

  • missing required field;
  • invalid controlled value;
  • duplicate or reused Registry Identifier;
  • unsupported Source Authority;
  • missing Registrability outcome;
  • incorrect Record Type;
  • broken canonical source reference;
  • missing or contradictory provenance;
  • invalid relationship direction or type;
  • collapsed version domains;
  • incoherent status or lifecycle transition;
  • silent correction;
  • human-readable and machine-readable mismatch;
  • publication before required validation completion.

Revalidation

Revalidation may be required after:

  • Registry Entry update;
  • Source Record version change;
  • schema or profile change;
  • identifier correction;
  • relationship change;
  • provenance correction;
  • status or lifecycle transition;
  • publication-path change;
  • governance exception;
  • material rule or policy update;
  • discovery of a validation defect.

Revalidation should identify which domains changed and whether full or targeted review is required.

Validation and Existing Publication

If a published SREG later fails validation, Registry may:

  • publish a correction notice;
  • return the SREG to review;
  • restrict publication;
  • mark validation as failed or indeterminate;
  • supersede the affected version;
  • revoke or archive the SREG when required;
  • preserve the prior public state for history;
  • publish a corrected Registry Entry Version.
Validation failure should change the Registry condition transparently. It should not erase the historical record.

Relationship to Registrability

Registrability occurs before construction and answers whether Registry should create the SREG.

Validation occurs after construction and answers whether the SREG conforms to the governing requirements.

Relationship to Certification

Registry Validation and Certifier Certification are separate institutional acts.

Registry Validation ≠ Certifier Certification

Registry validates the SREG as a Registry object. Certifier evaluates a certification subject under applicable certification standards and methodology.

Relationship to Attestation

Validation does not create an attestation.

Attestor may issue a distinct trust statement about a record, process, or validation result. Registry may catalog that attestation through a separate SREG.

Relationship to Publication

A production SREG should not be published as valid until required validation is complete.

Publication should preserve:

  • validation outcome;
  • validation date;
  • validated Registry Entry Version;
  • requirements applied;
  • warnings or conditions;
  • revalidation history;
  • validation report reference, when public.

What Validation 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 governmental approval.
  • It does not create endorsement or affiliation.
  • It does not guarantee permanent source availability.
  • It does not eliminate future revalidation.
  • It does not transfer authority from another Suite institution.

Validation Principle

Registry Validation should confirm that each SREG is structurally complete, institutionally coherent, traceable to its source, internally consistent, and ready for accurate publication.

Validation confirms Registry conformance. Certification evaluates a subject. The two must remain institutionally distinct.
Back to Registry → Open Provenance → Open Schemas →
Validation protects the integrity of the Registry object without claiming authority over the source.