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:190CallRecord.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.
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.
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:190CallRecord.srcaddr, set from the MQTT payload inmqtt_handler.py:245-- but is never read anywhere inincident_correlator.pyorupload.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 offcall_units, which is populated only by GPT entity extraction inintelligence.py-- skipped entirely fortranscript_too_shortcalls (<=5 words). Those calls are the ones_is_thin_callroutes 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_shortcalls 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_debugflags it because thin calls record no fit signal (#35).Related but distinct from what's already filed: #35 is about
fast/thinrecording 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 thatsrcaddr-- captured on every call, present inmodels.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
srcaddrinto_disambiguate/_call_fits_incidentas a unit-overlap-equivalent signal (same radio ID on the call and on an incident's prior calls = strong positive), or at minimum usesrcaddrequality as a same-talkgroup tie-breaker before falling back to pure recency in_is_thin_call's candidate selection.Fixed in
6c09508, pushed to main and live in prod as of66bbf5b(verified via /health git_sha). 422 pass, 0 fail.