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.
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 bothlocation_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.
#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.
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.
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.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Found reviewing the 2026-08-23 21:00-22:00 AI-on window (
964343cconfirmed 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:Post 1-2appears in bothlocation_mentionsandunitson 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 ColasandSouth 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_mentionthat also appears inunitsbefore 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, bareN-N-N) even when the unit list missed them.Separately worth deciding:
location_coords_sourcecurrently 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
geocode_max_km=40rejecting legitimate locations (the opposite failure)Note:
vocabulary_learning_enabledwas 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.Fixed in
cc038e6, deployed and verified live — /health returnscc038e6326(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.