---
name: inert-on-this-version-kills-a-probes-discrimination
description: "Before calling a behavioural probe discriminating, read the ENFORCEMENT STATE in the running image's own tree — a version banner's prose about what is inert is not evidence, and got four agents to mis-scope a real falsification"
metadata: 
  node_type: memory
  type: feedback
  originSessionId: d62f0296-f25d-4225-a244-7a5697de1b19
  modified: 2026-08-04T22:07:38.047Z
---

2026-08-04, HFENDULEAM running broker **0.52.0** while installed at 0.53.0. A disputed claim: does
a single `allow` sender-endpoint rule make an endpoint a whitelist that refuses everyone else? Two
remote peers cold-sent the rule-holding endpoint over a mode-less subnet; both arrived,
receiver-confirmed.

**The framing went wrong twice, in opposite directions, and only the tree settled it.**

1. I first logged it as "the fall-through arm confirmed on the wire". A peer objected: the 0.53.0
   CLI banner says sender-endpoint rules "were INERT on earlier versions (no sender subject was
   ever supplied) and are ENFORCED as of this version", so on 0.52.0 the rule refuses nobody, both
   hypotheses predict arrival, zero discriminating power. I adopted that, broadcast it, and four
   agents recorded "control passed, semantics untested".
2. Then I read the RUNNING image's tree instead of arguing about the word *inert* —
   `git show v0.52.0:crates/spt-daemon/src/wan.rs` :732-737 passes
   `msg.sender_proven.as_deref()` into `access_check_with_sender`, and `access.rs:371` lands it as
   `sender_endpoint`. The module doc at that tag says it outright: the sender-endpoint tier is LIVE
   on the MSG family, and "**Absence abstains** — no stamp ⇒ tier 1 cannot match and the chain
   continues". **Tier 1 was live, was consulted, could not match, abstained, and the messages
   arrived** — which is exactly what the whitelist reading forbids. The arms DID discriminate.

**Why:** "could this probe have failed?" depends on whether the mechanism is ACTIVE in the image
you fired at — and the authority on that is the running image's source, never a version banner's
prose. Both wrong beliefs that evening traced to CLI text (the other was `allow: creates the
restriction if absent`, which describes record creation, not deny semantics). A published surface
that is wrong is worse than absent: it manufactures confident agreement.

**How to apply:** before calling a behavioural probe discriminating, state (a) the two hypotheses,
(b) each one's predicted observation, and (c) the enforcement state **read from the tree of the
exact build that is running** — `git show <tag>:<path>`, not the installed CLI's help, not a
banner, not main. If the box runs an older image than your checkout, main is the wrong tree.
Pre-register predictions before firing so nothing is retrofitted.

Standing self-correction from that night: my own measurements held; three FRAMINGS I put around
other people's evidence each overstated toward a firmer finding — and then the correction of the
third one ALSO overstated, in the deflating direction, because I adopted a peer's premise about a
version without checking it. Audit a framing like a measurement, in both directions.

Related: [[verdict-from-probe-competence]], [[relay-is-not-the-gaters-word]],
[[source-read-needs-its-sha-and-ancestry]], [[derived-view-vs-on-disk-record]],
[[cfg-gated-code-is-invisible-to-the-other-platform-gate]], [[broker-cutover-refuses-from-a-perched-shell]].