Registry · Structural Architecture

Satoshium Registry Schemas

Registry Schemas define the structure, constraints, controlled values, relationships, and validation requirements used by Satoshium Registry Entries, or SREGs.

Schemas preserve one shared Registry architecture while allowing Record-Type Profiles to add controlled requirements for different kinds of Source Records.

Constitutional Position

Suite Schema Standard → Registry Schema Specification → SREG Base Schema → Record-Type Profile → Published SREG
Registry Schemas implement Suite-wide structural expectations without replacing Source Institution schemas or source-owned records.

What a Registry Schema Does

A Registry schema defines what a SREG must contain, which values are permitted, how relationships are expressed, how versions are recorded, and how official publication forms are validated.

It may define:

  • required fields;
  • optional fields;
  • field types;
  • controlled values;
  • identifier formats;
  • relationship structures;
  • status and lifecycle values;
  • version fields;
  • date formats;
  • reference requirements;
  • validation rules.

Suite Schema Standard

Defines Suite-wide structural expectations for identifiers, versions, dates, references, relationships, authority attribution, and machine-readable publication.

Registry Schema Specification

Defines Registry-wide structural rules, controlled values, validation behavior, schema versioning, and publication requirements.

SREG Base Schema

Defines the common fields and behaviors shared by every operational SREG, regardless of Record Type.

Record-Type Profile

Extends the SREG Base Schema with type-specific requirements for Tool, Jurisdiction, Media, Certification, Attestation, Signal, and future approved types.

SREG Base Schema

The SREG Base Schema should define common fields such as:

  • Registry Identifier;
  • title;
  • Registry Record Type;
  • Source Institution;
  • Authoritative Source Record;
  • Source-System Identifier;
  • Registry Status;
  • Registry Lifecycle State;
  • Source-Record Status;
  • Registry Entry Version;
  • Source-Record Version;
  • schema version;
  • Record-Type Profile version;
  • public references;
  • typed relationships;
  • registration date;
  • last updated date;
  • correction and historical references.
The Base Schema defines shared Registry structure. Record-Type Profiles add only the requirements needed for a specific type.

Tool Record-Type Profile

Adds fields for Tool Class, institutional purpose, operational function, maintainer, implementation status, dependencies, repositories, and integrations.

Jurisdiction Record-Type Profile

Adds fields for Jurisdiction Class, canonical and alternate names, parent jurisdiction, geographic codes, hierarchy, and historical relationships.

Media Record-Type Profile

Adds fields for Media Class, format, subject, publisher, platform, language, visibility, rights, access, and integrity references.

Certification Record-Type Profile

Adds fields for Certification Identifier, certified subject, class, outcome, Certification Status, standards, methodology, scope, evidence, and Certifier artifacts.

Attestation Record-Type Profile

Adds fields for attestation classification, attested subject, statement, evidence references, Attestor status, and trust-related relationships.

Signal Record-Type Profile

Adds fields for Signal Class, signal statement, chronology, originating channel, associated event or subject, and discovery relationships.

Authority Separation

Registry Schemas govern Registry-owned SREG structure.

They do not govern or overwrite the internal schema of the Source Institution.

Source schemas define source records. Registry schemas define how those records are cataloged through SREGs.

Identifier Requirements

Registry Schemas must preserve identifier domains separately.

  • Registry Identifier identifies the SREG.
  • Source-System Identifier identifies the Authoritative Source Record.
  • Certification Identifier identifies a certification.
  • Attestation Identifier identifies an attestation when applicable.
  • Integrity Reference Identifier identifies an Anchor-owned record when applicable.
Identifiers may be related. They must not be collapsed into one field.

Status and Lifecycle Requirements

Registry Schemas must distinguish:

  • Registry Status;
  • Registry Lifecycle State;
  • Source-Record Status;
  • Certification Status;
  • attestation status;
  • tool implementation status;
  • media publication or access status.

A controlled value from one status domain must not be reused as though it belongs to another domain without an explicit mapping.

Version Requirements

Registry Schemas should preserve independent version fields for:

  • 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.

Relationship Requirements

Registry Schemas should represent relationships as typed, attributable, directional structures.

A relationship may include:

  • relationship type;
  • source identifier;
  • target identifier;
  • direction;
  • target institution;
  • effective date;
  • status;
  • version or historical context;
  • supporting reference.

Validation

Schema validation should confirm:

  • required fields are present;
  • field types are correct;
  • controlled values are approved;
  • identifiers conform to expected formats;
  • required relationships exist;
  • relationship targets are valid;
  • status and lifecycle values belong to the correct domains;
  • version metadata is complete;
  • dates use approved formats;
  • human-readable and machine-readable forms agree materially.
Registry schema validation confirms SREG structure. It does not certify, attest to, or independently verify the Source Record.

Human-Readable and Machine-Readable Publication

A SREG may be represented through:

  • human-readable Registry Entry HTML;
  • machine-readable SREG JSON;
  • catalog indexes;
  • relationship indexes;
  • version histories;
  • correction records;
  • supersession, revocation, retirement, and archival records.

Official forms must preserve equivalent institutional meaning.

Schema Versioning

Every published schema should include:

  • schema name;
  • schema identifier;
  • schema version;
  • status;
  • effective date;
  • superseded version, when applicable;
  • compatibility notes;
  • migration guidance;
  • validation references;
  • changelog reference.

Prior schema versions should remain preserved and discoverable.

Schema Migration

Schema migration should preserve:

  • prior schema version;
  • new schema version;
  • migration date;
  • changed fields;
  • transformation rules;
  • validation result;
  • prior SREG version;
  • replacement SREG version;
  • compatibility or breaking-change notes.
Schema migration changes Registry structure. It does not necessarily mean the Source Record changed.

Relationship to Rules, Policies, and Procedures

Schemas, Rules, Policies, and Procedures serve different functions.

Rules → Policies → Procedures → Schemas → Validated SREG
  • Rules define foundational requirements.
  • Policies define domain-specific obligations.
  • Procedures define repeatable operational steps.
  • Schemas define the structure that must validate.

Interoperability

Registry Schemas support interoperability by preserving:

  • source attribution;
  • stable identifiers;
  • typed relationships;
  • version references;
  • status mappings;
  • canonical public references;
  • machine-readable publication;
  • authority boundaries.
Interoperability connects institutional objects. Schema design must not collapse institutional authority.

Schema Governance

Registry Schemas should be reviewed when:

  • Suite Standards change;
  • Suite Methodology changes;
  • Registry Rules change;
  • new Record Types are introduced;
  • identifier architecture changes;
  • status or lifecycle frameworks change;
  • new relationship types are introduced;
  • publication formats change;
  • validation failures reveal ambiguity;
  • interoperability requirements change.

Material schema changes should be versioned, documented, and preserved in the Registry Changelog.

One shared SREG model. Controlled profiles. Distinct authority. Consistent publication.