Identifier Lifecycle Register¶
Register — instantiates Durable Identifier Binding
Records where each identifier stands in its life — active, deprecated, retired, or superseded — and which identifier replaced which, so a handle is never silently reused or left dead-ending.
An identifier's job is to stay reliable long after the thing it names has changed, moved, split, or been withdrawn — which means the identifier itself has a life, and someone has to keep track of it. Identifier Lifecycle Register is the memory of that life: for each handle it records a status drawn from a defined lifecycle — active, deprecated, retired, superseded — and, when one identifier gives way to another, the explicit link from the old to its replacement. Its distinguishing job is status and succession over time, not the current binding: it does not tell you where a handle points now, it tells you whether that handle is still to be trusted and, if not, what took its place.
Example¶
Internet standards are a living example. RFC 2616 defined HTTP/1.1; it was not deleted when the specification moved on but marked Obsoleted by a later set of RFCs, which were themselves later obsoleted by a newer consolidation. The number 2616 stays permanently resolvable, stamped with its status (now historic) and an explicit forward pointer, so a decade-old citation to it still lands somewhere and still says "superseded — go here instead." A lifecycle register does exactly this bookkeeping: it keeps every retired identifier alive as a signpost rather than letting it rot or, worse, be handed to something new.
How it works¶
Its defining discipline is that identifiers age but are never silently recycled:
- Enforce a status lifecycle. Each identifier holds a state from a small, defined set, and only sanctioned transitions are allowed (active → deprecated → retired, and so on).
- Tombstone, never reuse. Retiring a handle leaves a marker in its place; the token is not returned to the pool for a different referent, which would break every existing reference.
- Record succession explicitly. When a referent is replaced, merged, or split, the register writes the successor–predecessor links so an old handle points forward instead of dead-ending.
Tuning parameters¶
- State vocabulary — how many lifecycle states to distinguish; a richer set (reserved, active, deprecated, retired, historic) is more expressive but heavier to administer than a bare active/retired split.
- Reuse policy — never-reuse (tombstone forever) versus reclaim-after-cooldown; reclamation saves address space but risks a stale reference resolving to the wrong new thing.
- Deprecation lead time — how long a handle sits "deprecated" before "retired," giving downstream consumers a window to migrate.
- Succession cardinality — whether the register allows only one-to-one renames or also many-to-one (merge) and one-to-many (split) succession links.
When it helps, and when it misleads¶
Its strength is preventing the two silent catastrophes of long-lived identifiers: a retired handle being reused for something unrelated — which corrupts every old reference at once — and a superseded handle dead-ending with no pointer to its replacement. It makes "whatever happened to X?" an answerable question years later.
Its weakness is that a register nobody consults is inert: if resolvers and downstream consumers do not check status, the tombstones and successor links change nothing, and the handle looks alive. After repeated merges and splits the succession graph can also tangle into chains that are hard to follow to a current answer. The corrupting misuse is quietly rewriting or back-dating status history to paper over a bad reuse, which defeats the register's entire evidentiary purpose. The discipline is append-only, dated transitions; never reusing a token without an explicit logged policy; and keeping succession chains navigable to a live endpoint. The systems term for the preserved-but-dead marker is a tombstone.[1]
How it implements the components¶
identifier_lifecycle_policy— the register is the enforced state machine: the allowed statuses and the sanctioned transitions between them.successor_predecessor_relation— it records the replaces / replaced-by links so a superseded handle resolves forward rather than dead-ending.
It records status and succession but does not act on them: redirecting a request from an old handle to its successor is the Alias Redirect Table's job, the current binding lives in the Identifier Registry, and the pre-assignment "reserved" state belongs to the Identifier Reservation Queue.
Related¶
- Instantiates: Durable Identifier Binding — it supplies the status and succession memory that lets references survive the referent's own changes.
- Consumes: Identifier Registry — it annotates the identifiers the registry holds with their lifecycle state.
- Sibling mechanisms: Collision Detection Review · Identifier Reservation Queue · Alias Redirect Table · Identifier Registry · Persistent Identifier Resolver · Identifier Minting Workflow · Namespace Prefix Registry · Accession Numbering Protocol · Check-Digit or Format Validation · UUID or Random Token Generator
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Identifier Lifecycle Register operates as a durable record, ledger, register, or trace whose value depends on preserving actual state or history because it records where each identifier stands in its life — active, deprecated, retired, or superseded — and which identifier replaced which, so a handle is never silently reused or left dead-ending
Independent corroboration: The frozen evidence defines Identifier Lifecycle Register as 'Records where each identifier stands in its life — active, deprecated, retired, or superseded — and which identifier replaced which, so a handle is never silently reused or left dead-ending', 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: Persistent-identifier status, deprecation, retirement, supersession, and succession links are canonical information-stewardship concerns.
Related originating lineages:
- Computer Science & Software Engineering — Retained as a formative lineage because the independent reviewer identified it as primary: Tracking minting, binding, retirement, tombstones, and prohibited reuse is a data-systems identity-lifecycle practice.
Review resolution: DataCite’s DOI policy defines identifier states, persistence, metadata maintenance, and non-reassignment. Software registries independently manage technical identifiers, but the lifecycle register’s persistence and stewardship logic is rooted in library/information-science identifier governance. The retained alternate domains identify independent or materially shaping provenance, not downstream reach alone. domain_reach=multi_domain because the mechanism has independent established use in several fields. The encyclopedia entry deliberately composes those lineages.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
- https://support.datacite.org/docs/doi-persistence — DataCite primary policy on DOI persistence and identifier lifecycle stewardship.
Notes¶
The register's whole value is realized only when it is consulted at resolution time: it is a source of truth for status, not an enforcement point. On its own it cannot stop anyone using a retired handle — it can only make the retirement knowable. Pair it with a resolver or redirect that honors its records, or the lifecycle it so carefully tracks stays invisible.
References¶
[1] Kleppmann, Martin. Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems. O'Reilly Media (2017). Uses tombstone for a retained deletion record that marks earlier values as dead for later compaction. registry ↩