FABRIC-3.5.md §XXI: item 9 settled -- SOS travels up the birth graph

Actionability is a property of the relationship, not of the message.
To the sender's birther an SOS is actionable: the parent may re-birth,
exercising its own birth authority rather than inheriting the child's, so
§IX.2 is untouched. To every other VM it is advisory -- a peer may shed
its own dependence on the sender but may not act on its behalf. One rule,
no exceptions list: an SOS is actionable exactly where the birth graph
already grants authority.

Pressure-tested against the supervisor risk §XIV.5 warned about, and it
survives: message-driven rather than polling (the doctrine's own
sanctioned form), optional rather than obligatory, no declarer since the
sender reports its own trouble, and no authority transfer.

What this actually closes is larger than a message type. §VII.1's ladder
had no actor for rung 2, and now each rung has exactly one: the VM itself
warm-restarts while alive, the birther re-births on SOS, and nobody acts
on compudynamic death. That also shows §IX.1's fleet-shutdown rule is not
a special case bolted on for Hera -- she has no birther, so rung 2 has no
actor and the ladder falls through to rung 3. The ladder and §IX are the
same rule from two ends: rung 2 exists iff you have a birther.

Flags a hazard specific to this system. Payloads here are FORTH text
executed by the receiver, per messaging.4th block 5041's own comment. An
SOS carrying an executable payload would let a failing VM drive its
parent, inverting the authority direction at the moment the sender is
least trustworthy. SOS payloads are descriptive only -- a deliberate
departure from the convention, and the reason the message exists.

Number: 10, the next in sequence. Verified 5 and 6 are genuinely
unallocated, but monotonic allocation means a number in any log means one
thing forever, which matters while legacy constants and the new kernel
enum coexist during cleanup. Names the consumer explicitly so this does
not become another SPAWN-EVENT, which §I.4 recorded as having none.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VkM1zHGvBerLF6aqkHPweP

FABRIC-3.5.md

@@ -605,9 +605,8 @@ premise rejected.
 **Still genuinely open — updated again 2026-09-18 after §XVII closed item 12. Nothing
 structural remains; what follows are small local decisions, one placement question, and one
 build-time check.**
-- **Item 9 (§VII.2/§XVI.5)** — half-answered. The consumer action is defined for the two
-  fleet-fatal cases; open is whether an *ordinary peer's* `SOS` is actionable or merely
-  advisory, plus the trivial number allocation.
+- ~~**Item 9**~~ — **SETTLED 2026-09-19 by §XXI**: actionable to the sender's birther, advisory
+  to peers; payload descriptive, never executable; number **10**.
 - **§VIII.3 first bullet** — where the sinking semaphore mechanically lives. The rest of
   §VIII.3 is settled by §XVI.
 - **Item 16 (§XV.4)** — an implementation check rather than a decision: every message-holding
@@ -1817,3 +1816,129 @@ the problem rather than solving it.
 the FORTH messaging layer Captain Bob ruled legacy. This ruling states the *principle* — the
 pairing is recorded, never derived — which kernel-Hermes must carry forward. It is not a
 proposal to patch the legacy path in place.
+
+---
+
+## XXI. Item 9 SETTLED: `SOS` travels up the birth graph. It is actionable there and advisory everywhere else.
+
+§VII.2 left two questions: who consumes an `SOS` and what do they do with it, and which number.
+The first turns out not to need a new rule — **§IX.2's "authority only ever flows down the
+birth graph" already answers it**, and answering it supplies something this document had been
+missing without noticing.
+
+### XXI.1 — RULING: actionability is a property of the relationship, not of the message
+
+- **To the sender's birther — actionable.** The parent may re-birth. This is the parent
+  **exercising its own birth authority** (§XV.1: any VM may birth), *not* inheriting the
+  child's. §IX.2 is untouched: nothing flows sideways or up.
+- **To every other VM — advisory.** A peer may adjust its *own* behaviour (stop sending to a
+  failing VM, note it, shed work that depended on it). A peer may **not** act on the sender's
+  behalf, re-birth it, or reclaim anything of its own.
+
+One rule, no exceptions list: **an `SOS` is actionable exactly where the birth graph already
+grants authority.**
+
+### XXI.2 — Why this does not smuggle in a supervisor
+
+Pressure-tested against the doctrine and the rulings, because "parent watches child and
+restarts it" is precisely the shape §XIV.5 warned about:
+
+- **Message-driven, not polling.** The parent acts on receipt, during its own tick. That is
+  the doctrine's own sanctioned form — `VM-PHYSICS-DYNAMIC-FLEET-DESIGN-20260705.md`: "a VM's
+  own internal state (e.g. Hermes's message queue) determining whether it does anything."
+  No timer, no scan, no watch loop.
+- **Optional, never obligatory.** A parent that ignores an `SOS` is behaving correctly. Nothing
+  polices it.
+- **No declarer.** The sender reports *its own* trouble. Nobody judges anyone else's liveness,
+  so §XV.2 holds exactly as ruled.
+- **No authority transfer.** The parent uses authority it already had, on a VM it already
+  birthed.
+
+A supervisor is a component that *must* watch and *may* decide another's fate. This is neither.
+
+### XXI.3 — What this actually closes: the ladder's missing actor
+
+§VII.1's ladder has three rungs, and until now only the first and third had an obvious actor.
+With `SOS` settled, each rung has exactly one:
+
+| Rung | Actor |
+|---|---|
+| 1. Recover gently (warm restart) | **The VM itself**, while still alive — self-applied (§XV.2) |
+| 2. Escalate to a from-scratch `BIRTH` | **The birther**, on receipt of the `SOS` |
+| 3. Fail brutally | **Nobody.** Compudynamic death (§XV.2) |
+
+**And this is why §IX.1's fleet-shutdown rule is not a special case.** Hera has no birther —
+`capsule_birth.c:178` sets her name at the root, and the Tripod legs are birthed *by her*
+(`kernel_main.c:865`). So for Hera, rung 2 has no actor, and the ladder falls straight through
+to rung 3. §IX.1's "no provisional handoff → the fleet runs its own shutdown" is not an extra
+rule bolted on for Hera; **it is what the ladder already does when you have no parent.**
+
+The ladder and §IX are the same rule seen from two ends: **rung 2 exists if and only if you
+have a birther.**
+
+### XXI.4 — An `SOS` must not carry an executable payload
+
+A real hazard specific to this system, worth stating before anything is built. In the existing
+mechanism a message's payload **is FORTH text executed by the receiver** — `messaging.4th`
+block 5041 says so directly of `BLK-ATTACH-EVENT`: "Payload is FORTH text, executed by the
+receiver, same as every other message here."
+
+An `SOS` whose payload were executed by the birther would let **a failing VM drive its own
+parent** — precisely inverting the authority direction §XXI.1 exists to preserve, and doing it
+at the moment the sender is least trustworthy.
+
+**So: an `SOS` payload is identifying and descriptive only — who is failing, and what for —
+never instructions.** The birther decides what to do; the sender only reports. This is a
+deliberate departure from the "payload is executed text" convention, and the reason is the
+whole point of the message.
+
+### XXI.5 — `SOS` is best-effort, and that is not a gap
+
+A VM that dies instantly emits nothing. There is no `SOS`, nobody notices, and per §XV.2
+nobody declares anything — it is simply gone.
+
+**This is correct, not a hole to plug.** Covering it would require something watching for
+absence, which is a detector, which §XV.2 rules out. `SOS` covers exactly the case where a VM
+can see its own failure coming; the silent case is covered by nothing, deliberately.
+(`FABRIC-3.md` §XX's wellness-check idea remains the separate, optional thing that *could*
+address it — on its own merits, not as a dependency of this design. §VII.3 was withdrawn for
+assuming otherwise.)
+
+### XXI.6 — RULING: `SOS` takes **10**. Do not reuse the gaps.
+
+Verified 2026-09-19: message types in use are 1, 2, 3, 4, 7, 8, 9; **5 and 6 are genuinely
+unallocated** — a repo-wide search for either as a message-type constant returns nothing (the
+sole `6` is `CH-CELLS`, unrelated). Status sentinels sit at the top: `MSG-NACKED` 253,
+`MSG-DELIVERED` 255.
+
+**Take 10, the next in sequence, rather than filling a gap.** The reasoning is legibility
+across the transition: during the dead-FORTH cleanup (§XIV.1) legacy constants and the new
+kernel enumeration coexist, and logs will span both eras. Monotonic allocation means **a number
+appearing in any log means exactly one thing, forever.** A reused gap would make an old log
+ambiguous for no gain. The gaps stay gaps; a documented hole is more honest than a silent
+reuse.
+
+**Scope note per §XIV.1:** `SOS` properly belongs to **kernel-Hermes's own message-type
+enumeration**, since the FORTH layer is legacy. The legacy numbering is not binding on the new
+enum — but it should be honoured as a floor, for the same log-legibility reason.
+
+### XXI.7 — Named consumers, so this does not become another `SPAWN-EVENT`
+
+§I.4 recorded the warning: `SPAWN-EVENT` was grepped across the whole tree and **has zero
+consumers** — "an unwired placeholder, not working infrastructure." A message type with no
+dispatcher is exactly what `SOS` cannot be.
+
+So, stated explicitly: **`SOS`'s consumer is the sender's birther**, whose handler is the
+rung-2 re-birth decision (§XXI.3), plus **any peer that chooses to shed dependence on the
+sender** (advisory, optional, and correct to omit entirely in a first implementation). If no
+birther is live, the `SOS` is simply never consumed — a determinate outcome, not a silent gap,
+because the birth graph says plainly whether a consumer exists.
+
+### XXI.8 — Punch list
+
+- ✅ **Item 9 — SETTLED** (§XXI). Actionable to the birther, advisory to peers; payload
+  descriptive, never executable; number **10**; consumer named.
+- ⬜ **§VIII.3 first bullet** — where the sinking semaphore mechanically lives. **Now the last
+  open design question in this document.**
+- ⬜ **Items 16, 17, 18** — the `STADIUM-EVICT` teardown check; `BYE` vs. a separate suicide
+  word; the empty-floor halt when Hera is already gone.