---
name: a-rig-that-seeds-one-direction-fails-when-a-cell-needs-the-reverse-judgement
description: two-role rig seeded A-knows-B only; the first cell where B must JUDGE something A said failed at the seed (roster/registry/ACL), twice in one lane wearing the dispatcher's red
metadata:
  type: feedback
---

A two-role rig's seed data (roster entries, registry rows, ACL grants, peer addresses) is
written for the direction its cells have always run. The first cell that needs the OTHER role
to judge something — B merging A's row, B honouring A's user-msg, B's ACL admitting A inbound —
fails at the seed, and the failure wears the red of the thing under test (W2 F17/F19,
2026-09-07: `never asked to serve within 120s` was a dispatcher bug, then a missing registry
row, then an empty roster; IR-83's tailnet ACL was the same shape in the network).

**Why:** each layer's gate is fail-closed on data the rig never wrote (registryhost.rs:85-88
`admits` = member subnet AND roster member), and the absence is silent — the product refuses
with the same token it uses for a real deny.

**How to apply:** when a cell adds a reverse-direction requirement, census the rig's seed
functions for BOTH directions before running (grep the seeding helper for each role's hex);
put a precondition assert that uses the product's OWN read verb for the arm (hertz's
`node_hosting_endpoint(...) == Some(a_hex)` failed in 0.5 s with the verdict word instead of
120 s later at the dispatcher). Presence first, quality second. See
[[a-source-read-cannot-witness-an-integration-cell]].
