Site Lineage Tombstone¶
Retirement record — instantiates Persistent Site Framing
Marks a retired, split, or merged site and points old references to its successor, so decommissioning leaves a trail instead of a dangling gap.
A Site Lineage Tombstone is the marker a site leaves behind when it stops existing as itself — retired, subdivided, merged, or relocated. Its defining move is that the end of a site is a recorded event with a forwarding address, not a silent deletion: the tombstone preserves the fact that the site once existed, when and why it ended, what (if anything) succeeded it, and enough anchoring context that references written against the old site still resolve. Where the ledger tracks the succession of occupants through a living site, the tombstone tracks the fate of the site itself at the moment it ceases to be a valid host position. It is the difference between a retired site that dangles and one that says "I became this."
Example¶
A platform team is decommissioning an aging application server whose hostname, orders-db-03, is referenced in dozens of runbooks, dashboards, and config files. Simply deleting it would leave every one of those references pointing at nothing — the software equivalent of a demolished building whose address still appears on old letters. Instead the team writes a Site Lineage Tombstone: orders-db-03 is marked retired as of the migration date, with the reason (consolidation), and a supersession pointer to the two shards that replaced it, orders-db-04a and orders-db-04b. The tombstone also carries the anchor context an old reference needs — the datacenter, the service, the namespace — so a stale runbook mentioning orders-db-03 can be resolved to its successors rather than hitting a void.
Nobody is admitted to orders-db-03 again; it hosts nothing. But its lineage is legible: an engineer who finds the old name six months later learns immediately that the site was retired, why, and where its role went.
How it works¶
The tombstone is a durable record created at a site's end-of-life and never reopened for occupancy. It captures four things: the supersession relation (retired / split-into / merged-with / moved-to, with pointers to successors), the timing and reason of the change, the anchor context needed to interpret references made against the old site, and a status that marks the site as no longer assignable. Two disciplines matter. First, the token is retired, not recycled: the old handle is never reissued to a different site, or the tombstone would resolve old references to the wrong place. Second, the forwarding is explicit: a split records all successors, a merge records the absorbing site, so lineage can be traversed in either direction. The tombstone consumes the registry entry it closes and hands nothing to the live turnover machinery — it is strictly about the afterlife of the site.
Tuning parameters¶
- Lineage depth — whether the tombstone records only the immediate successor or the full chain back to origin. Deep lineage supports long-range reference resolution but accumulates and must be maintained; shallow lineage is cheap but breaks multi-hop history.
- Anchor completeness — how much interpreting context the tombstone preserves. Rich context resolves more stale references unambiguously but can retain sensitive location detail past a site's life.
- Token quarantine period — how long a retired token is barred from reuse (or forever). Long quarantine protects old references but exhausts the namespace; short quarantine recycles handles but risks collisions with lingering references.
- Successor cardinality handling — how splits and merges are represented (one-to-many, many-to-one). Explicit multiplicity keeps traversal honest but complicates the record.
When it helps, and when it misleads¶
The tombstone's strength is that it prevents dangling references — the site-level analogue of link rot, where a decommissioned resource leaves every pointer to it broken.[n1] By retiring a site with a forwarding record, it keeps long-lived references interpretable and lets systems distinguish "this site never existed" from "this site was retired and became that."
Its failure mode is false persistence: a tombstone written too weakly — retiring the site but not recording the successor, or recycling the token — leaves history that looks continuous but silently misdirects, which is worse than an honest gap. The opposite misuse is ghost assignability: marking a site "retired" while leaving it technically assignable, so an occupant lands on a site that no longer exists. The guarding discipline is to make retirement a hard, non-assignable status, always record the successor (or an explicit "none"), and never reuse a retired token while references to it may still exist.
How it implements the components¶
The tombstone fills the archetype's end-of-life components:
site_supersession_record— it records that the site was retired, split, merged, or moved, with explicit pointers to whatever succeeded it.context_anchor_metadata— it preserves the anchoring context (namespace, location, service) that lets references written against the retired site still be interpreted and forwarded.
It concerns the site's own fate, not its occupants. The running history of who occupied the site while it lived — occupancy_relation_record and occupancy_history_ledger — is the Occupancy Ledger's, its nearest twin (the ledger records occupant succession within a live site; this tombstone records the site's retirement).
Related¶
- Instantiates: Persistent Site Framing — the tombstone is the archetype's lifecycle-closure record, preserving lineage past a site's end.
- Consumes: Site Registry — supplies the entry the tombstone closes and the token it retires.
- Sibling mechanisms: Site Registry · Physical or Virtual Labeling System · Site Map or Plan · Capacity-Fit Matrix · Assignment and Release Workflow · Occupancy Ledger · Vacancy Status Dashboard · Site Audit Walkthrough
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Site Lineage Tombstone operates as a persistent ledger, log, register, or case record that preserves history and traceability because it marks a retired, split, or merged site and points old references to its successor, so decommissioning leaves a trail instead of a dangling gap.
Independent corroboration: The frozen evidence defines Site Lineage Tombstone as 'Marks a retired, split, or merged site and points old references to its successor, so decommissioning leaves a trail instead of a dangling gap', so its operative form is Record, Log & Register.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Library & Information Science
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Leaving a durable deprecation notice that redirects old identifiers to successors is identifier and metadata stewardship. DataCite's tombstone practice preserves citation continuity for deleted or changed resources; planning supplies the site entity.
Related originating lineages:
- Architecture & Urban Planning — architecture_urban_planning contributes architecture and spatial planning to this mechanism's defining operation—Marks a retired, split, or merged site and points old references to its successor, so decommissioning leaves a trail instead of a dangling gap—without displacing the selected primary historical lineage.
- Computer Science & Software Engineering — Database tombstones and redirects prevent dangling references after merge or deletion.
- History & Historiography — Lineage links retain the historical identity of changed sites.
- Law & Governance — Successor records preserve jurisdiction and obligation continuity.
Review resolution: The blind reviewers disagree on primary lineage (library_information_science versus architecture_urban_planning). Authoritative or primary research supports library_information_science as the best historical origin: Leaving a durable deprecation notice that redirects old identifiers to successors is identifier and metadata stewardship. DataCite's tombstone practice preserves citation continuity for deleted or changed resources; planning supplies the site entity. The cited DataCite, Best Practices for Tombstones and Successor Records directly supports the mechanism's defining operation. All independently supported contributing domains are retained without an arbitrary cap. origin_mode=cross_disciplinary_synthesis records lineage, while domain_reach=multi_domain records later applicability separately from provenance.
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:
Notes¶
[n1] Link rot is the decay of references as the resources they point to move or disappear, leaving pointers that no longer resolve. On the web the disciplined answer is an explicit redirect (HTTP 301) or an honest "410 Gone"; a site lineage tombstone is the same discipline for physical or logical host positions — retire the site, but leave a forwarding record. ↩