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

New Issue

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

logan commented

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

Found reviewing the 2026-08-23 21:00-22:00 AI-on window (964343c confirmed live via /health), the first window with area_context v2 + Maps place verification (#36, #37) deployed.

The defect

Incident 38392161-8553-4647-86b8-8c1b2a18090e, Ossining - Police Dispatch, 3 calls:

location                Post 1-2
location_coords         {lat: 41.1512798, lng: -73.8629919}
location_coords_source  Post 1-2
location_mentions       ["Post 1-2"]
units                   ["1-2", "Lincoln", "Peter", "John", "2-0-2", "Post 1-2"]
title                   Vehicle Assistance at Post 1-2

Post 1-2 appears in both location_mentions and units on the same incident. It is a unit call-sign: the transcripts open "Post 1-2, Ossining. 1-2. Can we have a 47 for that vehicle?", i.e. a unit identifying itself. Place verification resolved it against the Ossining anchor and returned coordinates in Ossining that look entirely plausible and are entirely wrong. The title reads "Vehicle Assistance at Post 1-2" as though it were a place.

A false pin is worse than no pin. No pin is a visible gap; a confident wrong pin puts an incident on the map at a location it never happened, and the anchor check is what makes it land nearby enough to look right.

Scale

1 of only 5 pinned incidents in the window (20% of all pins). 50 incidents total, 45 with no coords at all.

This is not an argument against the feature. The other 4 pins are correct, and two of them (Bucci's Excavating, behind Champa Colas and South High, in front of Scarborough Church) are exactly the landmark-relative phrasing that plain geocoding failed on at the 0820 baseline. Place verification works where it fires. It also fires on unit designators.

Suggested fix

The signal is already present and free: drop any location_mention that also appears in units before geocoding. The same extraction pass produces both lists, so this needs no extra API call. Consider also refusing to verify mentions matching the unit-designator shape (Post N-N, bare N-N-N) even when the unit list missed them.

Separately worth deciding: location_coords_source currently echoes the location string rather than carrying a source type (places_verified / geocode / node). As written it cannot distinguish a verified place from a plain geocode, which makes this class of bug harder to spot in future dumps.

Note: vocabulary_learning_enabled was also on during this window, so learned vocabulary mutated while it ran. That does not explain this finding — the unit/location collision is structural, not a transcription artifact — but it is worth knowing before treating other numbers from this dump as a clean baseline.

Found reviewing the 2026-08-23 21:00-22:00 AI-on window (`964343c` confirmed live via `/health`), the first window with area_context v2 + Maps place verification (#36, #37) deployed. ## The defect Incident `38392161-8553-4647-86b8-8c1b2a18090e`, Ossining - Police Dispatch, 3 calls: ``` location Post 1-2 location_coords {lat: 41.1512798, lng: -73.8629919} location_coords_source Post 1-2 location_mentions ["Post 1-2"] units ["1-2", "Lincoln", "Peter", "John", "2-0-2", "Post 1-2"] title Vehicle Assistance at Post 1-2 ``` `Post 1-2` appears in **both** `location_mentions` and `units` on the same incident. It is a unit call-sign: the transcripts open `"Post 1-2, Ossining. 1-2. Can we have a 47 for that vehicle?"`, i.e. a unit identifying itself. Place verification resolved it against the Ossining anchor and returned coordinates in Ossining that look entirely plausible and are entirely wrong. The title reads "Vehicle Assistance at Post 1-2" as though it were a place. **A false pin is worse than no pin.** No pin is a visible gap; a confident wrong pin puts an incident on the map at a location it never happened, and the anchor check is what makes it land nearby enough to look right. ## Scale 1 of only **5** pinned incidents in the window (20% of all pins). 50 incidents total, 45 with no coords at all. This is not an argument against the feature. The other 4 pins are correct, and two of them (`Bucci's Excavating, behind Champa Colas` and `South High, in front of Scarborough Church`) are exactly the landmark-relative phrasing that plain geocoding failed on at the 0820 baseline. Place verification works where it fires. It also fires on unit designators. ## Suggested fix The signal is already present and free: **drop any `location_mention` that also appears in `units` before geocoding.** The same extraction pass produces both lists, so this needs no extra API call. Consider also refusing to verify mentions matching the unit-designator shape (`Post N-N`, bare `N-N-N`) even when the unit list missed them. Separately worth deciding: `location_coords_source` currently echoes the location string rather than carrying a source *type* (`places_verified` / `geocode` / `node`). As written it cannot distinguish a verified place from a plain geocode, which makes this class of bug harder to spot in future dumps. ## Related - #37 — the place-verification work this rides on - #28 — pre-existing incidents keeping unverifiable pins (different cause, same symptom class) - #6 — `geocode_max_km=40` rejecting legitimate locations (the opposite failure) Note: `vocabulary_learning_enabled` was also on during this window, so learned vocabulary mutated while it ran. That does not explain this finding — the unit/location collision is structural, not a transcription artifact — but it is worth knowing before treating other numbers from this dump as a clean baseline.

logan referenced this issue

2026-08-23 23:21:45 -04:00

Board 2026-08-23 — Operating cadence — FINAL MINUTES #53

logan commented

2026-08-23 23:31:34 -04:00

Fixed in cc038e6, deployed and verified live — /health returns cc038e6326 (Gitea Actions run 559, Deploy to VM: success).

location is now dropped when it matches one of the same scene s own units, before the geocoder sees it. Case- and punctuation-blind, no substring matching, so "1-2 Main Street" survives alongside unit "1-2". 8 new cases in tests/test_incident_identity.py including the real Post 1-2 incident; c2-core suite 250 pass.

Fixed in cc038e6, deployed and verified live — /health returns cc038e63265d7c517ecf950ff54e2473ad5eb99f (Gitea Actions run 559, Deploy to VM: success). location is now dropped when it matches one of the same scene s own units, before the geocoder sees it. Case- and punctuation-blind, no substring matching, so "1-2 Main Street" survives alongside unit "1-2". 8 new cases in tests/test_incident_identity.py including the real Post 1-2 incident; c2-core suite 250 pass.

logan closed this issue

2026-08-23 23:31:34 -04:00

logan referenced this issue

2026-08-30 02:44:06 -04:00

The primary scene's geocode leaks into every other scene's correlation, fabricating a location match #87

logan added the area/map area/transcription

labels 2026-10-05 02:04:30 -04:00

Sign in to join this conversation.