unit-continuity correlation path never writes corr_matched_units, so the debug view can't show why it matched #16

New Issue

2026-08-19T22:34:33-04:00

logan commented

2026-08-19 22:34:33 -04:00

incident_correlator.py, the unit-continuity block (~line 630, corr_debug = {"corr_path": "unit-continuity", "corr_incident_idle_min": ...}) never sets corr_matched_units, unlike fast/single and fast/disambig which call _matching_units(call_units, candidate.get("units")) and populate it whenever fit_signal == "unit_overlap".

Confirmed against production data: every corr_path == "unit-continuity" call in a 100-incident debug_correlation() pull (4 of 4) has corr_matched_units: null, even though the match was in fact unit-driven (verified by re-implementing _normalize_unit/_matching_units locally and intersecting each call's units against its incident's other calls - e.g. incident a8c74c13 call a930bcff (units=["Post 1-2"]) matched anchor call 06a37b07 (units=["5-4","9-0-8","1-2"]) via the normalizer collapsing "Post 1-2" and "1-2" to the same key "12" - real evidence the c09cb72 normalizer change is working, but invisible in /admin/debug/correlation because the field is blank).

This makes the debug view actively misleading for this path: an operator auditing why two calls merged via unit-continuity sees corr_matched_units: null and has no way to tell, from the API response alone, which unit(s) triggered the link. Low severity (doesn't affect correlation behavior, only observability) but a one-line fix: compute _matching_units(call_units, best_unit_inc.get("units")) and add it to that corr_debug dict the same way the other two paths do.

`incident_correlator.py`, the unit-continuity block (~line 630, `corr_debug = {"corr_path": "unit-continuity", "corr_incident_idle_min": ...}`) never sets `corr_matched_units`, unlike `fast/single` and `fast/disambig` which call `_matching_units(call_units, candidate.get("units"))` and populate it whenever `fit_signal == "unit_overlap"`. Confirmed against production data: every `corr_path == "unit-continuity"` call in a 100-incident debug_correlation() pull (4 of 4) has `corr_matched_units: null`, even though the match was in fact unit-driven (verified by re-implementing `_normalize_unit`/`_matching_units` locally and intersecting each call's `units` against its incident's other calls - e.g. incident `a8c74c13` call `a930bcff` (units=["Post 1-2"]) matched anchor call `06a37b07` (units=["5-4","9-0-8","1-2"]) via the normalizer collapsing "Post 1-2" and "1-2" to the same key "12" - real evidence the c09cb72 normalizer change is working, but invisible in `/admin/debug/correlation` because the field is blank). This makes the debug view actively misleading for this path: an operator auditing why two calls merged via unit-continuity sees `corr_matched_units: null` and has no way to tell, from the API response alone, which unit(s) triggered the link. Low severity (doesn't affect correlation behavior, only observability) but a one-line fix: compute `_matching_units(call_units, best_unit_inc.get("units"))` and add it to that `corr_debug` dict the same way the other two paths do.

logan referenced this issue from a commit

2026-08-23 01:30:09 -04:00

Surface LLM correlation fields in debug view; fix unit-continuity path

logan closed this issue

2026-08-23 01:30:09 -04:00

logan added the area/correlation

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

Sign in to join this conversation.