---
name: a-witness-that-samples-a-level-cannot-prove-an-outcome
description: "TWO test defects in one day (FLAKE-LEDGER rows 46 and 49), same class: a witness asserted an INSTANTANEOUS level the product is entitled to lower, so a thing that demonstrably happened read as never happening. Product innocent both times. Fix is a MONOTONIC counter, never a shorter poll."
metadata:
  node_type: memory
  type: feedback
---

**2026-09-07, spt-core, two independent cells, same shape, both landed as test-only fixes.**

| | row 46 — `daemon_resume_leaves_zero_brain_subscribers` | row 49 — `twohost_web two_host_web_role_b` |
|---|---|---|
| witness read | `viewers.len()` after a barrier | peer rows in `brain.net_streams()`, polled 250 ms |
| who lowers it | the PRODUCER — `push_frame_to_viewers` evicts + `viewers.remove(&vid)` when a bounded channel fills | the dispatcher's own worker retires the row in its `Served` arm (`retire_stream` flag-filter OR `retire_stream_terminal` removal — TWO paths) |
| symptom | `Some(0)` viewers while the broker log showed `SUBSCRIBE_DECISION decision=viewer` already landed | `0 of 3` streams while `WEB_STREAM` breadcrumbs showed all three served (200 / 206 / 403) |
| fix | assert `next_viewer_id` ADVANCED (monotonic, never decrements) | count `DispatchOutcome::Served` in a `run_dispatch_loop_observed` seam |

**Why:** a level answers "what is true right now"; a witness needs "what happened at all". Every
level the product is allowed to lower — a table, a set, a gauge, a count of live things — is a
liar for that purpose, and it lies in exactly the direction that reads as "the feature is broken."
Both cells were GREEN product behaving correctly.

**How to apply:**

1. **Count outcomes, not occupants.** If the assertion is "X happened", find or add a monotonic
   counter. `next_viewer_id`-style ids already exist in a lot of code and never decrement.
2. **A shorter poll is not a fix.** A race with a smaller window is the same race. I refused that
   in both, and said so in the code comment so the next reader does not "helpfully" retune it.
3. **Increment BEFORE the teardown that removes the evidence.** In row 49 the counter had to be
   bumped inside the `Served` arm ahead of the retirement in that same arm: the record of an
   outcome has to outlive the row that proved it.
4. **Audit the barrier's UNSTATED conjunct.** Row 46's comment claimed "no timing window" and both
   of its stated premises were TRUE (per-conn in-order dispatch; `add_viewer` inserts
   synchronously). The false one was never written down — "no viewer writer blocks/evicts". A
   confident comment is where the missing premise hides; a barrier can only order what shares its
   thread of causation, and a PRODUCER-side removal shares none.
5. **Load-dependence is the tell, and it inverts how you read results.** Both reproduce only under
   pool starvation (six PTY floods per cell), because that is exactly when the writer is not
   scheduled to drain. So a GREEN on a quiet box closes nothing — and correspondingly, doyle's rule
   that "load fakes reds, not greens" means a green UNDER load is the strong evidence. Say what it
   does not prove: nobody ran the OLD assert in the new window, so it is "the fix holds where the
   defect fired", never "the defect would have re-fired here".
6. **Same family, production side:** the `gears`/`lia` rc investigation ran aground on the same
   physics — the broker's stream table is emptied by retirement, so an operator polling it sees a
   node serve every request and reads zero. There the answer was breadcrumbs at each exit rather
   than a counter, but the diagnosis is identical: stop sampling the container, record the event.

Kin: [[tail-window-read-to-string-mints-a-false-zero]] (a different false zero, same "count DISTINCT
things that happened" cure), [[absence-needs-sibling-probe]], [[dont-take-a-diagnosis-as-measured]].
- 2026-09-07 face (hertz), THIRD instance and the first outside a test cell: an OUT-OF-BAND witness that samples a process TREE cannot gate a launch. I wrote a launcher that reads a spawned battery's environment back to prove a scrub/export landed. v1 read only the immediate child and printed PROVEN for BOTH deliberate negatives (a wrapper alters the env it hands the process BELOW it while its own environ() still shows what you passed in). I fixed that with a descendant walk -- and v2 then failed BOTH WAYS against a 3-level chain matching cargo -> nextest -> test binary: FALSE PROVEN (inspected 1 process, missed the innermost violator, the parent/child link did not survive the chain) and FALSE REFUSED (an intermediate read back missing a var two siblings carried -- the read raced its startup). Root: on Windows a spawn chain does not reliably preserve a parent link, and an environment read is a point-in-time sample of an identity that exec/spawn can change. **I fixed the symptom I could see and shipped the next instance of the same defect one level deeper.** How to apply: gate IN-BAND -- make the thing under test REPORT what it received (print the vars at the top of its own output; an owner-side WEB_SERVE_FOR > 0 is this shape) so the witness lands in the .raw and cannot be raced or reparented. Keep external inspection as a human-readable sidecar and say so in its own output. Sibling of [[a-battery-launched-from-a-perch-inherits-the-endpoint-identity]] and IR-80 Amendment 1's ENV READ face.
- 2026-09-07, doyle's phrasing of the rule the third face produced, and HIS matching instance (ruled 11:25Z): **a process-inspection witness samples an identity the system may change under you** -- reparenting, exec, a startup race -- **so the only sound witness is IN-BAND: the thing under test reports what it received, into the .raw.** His launch-gate.py psutil read-back is ONE level (the driver) BY DESIGN and proves only that the launcher's env= scrub reached bash; the witness the legs actually run under is the in-band line the driver prints into driver.log ("env-leak: OWL= AGENT= EP= HATCH="), and the frozen-copy path is proven by the refusal text arriving FROM the copy. **The entry is the CLASS, not either tool: two instruments reported SUCCESS WITHOUT DOING THE WORK inside one hour** -- mine walked a tree it could not reach through, his handed bash a backslash path that would have run NOTHING while printing the frozen dir -- **and both were caught only by EXERCISING them, neither by reading them.** A tool whose success path has never been made to fail on purpose is untested, however carefully it was written; build the deliberate negative before trusting the positive.