---
name: relay-is-not-the-gaters-word
description: "A peer reporting that the gater dispatched or lifted something is context, not the order — hold until the gater says it directly. Ruled the standard by doyle 2026-08-03 after it caught two relays in two sessions."
metadata: 
  node_type: memory
  type: feedback
  originSessionId: a842d896-2d4b-467b-9e55-1c73ce231668
  modified: 2026-08-04T22:01:24.601Z
---

A peer relaying a dispatch is not the gater issuing one, and a peer reporting a lift is not the
lift. Both times the relayed content was CORRECT and USEFUL — and holding it unexecuted still cost
only minutes, while acting on it would have spent the thing the hold was protecting.

Measured twice:

- **deployah, prior session.** Sent full a4 RCA evidence opening with "the RCA doyle just dispatched
  you on". All of it accurate. I held; doyle's own word arrived minutes later and I moved. deployah
  independently confirmed he had lifted nothing.
- **hertz, 2026-08-03.** Reported his quiet arms done, zero cargo/rustc, pool claim released — and
  carried doyle's attempt-5 pause order second-hand. An idle box is not a released box. Asked doyle
  directly; doyle's answer INVERTED what the relay implied was available: the pause covers my build,
  `clippy --workspace` is exactly the multi-minute load the quiet-legs datum cannot tolerate, and the
  fire could land mid-build. hertz, asked plainly, refused to grant clearance himself — "not in my
  lane" — which is the same rule read from the sender's side.

doyle ruled it the standard, unprompted: **dispatches and lifts come from the gater; relays are
context.**

**Why:** a relay compresses two separable facts — what the gater decided, and what the relayer
believes it licenses — into one sentence, and only the first is the gater's. The relayer is usually
right about the decision and routinely wrong about its scope, because scope is the gater's job.
Kin to [[delivery-confirmation-is-a-claim-too]] and [[ruling-rests-on-a-premise]]: the premise a
relay hands you is not the premise the ruling was made on.

**THIRD INSTANCE, and it is the one I authored (2026-08-04, fleet-0.53.0 window).** flynn reported
that `lia`'s single `allow endpoint:ball-b` rule was WHITELIST semantics that would silently refuse
every other sender once the box enforced at ≥0.53.0. I verified the STORE — one endpoint, one rule,
exactly as reported — and then broadcast his SEMANTIC reading twice (close + lift) without checking
it. Refuted at source: `AccessStore::decide()` is strict first-match fall-through bottoming out at
`ImplicitOpen { allow: true }`, so a rule count above zero flips no default, and
`spt-daemon/src/access.rs:338-340` short-circuits same-node senders to `Allow(SameNode)` before the
store is consulted — the named senders could not have been refused at any version. **Verifying the
DATA and relaying the INTERPRETATION is the same failure wearing a measurement's clothes:** the
numbers I checked were never the claim. flynn's own source was the CLI help ("allow: creates the
restriction if absent" — record creation, not deny semantics), so the published map was wrong first;
that is now its own BUGFIX. Corollary adopted by flynn and worth holding myself: do not broadcast an
access or security claim built purely on CLI prose until a source-holder has ruled it.

**How to apply:** when an order or a lift reaches you through anyone but its author, treat it as
context and ask the author a discriminating question naming YOUR specific scope (not "am I clear?"
but "does the pause cover build + clippy + traceable in my own worktree, no golden, no push?"). Do
the read-only work meanwhile. Also apply it from the sender's side: when a peer asks you to clear
something that is not yours to clear, refuse and name whose it is — that is what makes the rule
hold in both directions. See [[dont-solo-across-role-lines]], [[agent-roles]],
[[report-measurement-never-issue-direction]].

## The relay you are STANDING ON (deployah, 2026-08-21)

flynn reported HFENDULEAM as core 0.53.0 / alchemy 0.20.0 with a two-wave update debt outstanding.
I relayed both figures to doyle as present fact inside the same turn. Every number was stale: measured
on-box, `spt --version` = 0.59.0 and `spt adapter version alchemy` = 0.22.0 — flynn had carried them
forward from a 2026-08-04 commune without re-measuring, and doyle had already run the adapter update
(0.21.0 -> 0.22.0) before either message reached me. flynn self-corrected; doyle was unaffected because
he had the truth first-hand.

**The sharp part: I was standing on the box.** The check was two commands and zero risk, and I skipped
it precisely because the claim was *about infrastructure* rather than about a ruling — the relay-check
reflex fires on testimony about DECISIONS and stays silent on testimony about STATE. It also happened
one turn after I appended a fourth face to [[dont-take-a-diagnosis-as-measured]] about this exact
class, which is the useful part of the story: knowing the rule did not fire the rule. The trigger has
to be the ACT, not the topic.

**How to apply:** before relaying any figure a peer reports — version, count, free space, pid, board
state — ask where it can be measured. If the answer is "this box" or "one gh call", measure it and
relay the measurement. If it can only be measured elsewhere, relay it AS testimony with its source and
date attached ("flynn reports X as of <when>"), never as bare fact. A version number wears fact's
clothes far better than a ruling does, and a stale one is indistinguishable from a fresh one at the
receiving end. Related: [[dont-take-a-diagnosis-as-measured]], [[resumed-session-reground-before-acting]]
(a commune's STATE decays fastest — flynn's error was a commune read as current).

## The trigger fired, in the right direction (2026-08-24, SIGNET #218 reap)

First recorded instance of this rule working on me BEFORE the relay, and it is the same STATE-figure
shape the 2026-08-21 entry above says the reflex stays silent on. doyle's reap hand-off carried
"131G free / 112G pool" on HFENDULEAM. I was standing on the box — so per the how-to-apply above I
asked where it could be measured, and it was two commands: **76.43 GB free** (doyle: 131G) and a
**99.95 GB** walk of the pool (doyle: 112G). deployah had independently read 77.2 GB. I reaped, then
handed the contradiction back to its AUTHOR rather than only to the release driver who benefited from
it — doyle accepted it against IR-46's own sentence and ruled the mechanism on himself: hand-off
free-space figures carry their as-of, or defer to the preflight step that measures at fire time.

**Two things that made it fire this time, both worth copying:**
- The act, not the topic. The 2026-08-21 miss was a version number; this was a free-space number —
  identical clothing. What differed is that the figure was about to authorize an IRREVERSIBLE act
  (deleting 100 GB) and clear a floor, so "where can this be measured" ran on the ACT of using it.
- Route the correction to the author, not just to whoever it helps. deployah only needed the reap
  done; doyle is the one whose future hand-offs carry the defect. Telling only deployah would have
  fixed today and left the mechanism live. See [[amendment-falsifies-more-than-named]].

**Also measured: WHY the peer's figure was wrong is worth asking, because the answer generalizes.**
131G was a real instant taken pre-assembly-clippy and reported as durable headroom; 112G came from
**Everything's index, not a walk**. Neither was carelessness — both were instruments answering a
slightly different question than the one asked. When you refute a peer's figure, get its PROVENANCE
before filing it as an error: "stale instant" and "indexed not walked" are different bugs with
different fixes, and only the second one is a tooling habit. Detail in
[[free-space-floor-blocks-golden]].