diff --git a/FABRIC-3.5.md b/FABRIC-3.5.md index 806b9eea..2f4f1895 100644 --- a/FABRIC-3.5.md +++ b/FABRIC-3.5.md @@ -4223,3 +4223,110 @@ future reader will conflate them exactly as §XV.4 and §XXXIV.6 did.** - ⬜ **Item 42, NEW** — qualify "K"/"conservation" throughout the docs (§XXXIX.6). Folds into item 13. - ⬜ **Item 40** unchanged — separate reservation from age (§XXXVIII.4). + +--- + +## XL. Item 40 SETTLED: preserve the consumption model, ledger the sink — and a correction to §XXXVIII's framing + +§XXXVIII.4 recommended separating reservation from age to remove what it called a leak. +**Further evidence found while settling this says the behaviour is a deliberate model, not a +defect — and the recommendation is revised accordingly.** + +### XL.1 — The authors knew. It is documented at the reap site. + +`messaging.4th`, block 5025, immediately above `MSG-REAP`: + +> `( K reap only fires at heat=0: freed K contribution is 0. )` +> `( Force-reap not yet implemented. If added: explicit )` +> `( K redistribution will be required here. )` + +**That is not an oversight; it is a design note.** It states outright that reaping returns zero, +and anticipates that a *force*-reap — freeing a message before it has cooled — would need +"explicit K redistribution," i.e. handing the remaining heat back. **The zero-return at natural +reap is intended: the heat is modelled as consumed over the message's life, not held as a +refundable deposit.** + +### XL.2 — CORRECTION to §XXXVIII + +§XXXVIII called it "a real, structural leak" and framed the two-meanings conflation as an +error. **That framing was wrong.** The trace in §XXXVIII stands exactly — decay drains the +field, reap returns nothing, the eviction guard is bypassed — **but the interpretation does +not.** It is a consumption economy, documented where it happens, and §XXXVIII did not find that +comment. + +**What survives from §XXXVIII:** the mechanism, the arithmetic, and the observation that +nothing replenishes. **What is withdrawn:** the word "leak," and the §XXXVIII.4 recommendation +to change the economics as part of this reshuffle. + +### XL.3 — Two further roles for message heat, both consistent with the model + +- **`MSG-NACK-LAST` halves it** (`messaging.4th:432`): `DUP MSG-HEAT@ 2 / OVER MSG-HEAT!`. A + rejected message ages **twice as fast** — a penalty expressed in the same currency. This only + makes sense if heat is a time-to-live, reinforcing §XL.1. +- **Delivery order does *not* use it.** `MSG-DELIVER-ALL` scans the arena in slot order and + delivers anything not already delivered or nacked — **no heat comparison anywhere.** So heat + plays no scheduling role, which is consistent with §XV.3 (nothing owns turn order) and means + changing it cannot perturb delivery sequencing. + +### XL.4 — RULING: keep the model; make the sink explicit + +> **Kernel-Hermes preserves the consumption economy exactly — heat decays, natural reap returns +> nothing — and additionally *records what it consumes*.** + +The Stadium per-VM invariant then reads: + +``` + Σ(resident patron heat) + reservoir + consumed == Q48_ONE +``` + +**This is what makes item 41's `stadium_conserved()` possible at all.** Without a `consumed` +term, a checker over a system with a designed sink reports non-conservation as *normal +operation* — which forces a tolerance that hides real bugs, or makes the checker useless. +**With it, the invariant is exact and the epsilon stays zero.** + +**A pleasing arc worth recording:** §XXXVII.3 invented a `decayed` counter to keep the ledger +exact. §XXXVIII.5 proposed deleting it by separating the fields. **It turns out to be the thing +that makes Stadium conservation checkable** — the counter was right, and for a better reason +than the one it was introduced for. + +### XL.5 — Why not separate the fields now, despite it being cleaner + +§XXXVIII.4's design is still the better *architecture*. It is rejected for **this** reshuffle on +three grounds, none of them about elegance: + +1. **Scope.** This document's own discipline is "a reorganization, not an invention." Changing + the fleet's economic model is an invention, and it would be smuggled in under a relocation. +2. **Measurement comparability.** Every DoE campaign and the patent-supporting figures were + taken under the current economics. §XXV.1 relieves some of that by rewriting the DoE's + invocative paths, but **it does not make a behavioural change to the economy free.** +3. **The economics are not understood well enough to change safely.** §XL.3 found two + additional roles for message heat *while settling a question about a third*. That is a + subsystem still yielding surprises, and changing its semantics mid-reshuffle is how a + relocation becomes an outage. + +### XL.6 — The question that is real and is deliberately not answered here + +**Nothing replenishes a Stadium reservoir.** Each VM's quota starts at `Q48_ONE` and thereafter +only moves within that VM or is consumed. So a long-lived VM's capacity to send **declines +monotonically**, and the decline accelerates with fleet size — batched pumping (§XXII's +`SK_MSG_PUMP_BATCH`) means longer queue residency, more decay per message, more consumption. + +**This is the fourth instance of this reshuffle's recurring pattern:** latent at Tripod scale, +visible at fleet scale — after the pump's O(N) walk, `SK_SWITCH_MAX_SLOTS`, and +`MSG-TOTAL-HEAT`'s arena scan. + +**Whether a reservoir should ever replenish is a genuine open design question about the +compudynamics**, not a reshuffle decision. **Punch item 43, explicitly outside this work**, and +properly `FABRIC-3.md`'s or a successor's topic. Recorded here so it is not lost — and so that +whoever meets a VM that has quietly stopped being able to send knows where it was first named. + +### XL.7 — Punch list + +- ✅ **Item 40 — SETTLED** (§XL): preserve the consumption model; kernel-Hermes ledgers + `consumed`; §XXXVIII's "leak" framing withdrawn and its recommendation revised. +- ✅ **Item 41 clarified** — `stadium_conserved()` checks + `Σ patron + reservoir + consumed == Q48_ONE`, exactly, epsilon zero. +- ✅ **§XXXVII.3's counter vindicated** — kept, and now load-bearing for §XL.4. +- ⬜ **Item 43, NEW, outside this reshuffle** — should a Stadium reservoir ever replenish? + (§XL.6) +- Items 32–35, 37, 42 unchanged.