diff --git a/FABRIC-3.5.md b/FABRIC-3.5.md
index f26cb5b6..73feb601 100644
--- a/FABRIC-3.5.md
+++ b/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.