diff --git a/FABRIC.md b/FABRIC.md index a214b29..fd622d9 100644 --- a/FABRIC.md +++ b/FABRIC.md @@ -923,3 +923,131 @@ something load-bearing. L0 should make it explicit: > recorded for diagnostics and must never be an input to a decision.** **DECIDED**, and it supersedes the "leaning (1)" in the earlier draft of this section. + +--- + +## 19. Mass, density, and what K actually is + +§4 is marked LEANING with the note that *"the density formulation needs a concrete +definition."* This section supplies it. It is the keystone: §4 claims ranking is **read** +rather than decided, and that claim is empty until the thing being read is a number. + +The objection that forced this section is the right one. Density is *quantity per unit +volume*, so it implies a mass and a volume. Neither had been named. + +### 19.1 K is already defined, and it is not an occupancy ratio + +This has to come first, because the obvious definition of K contradicts working code. + +`vm_physics_conserved()` (`capsule/capsule_vm_physics.c:456-461`) sums +`execution_heat_q48` across live VMs and tests that total against `Q48_ONE`: + +```c +uint64_t sum = vm_physics_fleet_heat_sum(); +uint64_t diff = (sum > Q48_ONE) ? (sum - Q48_ONE) : (Q48_ONE - sum); +return diff < VM_PHYSICS_EPSILON_Q48; +``` + +So: + +> **K is a conserved, normalised heat *share*. Total heat is always 1.0. Traffic transfers +> heat to a patron from the others; it does not create it.** + +K is **not** occupancy, and defining it as `Σmass / capacity` would contradict an +implemented, tested mechanism. It stays exactly as it is. + +### 19.2 Three quantities, not one + +| Quantity | What it is | Range | Status | +|---|---|---|---| +| **Heat** | conserved share, moved by traffic | Σ = 1.0 always | already implemented | +| **Mass** | cells the patron occupies — its footprint | integer ≥ 1 | new | +| **Density** | **heat ÷ mass** — heat per cell | derived | new | + +Heat is the conserved quantity. Mass is an independent axis and never enters K. Density is +the ratio, and it is density in the literal sense at last: quantity per unit volume, where +the volume is a patron's own footprint inside the bounded capacity §2 requires. + +A patron holding a large share of the fleet's heat in a single cell is dense. A patron +squatting on four cells with a negligible share is sparse, and belongs back in the +warehouse. + +**DECIDED.** + +### 19.3 Everything else reads off it + +The point of §4 is that no policy exists. With density defined, none is needed: + +- **Ranking** — order by density. Read, not computed by a scheduler. §4's first bullet is + now true rather than aspirational. +- **Admission when full** — admit the newcomer if it is denser than the least dense + resident, and evict that one. This is a comparison of two intrinsic numbers, not a + policy, and it closes the "what happens when the Stadium is full" gap. +- **Hysteresis** — falls out unpaid-for. A heavy patron needs a proportionally larger heat + share to hold its floor space, so a block sitting near the threshold does not oscillate + on and off. No damping constant to pick, which is what §4 wanted and could not previously + deliver. +- **Migration cost is not a separate quantity.** An earlier draft of this reasoning treated + cost-to-move as its own axis. It is not needed: footprint and cost correlate, because a + patron is expensive to move precisely because it is large. Deriving cost from mass avoids + introducing a second tunable, which §11 would rightly call speculative generality. + +### 19.4 Correction to §4 — the self-limiting claim has the wrong mechanism + +§4's third bullet states: + +> *Popularity is self-limiting. A crowded entry is harder to reach, which throttles traffic +> to it, which cools it. The governor is local and emergent — no global damping constant to +> pick.* + +**The conclusion is right and the mechanism is wrong.** In a hall, a crowd physically +blocks access to the car. In a computer the inverse is true — a hot entry is *easier* to +reach, since that is the entire purpose of a cache. The metaphor does not survive +translation, and no mechanism in this design reproduces the blocking effect because the +effect is not real in this substrate. + +The real governor is **conservation**. Heat is zero-sum: total heat is 1.0, so a patron +heating up necessarily cools every other patron, and nothing can exceed the ceiling. +Popularity is self-limiting because there is a fixed amount of popularity to go around. + +This is §4's *second* bullet — *"K constrains the total, so ordering is forced by +conservation rather than by tuned parameters"* — which was the correct answer already. The +third bullet should be struck, not repaired. Designing a mechanism to make the crowd +metaphor come true would be fitting the system to the analogy, which §14 already warns +against in the other direction. + +**DECIDED.** §4's third bullet is superseded by this section. + +### 19.5 Correction to §4 — "density generates heat" reverses the causality + +§4 says *"Density generates heat; nobody computes it."* Under §19.2 that is backwards, and +the confusion is that one word was carrying two meanings: + +- **Traffic** generates heat — activity concentrated on a patron transfers heat share to + it. §4's causality is correct with this word substituted. +- **Density** is heat per cell — *derived* from heat, downstream of it, and it is the + quantity that gets read when ranking. + +The corrected statement: + +> **Traffic confers heat. Heat is conserved at 1.0. Density is heat per cell. Ranking reads +> density.** + +Nobody decides what matters at any step in that chain. §4's spirit is intact; only the +noun was overloaded. + +### 19.6 Open + +1. **What is mass, exactly, for each patron?** The definition is "cells occupied," which + requires §12 Q1 (payload threshold — inline versus by reference) and §12 Q2 (header + size) to be settled first. A patron stored by reference has small mass regardless of + payload size, which may be right or may be a loophole — a 1 MB block held by reference + would occupy one cell and read as dense. This needs deciding. +2. **Is mass constant for a patron's lifetime?** §17.4 Q4 (do patrons mutate in place) + decides this. If mass can change while a patron is resident, density is not stable and + ranking may thrash. +3. **How does traffic transfer heat between patrons, concretely?** `vm_physics_touch()` + does this today for VMs, but it scales the transfer by wall-clock elapsed time + (`capsule_vm_physics.c:272`), which §18.5 forbids for anything influencing patron state. + **The transfer rule must be restated on tick count before L0 can use it.** This is the + single most concrete piece of work this section implies.