Satoshium Registry Identifiers

Canonical Identifier Relationship

Registry links these identifiers without collapsing them into one identity domain.

Identifier Domains

• Registry Identifier — identifies the SREG.
• Source-System Identifier — identifies the Source Record within its originating institution.
• External Identifier — identifies the record or subject in a third-party system.
• Version Identifier — identifies a specific version or release.
• Artifact Identifier — identifies a generated report, receipt, record, package, or derivative artifact.
• Relationship Identifier — identifies a governed relationship object when required.
• Integrity Identifier — identifies a hash, signature, timestamp, commitment, or Anchor reference.
• Workflow Identifier — identifies a process, review, validation, or Navigator workflow.

Registry Identifier Requirements

Every production Registry Identifier should be:

• globally unique within Satoshium Registry;
• permanent after assignment;
• non-reusable;
• machine-readable;
• human-recognizable;
• resolvable to the canonical SREG publication;
• independent from mutable titles and URLs;
• independent from Source-System Identifiers;
• preserved after supersession, revocation, retirement, or archival;
• documented through an assignment record;
• validated before publication;
• historically traceable after correction.

Identifier Structure

A production Registry Identifier uses a controlled structure that identifies Registry ownership, issuance year, and sequence without embedding Record Type or other mutable classification meaning.

Illustrative examples:

Assignment Authority

Registry alone assigns Registry Identifiers.

Identifier assignment should occur only after:

• Source Authority review is complete or explicitly provisional;
• Registrability outcome permits progression;
• the proposed SREG is not a duplicate;
• one approved Record Type is selected;
• minimum identity metadata is available;
• identifier namespace is confirmed;
• the next available sequence is reserved;
• the assignment event is recorded.

Identifier Assignment Record

The assignment record should preserve:

• Registry Identifier;
• identifier namespace;
• identifier pattern version;
• Record Type;
• proposed SREG title;
• Source Institution;
• Source-System Identifier;
• assignment date;
• assignment authority;
• Registrability outcome reference;
• status at assignment;
• reservation or publication state;
• supporting workflow reference.

Permanence and Non-Reuse

Once assigned, a production Registry Identifier should never be reassigned to a different SREG.

This applies even when the original SREG becomes:

• superseded;
• revoked;
• retired;
• archived;
• withdrawn from active publication;
• historical;
• unavailable.

Reserved Identifiers

Registry may reserve an identifier before publication when a positive Registrability outcome has been reached and operational construction is underway.

A reserved identifier should preserve:

• reservation date;
• proposed Record Type;
• proposed source reference;
• reservation status;
• expiration or review rule, if any;
• reason for reservation;
• workflow or reviewer reference.

Reserved identifiers must not be silently reused if the proposal is later withdrawn.

Source-System Identifiers

Registry should preserve Source-System Identifiers exactly as assigned by the Source Institution whenever possible.

Registry should not:

• rewrite a Source-System Identifier for stylistic consistency;
• replace it with the Registry Identifier;
• infer an identifier that the Source Institution never assigned;
• treat a URL as an identifier when it is only a location;
• collapse multiple source identifiers into one field;
• hide identifier changes made by the Source Institution.

Multiple Source Identifiers

A Source Record may possess multiple valid identifiers, including:

• institutional identifier;
• repository identifier;
• publication identifier;
• package identifier;
• artifact identifier;
• legacy identifier;
• external standards identifier;
• archive identifier;
• hash or integrity reference.

Registry should preserve each identifier with its domain, issuing authority, purpose, and status.

Aliases and Alternate References

A SREG may preserve aliases that improve discovery without replacing the canonical Registry Identifier.

Aliases may include:

• former titles;
• abbreviations;
• legacy identifiers;
• common names;
• translated names;
• former URLs;
• repository paths;
• external database references.

Identifier Resolution

A published Registry Identifier should resolve to the canonical SREG presentation and expose links to:

• human-readable SREG;
• machine-readable SREG;
• Authoritative Source Record;
• Source Institution;
• Source-System Identifier;
• current Registry Status;
• current Registry Lifecycle State;
• Registry Entry Version;
• correction history;
• supersession or successor relationships;
• archival references.

Canonical URLs

The Registry Identifier should remain independent from the canonical URL, but the canonical URL should resolve the identifier.

If a publication path changes, Registry should preserve redirects and prior references without changing the Registry Identifier.

Identifier Corrections

A Registry Identifier should not be changed merely because:

• the title changes;
• the source URL moves;
• the source version changes;
• the Source Institution changes through succession;
• the SREG is corrected;
• the Registry Status changes;
• the Lifecycle State changes.

Identifier correction should be exceptional and limited to conditions such as:

• assignment collision;
• format defect;
• namespace error;
• misassignment to the wrong SREG;
• security or integrity failure;
• governance-directed migration.

Correction Without Erasure

When an identifier defect requires replacement, Registry should preserve:

• the original identifier;
• the replacement identifier;
• the correction date;
• the reason;
• the governing authority;
• the affected SREG;
• redirect or resolution behavior;
• correction history;
• machine-readable equivalence or replacement relationship.

Supersession and Successor Identifiers

When one SREG is replaced by another, the original Registry Identifier remains permanent and resolvable.

Supersession creates a relationship between identities. It does not overwrite one identity with another.

Version Identifiers

Registry Entry Version must remain separate from Registry Identifier.

The Registry Identifier identifies the continuing SREG. The Registry Entry Version identifies one published state of that SREG.

Identifier Validation

Identifier validation should confirm:

• format matches the approved identifier pattern;
• identifier is unique within the namespace;
• identifier has not been reused;
• year and sequence segments match the approved production pattern;
• assignment record exists;
• Registrability reference exists;
• Registry Identifier and Source-System Identifier are distinct;
• aliases are not marked as canonical identifiers;
• human-readable and machine-readable SREGs agree;
• resolution target exists or is intentionally historical;
• correction and supersession relationships are preserved.

Invalid Identifier Conditions

• duplicate Registry Identifier;
• reused identifier;
• identifier assigned before Registrability approval;
• Source-System Identifier used as Registry Identifier;
• mutable title embedded as required identity;
• incorrect year or sequence segment;
• missing assignment record;
• unresolvable published identifier without historical explanation;
• alias represented as canonical identity;
• silent identifier replacement;
• human-readable and machine-readable mismatch;
• identifier collision across namespaces.

Relationship to Record Types

Registry Record Type does not alter the canonical Registry Identifier pattern.

Record Type remains a separate controlled field within the SREG and must not be inferred from the identifier string.

Relationship to Relationships

Identifiers provide the stable endpoints used by typed Registry relationships.

A relationship should identify:

• source identifier;
• source identifier domain;
• target identifier;
• target identifier domain;
• relationship type;
• direction;
• authority;
• effective date;
• version context.

Relationship to Lifecycle

Registry Lifecycle State may change throughout the SREG's history.

The Registry Identifier remains stable through:

• Pending Registration;
• Registered;
• Active;
• Updated;
• Superseded;
• Revoked;
• Archived.

Lifecycle describes institutional condition. Identifier preserves identity.

Relationship to Publication

Publication should expose the Registry Identifier consistently across:

• page title;
• metadata;
• canonical URL;
• human-readable SREG;
• machine-readable SREG;
• downloadable artifacts;
• relationship objects;
• correction records;
• history and version references.

Suite Identifier Examples

What Identifier Assignment Does Not Establish

• It does not create Source Authority.
• It does not certify the Source Record.
• It does not create legal ownership.
• It does not establish endorsement or affiliation.
• It does not replace Source-System Identifiers.
• It does not guarantee permanent source availability.
• It does not determine Registry Status.
• It does not determine Source-Record Status.
• It does not eliminate versioning requirements.
• It does not permit identifier reuse after retirement.

Identifier Principle

Registry identity must remain permanent, unique, resolvable, and independent from mutable source details.