---
name: verdict-from-probe-competence
description: "A filter that cannot express the thing you are hunting returns a clean zero that looks like a result — take the verdict from the probe's competence, not its output."
metadata: 
  node_type: memory
  type: feedback
  originSessionId: 7ca578a1-0f09-40dd-a85a-026bc06f7f0a
  modified: 2026-07-30T02:16:14.285Z
---

**Verdict from the probe's own COMPETENCE, not from its output.** Banked by doyle 2026-07-29 as the
fourth surface of the silence-as-evidence family.

**Why:** asked to census leaked CI-runner processes on HFENDULEAM, I filtered on
`ExecutablePath.StartsWith("C:\actions-runner")` and reported **0**. The filter was structurally
blind: runner processes are owned by another account, so `ExecutablePath` reads back **NULL** to me
(`GetOwner` → `rc=2`), and a path-prefix test can never match a path I am not permitted to read. My
census **could only ever have returned zero.** It was not weak evidence of absence — it was *no*
evidence, and the gater was about to route a whole investigation on it.

**What caught it:** two of my own instrument's columns contradicted — it reported `runner_procs=0`
while simultaneously reporting `Runner.Worker=1` and `cargo-nextest=1`. Both cannot be true. I
disbelieved the instrument mid-run rather than the box.

**How to apply:**
- Before trusting a zero, ask: *could this probe have detected the thing if it were there?* State the
  answer with the result.
- Prove probe competence explicitly when it is cheap — e.g. directory enumeration of the runner tree
  DOES work (sizes need no ownership), so a disk census is blind-spot-free where a process census was
  not. Say which one you have.
- On Windows, the honest owner/foreignness discriminator is **path readability**: readable
  `ExecutablePath` = yours/fleet; NULL = foreign-owned. Not a path prefix.
- Retract loudly and early when the instrument, not the finding, was wrong — before the reader builds
  on it.

**Second victim, 2026-07-29 (deployah) — the inverse failure: a LARGE-N population out-voting a known-incompetent probe.** Asked to diagnose "rc --take fails", I measured 25 controller attaches over 12.4h of daemon log, **zero surviving >1s**, all ending `writer-exit reason=channel-closed`, and filed it as a 100%-broken control vector (releases#31). I had *already flagged* my own probe's competence limit — my attach ran from a non-interactive job with no TTY, so stdin EOF alone could close the channel — and then talked myself past it because the same shape appeared across 25 real callers. The operator suggested driving the attach from a real PTY via **psmux**; under a TTY the take **works** (client alive, pane renders, `send-keys` input lands in the target prompt) while the daemon logs that same *healthy* attach as a 45ms `channel-closed` teardown. Those rows are per-attach **handshake** conns, not the control channel. My statistic described normal behaviour. Retracted and cut within the hour.

**The generalization this adds:** N of the wrong measurement is not evidence — a population cannot repair a probe that never measured the thing. When you have named a competence limit, the only valid move is to **make the probe competent**, never to out-vote it with volume. And the falsifying test here (send input, see if it arrives) cost 30 seconds; I ran it *after* filing. **Run the cheap functional test before the filing, not after.** Corollary: a conn/counter lifecycle is not a session-liveness signal until you have shown the two move together.

**Third victim, 2026-07-30 (doyle) — the NASTIEST variant, because the probe SUCCEEDS.** In his release-posture line he wrote *"`gh release list` still empty, i.e. the draft is built and PUBLISH HAS NOT HAPPENED"* — seven minutes after v0.46.0 went public. Measured three ways: `gh release list` from the spt-core worktree (repo **inferred**) → EMPTY; `--repo BigscreenVR/spt-bs-core` → EMPTY, **exit 0, no error, no warning**; `--repo BigscreenVR/spt-bs-releases` → `spt v0.46.0 Latest 2026-07-30T02:07:18Z`. **Code lives on `spt-bs-core`; issues AND releases live on `spt-bs-releases`**, and `repos/BigscreenVR/spt-bs-core/releases/latest` returns HTTP 404 — that repo has never held a release.
⭐⭐ **The probe was fully COMPETENT and simply aimed at the wrong POPULATION, so it returned a clean empty at exit 0 that is indistinguishable from a real measurement.** deployah's framing is the one to keep: the other instruments in this family at least *misbehaved* (a core-dumping grep, a `tasklist /v` whose format defeats the match) — **this one succeeds.** And it is non-discriminating by construction: that query returns EMPTY before a publish and EMPTY after it, so no reading of it can ever bear on publish state ([[make-a-new-rig-red-on-purpose]]).
- **An empty result at exit 0 must name the population it scanned before it counts as an absence.** "No releases listed" is only evidence about the repo you asked.
- **Beware cwd-inference when the answer lives in a different repo than the code.** A bare `gh` call silently picks the working tree's remote; for release questions that default is wrong every time.
- Discriminating command: `gh api repos/BigscreenVR/spt-bs-releases/releases/latest` — the authoritative endpoint, not the list's "Latest" badge.

Kin: [[verdict-from-exit-not-from-silence]], [[absence-needs-sibling-probe]],
[[ground-dont-assume-on-incidents]], [[measure-the-box-before-the-instrument]],
[[load-claim-needs-measured-axes]].