Redirect and Tombstone Policy¶
Policy — instantiates Persistent Identifier Stewardship
Governs what a token resolves to once direct access ends — a redirect to a successor or a tombstone that explains the withdrawal — so continuity survives moves and deletions.
Redirect and Tombstone Policy governs the discontinuity states of a persistent identifier: what a token should resolve to once its original target is no longer directly valid. Its defining commitment is that an identifier must never silently 404 and must never be silently reassigned — so when an entity moves, merges, splits, is superseded, or is withdrawn, the policy decides between two responses: a redirect to the successor or new location, or a tombstone — an explanatory record that says the entity is gone and why. Where the version rule chooses among targets that do exist, this policy handles the case where the naïve target does not, keeping the token resolvable to something meaningful even at the end of the entity's life.
Example¶
An academic journal retracts a published article. The article's DOI has been cited for years, so it cannot be allowed to break, and it must not keep resolving to the original text as though nothing happened. The redirect and tombstone policy handles it: the DOI resolves to a tombstone — a retraction notice stating that the article was retracted, when, on what grounds, and linking to any correction or replacement — while the DOI string itself stays permanent and unchanged.
Contrast the move case. When that same journal migrates from one publisher's platform to another, the policy maps the old DOIs' resolution to the new host — a redirect — so every existing citation keeps landing on the live article at its new home. One policy, two lifecycle events, two responses: a redirect where the entity still exists elsewhere, a tombstone where it does not, and in neither case a silent disappearance.
How it works¶
The policy pairs lifecycle events with resolution responses:
- Enumerate the discontinuity states. Moved, merged, split, superseded, restricted, withdrawn — each is a lifecycle event that changes what the token should return.
- Map each state to a response. A redirect (with a successor pointer) where the entity persists elsewhere; a tombstone (an explanatory status record) where it does not.
- Trigger on the event, preserving provenance. The mapping change fires when the lifecycle event is recorded, and the old binding's history is kept rather than overwritten — the token is never reassigned to a different entity.
- Signal permanence honestly. Use resolution semantics that tell callers whether the change is permanent (a moved-permanently redirect, a gone-and-explained tombstone) or temporary.
Tuning parameters¶
- Redirect-versus-tombstone threshold — how much continuity a successor must have before a redirect is honest rather than a tombstone. Aggressive redirecting preserves links; over-eager redirects imply a sameness that may not hold.
- Tombstone disclosure — how much a tombstone reveals about why an entity was withdrawn. Fuller disclosure aids trust; too much can leak sensitive or legally erasable detail.
- Successor semantics — whether a pointer asserts "same entity, new identifier" or merely "related successor." Precision here prevents false continuity.
- Redirect-chain handling — collapse multi-hop chains to a single hop, or preserve the chain for provenance. Collapsing is fast; preserving keeps history.
- Permanence signaling — which resolution status a moved or withdrawn token returns, so caches and crawlers treat it correctly.
When it helps, and when it misleads¶
Its strength is that continuity survives the events most likely to break it — deletion, migration, merger — because the token keeps resolving to something interpretable instead of vanishing. It embodies the principle that cool URIs don't change:[n1] the address stays put while the world behind it churns, and a reader who follows an old reference always learns the entity's fate.
Its failure modes are two, both about honesty. A tombstone can leak what should stay private — the fact and reason of a withdrawal is sometimes itself sensitive. And a successor redirect can imply continuity that isn't there, pointing an old token at a "replacement" that is actually a different entity, silently corrupting the citation record. The classic misuse is returning a bare not-found for withdrawn content — a silent disappearance — instead of an explanatory tombstone. The discipline is to prefer explanatory resolution over silent breakage, and to state successor relationships precisely enough that no reader mistakes "related" for "the same."
How it implements the components¶
Redirect and Tombstone Policy realizes the discontinuity slice of the archetype — the parts that keep a token meaningful past its target's life:
alias_redirect_and_tombstone_map— it maintains this map: the table binding deprecated, moved, merged, and withdrawn tokens to their redirect or tombstone responses.lifecycle_event_update_rule— it defines which lifecycle events (withdrawal, move, merge, split, supersession) trigger which change to that mapping.
It does NOT choose among currently valid versions (version_selection_policy) — that's Identifier Version Resolution Rule; and it authors the responses but does not itself detect that a live link has rotted (resolution_integrity_monitor — that's Resolution Link Checker). This policy decides the response to a lifecycle event; the checker only detects that one is needed.
Related¶
- Instantiates: Persistent Identifier Stewardship — the policy governs resolution through discontinuity.
- Consumes: Resolution Link Checker — breakage the checker surfaces is one trigger the policy responds to.
- Sibling mechanisms: Persistent Identifier Resolver Service · Resolver Landing Page · Identifier Version Resolution Rule · Custodial Transfer Protocol · Resolution Link Checker · Identifier Registry · Identifier Minting Workflow
Editorial Notes¶
Form Classification¶
Form family: Rule, Policy & Commitment
Rationale: Redirect and Tombstone Policy operates as a standing rule, threshold, contractual commitment, or policy constraint governing future conduct because it governs what a token resolves to once direct access ends — a redirect to a successor or a tombstone that explains the withdrawal — so continuity survives moves and deletions.
Independent corroboration: The frozen evidence defines Redirect and Tombstone Policy as 'Governs what a token resolves to once direct access ends — a redirect to a successor or a tombstone that explains the withdrawal — so continuity survives moves and deletions', so its operative form is Rule, Policy & Commitment.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Library & Information Science
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Specialized
Rationale: Persistent identifiers and tombstone records descend from archival and bibliographic stewardship.
Related originating lineages:
- Computer Science & Software Engineering — Web architecture materially supplies redirects and resolver behavior.
Review resolution: Both blind reviewers agree that library_information_science is the primary origin. Explicit reconciliation of domain reach disagreement adopts reviewer_a's classification because persistent identifiers and tombstone records descend from archival and bibliographic stewardship. The resulting lineage records alternates=computer_science, origin_mode=cross_disciplinary_synthesis, and domain_reach=specialized; these describe formative provenance separately from later applicability.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
The redirect/tombstone split is the practical form of the successor-and-tombstone resolution pattern: a redirect says "still here, moved"; a tombstone says "gone, and here is what happened." Confusing the two — tombstoning what merely moved, or redirecting what was actually withdrawn — is the most common way this policy quietly misleads its readers.
[n1] "Cool URIs don't change" — Tim Berners-Lee's W3C style note arguing that a well-chosen identifier should remain valid indefinitely, and that when a resource moves or disappears the responsible act is a redirect or an explanatory status, never a broken link. Redirect and tombstone policy is that argument turned into operational rules. ↩