FABRIC-3.5.md §XV: the authority questions answered, three by rejecting the premise

Captain Bob, 2026-09-18. Any VM may birth a near-clone of itself carrying
its own ACL DNA; nobody declares a VM dead, it dies a compudynamic death;
nobody owns turn order, turn order is compudynamic.

These close six punch items. Birth-by-near-clone settles what "ACL/DNA"
refers to -- inheritance by copy, using the existing ACL-INHERIT
semantics, needing no fifth DictEntry field -- and settles "standing" as
decorative, confirming the minimal reading. The authority bound holds
literally rather than aspirationally: a child cannot exceed its parent
because it is built from it, so there is no gate to bypass.

Compudynamic death retires the largest scheduler-shaped risk in the
design. §VII's ladder appeared to need a supervisor watching liveness,
and a supervisor with a timer is a scheduler's twin; with death as a
physical outcome rather than a judgment, that component is not needed and
does not exist. §VII.3 and §IX.3 both asked the wrong question and are
marked withdrawn and premise-rejected in place.

Turn order gets a stronger invariant than the firewall previously
proposed: that one named an owner, and naming an owner is what a
conventional scheduler is. Nothing owns turn order. Flags one honest
seam for later, predating this work and belonging to §XXVIII:
SK_SWITCH_READINESS_THRESHOLD is a hardcoded 50, the same category of
fixed policy §XIX rejected.

Reframes the message-durability question that was posed badly enough to
be unintelligible. It is not persistence but conservation: a message
holds Q.SLOT of heat (MSG-ALLOC pulls, MSG-FREE-NODE evicts), so a dying
arbiter holds N x Q.SLOT of fleet heat. Payloads may vanish; the heat may
not, or K breaks. Nothing survives except K. This dissolves the
Artemis-at-death-time hazard entirely rather than trading against it --
there is nothing to persist, and since death is already a Stadium
eviction, returning heat is what dying consists of.

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

FABRIC-3.5.md

@@ -434,6 +434,12 @@ Hermes is the exception, for a structural reason — §VIII.
 
 ### VII.3 — The existing precedent this should be reconciled with
 
+> **WITHDRAWN 2026-09-18 by §XV.2 — this section's premise is wrong.** It assumed the ladder
+> needs a detection mechanism. Death is compudynamic: no detector, no declarer, nothing to
+> build. The closing claim below ("a recovery ladder with no detection story only ever triggers
+> on failures loud enough to notice by accident") does not hold. The wellness-check idea stands
+> on its own merits, unrelated to this ladder. Left in place, not rewritten.
+
 Per §XX, closed as captured-for-later: Captain Bob's self-healing idea — "all VMs participating
 in a wellness check at their nearest participating wellness center" — a distributed
 liveness/failure-detection concept "deliberately not built as part of this fix."
@@ -517,6 +523,11 @@ some future failure mode makes a provisional handoff look temporarily attractive
 
 ### IX.3 — Open
 
+> **PREMISE REJECTED 2026-09-18 by §XV.2.** The first bullet asks the wrong question. Nobody
+> declares a VM dead — it dies a compudynamic death. The "circular by construction" difficulty
+> was an artifact of assuming death is a judgment someone renders rather than a physical
+> outcome of the physics. Left in place, not rewritten.
+
 - **What has standing to declare a birther dead?** Circular by construction: the fleet must
   conclude Hera is gone without Hera participating. Ties directly to §VII.3's undesigned
   detection story.
@@ -581,12 +592,22 @@ There is no other test.
 
 ## XII. Explicitly not decided anywhere in this document
 
-Collected so nothing here is mistaken for settled. **Updated 2026-09-18 after §XIV's rulings**
-— §III.3, §III.4 and §IV.2 have left this list (resolved or dissolved; see §XIV.2). Still open:
-§V.3 (all four), §VI.3, §VI.4, §VII.2 (number and consumer), §VII.3, §VII.4, §VIII.3 (all
-three), §IX.3 (both), §XIII.5's Console-singleton question (punch item 12, gates §IV),
-§XIV.4's message-durability trade (item 15), and §XIV.5's scheduler firewall (item 14).
-The proposed resolution shapes in §XIII.5, §XIV.4 and §XIV.5 are **analysis, not rulings.**
+Collected so nothing here is mistaken for settled. **Updated 2026-09-18 after §XV's rulings.**
+Most of this list is now closed — see §XIV.2 and §XV.6 for what resolved, dissolved, or had its
+premise rejected.
+
+**Still genuinely open: four items.**
+- **Item 10 (§VIII.3)** — the sinking semaphore's mechanism, what a clean-shutdown routine
+  concretely does, and whether the window is bounded. **The largest remaining design item.**
+- **Item 9 (§VII.2)** — `SOS`'s message-type number and its consumer. Downstream of item 10,
+  and narrowed by §XV.2: with no death-declarer, an `SOS` consumer cannot be a supervisor.
+- **Item 12 (§XIII.5)** — is the Console Tripod leg a new singleton, distinct from today's
+  per-attach proxies? Independent of the others, and still gates §IV.
+- **Item 16 (§XV.4)** — an implementation check rather than a decision: every message-holding
+  teardown path must reach `STADIUM-EVICT`, verifiable via `fleet_conserved`.
+
+§XIII.5's proposed Console resolution shape remains **analysis, not a ruling.** §XIV.4's and
+§XIV.5's proposals were both superseded by §XV.4 and §XV.3 respectively.
 
 What **is** decided, all by Captain Bob on 2026-09-18 and recorded in §III.1, §IV.1, §V.1,
 §VI.1, §VII.1, §VII.2, §VIII.1 and §IX.1: Hermes goes into the kernel and becomes the arbiter
@@ -919,3 +940,179 @@ items are no longer about *mechanism* — they are about *authority*: who may bi
 decides a VM is dead (8, 11), who owns turn order (14), and what survives a death (15). That
 is a better class of question to be left with, and §IX's "authority only ever flows down the
 birth graph" is the principle most of them should be tested against.
+
+---
+
+## XV. The authority questions, answered (Captain Bob, 2026-09-18)
+
+§XIV.6 observed that the surviving open items were no longer about mechanism but about
+authority — who may birth, who declares a VM dead, who owns turn order, what survives a death.
+All four are answered here, and three of the four are answered by **rejecting the question's
+premise** rather than by naming an owner. That pattern is the finding.
+
+### XV.1 — RULING: any VM may birth a near-clone of itself, carrying its own ACL DNA
+
+**Captain Bob, verbatim:** "Any VM can birth another VM that is almost a clone of itself with
+its own ACL DNA whatever ya wanna call it."
+
+This closes **§VI.3** and **§VI.4** together:
+
+- **§VI.3 ("ACL/DNA" needs a precise referent) — ANSWERED: inheritance by copy, from the
+  parent.** The child is *almost a clone* of its birther: it starts from the parent's own
+  state and carries **its own** DNA — a copy it owns and may diverge, not a shared reference
+  to the parent's. This is the reading §VI.3 hoped for: it uses the existing word-level
+  `ACL-INHERIT` semantics (pin cleared, mode copied) rather than inventing a VM-level
+  construct, so it stays inside the "reorganization, not invention" scope, and it does not
+  need a fifth `acl_*` field on `DictEntry` (the constraint §VI.3 flagged).
+- **§VI.4 ("standing" is undefined) — ANSWERED: standing is decorative.** "Any VM can birth"
+  confirms reading (a) — standing means nothing more than having `BIRTH` registered. Per §I.5
+  the C implementation is already VM-agnostic, so this is a registration change, exactly as
+  §VI.2 predicted. No Stadium-economy gate, no `ACL.4th` predicate. Consistent with
+  `.claude/CLAUDE.md`'s "do not over-engineer — if the user says 'BIRTH is a primitive', that
+  is the complete specification."
+
+**Why the authority bound still holds without a check.** A near-clone cannot exceed its parent
+because it is *built from* the parent. §VI.1's "enforced by inheritance, not by a separate
+authorization check" is therefore literal, not aspirational — there is no gate to bypass
+because there is no gate.
+
+### XV.2 — RULING: nobody declares a VM dead. It dies a compudynamic death.
+
+**Captain Bob, verbatim:** "Nobody declares a VM dead, it died a compudynamic death."
+
+**This rejects the premise of §IX.3 and of §VII.3's detection gap, and both were wrong to ask
+what they asked.** §IX.3 asked "what has standing to declare a birther dead?" and called it
+"circular by construction." The circularity was an artifact of assuming death is a *judgment*
+someone renders. It is not: death is a physical outcome of the compudynamics — heat exhausts,
+the reservoir empties, the patron leaves the Stadium floor. There is no detector, no quorum, no
+supervisor, and nothing to build.
+
+**This retires the largest scheduler-shaped risk in the whole design.** §VII's ladder appeared
+to need a supervisor — some component watching liveness and deciding to escalate — and §XIV.5
+warned that a supervisor with a timer is a scheduler's twin. With death compudynamic, **that
+component does not exist and is not needed.** The ladder is self-applied while a VM is alive;
+once it is dead it is dead, which is exactly §VII.1 step 3's "fast and total, not a slow
+degrade." No actor, no handoff (§IX.1 already forbade one), no partial states.
+
+**Consequence for §VII.3.** The "wellness check at the nearest participating wellness center"
+idea recorded in `FABRIC-3.md` §XX does **not** need to be reconciled with this ladder as a
+detection mechanism, because no detection mechanism is required. It remains an independent idea
+on its own merits. §VII.3's framing ("a ladder with no detection story only fires on failures
+loud enough to notice by accident") was built on the same wrong premise and is withdrawn.
+
+### XV.3 — RULING: nobody owns turn order. Turn order is compudynamic.
+
+**Captain Bob, verbatim:** "Nobody owns the turn order. The turn order is compudynamic."
+
+This answers **§XIV.5 (item 14)** with a stronger invariant than the one proposed there. §XIV.5
+suggested a firewall — *"`switch.c` remains the sole owner of who runs next."* That named an
+owner, and naming an owner is what a conventional scheduler is. **The correct invariant names
+none:**
+
+> **Turn order is an emergent output of the compudynamics, not a decision any component makes.
+> Kernel-Hermes publishes facts into that system — "this VM has mail" — and computes no
+> ordering. Neither does anything else.**
+
+This is consistent with the project's own standing position, independently of this document:
+`FABRIC-3.md` §XIX records the design direction as "fix the gap **without a scheduler**," with
+the reasoning that "a fixed round-robin across identities would just be a different hardcoded
+policy — not in the spirit of" the design. §XV.3 is that same position restated for the
+reshuffle.
+
+**One honest observation, offered as a flag rather than an objection.** Traced 2026-09-18:
+`sk_vm_switch_signal_tick()` gates on `readiness >= SK_SWITCH_READINESS_THRESHOLD && has_work`,
+and `SK_SWITCH_READINESS_THRESHOLD` is `50u`, a hardcoded constant
+(`capsule_vm_switch_signal.c:52`). That is a fixed policy sitting in the middle of a
+mechanism this section calls compudynamic — the same category §XIX rejected as "a different
+hardcoded policy."
+
+The layering does reconcile: the compudynamic **turn-attractor** (§XIX/§XXI) decides what work
+is assigned, and the CPU-level switch signal is the mechanical follower that moves the
+processor. Turn order in the meaningful sense is the attractor, and it is compudynamic as
+ruled. But the constant `50` is a real seam, and it is the exact place where a hardcoded policy
+could quietly start deciding turns. **Flagged for later, not proposed as work here** — it
+predates this reshuffle and is `FABRIC-3.md` §XXVIII's own territory. Noted so it is not
+discovered later and mistaken for something this document introduced. (`FABRIC-4.md` §1's
+fixed-then-adaptive `rate` graduation is the precedent for how such a constant earns its way
+to adaptive: measure against a fixed baseline first, self-tune only after.)
+
+### XV.4 — §XIV.4 reframed: the question was persistence; the answer is conservation
+
+§XIV.4 asked whether in-flight messages must survive an arbiter's death, and warned that
+answering "yes" would force Hermes to hold durable state it could not safely write through
+Artemis at death-time. **Captain Bob, on that item: "What survives the death of what? I don't
+understand that last part."** Fair — it was posed as a persistence question, which is the wrong
+frame and the reason it read as opaque.
+
+**The right frame, given §XV.2.** A message is not only content; it is *heat*. Traced
+2026-09-18 in `capsules/common/messaging.4th`: `MSG-ALLOC` pulls `Q.SLOT` from the caller's own
+reservoir before admitting a message (rolling back via `STADIUM-RES-PUSH` on refusal, line
+127), and `MSG-FREE-NODE` releases it with `STADIUM-EVICT` (line 135-136). An arbiter dying
+while holding N messages is holding **N × `Q.SLOT` of fleet heat.**
+
+So the question is not "must the payloads be saved." It is:
+
+> **Does a dying arbiter return the heat its undelivered messages were holding?**
+
+- **Payloads may vanish.** Consistent with §VII.1 step 3's "no lingering, no partial states."
+- **The heat may not.** `K` = `vm_physics_fleet_heat_sum()` is held at `Q48_ONE` and
+  continuously verified (`FABRIC-3.md` §XVIII, `fleet_k_q48`/`fleet_conserved`). Heat that
+  dies with the arbiter is heat that breaks a live invariant.
+
+**The answer to "what survives the death of what" is therefore: nothing survives except K.**
+
+**This dissolves §XIV.4's hazard rather than resolving it.** There is nothing to persist, so
+there is no death-time write, so there is no circular dependency on Artemis, so the
+stateless-arbiter shape §XIV.4 recommended is simply correct rather than a trade-off. And since
+death is compudynamic (§XV.2), a VM's death *is* already a Stadium eviction event — returning
+heat is not a special case bolted onto death, it is what dying consists of. **§XIV.3's
+"Artemis for persistence" ruling stands untouched and applies to fleet/floor persistence; the
+arbiter simply never needed any.**
+
+**The one thing to verify when this is eventually built** (not a design question, an
+implementation check): that every message-holding structure's teardown path actually reaches
+`STADIUM-EVICT`, so a mass teardown returns heat rather than leaking it. `fleet_conserved`
+already makes that directly testable — a leak shows up as K ≠ `Q48_ONE`, not as a silent
+error. Added as punch item 16.
+
+### XV.5 — What these four rulings have in common
+
+Three of the four answers reject the question rather than answer it. There is no death
+declarer, no turn-order owner, and nothing to persist — and in each case the thing that seemed
+to need an authority turned out to be an outcome of the physics instead. The one question that
+*was* answered directly (§XV.1, who may birth) was answered with "anyone," which also declines
+to create an authority.
+
+**That is the actual defence against becoming a conventional scheduler**, and it is stronger
+than the firewall §XIV.5 proposed. A firewall constrains a component that owns something. These
+rulings mean **there is no owner to constrain.** The design's protection is structural, not
+procedural: authority only ever flows down the birth graph (§IX.2), and everything else —
+death, turn order, conservation — is physics rather than policy.
+
+### XV.6 — Punch list after these rulings
+
+- ✅ **Item 6 (§VI.3, "ACL/DNA" referent) — ANSWERED** (§XV.1): inheritance by copy; existing
+  `ACL-INHERIT` semantics suffice; no fifth `DictEntry` field.
+- ✅ **Item 7 (§VI.4, "standing") — ANSWERED** (§XV.1): decorative; reading (a) confirmed.
+- ✅ **Item 8 (§VII.3, ladder vs. detection) — WITHDRAWN** (§XV.2): premise wrong, no detection
+  mechanism required.
+- ✅ **Item 11 (§IX.3, who declares a birther dead) — PREMISE REJECTED** (§XV.2): nobody;
+  compudynamic death.
+- ✅ **Item 14 (§XIV.5, scheduler firewall) — ANSWERED** (§XV.3), with a stronger invariant
+  than the one proposed: no owner, not a named owner.
+- ✅ **Item 15 (§XIV.4, message durability) — DISSOLVED** (§XV.4): reframed from persistence to
+  conservation; nothing survives but K.
+- ⬜ **Item 16, NEW** (§XV.4) — implementation check, not a design question: verify every
+  message-holding teardown path reaches `STADIUM-EVICT` so mass teardown returns heat.
+  Testable directly via `fleet_conserved`.
+- ⬜ **Item 9** (§VII.2 — `SOS` message-type number and its consumer) — still open. Note §XV.2
+  narrows it: with no death-declarer, an `SOS` consumer cannot be a supervisor, so the question
+  is now specifically what a *peer* does on receipt.
+- ⬜ **Item 10** (§VIII.3 — the sinking semaphore's mechanism, the clean-shutdown routine's
+  definition, and whether the window is bounded) — still open, and now the largest remaining
+  design item.
+- ⬜ **Item 12** (§XIII.5 — is the Console Tripod leg a new singleton, distinct from today's
+  per-attach proxies?) — still open, and still gates §IV.
+
+**Remaining open: items 9, 10, 12, 16.** Item 10 is the substantive one; 9 is downstream of it,
+12 is independent, and 16 is a build-time check rather than a decision.