---
name: barrier-must-be-the-fact-you-assert
description: "A rig_wait that polls on EXISTENCE and then asserts a LATER-written field reads a pre-write snapshot; the assert can only pass by luck, and its panic can kill the very operation it measures."
metadata: 
  node_type: memory
  type: feedback
  originSessionId: 1e15e6ca-6830-40c8-b051-25a9b1850b5c
  modified: 2026-08-19T20:38:02.492Z
---

If a cell waits on fact X and asserts fact Y, and Y is written AFTER X by the
producer, the wait is not a barrier for the assert — it is a starting gun for a
race the cell then loses at whatever rate the producer's step gap allows. Worse
when the wait CLONES the row at first sighting: the assert reads a snapshot taken
three steps upstream of the write it names, so the cell can never see Y no matter
how long the deadline is.

Measured (golden 32191618042 @ 93c1130, twohost.rs:2406, denominator ONE):
`produce_addressed` commits the notif row → deliver → `mark_seen` writes `seen`.
`rig_wait` polled on the row's coalesce_key, cloned it, and asserted
`row.seen.contains(ID_A)` on that clone — panic 13.5 ms after the insert, `seen:
{}`. The SAME file already had the right shape three times (`seen.contains(..)`
INSIDE the wait predicate); the two rungs that deviated were the two that had
never executed. Second face: the panic exited the process mid-handler, so the ack
the peer was blocking on was never returned — a second signature 60 s later in the
other job that was purely this cell's own kill, carrying no information.

**Why:** an existence barrier looks like a barrier and prints a convincing
"OK: <thing> converged" line immediately before the failure. A green here would
have been luck, and would have read as coverage of the surfacing contract.

**Third face — the barrier and the subject can share a LOCK and still race
(2026-08-18, golden 32205195794, Windows Phase B,
`registry_lifecycle.rs:610`, `left: 0` / `right: 1`, Linux green same run).** Barrier was
`converge(|| rows(...))`; assert was on `snapshot_write_count`. `apply_feed_batch` merges under the
`regs` lock, the scoped block ENDS (lock dropped), and only THEN calls `write_snapshots`, whose first
statement is the counter's `fetch_add` (`registryhost.rs:881`). `rows()` takes that same lock, so the
predicate goes true the instant the merge block drops it, and `converge` returns on the FIRST true
poll with no settle window. Same class as face one, but the sibling-vs-subject gap is microseconds
wide, which is why it stayed green for a month and fired once on the slower box.

Two riders from this face. **The DIRECTION refutes the product hypothesis before any source is
read:** the cell guards against write AMPLIFICATION, so a real regression of what it guards reads 2
or more — `left: 0` is a different failure, not a weaker one. **A zero delta can be EVIDENCE:** here
it certified the feed merged as ONE transaction, since a second batch's write would have ticked the
counter before the last record could merge. Fix shape is converge-on-the-SUBJECT (poll until the
counter reaches its value under a bound, then assert it does not EXCEED it) — never a sleep; and note
a GLOBAL counter shared with other writers stays exposed in the OVER direction, so a wait-only fix
leaves that half open.

**Fourth face — A BARRIER CAN EXPIRE WITH THE DEFECT IT WAS BUILT TO MEASURE (2026-08-19, #164
briefing-presentation rig).** Two barrier bugs in ONE instrument, and the second is a class the first
three do not cover. (a) The ordinary face: I waited on `info.session_id` going non-empty — a fact the
HARNESS stamps — and then sampled the spool for a briefing the SEAT SETTLE writes afterwards. Read
`briefings=0`, and folded that zero into a min-across-hold, so the instrument would have reported a
row as TAKEN that had not yet been WRITTEN. (b) The new face: the repaired barrier waited on the row
being PENDING, which was correct only while nothing presented it. The fix I then built takes the row
in milliseconds, so post-fix that barrier NEVER GOES TRUE — the instrument times out and REDS on the
tree its own subject works on, and the red reads as "the briefing never spooled" when the truth is
"delivered before I looked". Caught by predicting it, not by hitting it.

**Why it is its own face:** faces 1-3 are all "the barrier is upstream of the assert IN TIME". This
one is "the barrier is a predicate over a state THE FIX DELETES". An instrument written against a
defect quietly encodes that defect's state as a precondition, and then dies at the moment it would
have been most useful — proving the fix. Ask of every measurement barrier: *what does this poll on,
and does that state still exist once the thing I am measuring is repaired?* Prefer an EXISTENCE read
over a STATE read (here: the audit row, which sees the row delivered or pending, over the pending
read, which loses it to any taker) — an instrument must outlive its subject's repair.

**How to apply:** name the fact the assert claims, then make THAT the wait
predicate (and re-read, never assert a snapshot the predicate captured). When a
cell fails on a field that a later step writes, check the producer's step order
before proposing a product mechanism — and check whether the panic itself killed a
peer's in-flight exchange before treating a second red as independent. Kin:
[[stale-snapshot-equality-proxy]], [[healthy-path-emits-the-same-silence]],
[[base-rate-is-over-cell-executions-not-suite-runs]].