Registry · Controlled Values

Satoshium Registry Controlled Values

Satoshium Registry Controlled Values define the governed vocabularies, enumerations, codes, statuses, lifecycle states, relationship types, validation outcomes, publication notices, and other approved terms used across SREGs and Registry operations.

Controlled Values ensure that human-readable and machine-readable Registry materials use the same institutional language.

Constitutional Position

Controlled Values operate beneath Registry Governance and within the SREG Base Schema, Record-Type Profiles, Rules, Policies, Procedures, Validation, Publication, and Interoperability requirements.

Suite Standards Registry Governance Controlled-Value Sets Schemas and Profiles Published SREGs
Controlled Values define approved language. They do not replace the institutional rules that govern when each value applies.

Why Controlled Values Matter

Without governed values, equivalent concepts may be expressed through inconsistent labels, abbreviations, capitalization, codes, or interpretations.

The Core Question

Controlled Values ask:

Which approved value must Registry use to represent this condition, class, relationship, outcome, or notice?

Registry's Responsibility

Registry must define, version, validate, publish, deprecate, and preserve the controlled vocabularies used in Registry-owned fields.

Registry's Limitation

Registry must not replace source-owned values with Registry terms when the Source Institution remains authoritative for the source-domain field.

Canonical Controlled-Value Model

Value Set Approved Value Definition Usage Rule Schema Field

Controlled-Value Requirements

Every governed value should identify:

  • value-set identifier;
  • value-set title;
  • value-set version;
  • canonical value;
  • machine-readable code;
  • human-readable label;
  • definition;
  • usage rule;
  • authority;
  • effective date;
  • status;
  • aliases or legacy values;
  • replacement value, when applicable;
  • related schema fields;
  • change history.

Canonical

One approved value represents the concept in current Registry materials.

Defined

Every value has a stable institutional definition and usage boundary.

Versioned

Changes to values and value sets preserve prior versions and effective dates.

Validatable

Schemas and Procedures can determine whether a submitted value is approved.

Machine-Readable Controlled Values

Registry now publishes a canonical machine-readable Controlled Values resource alongside this human-readable framework.

Controlled Values Framework controlled-values.json Schemas and Record-Type Profiles Published SREGs
  • Canonical File: controlled-values.json
  • Version: 1.0
  • Authority: Satoshium Registry
  • Effective Date: August 14, 2026
  • Current Machine-Readable Scope: the initial published resource operationalizes the Registry Status value set beginning with the production value Active.
The machine-readable resource does not replace this institutional framework. This page defines the governed meaning and architecture of Controlled Values; controlled-values.json provides the canonical machine-readable publication of value sets as they are formally operationalized.
Open Controlled Values JSON →

Core Controlled-Value Sets

  • Registry Record Types;
  • Registry Status values;
  • Registry Lifecycle States;
  • Source Authority Review Outcomes;
  • Registrability Outcomes;
  • Identifier States;
  • Relationship Types;
  • Relationship Statuses;
  • Validation Outcomes;
  • Validation Finding Classes;
  • Publication Readiness Outcomes;
  • Publication Notice Types;
  • Correction Categories;
  • Access and Restriction Conditions;
  • Custody Types;
  • Provenance Artifact Types;
  • Version Change Classes;
  • Governance Decision Statuses;
  • Policy Statuses;
  • Procedure Statuses;
  • Exception Statuses;
  • Preservation Conditions.

Registry Record Types

Initial Registry Record Types may include:

  • Tool
  • Jurisdiction
  • Media
  • Certification
  • Attestation
  • Signal
  • Event
  • Integrity Reference
  • Workflow
  • Institution
  • Schema
  • Policy
  • Procedure
  • Governance Decision
Final Record Types and Profile assignments remain subject to Registry Governance.

Registry Status Values

Registry Status describes the current Registry condition of the SREG.

  • Pending — under Registry review and not yet operational.
  • Active — valid and currently published for operational use.
  • Restricted — operational but subject to access or publication limits.
  • Disputed — material Registry or source conflict remains unresolved.
  • Superseded — replaced by a successor SREG or Registry representation.
  • Revoked — withdrawn from valid operational use by Registry authority.
  • Retired — intentionally removed from active use without direct revocation.
  • Archived — preserved primarily for historical reference.
Registry Status must remain separate from Source-Record Status, Certification Status, Attestation Status, and Registry Lifecycle State.

Registry Lifecycle States

Registry Lifecycle State describes where the SREG is within its institutional lifecycle.

  • Proposed
  • Under Review
  • Registered
  • Published
  • Updated
  • Superseded
  • Revoked
  • Retired
  • Archived

Permitted transitions and exact semantics remain governed by the Registry Lifecycle framework.

Source Authority Review Outcomes

  • Confirmed — Source Authority is sufficiently established.
  • Confirmed with Conditions — authority is sufficient but limitations apply.
  • Delegated — authority is exercised through a documented delegation.
  • Historical — authority applied historically and remains relevant for provenance.
  • External — authority belongs to an institution outside the Suite.
  • Conflicted — competing authority claims remain unresolved.
  • Insufficient — available evidence does not support Source Authority.
  • Not Evaluated — review has not yet occurred.

Registrability Outcomes

  • Registrable — requirements are satisfied.
  • Conditionally Registrable — registration may proceed under documented conditions.
  • Provisionally Registrable — registration may proceed pending additional review.
  • Restricted Registrable — registration is permitted with access limitations.
  • Historical Registrable — appropriate for historical Registry preservation.
  • Not Registrable — one or more blocking conditions prevent registration.
  • Indeterminate — available evidence is insufficient to decide.
  • Not Evaluated — review has not yet occurred.

Identifier States

  • Reserved — held for a proposed Registry object.
  • Assigned — formally assigned to a SREG.
  • Published — resolves through an official Registry publication.
  • Superseded — remains resolvable but points to a successor context.
  • Revoked — no longer valid for active operational use.
  • Archived — preserved for historical resolution.
Identifier State describes the condition of the identifier. It does not replace Registry Status or Lifecycle State.

Relationship Types

Initial relationship values may include:

  • 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;
  • depends on;
  • dependency of;
  • integrates with;
  • supersedes;
  • superseded by;
  • successor to;
  • predecessor of;
  • derived from;
  • has derivative;
  • version of;
  • archived as;
  • archival representation of.

Relationship Statuses

  • Active
  • Historical
  • Provisional
  • Disputed
  • Superseded
  • Revoked
  • Invalid

Validation Outcomes

  • Valid
  • Valid with Warnings
  • Conditionally Valid
  • Invalid
  • Indeterminate
  • Not Evaluated

These values describe Registry-object conformance. They do not certify the Source Record.

Validation Finding Classes

  • Blocking Error
  • Warning
  • Exception
  • Informational Finding

Publication Readiness Outcomes

  • Ready
  • Ready with Notices
  • Restricted
  • Not Ready

Publication Notice Types

  • provisional publication;
  • restricted source access;
  • source unavailable;
  • validation warning;
  • correction issued;
  • superseded entry;
  • revoked entry;
  • retired entry;
  • archived entry;
  • historical record;
  • disputed relationship;
  • external-source disclaimer;
  • rights or reuse limitation;
  • governance exception;
  • migration notice.

Correction Categories

  • Identifier Correction
  • Source Attribution Correction
  • Classification Correction
  • Provenance Correction
  • Relationship Correction
  • Status Correction
  • Lifecycle Correction
  • Version Correction
  • Publication Correction
  • Schema or Format Correction
  • Typographical Correction

Access and Restriction Conditions

  • Public
  • Public Metadata Only
  • Restricted
  • Controlled Access
  • Internal
  • Withdrawn
  • Unavailable

Custody Types

  • Original Custody
  • Delegated Custody
  • Archival Custody
  • Successor Custody
  • External Custody
Custody describes possession or preservation. It does not establish Source Authority.

Provenance Artifact Types

  • Original Source
  • Canonical Source
  • Derived Artifact
  • Generated Artifact
  • Mirror
  • Archived Snapshot
  • Generation Manifest
  • Integrity Reference
  • Supporting Evidence

Version Change Classes

  • Major
  • Minor
  • Patch
  • Non-Versioned
  • Rollback
  • Migration

Governance Decision Statuses

  • Draft
  • Under Review
  • Approved
  • Active
  • Amended
  • Superseded
  • Retired
  • Archived

Policy and Procedure Statuses

  • Draft
  • Under Review
  • Approved
  • Active
  • Revised
  • Superseded
  • Retired
  • Archived

Exception Statuses

  • Requested
  • Under Review
  • Approved
  • Approved with Conditions
  • Denied
  • Expired
  • Revoked
  • Closed

Preservation Conditions

  • Current
  • Historically Preserved
  • Archived
  • Source Unavailable
  • Partial Preservation
  • Integrity Verified
  • Integrity Unverified
  • Preservation Restricted

Machine-Readable Codes

Controlled Values use stable machine-readable codes while preserving corresponding human-readable labels.

registry_status: "active" Framework examples for additional governed sets: registry_lifecycle_state: "published" validation_outcome: "valid_with_warnings" publication_readiness: "ready_with_notices"
The canonical machine-readable publication is controlled-values.json. Additional value sets and codes should be added there as they are formally operationalized and reconciled with the SREG Base Schema, applicable Record-Type Profiles, and Registry Governance.
Open Controlled Values JSON →

Labels, Codes, and Definitions

Each controlled concept may have:

  • canonical machine-readable code;
  • canonical human-readable label;
  • plain-language description;
  • formal institutional definition;
  • usage conditions;
  • prohibited uses;
  • legacy labels or aliases;
  • replacement value, when deprecated.
Labels may support presentation. Codes support consistency. Definitions preserve meaning.

Aliases and Legacy Values

Registry may preserve aliases for:

  • historic terminology;
  • deprecated labels;
  • prior machine-readable codes;
  • common abbreviations;
  • source-system equivalents;
  • migration compatibility.

Aliases should not replace the current canonical value in new Registry records.

Deprecation and Retirement

When a value is deprecated or retired, Registry should preserve:

  • prior canonical code;
  • prior label;
  • definition;
  • effective period;
  • deprecation or retirement date;
  • reason;
  • replacement value, when applicable;
  • migration guidance;
  • historical interpretation requirements.
A retired value may disappear from new records. It must remain understandable in historical records.

Controlled-Value Versioning

Value-set changes should preserve:

  • prior value-set version;
  • new value-set version;
  • change date;
  • effective date;
  • approval authority;
  • added values;
  • amended values;
  • deprecated values;
  • retired values;
  • replacement mappings;
  • affected schemas and profiles;
  • migration requirements;
  • historical publication.

Controlled-Value Governance

Registry Governance should control:

  • creation of value sets;
  • definitions;
  • codes and labels;
  • usage rules;
  • aliases;
  • inverse relationships;
  • symmetry rules;
  • versioning;
  • deprecation;
  • retirement;
  • migration;
  • exception handling;
  • publication and preservation.

Controlled-Value Validation

Validation should confirm:

  • value belongs to the approved value set;
  • value-set version is declared when required;
  • code and label correspond;
  • deprecated values are not used in new records without authorization;
  • retired values remain interpretable historically;
  • field usage matches the value definition;
  • aliases are not used as canonical values;
  • human-readable and machine-readable forms agree;
  • source-owned values are not replaced improperly;
  • migration mappings are preserved.

Invalid Controlled-Value Conditions

  • unrecognized value;
  • incorrect code;
  • label and code mismatch;
  • value used in the wrong field;
  • deprecated value used without authorization;
  • retired value presented as current;
  • alias used as canonical value;
  • source-owned value overwritten by Registry terminology;
  • undefined inverse relationship;
  • assumed symmetry without governance;
  • missing value-set version when required;
  • human-readable and machine-readable mismatch.

Relationship to Schemas

Schemas identify which fields require Controlled Values and which value sets apply.

Controlled Values define the permitted terms within those fields.

Schemas define structure. Controlled Values define permitted institutional language.

Relationship to Record-Type Profiles

Record-Type Profiles may:

  • require specific Controlled Values;
  • limit a field to a subset of a value set;
  • define type-specific relationships;
  • define type-specific status conditions;
  • require additional notice or provenance values.

Relationship to Source Values

Registry-controlled values and Source-System values should remain distinct when their meanings or authorities differ.

Registry may preserve:

  • original source value;
  • source-value definition;
  • Registry mapping;
  • mapping authority;
  • mapping confidence or limitation;
  • effective mapping version.
Mapping supports interoperability. It does not transfer authority over the source value.

Relationship to Interoperability

Controlled Values support interoperability by giving Suite institutions and external systems stable meanings, codes, and mappings.

Interoperability should preserve:

  • canonical Registry value;
  • external equivalent;
  • mapping direction;
  • mapping authority;
  • mapping version;
  • known semantic differences;
  • deprecation or migration history.

What Controlled Values Do Not Establish

  • They do not create Source Authority.
  • They do not determine Source-Record truth.
  • They do not replace Rules, Policies, or Procedures.
  • They do not certify a record.
  • They do not create an attestation.
  • They do not make similar source and Registry terms identical.
  • They do not permit silent semantic change.
  • They do not erase deprecated or retired meanings.
  • They do not override source-owned vocabularies.
  • They do not expand Registry authority.

Controlled-Values Principle

Registry Controlled Values should provide stable, governed, versioned language that preserves shared meaning across human-readable records, machine-readable data, procedures, validation, publication, and interoperability.

Structure organizes data. Controlled Values preserve meaning. Governance keeps that meaning stable.
Back to Registry → Open Schemas → Open Governance →

Shared systems become trustworthy when the same words preserve the same meaning across every form.