fast/thin correlation path never uses srcaddr for disambiguation, even though every call already carries it #158

New Issue

2026-09-20T19:11:54-04:00

logan commented

2026-09-20 19:11:54 -04:00

metadata_watcher.py (Client) captures the P25 source radio ID (srcaddr) on every call independent of transcript content. It reaches the server unchanged -- models.py:190 CallRecord.srcaddr, set from the MQTT payload in mqtt_handler.py:245 -- but is never read anywhere in incident_correlator.py or upload.py.

_disambiguate()'s highest-weight signal (unit_overlap, weight 10.0, beats even <2min recency at 8.0) and _call_fits_incident's unit-overlap check both key off call_units, which is populated only by GPT entity extraction in intelligence.py -- skipped entirely for transcript_too_short calls (<=5 words). Those calls are the ones _is_thin_call routes down the fast/thin path, which per its own docstring links "without a fit test," purely by same-talkgroup + most-recently-updated-incident-in-window.

server-26#1ffff25 (2026-09-20) just started letting transcript_too_short calls attempt correlation at all (previously excluded entirely). That's the right direction, but it means exactly this population -- "10-4", "unit 1 on scene", "show me clear" -- now flows through the one path with zero identity-based disambiguation, even though the ground-truth identity (srcaddr) needed to do it right is already sitting on the call doc.

Failure mode: two incidents active on the same dispatch talkgroup at once (normal on a busy channel) -- a short ack from the unit on incident B can silently misattach to incident A merely because A is more recently active. Not an orphan call, a wrong-incident attach, and nothing in corr_debug flags it because thin calls record no fit signal (#35).

Related but distinct from what's already filed: #35 is about fast/thin recording no fit signal at all (auditability); #134 is about the dispatch/tactical name-guess picking the window size for this path. Neither touches the fact that srcaddr -- captured on every call, present in models.py, currently unused -- is a stronger and cheaper signal than time recency and is available even when the call is too short for GPT extraction to run.

Suggested fix: thread srcaddr into _disambiguate/_call_fits_incident as a unit-overlap-equivalent signal (same radio ID on the call and on an incident's prior calls = strong positive), or at minimum use srcaddr equality as a same-talkgroup tie-breaker before falling back to pure recency in _is_thin_call's candidate selection.

`metadata_watcher.py` (Client) captures the P25 source radio ID (`srcaddr`) on every call independent of transcript content. It reaches the server unchanged -- `models.py:190` `CallRecord.srcaddr`, set from the MQTT payload in `mqtt_handler.py:245` -- but is never read anywhere in `incident_correlator.py` or `upload.py`. `_disambiguate()`'s highest-weight signal (`unit_overlap`, weight 10.0, beats even <2min recency at 8.0) and `_call_fits_incident`'s unit-overlap check both key off `call_units`, which is populated *only* by GPT entity extraction in `intelligence.py` -- skipped entirely for `transcript_too_short` calls (<=5 words). Those calls are the ones `_is_thin_call` routes down the fast/thin path, which per its own docstring links "without a fit test," purely by same-talkgroup + most-recently-updated-incident-in-window. server-26#1ffff25 (2026-09-20) just started letting `transcript_too_short` calls attempt correlation at all (previously excluded entirely). That's the right direction, but it means exactly this population -- "10-4", "unit 1 on scene", "show me clear" -- now flows through the one path with zero identity-based disambiguation, even though the ground-truth identity (`srcaddr`) needed to do it right is already sitting on the call doc. Failure mode: two incidents active on the same dispatch talkgroup at once (normal on a busy channel) -- a short ack from the unit on incident B can silently misattach to incident A merely because A is more recently active. Not an orphan call, a *wrong-incident* attach, and nothing in `corr_debug` flags it because thin calls record no fit signal (#35). Related but distinct from what's already filed: #35 is about `fast/thin` recording no fit signal at all (auditability); #134 is about the dispatch/tactical name-guess picking the *window size* for this path. Neither touches the fact that `srcaddr` -- captured on every call, present in `models.py`, currently unused -- is a stronger and cheaper signal than time recency and is available even when the call is too short for GPT extraction to run. Suggested fix: thread `srcaddr` into `_disambiguate`/`_call_fits_incident` as a unit-overlap-equivalent signal (same radio ID on the call and on an incident's prior calls = strong positive), or at minimum use `srcaddr` equality as a same-talkgroup tie-breaker before falling back to pure recency in `_is_thin_call`'s candidate selection.

logan referenced this issue from a commit

2026-09-20 20:22:55 -04:00

correlator: use srcaddr for thin-call disambiguation instead of pure recency (#158)

logan commented

2026-09-20 20:31:16 -04:00