Use Maps to verify corrected place names against the talkgroup anchor, and point the induction loop at talkgroups #37

New Issue

2026-08-23T16:16:56-04:00

logan commented

2026-08-23 16:16:56 -04:00

Depends on the revised area_context anchor in server-26#36.

The idea

Today the corrector (internal/transcript_correction.py) is given a reference list and asked to substitute sound-alikes. It has no way to tell whether what it produced is a real place. So "Cool Parts, Illinois" and "Shout out to Optum" are as acceptable to it as a genuine street name — it can only match against what it was handed.

Maps should not be prompt stuffing. Injecting every road and POI in a town would be hundreds of names per request, on a pass that runs on every transcribed call. Use it as a verifier instead, on the handful of location-shaped nouns a transcript actually contains:

The corrector emits a location-shaped noun.
Geocode it, bounded by the talkgroup's anchor (center / radius_km from #36).
Resolves inside the radius → accept, done.
Does not resolve, or resolves outside → search for a sound-alike that does resolve inside the radius.
If one is found, correct to it and propose {term, meaning} to that talkgroup's local_knowledge as a pending entry.

Cost scales with location nouns, not with call volume, and each verified miss permanently improves the reference data for that channel. Google Maps geocoding is already wired up (GOOGLE_MAPS_API_KEY, internal/intelligence.py:441).

No anchor means skip the check. Per #36, a system whose anchor is too wide to discriminate writes no center/radius_km. Verification must then not run at all — a statewide radius would confirm anything inside it and make the check worse than useless.

Re-anchoring the existing geocoder (server-26#6)

The same anchor fixes a live bug. _geocode_location (internal/intelligence.py:469) rejects any result more than geocode_max_km (40 km) from the node:

if dist_km > settings.geocode_max_km:

A node's position is not its jurisdiction. A system can span a county or several, so a node can legitimately sit far from the area a talkgroup covers — which is why #6 says the 40 km cap "may be rejecting legitimate MTA locations". The talkgroup's own anchor is the correct reference; distance-from-node was always a stand-in for it.

Re-pointing the induction loop

vocabulary_induction_loop samples recent transcripts and proposes terms at system level. It should propose at talkgroup level instead, and never promote.

The argument is blast radius. A wrong term on a talkgroup misleads one channel. The same term at system level misleads every channel on that system — including one 400 km away on a statewide system, which is precisely the context poisoning #36's scope rule exists to prevent. And promotion buys little: if a term genuinely applies system-wide, carrying it on several talkgroups costs almost nothing, while auto-promoting a wrong one is expensive to notice.

So: tg-level pending terms only, no automatic promotion. A term appearing across many talkgroups may be worth surfacing to a human as a suggestion; it must not write itself upward.

The verifier above is a better source for this loop than what it does now — a sound-alike that geocodes inside the anchor is evidence, where sampling raw transcripts is guesswork.

Open

What counts as "location-shaped"? The corrector can label its own output, or extraction's location field can be the trigger — the latter is free but arrives later in the pipeline.
Sound-alike search: Maps' own fuzzy matching against a biased region may be enough, or it may need a phonetic pass (metaphone/soundex) over the anchor's place names first.
Radius threshold above which an anchor is discarded as non-discriminating. Needs a number, and it should be a setting.

Depends on the revised `area_context` anchor in server-26#36. ## The idea Today the corrector (`internal/transcript_correction.py`) is given a reference list and asked to substitute sound-alikes. It has no way to tell whether what it produced is a **real place**. So "Cool Parts, Illinois" and "Shout out to Optum" are as acceptable to it as a genuine street name — it can only match against what it was handed. Maps should not be prompt stuffing. Injecting every road and POI in a town would be hundreds of names per request, on a pass that runs on every transcribed call. Use it as a **verifier** instead, on the handful of location-shaped nouns a transcript actually contains: 1. The corrector emits a location-shaped noun. 2. Geocode it, bounded by the talkgroup's anchor (`center` / `radius_km` from #36). 3. Resolves inside the radius → accept, done. 4. Does not resolve, or resolves outside → search for a **sound-alike that does** resolve inside the radius. 5. If one is found, correct to it and propose `{term, meaning}` to that talkgroup's `local_knowledge` as a pending entry. Cost scales with location nouns, not with call volume, and each verified miss permanently improves the reference data for that channel. Google Maps geocoding is already wired up (`GOOGLE_MAPS_API_KEY`, `internal/intelligence.py:441`). **No anchor means skip the check.** Per #36, a system whose anchor is too wide to discriminate writes no `center`/`radius_km`. Verification must then not run at all — a statewide radius would confirm anything inside it and make the check worse than useless. ## Re-anchoring the existing geocoder (server-26#6) The same anchor fixes a live bug. `_geocode_location` (`internal/intelligence.py:469`) rejects any result more than `geocode_max_km` (40 km) **from the node**: ```python if dist_km > settings.geocode_max_km: ``` A node's position is not its jurisdiction. A system can span a county or several, so a node can legitimately sit far from the area a talkgroup covers — which is why #6 says the 40 km cap "may be rejecting legitimate MTA locations". The talkgroup's own anchor is the correct reference; distance-from-node was always a stand-in for it. ## Re-pointing the induction loop `vocabulary_induction_loop` samples recent transcripts and proposes terms at **system** level. It should propose at **talkgroup** level instead, and never promote. The argument is blast radius. A wrong term on a talkgroup misleads one channel. The same term at system level misleads every channel on that system — including one 400 km away on a statewide system, which is precisely the context poisoning #36's scope rule exists to prevent. And promotion buys little: if a term genuinely applies system-wide, carrying it on several talkgroups costs almost nothing, while auto-promoting a wrong one is expensive to notice. So: **tg-level pending terms only, no automatic promotion.** A term appearing across many talkgroups may be worth surfacing to a human as a suggestion; it must not write itself upward. The verifier above is a better source for this loop than what it does now — a sound-alike that geocodes inside the anchor is evidence, where sampling raw transcripts is guesswork. ## Open - What counts as "location-shaped"? The corrector can label its own output, or extraction's `location` field can be the trigger — the latter is free but arrives later in the pipeline. - Sound-alike search: Maps' own fuzzy matching against a biased region may be enough, or it may need a phonetic pass (metaphone/soundex) over the anchor's place names first. - Radius threshold above which an anchor is discarded as non-discriminating. Needs a number, and it should be a setting.

logan referenced this issue from a commit

2026-08-23 18:10:10 -04:00

area_context v2 + Maps place verification (server-26#36, #37)

logan referenced this issue

2026-08-23 22:15:51 -04:00

Place verification geocodes unit call-signs: "Post 1-2" became a real map pin #52

logan referenced this issue

2026-08-23 23:44:46 -04:00

Board 2026-08-23 — Owner goals — FINAL MINUTES #54

logan referenced this issue

2026-08-25 21:30:50 -04:00

Two AI spend paths escape config/ai_features entirely, so "AI is off" is not true and #45 cannot measure spend #76