Upstream dispatch-vs-chatter classifier — shadow mode #127
Closed
opened 2026-09-12 23:58:06 -04:00 by logan
·
1 comment
No Branch/Tag Specified
Labels
Clear labels
area/ai-pipeline
area/auth
area/billing
area/correlation
area/discord
area/frontend
area/governance
area/growth
area/infra-deploy
area/legal
area/map
area/mqtt
area/node-ota
area/osint
area/recording-audio
area/sdr-radio
area/transcription
board
board:agenda
minutes:draft
minutes:final
role:ceo
role:cfo
role:cio
role:ciso
role:cmo
role:coo
role:cto
Scene/entity extraction, summarizer, AI providers, embeddings
AuthN/Z, roles, tenancy/org scoping, API keys, credentials
Plans, entitlements, AI spend accounting and caps
Incident correlation, linking, lifecycle, severity, corr_debug
Discord bot, radio bots, voice streams, bot tokens, webhooks
Web UI: Next.js app and the edge-node local dashboard
Board process, minutes, unattended runner, agent tooling
Go-to-market, outreach, cold email, discovery conversations
CI/CD, VM, registry, Firestore rules/indexes deploy, Terraform/Caddy
ToS, retention, licences/DAAs, CAN-SPAM, E&O, name suppression
Live map: pins, paths, tiles, legend, geocoding
Node-C2 MQTT, checkins, commands, node sweeper, dynsec
Node install, enrollment, OTA updater, image skew
External feeds: cameras, 511, ADS-B, AIS, outages, and their licences
Call capture, boundaries, PulseAudio, ring buffer, trimming, attribution
OP25 decode, SDR hardware/tuning, conventional, second SDR, mesh radio
STT, transcript correction, place verification, name accuracy
Board process: minutes and board-filed items
Needs board scoping at the next sitting; CEO removes the label once scoped
One exec pre-read, closed by CEO
CEO ruling; open until enacted
Filed by the CEO
Filed by the CFO
Filed by the CIO
Filed by the CISO
Filed by the CMO
Filed by the COO
Filed by the CTO
kind
behavior-bug
Wrong product behavior; the instrument reads it correctly
kind
measurement-bug
Corrupts the recording/instrument (debug data, evals, health checks), not behavior
priority
p0
Drop everything: prod broken, live exposure, or owner-ruled P0
priority
p1
Next up: blocks a gate, a customer, or core incident quality
priority
p2
Normal: real defect or planned work, schedule in turn
priority
p3
Low: minor, cosmetic, or someday
status
blocked
Waiting on an external party, spend, or another issue
status
in-progress
Branch or PR open against it
status
needs-decision
Waiting on an owner or board ruling before work
status
needs-info
Root cause or repro unknown; needs a reading first
type
bug
Something built is wrong: code, data, or a measurement
type
chore
Maintenance, refactor, tests, pinning, cleanup: no user-visible change
type
decision
A ruling to make or record: board minutes, owner calls, legal reviews
type
docs
Docs, runbooks, CLAUDE.md, skills, SOPs
type
feature
New capability or an extension of an existing one
type
security
Security, privacy, credential or tenant-isolation exposure
type
tracking
Tracker, checklist, initiative or punch-list spanning several changes
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: logan/server-26#127
Reference in New Issue
Block a user
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.
Per #115's decision (comments 2026-09-08 and 2026-09-12) and both
CORRELATION_REVIEW_0907b.md/CORRELATION_REVIEW_0912.md: two consensus-layer fixes (#125, #126) have now both measured as no-ops on the top-line new-incident rate. The disagreement shape they target (corr_llm_action==orphan,corr_rules_action==new) is real but structurally small — backtesting a perfect version of that gate against window #3's own data caps out around 14/57 single-call "junk" incidents in a 4h window. 43/57 are outside the gate's scope entirely, and the largest single bucket (15/57) isagreed— both correlator tiers independently called it a new incident, with no disagreement for any consensus-layer fix to arbitrate.Decision (both review docs): stop iterating the consensus layer. Move the fix upstream — a dispatch-vs-chatter classifier in scene extraction (
intelligence.py) so radio housekeeping never produces a scene at all.What this issue ships
drb-c2-core/app/internal/chatter_classifier.py— a pure functionclassify_chatter(transcript) -> (bool, reason)that recognizes two shapes, drawn from hand-labeled examples in the review docs cross-referenced against the real dumps (not invented regexes):roll_call— transcript contains a roll-call announcement or line-up ("stand by for roll call", "Baker 1? Baker 1. Henry 1? ...")bare_acknowledgement— every token in the transcript reduces to a callsign/10-code/unit-ID (any digit-led token) or a small fixed set of procedural filler words ("central", "affirmative", "10-4", "stand by", "show me", "clear", ...). Any other word — a location, an action, a description — leaves the transcript unclassified.Deliberately conservative: when a transcript doesn't cleanly reduce, it returns
(False, None)and the existing pipeline runs exactly as today. Precision over recall — a false positive here would (once live) silently mean a real event never gets a scene.SHIPPED IN SHADOW MODE ONLY.
intelligence.extract_scenesnow computes the verdict alongside the existing_is_garbage_transcript/transcript_too_shortgates and writeschatter_classifier_verdict(bool) andchatter_classifier_reason(str|None) onto the call doc — but does not skip scene extraction. Scene extraction runs exactly as it does today regardless of the verdict. The two fields are now surfaced in/admin's correlation-debug_call_summary, same pattern ascorr_gate_veto(#115/#126), so the next live measurement window can report the real-world false-positive rate before anything is wired to actually skip extraction.Backtest (offline, against the three existing dumps — see PR for script)
corr_dump_9-7_0437am.json(window #1)corr_dump_9-7_pm.json(window #2)corr_dump_9-12.json(window #3)* false positive = a flagged call carrying tags, coords, non-routine severity, or one of the specific transcripts the review docs named as dangerous to drop (the major "extinguishing fire" call, the geocoded 911-hangup call, both pursuit updates, the "6 Alpha... Pelham Station" subject check, the property-retrieval call, the Maronex subject check, the milepost-13.7 trespass call) — all individually re-checked and confirmed
(False, None).Catch rate against a proxy chatter-universe (severity none/routine, no tags, no coords, no resolved incident_type — a superset of true housekeeping that also includes some mid-conversation follow-up fragments of real events, so this undercounts precision on the narrower true-chatter set): 55/343 (16%), 72/271 (27%), 27/201 (13%). Recall is intentionally low — the classifier only recognizes the two shapes above, not every housekeeping pattern (garbled spelled-out roll call like "Five units. Six hundred. Eighty-four. Ten-four.", ambiguous check-ins with a stray content word like "7-4, call Central. 6-9, location.", CID/plate/case-number readbacks that mix in other words) were deliberately left uncaught rather than risk a broader net.
Tests
drb-c2-core/tests/test_chatter_classifier.py— real transcripts pulled from the dumps and review docs, both directions: chatter examples that must classifyTrue, and the review docs' own named-dangerous real events that must classifyFalse.Next step — NOT done here
This is shadow mode only. Nothing skips scene extraction yet. A
# TODO(server-26#<this-issue>)at the call site marks exactly what has to be true before flipping it live: run at least one more live shadow-mode measurement window, confirm the false-positive rate against real production traffic is still zero (this backtest only proves it against three already-collected dumps), and only then wire the verdict to actually skipextract_scenes.Links: #115,
CORRELATION_REVIEW_0907.md,CORRELATION_REVIEW_0907b.md,CORRELATION_REVIEW_0912.md.Review found and fixed two real gaps in the shadow-mode PR (#128, commit
3ae0bb2):transcript_too_shortskip, but 82% of its backtest flags were on ≤5-word transcripts — a live shadow window would have shown roughly a fifth of the real catch rate. Moved the classification ahead of that check, folded into the existingdoc_set(no extra write).admin.py'ssummaryonly had per-call fields, same gapcorr_gate_veto(#126) fixed for the consensus gate. Addedchatter_classifier_flagged/chatter_classifier_reasonto the tally, spanning bothlinkedcalls andorphans— the target population (non-events) lands in both places, solinkedalone undercounts it.Confirmed still zero behavior change: nothing reads the verdict, extraction runs unconditionally either way. Sandboxed pytest 364 green (unchanged from the PR's own count — this was a placement/observability fix, not new logic).
Not fixed, flagged for the go-live decision instead of touched now: the review found the classifier's shapes are riskier than the offline backtest could show —
roll_callmatches "roll call" anywhere in the transcript, not just whole-transcript ("Delayed for roll call, then respond to a structure fire at 12 Main Street" → flagged).All three are harmless in shadow mode (nothing gates on them) but mean a clean shadow-mode window is not sufficient evidence to flip to live — the TODO comment in
intelligence.pynow says so explicitly. Whoever does the live-flip work should tightenroll_callto whole-transcript and special-case digit-hyphen + phonetic-word-as-street-name before trusting a 0-false-positive window.