From a842789ae661a672660d7d8d7044d081f8c05787 Mon Sep 17 00:00:00 2001 From: Claude Date: Fri, 18 Sep 2026 21:50:27 +0000 Subject: [PATCH] =?UTF-8?q?FABRIC-3.5.md=20=C2=A7XV:=20the=20authority=20q?= =?UTF-8?q?uestions=20answered,=20three=20by=20rejecting=20the=20premise?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 Claude-Session: https://claude.ai/code/session_01VkM1zHGvBerLF6aqkHPweP --- FABRIC-3.5.md | 209 ++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 203 insertions(+), 6 deletions(-) diff --git a/FABRIC-3.5.md b/FABRIC-3.5.md index 54da55cf..b38413d5 100644 --- a/FABRIC-3.5.md +++ b/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.