Identifier Registry¶
Register — instantiates Durable Identifier Binding
The authoritative book of record that holds every identifier-to-referent binding together with the trail of who assigned it and when.
Identifier Registry is the authoritative store where each handle-to-referent binding is recorded as fact, along with the provenance of how it came to be. It is not the thing that resolves a handle to a live location, nor the thing that tracks a handle's lifecycle state, nor the thing that governs namespaces — it is the single place everything else defers to when the question is "what is the authoritative binding for this handle, and who assigned it?" Its defining property is authority: the registry holds the ground truth, and disputes are settled by consulting it rather than by argument or re-description.
Example¶
An internet domain registry — the operator behind a top-level domain such as .org — keeps the authoritative record that example.org is bound to a particular registrant through a particular registrar, with its creation date, its transfer and renewal history, and its current status. When two parties disagree about who holds the name, the registry's record is what decides it; services like WHOIS and RDAP merely expose that record. Crucially, the registry does not translate example.org into a network address — that resolution happens elsewhere. The registry's job is narrower and deeper: to hold the binding and its full provenance as the fact of record.
Any downstream cache, mirror, or directory that answers faster is, by definition, a copy; if it ever disagrees with the registry, the registry wins.
How it works¶
The registry is authoritative-write plus append-only audit. Each binding is a record keyed by the handle, stating the referent it points to and its current standing. Every assignment or change to that record is appended to an audit trail capturing who made it, when, and under what authority — so each binding carries its own history. Reads by other mechanisms (a resolver serving lookups, a lifecycle register checking state) are served from the registry or reconciled back to it. What the registry deliberately does not do is answer operational questions — current location, access rights, retirement state — that belong to mechanisms built on top of it.
Tuning parameters¶
- Authoritativeness scope — whether this registry is the single global source of truth or one authoritative node with downstream mirrors. A sole authority prevents divergence; mirrors improve availability but risk staleness.
- Audit granularity — log only assignments, or every field-level change. Finer audit gives complete provenance at the cost of storage and write speed.
- Record mutability — correct-in-place versus append-only versioning. Append-only preserves full history and supports dispute resolution but complicates reads.
- Openness — fully public (WHOIS-style), gated, or closed. Openness builds trust and eases dereference; it trades against privacy.
- Consistency model — strong versus eventual. Strong consistency stops two authorities registering the same handle; eventual scales further but needs reconciliation for collisions.
When it helps, and when it misleads¶
Its strength is that it gives the whole system one ground truth — a system of record[n1] — so disagreements resolve by lookup rather than negotiation, and provenance is always at hand. Everything from resolution to dispute adjudication becomes tractable once there is exactly one place the answer authoritatively lives.
Its failure mode is drift: a resolver cache or a convenient downstream copy gets treated as authoritative and quietly diverges, or the registry becomes writable by too many hands until its "authority" is fiction. The classic misuse is hammering the registry as a live operational lookup — using the book of record as the query path — which both overloads it and blurs the line between the authoritative record and the fast copies that should serve reads. The discipline is to keep exactly one authoritative registry, serve reads through caches and resolvers, and reconcile those copies back to the registry rather than letting them become rival truths.
How it implements the components¶
Identifier Registry realizes the record-keeping core of the archetype — the components a store owns, not the ones that act on the store:
binding_record— its very content: the authoritative record binding each handle to its referent, and the standing of that binding.assignment_audit_trail— every assignment and change is appended with who, when, and under what authority, giving each binding a traceable provenance.
It does NOT resolve a handle to a live location or apply access policy (that's Persistent Identifier Resolver), track lifecycle state or successor links (that's Identifier Lifecycle Register), or allocate the namespaces handles are minted under (that's Namespace Prefix Registry).
Related¶
- Instantiates: Durable Identifier Binding — the registry is the authoritative store the rest of the archetype defers to.
- Sibling mechanisms: Persistent Identifier Resolver · Identifier Minting Workflow · Accession Numbering Protocol · Alias Redirect Table · Check-Digit or Format Validation · Collision Detection Review · Identifier Lifecycle Register · Identifier Reservation Queue · Namespace Prefix Registry · UUID or Random Token Generator
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Identifier Registry operates as a durable record, ledger, register, or trace whose value depends on preserving actual state or history because it the authoritative book of record that holds every identifier-to-referent binding together with the trail of who assigned it and when
Independent corroboration: The frozen evidence defines Identifier Registry as 'The authoritative book of record that holds every identifier-to-referent binding together with the trail of who assigned it and when', so its operative form is Record, Log & Register.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Library & Information Science
Origin pattern: Convergent development
Present-day reach: Multi-domain
Rationale: A single authoritative register resolving names and identifiers continues the authority-file and catalog-control tradition.
Related originating lineages:
- Computer Science & Software Engineering — Systems of record, service registries, and canonical identity databases independently developed the same governing role.
Review resolution: Both reviewers independently assign library_information_science as the primary originating domain, so that shared primary is retained. Alternate domains are the union of reviewer-identified formative or independently originating lineages; later application settings alone are excluded. The record preserves independently developed forms rather than treating every alternate as mere application. It has established independent use across several domains, but that does not make it domain-free. The encyclopedia entry generalizes the established mechanism without creating a new composite lineage.
Attribution caveat: Bibliographic registries and enterprise-computing registries converge on nearly the same professional form.
Review outcome: Reconciled after independent review; medium confidence.
Notes¶
Three registers divide the labour and should not be conflated: this Identifier Registry holds the binding and its provenance; the Identifier Lifecycle Register tracks each handle's state over time (active, deprecated, retired) and its successor links; the Namespace Prefix Registry governs the namespaces handles are minted under. Keeping them separate is what stops the book of record from swelling into an undisciplined general-purpose database.
[n1] System of record — the enterprise-architecture term for the one data store designated as the authoritative source for a given fact, against which all other copies are reconciled. Naming a single system of record is precisely how an identifier registry earns the authority to settle disputes by lookup. ↩