Successor Forwarding Record¶
Forwarding record — instantiates Registry-Mediated Discovery
Leaves a persistent tombstone at a retired key that names its successor, so a caller arriving at the old identifier is explicitly redirected to the current one instead of hitting a dead end, with the supersession on record.
A Successor Forwarding Record is what a registry leaves behind when an entry is retired, moved, merged, or superseded: not a deletion, but a persistent stored record at the old key that declares its lifecycle state and points to the successor. What makes it this mechanism is that the redirect is a durable data artifact — a tombstone with a forwarding target and a timestamp — so any caller still holding the old identifier gets an explicit "this moved; go here" instead of a silent failure. It exists so that turnover in a registry is legible and traversable after the fact: the old key keeps working as a signpost, and the supersession is recorded, rather than the reference simply rotting.
Example¶
An organization retires an old documentation URL, /docs/api/v1/auth, when it restructures its site. Instead of letting the link 404, it leaves an HTTP 301 Moved Permanently response at the old path that names the new location, /reference/authentication. A user who bookmarked the old URL years ago, or a search engine that indexed it, arrives at the retired key and is automatically forwarded — and the redirect is a recorded, permanent statement, not a guess. The same pattern governs persistent identifiers like DOIs: when a dataset is superseded, its record is not deleted but marked with a successor pointer, so a decade-old citation still resolves to something that explicitly says "this was replaced by that." This is the discipline behind cool URIs don't change — an identifier, once published, keeps meaning something by pointing onward rather than dying.[n1]
How it works¶
When an entry reaches end-of-life, the registry does not remove it; it transitions the record to an explicit lifecycle state — retired, moved, merged, split, or superseded — and attaches the successor's identifier (or, for a split, several). A caller resolving the old key receives that state plus the forwarding target, and can follow it: the old reference degrades into a signpost rather than a dead end. The supersession is timestamped and logged, so the chain of who-replaced-whom is auditable long afterward. The mechanism's whole value is in not deleting: because the tombstone persists, references made before the change keep resolving to a meaningful answer, and the history of the identifier's lifecycle is reconstructable from the records themselves.
Tuning parameters¶
- State vocabulary — how many lifecycle outcomes are distinguished (moved vs merged vs split vs superseded). Richer vocabulary lets callers react precisely and asks more of whoever authors the record.
- Chain-following depth — how many successive forwards a resolver will follow before giving up. Deep following survives serial moves but risks loops and latency.
- Tombstone retention — how long a forwarding record is kept. Indefinite retention honors old references forever at a storage-and-clutter cost; expiry reclaims space but breaks the oldest links.
- Redirect permanence — temporary versus permanent (do callers update their reference or keep re-following). Permanent invites callers to rebind; temporary keeps the forward authoritative.
- Audit detail — how much supersession context is logged. Fuller history aids reconciliation disputes and grows the trail.
When it helps, and when it misleads¶
It is the right mechanism wherever identifiers outlive the things they name and old references cannot be recalled — published URLs, citations, catalog keys, account identifiers after a merger. It converts inevitable turnover from silent breakage into explicit, traversable redirection with a paper trail. Its failure modes are chain pathologies: forwarding records accumulate into long redirect chains that slow resolution, or curl into loops (A→B→A after a botched merge), or point at successors that have themselves since died — a forward to another dead end. The classic misuse is treating a forward as a permanent crutch instead of prompting callers to rebind to the current key, so the chain grows forever. The guarding discipline is to detect and collapse chains and loops, and to nudge live callers toward updating their reference rather than re-following indefinitely.
How it implements the components¶
lifecycle_and_successor_state— its defining contribution: the record carries an explicit end-of-life state and names the successor that replaces it.stale_reference_fallback_rule— a caller arriving at the retired key is forwarded to the successor instead of failing, so an old reference degrades gracefully.discovery_audit_trail— the timestamped supersession record makes the chain of replacements reconstructable after the fact.
It vests no authority in people who forward you by judgment — that human registry_authority_and_stewardship is Human Referral Directory, whereas this is a stored, mechanical redirect — and it applies no caller-side resolver_cache_policy, which is Resolver Cache with TTL; a forwarding record is a durable tombstone in the registry, not a person's referral or a consumer's cache.
Related¶
- Instantiates: Registry-Mediated Discovery — the lifecycle machinery that keeps retired keys meaningful by redirecting to their successors.
- Sibling mechanisms: Human Referral Directory · Resolver Cache with TTL · Name Resolution Service · Directory Service · Registry Query API · Catalog or Broker Directory · Service Registry · Federated Registry Synchronization · Lease or Heartbeat Registration
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Successor Forwarding Record operates as a persistent ledger, log, register, or case record that preserves history and traceability because it leaves a persistent tombstone at a retired key that names its successor, so a caller arriving at the old identifier is explicitly redirected to the current one instead of hitting a dead end, with the supersession on record.
Independent corroboration: The frozen evidence defines Successor Forwarding Record as 'Leaves a persistent tombstone at a retired key that names its successor, so a caller arriving at the old identifier is explicitly redirected to the current one instead of hitting a dead end, with the supersession on record', so its operative form is Record, Log & Register.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Universal
Rationale: Persistent redirects and tombstone records are established namespace and API lifecycle mechanisms.
Related originating lineages:
- Engineering & Design — Engineering design, reliability, and systems-safety practice supplies a parallel or contributing lineage for the mechanism's defining operation: leaves a persistent tombstone at a retired key that names its successor, so a caller arriving at the old identifier is explicitly redirected to the current one instead of hitting a….
- Library & Information Science — Authority control records superseded identifiers and successors.
Review resolution: The blind reviewers agree that computer_science is the primary origin and differ only on alternate origin disagreement, domain reach disagreement, encyclopedia synthesis disagreement. I preserve every independently explained alternate from both records rather than imposing a numeric cap. I retain single_lineage because the combined evidence shows one traceable formative lineage. The broader reach of universal records portability separately from historical provenance; encyclopedia_synthesis=true preserves the affirmative synthesis judgment where either reviewer identified one.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Tim Berners-Lee's "Cool URIs don't change" — the principle that a published identifier should keep resolving to something meaningful indefinitely, achieved not by never changing what it points at but by maintaining redirection when the target moves. It is the design rationale for persistent forwarding records over outright deletion. ↩