FABRIC.md §19 — mass, density, and what K actually is

Supplies the concrete definition §4 was missing. §4's claim that ranking is
read rather than decided is empty until the thing being read is a number.

Three quantities, not one:
  Heat    conserved share moved by traffic, sum = 1.0 always (already built)
  Mass    cells a patron occupies -- its footprint (new)
  Density heat / mass -- heat per cell (new, derived)

K is left untouched. vm_physics_conserved() already defines it as a normalised
heat share summing to Q48_ONE, not an occupancy ratio; defining it as
mass/capacity would have contradicted implemented, tested code.

Ranking, admission-when-full, and migration hysteresis all read off density
with no policy and no damping constant.

Two corrections to §4:
  - The self-limiting claim keeps its conclusion but loses its mechanism. A hot
    entry is easier to reach, not harder; the real governor is conservation,
    since heat is zero-sum and capped at 1.0.
  - "Density generates heat" reverses the causality. Traffic confers heat;
    density is heat per cell, derived downstream.

Open: mass depends on payload threshold and header size (§12 Q1, Q2), which are
now prerequisites rather than sizing details; and vm_physics_touch scales heat
transfer by wall-clock time, which §18.5 forbids and which must be restated on
tick count before L0 can use it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

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.