summarizer reads the whole-call transcript per incident — next leg of the #80/#95/#102 scene-context leak #114

New Issue

2026-09-07T00:12:58-04:00

logan commented

2026-09-07 00:12:58 -04:00

Found by drb-correlation-review while reviewing #102.

drb-c2-core/app/internal/summarizer.py:70-71 reads doc["transcript"] (whole-call) when building an incident summary, and ignores transcript_corrected entirely. Same defect class as #87 (coords), #80/#95 (embedding/severity), #102 (LLM correlation prompt): a multi-scene call contributes text from its other scenes to an incident it was only partially part of, and the summary is built on raw rather than corrected transcription.

This one is user-visible — it lands in the incident summary shown on the incident page.

Fix shape: the summarizer already iterates an incident's linked calls; for each, use that call's scene-relevant text. The per-scene transcript field added to intelligence.py's processed[] in #102 is written to the call doc only as the primary scene's — so either (a) persist per-scene text on the call doc (schema change, overlaps #96's per-scene debug record), or (b) at minimum switch to transcript_corrected or transcript so summaries stop being built on raw transcription. (b) is a one-liner and worth doing now; (a) is the real fix and should ride with #96.

Blocked-by / relates-to: #96 (per-scene call-doc record), #102 (the correlation half of this leak).

Found by drb-correlation-review while reviewing #102. `drb-c2-core/app/internal/summarizer.py:70-71` reads `doc["transcript"]` (whole-call) when building an incident summary, and ignores `transcript_corrected` entirely. Same defect class as #87 (coords), #80/#95 (embedding/severity), #102 (LLM correlation prompt): a multi-scene call contributes text from its *other* scenes to an incident it was only partially part of, and the summary is built on raw rather than corrected transcription. This one is **user-visible** — it lands in the incident summary shown on the incident page. **Fix shape:** the summarizer already iterates an incident's linked calls; for each, use that call's scene-relevant text. The per-scene `transcript` field added to `intelligence.py`'s `processed[]` in #102 is written to the call doc only as the primary scene's — so either (a) persist per-scene text on the call doc (schema change, overlaps #96's per-scene debug record), or (b) at minimum switch to `transcript_corrected or transcript` so summaries stop being built on raw transcription. (b) is a one-liner and worth doing now; (a) is the real fix and should ride with #96. Blocked-by / relates-to: #96 (per-scene call-doc record), #102 (the correlation half of this leak).

logan referenced this issue

2026-09-07 00:13:14 -04:00

correlator: LLM tier reads the scene transcript, not the whole call (#102) #112

logan referenced this issue from a commit

2026-09-13 13:25:45 -04:00

correlator+summarizer: per-scene call-doc storage, fixes #96 and #114's real fix

logan referenced this issue

2026-09-13 13:26:11 -04:00

correlator+summarizer: per-scene call-doc storage, fixes #96 and #114's real fix #132

logan commented

2026-09-13 13:26:29 -04:00

Fixed in #132 (fix/96-114-per-scene-call-doc), option (a) from the issue's fix shape (the real fix, riding with #96 as predicted).

Each scene's own text is now persisted on the call doc under scenes.<scene_index>.transcript (server-26#96's new map), alongside which incident_id that scene resolved to. summarizer.py's new _scene_text_for_incident reads a linked call's scenes map and picks only the scene(s) whose incident_id matches the incident being summarized, joining more than one if several scenes landed in the same incident.

Also did the one-liner half (b) regardless, for calls with no scenes field (predates this change): falls back to transcript_corrected or transcript instead of raw transcript.

14 new tests (including an end-to-end _summarize_incident test proving a 2-scene call only contributes its incident-relevant scene's text, not the whole-call blend), full suite 364 -> 378 passed.

Fixed in #132 (fix/96-114-per-scene-call-doc), option (a) from the issue's fix shape (the real fix, riding with #96 as predicted). Each scene's own text is now persisted on the call doc under `scenes.<scene_index>.transcript` (server-26#96's new map), alongside which `incident_id` that scene resolved to. `summarizer.py`'s new `_scene_text_for_incident` reads a linked call's `scenes` map and picks only the scene(s) whose `incident_id` matches the incident being summarized, joining more than one if several scenes landed in the same incident. Also did the one-liner half (b) regardless, for calls with no `scenes` field (predates this change): falls back to `transcript_corrected or transcript` instead of raw `transcript`. 14 new tests (including an end-to-end `_summarize_incident` test proving a 2-scene call only contributes its incident-relevant scene's text, not the whole-call blend), full suite 364 -> 378 passed.

logan referenced this issue from a commit

2026-09-13 13:33:55 -04:00

correlator: delete stale scenes on re-extraction instead of leaving them to rot (#96/#114)

logan referenced this issue

2026-09-13 13:34:18 -04:00

corr_debug is overwritten per scene on the shared call doc, so #35's "LLM tier decides 3.5% of links" is a per-call blend and cannot answer whether the tier works #96

logan commented

2026-09-13 13:34:18 -04:00

Review found and fixed one blocker (commit 0fe6d3b):

Blocker — stale scenes entries survived re-extraction. PATCH /calls/{id}/transcript wipes tags/severity/location/units/embedding before re-running extraction, but not scenes, and doc_set(merge=True) can only add/overwrite nested map keys, never remove one. A call corrected from 3 scenes down to 1 kept scenes.1/scenes.2 with pre-correction transcripts and incident_ids forever — corrupting the exact per-scene tally #96 exists to make trustworthy, and able to re-feed stale text into #114's summarizer fix if a stale scene's incident_id still named a real incident. Fixed with fstore.doc_update(..., {"scenes": fstore.DELETE_FIELD}) — a real delete, not a merge over {}. Added fstore.DELETE_FIELD (re-exports the real sentinel) and a matching stub entry in tests/conftest.py, which didn't have one. New test: tests/test_reprocess_clears_stale_scenes.py.

Also softened an overclaiming docstring — the Firestore nested-merge behavior is verified against the doc_set wrapper's pass-through code and Firestore's documented contract, not against a live Firestore instance (no SDK available in any sandbox this landed from).

Sandboxed pytest: 378 → 380, all green.

Not fixed, noted instead (non-blocking, safe by construction): the manual-attach endpoint and any future #131 relink both skip writing a scenes entry. summarizer._scene_text_for_incident falls back to whole-call transcript_corrected or transcript when no scene matches — the old #114 behavior, not an error, no data loss, just not the full per-scene fix on those two paths. Worth a follow-up if #131's relink bug turns out to be common.

Review found and fixed one blocker (commit `0fe6d3b`): **Blocker — stale `scenes` entries survived re-extraction.** `PATCH /calls/{id}/transcript` wipes `tags`/`severity`/`location`/`units`/`embedding` before re-running extraction, but not `scenes`, and `doc_set(merge=True)` can only add/overwrite nested map keys, never remove one. A call corrected from 3 scenes down to 1 kept `scenes.1`/`scenes.2` with pre-correction transcripts and `incident_id`s forever — corrupting the exact per-scene tally #96 exists to make trustworthy, and able to re-feed stale text into #114's summarizer fix if a stale scene's `incident_id` still named a real incident. Fixed with `fstore.doc_update(..., {"scenes": fstore.DELETE_FIELD})` — a real delete, not a merge over `{}`. Added `fstore.DELETE_FIELD` (re-exports the real sentinel) and a matching stub entry in `tests/conftest.py`, which didn't have one. New test: `tests/test_reprocess_clears_stale_scenes.py`. Also softened an overclaiming docstring — the Firestore nested-merge behavior is verified against the `doc_set` wrapper's pass-through code and Firestore's documented contract, not against a live Firestore instance (no SDK available in any sandbox this landed from). Sandboxed pytest: 378 → 380, all green. **Not fixed, noted instead (non-blocking, safe by construction):** the manual-attach endpoint and any future #131 relink both skip writing a `scenes` entry. `summarizer._scene_text_for_incident` falls back to whole-call `transcript_corrected or transcript` when no scene matches — the old #114 behavior, not an error, no data loss, just not the full per-scene fix on those two paths. Worth a follow-up if #131's relink bug turns out to be common.

logan referenced this issue from a commit

2026-09-13 13:34:20 -04:00

Merge pull request 'correlator+summarizer: per-scene call-doc storage, fixes #96 and #114's real fix' (#132) from fix/96-114-per-scene-call-doc into main

logan referenced this issue

2026-09-13 17:33:31 -04:00

Board 2026-09-13 — Beachhead checkpoint miss and dev-progress review — CTO draft #141

logan referenced this issue

2026-09-13 18:49:36 -04:00

Board 2026-09-13 — Beachhead checkpoint miss and dev-progress review — FINAL MINUTES #146

logan commented

2026-09-14 00:34:01 -04:00

Fixed and merged (PR #132, commits fae84a4 + 0fe6d3b) — confirmed live on main: summarizer.py has _scene_text_for_incident, reads per-scene text keyed by which incident that scene resolved to. This was already done, just never closed. Closing now.

Fixed and merged (PR #132, commits fae84a4 + 0fe6d3b) — confirmed live on main: `summarizer.py` has `_scene_text_for_incident`, reads per-scene text keyed by which incident that scene resolved to. This was already done, just never closed. Closing now.

logan closed this issue

2026-09-14 00:34:01 -04:00

logan added the area/ai-pipeline

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

Sign in to join this conversation.