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 →