alex/sots-re
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

rules 19-20: the instrument can perturb the measurement; a count cannot separate did-not-fire from fired-and-found-nothing

Browse source
This commit is contained in:
alex 2026-09-08 13:56:06 -04:00
parent 132d41c44e
commit 8b6c946614
1 changed files with 34 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

34
guides/method-rules.md
View file

@ -211,3 +211,37 @@ separate "no success" from "empty candidate list" — a hook on the callee separ
Corollary, from the same session: **search the notes before the binary.** The dominant RNG consumer
was already identified in `strategic-turn-internals.md` months of lanes earlier. What was missing was
never the identification — it was the connection.
## 19. The instrument can perturb the thing it measures — check, do not assume
Lane H bisected an autosave that differed by 4 bytes from a byte-identical input, across
configurations, and found the cause: **a MinHook detour on one function changed the game's
behaviour.** The patched 5 bytes land on a clean prologue boundary with no branch target inside,
and the *suppressed* draw belongs to a function that runs earlier in the turn than the hooked one.
The mechanism is still undetermined.
Two things follow. First, the ledger built with a different hook set was checked and came out
**behaviour-neutral** — its numbers stand. Second, that check had never been run before; it came
out right by luck, not by design.
So: **before trusting a measurement, take the same measurement with the instrument removed.**
`hooks=off` in two fresh processes is cheap and it is the control. A hook that changes the autosave
has invalidated every number taken with it installed, and you will not notice from inside the run.
Corollary for the oracle: re-run it after any change to the hook set, not only after engine changes.
## 20. A count cannot separate "did not fire" from "fired and found nothing"
`CreateRaidEncounter` cost 0 words on every measured turn, which was read as "the roll never
succeeds (~11%, unremarkable over three turns)". An entry probe showed it is **entered 2x on one
turn and 1x on the next, drawing 0 every time** — the rolls succeed at about the predicted rate and
the *candidate list is empty*. Also, three quiet turns at that rate is 1-in-720, not unremarkable:
when a prior says "unremarkable", compute it.
Same shape elsewhere in the same lane: four tail callees were "never observed firing" and turned out
to be **entered every single turn and gated inside** — a much stronger negative than reachability.
And a residual measured at "2 words per turn" on two saves is **one word per player that passes a
gate**, where exactly one player passes on both corpus saves. A constant fitted to two observations
is not a constant.
Instrument the **entry**, not just the cost.