Pre-existing incidents keep an unverifiable map pin until a call links to them #28

New Issue

2026-08-23T01:36:06-04:00

logan commented

2026-08-23 01:36:06 -04:00

server-26#23 (commit 82c8837) made an incident's location_coords valid only when the new location_coords_source field still matches its location. _verified_pin() drops any pin that cannot be tied back to the label.

Every incident written before that commit has no location_coords_source, so its pin is unverifiable — and per CORRELATION_REVIEW_0820.md section 5, 5 of 6 of those pins are on the wrong place. The drop only happens when _update_incident next runs on the incident, i.e. when another call links to it. An idle or already-resolved incident is never touched, so it keeps displaying a known-unreliable pin indefinitely.

Not fixed in that commit because a backfill has to page every historical incidents document against production Firestore, which the authoring machine cannot do.

Fix shape: an admin route (or a script under drb-c2-core/scripts/) that pages incidents and clears location_coords wherever location_coords_source is absent, leaving location and location_mentions intact.

Also tracked in DEFERRED.md (Version 5C root, Server section).

server-26#23 (commit 82c8837) made an incident's `location_coords` valid only when the new `location_coords_source` field still matches its `location`. `_verified_pin()` drops any pin that cannot be tied back to the label. Every incident written before that commit has no `location_coords_source`, so its pin is unverifiable — and per CORRELATION_REVIEW_0820.md section 5, 5 of 6 of those pins are on the wrong place. The drop only happens when `_update_incident` next runs on the incident, i.e. when another call links to it. An idle or already-resolved incident is never touched, so it keeps displaying a known-unreliable pin indefinitely. Not fixed in that commit because a backfill has to page every historical `incidents` document against production Firestore, which the authoring machine cannot do. Fix shape: an admin route (or a script under `drb-c2-core/scripts/`) that pages `incidents` and clears `location_coords` wherever `location_coords_source` is absent, leaving `location` and `location_mentions` intact. Also tracked in DEFERRED.md (Version 5C root, Server section).

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-24 23:03:42 -04:00

P0: standing correlation-quality evaluation procedure (scheduled AI window) #57

logan referenced this issue

2026-08-24 23:29:44 -04:00

Board 2026-08-24 — Unattended operating cadence and GOALS tracking — CTO draft #60

logan referenced this issue

2026-08-24 23:39:09 -04:00

Board 2026-08-24 - Unattended operating cadence and GOALS tracking - FINAL MINUTES #62

logan commented

2026-08-24 23:42:53 -04:00

Board minutes #62 (2026-08-24), section 9. Recording so this does not get quietly marked covered.

#57 recurring correlation dump does not cover this issue and structurally cannot: a passive recurring scan cannot surface a document that nothing links to. #28 is about pre-fix incidents that never get touched again.

This needs the one-time backfill route named in DEFERRED.md:51, not a repeating instrument (CTO draft #60 rec. 3). Not folded into #57.

**Board minutes #62 (2026-08-24), section 9.** Recording so this does not get quietly marked covered. #57 recurring correlation dump **does not** cover this issue and structurally cannot: a passive recurring scan cannot surface a document that nothing links to. #28 is about pre-fix incidents that never get touched again. This needs the **one-time backfill route** named in `DEFERRED.md:51`, not a repeating instrument (CTO draft #60 rec. 3). Not folded into #57.

logan referenced this issue

2026-08-26 09:31:44 -04:00

Scene over-splitting: one radio conversation becomes two incidents #5

logan commented

2026-08-27 02:49:24 -04:00

Extension found by the standing correlation pass, unattended run 2026-08-27 — unconfirmed against live data.

The server-side pin guard cannot cover the call-level case, because the frontend does not go through the server.

_verified_pin (incident_correlator.py:316) only ever runs on incidents. location_coords_source is never written to a call doc at all. Meanwhile drb-frontend/components/MapView.tsx:379-394 draws the incident path polyline straight from call.location_coords, read directly from Firestore in the browser.

So every vertex of a plotted path is an unverified coordinate, and no server-side guard can intervene on it — the read never touches auth.py or the correlator. Tightening _verified_pin further will not fix this.

This matters for the product claim specifically: a pursuit rendered as a PATH is the flagship output, and its vertices are exactly the unguarded values.

Fix shape is one of: write location_coords_source onto call docs and have MapView filter on it, or move the path read behind a server route. Not attempted this run — it is a frontend change and there are zero JS/TS tests in the project, so typecheck is the only safety net.

**Extension found by the standing correlation pass, unattended run 2026-08-27 — unconfirmed against live data.** The server-side pin guard cannot cover the call-level case, because the frontend does not go through the server. `_verified_pin` (`incident_correlator.py:316`) only ever runs on **incidents**. `location_coords_source` is never written to a **call** doc at all. Meanwhile `drb-frontend/components/MapView.tsx:379-394` draws the incident path polyline straight from `call.location_coords`, read **directly from Firestore in the browser**. So every vertex of a plotted path is an unverified coordinate, and no server-side guard can intervene on it — the read never touches `auth.py` or the correlator. Tightening `_verified_pin` further will not fix this. This matters for the product claim specifically: a pursuit rendered as a PATH is the flagship output, and its vertices are exactly the unguarded values. Fix shape is one of: write `location_coords_source` onto call docs and have `MapView` filter on it, or move the path read behind a server route. Not attempted this run — it is a frontend change and there are zero JS/TS tests in the project, so typecheck is the only safety net.

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/correlation area/map

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

logan referenced this issue