The primary scene's geocode leaks into every other scene's correlation, fabricating a location match #87

New Issue

2026-08-30T02:44:06-04:00

logan commented

2026-08-30 02:44:06 -04:00

Found by the standing static correlation pass, unattended run 2026-08-30. Static reading only — no live data, no test written yet. Searched open and closed: this is not a duplicate of #80, #28, #37, #6 or the closed #52. Nearest neighbour is #80, and the difference is stated below.

What happens

incident_correlator.py:792:

coords = location_coords or call_doc.get("location_coords")

In the multi-scene loop (routers/upload.py:334) a scene with no location of its own passes location_coords=None. The or fallback then substitutes the call document's coords — and intelligence.py:357-361 wrote those from the primary scene only. Worse, they survive a reprocess in which the new primary scene has no location at all, because doc_set merges rather than replaces.

So for scene 2 and every scene after it on a multi-scene call, the correlator is handed an address that scene never claimed.

Why it matters more than a tuning bug

Three consequences, all pushing the same direction — over-merge:

The scene is no longer thin. _is_thin_call sees truthy coords, so the scene skips the thin-call handling entirely.
It can win the location path at incident_correlator.py:1120-1148 on coordinates belonging to a different scene.
_call_fits_incident then returns location_proximity as the fit signal — the strongest accept evidence the system has.

Only ~7% of calls geocode at all. Those are the single most reliable anti-merge signal available, and this converts a subset of them into a fabricated positive accept. That is the distinction from #80: #80 argues the call-level primary-scene embedding and severity make correlation judge on the wrong basis — a tuning question. This one manufactures evidence that does not exist, which no amount of threshold tuning corrects.

Fix direction (not prescriptive)

Do not fall back to the call document's coords for a non-primary scene. A scene with no location should reach the correlator with no location and be judged thin, which is the honest answer. Either pass the scene index down so the fallback applies only to the primary scene, or drop the or fallback in the scene path entirely. Whichever is chosen, the reprocess-merge behaviour needs its own check — stale coords from a previous primary currently outlive the extraction that produced them.

Not verified

No live data was available this run (AI is off; windows are evening-only and there was nothing new to evaluate). Unmeasured: how often calls are genuinely multi-scene, which sets the blast radius. Worth measuring in the next live window before choosing between the two fix directions.

Refs #80, #5, #28.

Found by the standing static correlation pass, unattended run 2026-08-30. Static reading only — no live data, no test written yet. Searched open and closed: this is **not** a duplicate of #80, #28, #37, #6 or the closed #52. Nearest neighbour is #80, and the difference is stated below. ## What happens `incident_correlator.py:792`: ``` coords = location_coords or call_doc.get("location_coords") ``` In the multi-scene loop (`routers/upload.py:334`) a scene with no location of its own passes `location_coords=None`. The `or` fallback then substitutes the **call document's** coords — and `intelligence.py:357-361` wrote those from the **primary scene only**. Worse, they survive a reprocess in which the new primary scene has no location at all, because `doc_set` merges rather than replaces. So for scene 2 and every scene after it on a multi-scene call, the correlator is handed an address that scene never claimed. ## Why it matters more than a tuning bug Three consequences, all pushing the same direction — **over-merge**: 1. The scene is no longer thin. `_is_thin_call` sees truthy coords, so the scene skips the thin-call handling entirely. 2. It can win the location path at `incident_correlator.py:1120-1148` on coordinates belonging to a different scene. 3. `_call_fits_incident` then returns `location_proximity` as the fit signal — the strongest accept evidence the system has. Only ~7% of calls geocode at all. Those are the single most reliable anti-merge signal available, and this converts a subset of them into a **fabricated positive accept**. That is the distinction from #80: #80 argues the call-level primary-scene embedding and severity make correlation *judge on the wrong basis* — a tuning question. This one *manufactures evidence that does not exist*, which no amount of threshold tuning corrects. ## Fix direction (not prescriptive) Do not fall back to the call document's coords for a non-primary scene. A scene with no location should reach the correlator with no location and be judged thin, which is the honest answer. Either pass the scene index down so the fallback applies only to the primary scene, or drop the `or` fallback in the scene path entirely. Whichever is chosen, the reprocess-merge behaviour needs its own check — stale coords from a previous primary currently outlive the extraction that produced them. ## Not verified No live data was available this run (AI is off; windows are evening-only and there was nothing new to evaluate). Unmeasured: how often calls are genuinely multi-scene, which sets the blast radius. Worth measuring in the next live window before choosing between the two fix directions. Refs #80, #5, #28.

logan referenced this issue from a commit

2026-08-31 02:45:35 -04:00

correlator: stop non-primary scenes inheriting the call doc's pin (#87)

logan referenced this issue

2026-08-31 02:45:53 -04:00

Scene correlation is judged on the call-level (primary-scene) embedding and severity, not the scene it is correlating #80

logan referenced this issue

2026-08-31 02:45:55 -04:00

LLM correlation tier sees the whole-call transcript for every scene, so it cannot separate scenes and pays N times for one prompt #91

logan referenced this issue

2026-09-01 02:43:34 -04:00

Non-primary scenes inherit the primary scene's severity from the call doc, so bdb57ae closed one of three leaks and the other two now carry the weight alone #95

logan commented

2026-09-01 02:44:04 -04:00

Fixed and verified. Closing — commit bdb57ae ("correlator: stop non-primary scenes inheriting the call doc's pin (#87)"), an ancestor of live b722223 and deployed.

Verified by the standing P0 correlation static pass on the unattended run of 2026-09-01, not merely by reading the commit message:

_build_context no longer falls back to the call doc's location_coords when a scene passes none (incident_correlator.py:792-799, which cites this issue directly).
Each scene now geocodes its own location (intelligence.py:309-323), so only genuinely locationless scenes lose coordinates — the fix does not blank out coords wholesale.
recorrelation_sweep.py:96-97 passes both values explicitly, so the sweep path is unchanged and did not silently inherit the new behaviour.
No regression found in the coords path. drb-c2-core is at 290 pass / 0 fail (bdb57ae added one test).

One thing the fix did not do, now tracked separately. The primary-scene leak had three channels into _build_context, and coords was one of them. severity (:784) and embedding (:780) are still read off the call doc, because intelligence.py writes both from processed[0] only while it unions tags, units and vehicles. Removing the coords crutch means those two now carry the full weight of the primary scene's identity alone — the direction of travel is toward over-splitting.

embedding half: #80 (already open)
severity half: #95 (filed today, was untracked)

Neither is a reason to hold this issue open — #87's stated defect is fixed. Recorded in DEFERRED.md so the tracker and that file do not drift.

**Fixed and verified. Closing — commit `bdb57ae` ("correlator: stop non-primary scenes inheriting the call doc's pin (#87)"), an ancestor of live `b722223` and deployed.** Verified by the standing P0 correlation static pass on the unattended run of 2026-09-01, not merely by reading the commit message: - `_build_context` no longer falls back to the call doc's `location_coords` when a scene passes none (`incident_correlator.py:792-799`, which cites this issue directly). - Each scene now geocodes its own location (`intelligence.py:309-323`), so only genuinely locationless scenes lose coordinates — the fix does not blank out coords wholesale. - `recorrelation_sweep.py:96-97` passes both values explicitly, so the sweep path is unchanged and did not silently inherit the new behaviour. - **No regression found in the coords path.** `drb-c2-core` is at 290 pass / 0 fail (`bdb57ae` added one test). **One thing the fix did not do, now tracked separately.** The primary-scene leak had three channels into `_build_context`, and coords was one of them. `severity` (`:784`) and `embedding` (`:780`) are still read off the call doc, because `intelligence.py` writes both from `processed[0]` only while it unions tags, units and vehicles. Removing the coords crutch means those two now carry the full weight of the primary scene's identity alone — the direction of travel is toward over-splitting. - embedding half: **#80** (already open) - severity half: **#95** (filed today, was untracked) Neither is a reason to hold this issue open — #87's stated defect is fixed. Recorded in `DEFERRED.md` so the tracker and that file do not drift.

logan referenced this issue

2026-09-01 02:44:06 -04:00

Scene correlation is judged on the call-level (primary-scene) embedding and severity, not the scene it is correlating #80

logan closed this issue

2026-09-01 02:44:06 -04:00

logan referenced this issue

2026-09-06 15:10:45 -04:00

llm_correlator._call_block reads the whole-call transcript per scene — remaining leg of #80/#95 #102

logan referenced this issue

2026-09-06 15:11:33 -04:00

Scene correlation is judged on the call-level (primary-scene) embedding and severity, not the scene it is correlating #80

logan referenced this issue