---
name: outcome-discriminates-what-instrument-cannot
description: "When a local instrument conflates two answers, resolve it with an external observable whose semantics differ — don't argue from the ambiguous output."
metadata: 
  node_type: memory
  type: feedback
  originSessionId: af766430-dd07-403e-a7c4-f96fda10be91
  modified: 2026-08-02T17:11:33.222Z
---

2026-08-02, BAROMETER rerun: hertz rooted a kill set on the RUNNER's cargo (blank
command line + one-second start-time match) and could not say whether four
descendants died by his hand, because his kill loop's `catch` rendered
already-exited and access-denied as the same string. The answer came from outside
his process table entirely: the Windows `n1-gate` job concluded SUCCESS, and a
`build-script-main`/`rustc`/`cl` killed mid-compile FAILS the compile. Green proves
no child died.

**Why:** an ambiguous instrument invites arguing from its output — usually in the
direction that flatters whoever is arguing. The move is to find an external
observable whose semantics DIFFER on the two branches, not to re-read the
ambiguous one. Kin to [[discriminator-question]] and
[[instrument-soundness-guards]]; the mirror of
[[absence-proxy-breaks-when-success-writes]], where I had to REFUSE an absence
argument (0 `KILL_REFUSED` tokens while a spare-path test passed silently in the
same log — passing tests' output is not captured, so zero could not discriminate).

**How to apply:**
- Ask what observable would differ between the two branches, then go get it.
- Record it as resolved-by-OUTCOME, not resolved-by-report, so the record does not
  rest on the ambiguous instrument.
- Same discipline as [[cross-wave-claims-need-assembled-head]]: state the basis, not
  just the conclusion.