---
name: probe-an-unmodified-subject-needs-no-baseline
description: "To test whether YOUR change causes an effect, probe through a subject you did NOT modify that references nothing under edit — it measures the tool's behaviour, not your edit, so no stash/revert baseline arm is needed and no shared checkout gets mutated."
metadata: 
  node_type: memory
  type: feedback
  originSessionId: 7a3c43bb-f0d9-471d-88ad-ac02f7759292
  modified: 2026-08-03T16:22:43.330Z
---

When you need to know whether your change is responsible for an effect, the obvious
design is a two-arm test: measure with the change, revert it (stash / checkout /
second worktree), measure again. That arm is expensive and, in a shared checkout, it
is dangerous — it mutates a tree someone else is committing into.

**Cheaper and stronger: probe through a subject you did not touch, which references
nothing under edit.** Whatever it shows is the TOOL's behaviour, not your change's,
because your change is not in its path. One arm, no revert, no baseline.

Worked instance, spt-core 2026-08-03. I had converted 11 test call sites to
`env!("CARGO_BIN_EXE_<fixture>")`, claiming in IR-21 that this "forces cargo to build"
the fixture — a real dependency edge. To test it: deleted all four
`translate_proof_fixture` artifacts, then built **`--test attach_wedge_e2e`**, an
unmodified integration test that never mentions the fixture. The plain exe came back
anyway; the hash-suffixed harness exes stayed absent. Conclusion: cargo builds every
bin target of a package whenever it builds ANY integration test of that package, so
the env var added no edge. **My own claim, in a register entry doyle had landed 20
minutes earlier, measured false.** doyle replicated it on a different fixture, probe
test and pool before ruling, and corrected the entry by replacement across four sites.

**Why:** a baseline arm exists to separate "the tool does this anyway" from "my change
did this". An unmodified subject separates them *by construction* — there is nothing to
control for. It also sidesteps the shared-checkout hazard entirely, which is what made
it usable at all here (doyle was committing into the same root checkout;
[[check-branch-before-commit-shared-checkout]], [[no-reset-hard-with-uncommitted-work]]).

**How to apply:** when designing any "did my change cause X" probe, first ask *is
there a subject that exercises the same tool path but contains none of my edit?* If
yes, use it and **say out loud that this is why no baseline arm is needed** — doyle's
words: it is the discriminating move, not a caveat, so state it rather than leaving a
reader to wonder what you controlled for. Pair with a positive control when a NEGATIVE
result is the finding ([[make-a-new-rig-red-on-purpose]],
[[zero-match-filter-reads-as-absent]]), since "it refused" must be shown to be the
tool refusing and not your scaffold being wrong. Related:
[[report-measurement-never-issue-direction]],
[[precise-claim-is-falsifiable-vague-is-useless]], [[is-this-red-mine-delta-test]].