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.
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.
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.
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.
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.
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:In the multi-scene loop (
routers/upload.py:334) a scene with no location of its own passeslocation_coords=None. Theorfallback then substitutes the call document's coords — andintelligence.py:357-361wrote those from the primary scene only. Worse, they survive a reprocess in which the new primary scene has no location at all, becausedoc_setmerges 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:
_is_thin_callsees truthy coords, so the scene skips the thin-call handling entirely.incident_correlator.py:1120-1148on coordinates belonging to a different scene._call_fits_incidentthen returnslocation_proximityas 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
orfallback 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.
Fixed and verified. Closing — commit
bdb57ae("correlator: stop non-primary scenes inheriting the call doc's pin (#87)"), an ancestor of liveb722223and 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_contextno longer falls back to the call doc'slocation_coordswhen a scene passes none (incident_correlator.py:792-799, which cites this issue directly).intelligence.py:309-323), so only genuinely locationless scenes lose coordinates — the fix does not blank out coords wholesale.recorrelation_sweep.py:96-97passes both values explicitly, so the sweep path is unchanged and did not silently inherit the new behaviour.drb-c2-coreis at 290 pass / 0 fail (bdb57aeadded 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) andembedding(:780) are still read off the call doc, becauseintelligence.pywrites both fromprocessed[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.Neither is a reason to hold this issue open — #87's stated defect is fixed. Recorded in
DEFERRED.mdso the tracker and that file do not drift.