LLM correlation tier decides only 3.5% of links, and the dominant fast/thin path records no fit signal #35

New Issue

2026-08-23T03:20:35-04:00

logan commented

2026-08-23 03:20:35 -04:00

Now that server-26#24 surfaced the LLM fields, the correlation dump can answer what the LLM tier actually does. Over 309 linked calls (2026-08-23, full AI window):

field	value
`corr_llm_action` populated	11 of 309 (3.5%) — 8 `orphan`, 3 `link`
`corr_consensus`	`rules_only` 154, absent 122, `agreed` 22, `tiebreak` 11
`corr_path`	`fast/thin` 194, `new` 98, `fast/disambig` 8, `fast/single` 6, `unit-continuity` 3
`corr_fit_signal` populated	14 of 309 — `unit_overlap` 12, `location_proximity` 1, `tactical_default` 1

This is not a malfunction — it is the design working exactly as written, and the design means the consensus machinery has almost no influence over what gets correlated. llm_correlator.decide() (internal/llm_correlator.py:224-231) returns None on three conditions:

if not settings.gemini_api_key:  return None
if ctx["is_thin_call"]:          return None
if not ctx["recent"]:            return None

The second skips 194 calls (63% of all links, every fast/thin). The third skips most of the 98 new decisions. Between them roughly 94% of traffic never reaches the LLM, which is precisely the 3.5% observed.

Why that matters: fast/thin is simultaneously the most common correlation path and the least audited one. It gets no LLM opinion, and it writes no corr_fit_signal — hence 295 of 309 calls carry no fit signal at all, and the "fit_signal distribution" panel in the admin debug view is empty. server-26#22 bounded the damage from thin-call attach with incident_max_calls / incident_max_duration_minutes, and those caps are holding (nothing in this dump exceeds 40 calls or 120 minutes). But the decision itself is still made by a rule with no recorded reasoning.

The thin-call skip is defensible on its face — a call with no transcript, units or coords gives an LLM nothing to reason about. The question this data raises is whether the cost of the tier is justified when it decides 3.5% of links, and whether fast/thin should be emitting a fit signal so the path that makes most of the decisions is at least reviewable.

Two directions, either is a real improvement:

Make fast/thin record a corr_fit_signal (even a literal thin_auto_attach) so the debug view stops looking broken and the dominant path becomes auditable.
Reconsider the tier's cost/benefit: on current traffic it fires 11 times per 309 calls, of which 11 needed a tiebreak. Either widen what reaches it or drop it and spend the budget on extraction quality (server-26#5, and the titling issue filed alongside this one).

Measured on the 2026-08-23 window; correlation flags were switched back off afterwards.

Now that server-26#24 surfaced the LLM fields, the correlation dump can answer what the LLM tier actually does. Over 309 linked calls (2026-08-23, full AI window): | field | value | |---|---| | `corr_llm_action` populated | **11 of 309 (3.5%)** — 8 `orphan`, 3 `link` | | `corr_consensus` | `rules_only` 154, absent 122, `agreed` 22, `tiebreak` 11 | | `corr_path` | `fast/thin` **194**, `new` 98, `fast/disambig` 8, `fast/single` 6, `unit-continuity` 3 | | `corr_fit_signal` populated | 14 of 309 — `unit_overlap` 12, `location_proximity` 1, `tactical_default` 1 | This is not a malfunction — it is the design working exactly as written, and the design means the consensus machinery has almost no influence over what gets correlated. `llm_correlator.decide()` (`internal/llm_correlator.py:224-231`) returns None on three conditions: ```python if not settings.gemini_api_key: return None if ctx["is_thin_call"]: return None if not ctx["recent"]: return None ``` The second skips 194 calls (63% of all links, every `fast/thin`). The third skips most of the 98 `new` decisions. Between them roughly 94% of traffic never reaches the LLM, which is precisely the 3.5% observed. Why that matters: `fast/thin` is simultaneously the **most common** correlation path and the **least audited** one. It gets no LLM opinion, and it writes no `corr_fit_signal` — hence 295 of 309 calls carry no fit signal at all, and the "fit_signal distribution" panel in the admin debug view is empty. server-26#22 bounded the damage from thin-call attach with `incident_max_calls` / `incident_max_duration_minutes`, and those caps are holding (nothing in this dump exceeds 40 calls or 120 minutes). But the decision itself is still made by a rule with no recorded reasoning. The thin-call skip is defensible on its face — a call with no transcript, units or coords gives an LLM nothing to reason about. The question this data raises is whether the *cost* of the tier is justified when it decides 3.5% of links, and whether `fast/thin` should be emitting a fit signal so the path that makes most of the decisions is at least reviewable. Two directions, either is a real improvement: - Make `fast/thin` record a `corr_fit_signal` (even a literal `thin_auto_attach`) so the debug view stops looking broken and the dominant path becomes auditable. - Reconsider the tier's cost/benefit: on current traffic it fires 11 times per 309 calls, of which 11 needed a tiebreak. Either widen what reaches it or drop it and spend the budget on extraction quality (server-26#5, and the titling issue filed alongside this one). Measured on the 2026-08-23 window; correlation flags were switched back off afterwards.