FABRIC.md: resolve item 1.2 -- resting floor is derived, not tuned

Punch list §25 item 1.2 complete.
Floor = max(mass of pinned patrons, one message-sized cell); both terms
derived rather than a tuned constant, closing the zero-pinned-patrons
reachability deadlock the first term alone would leave open.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
Robert Allan James
2026-08-04 08:07:23 -04:00
co-authored by Claude Sonnet 5
parent f81a53cbf6
commit 9f8bd2a13d
+20 -6
View File
@@ -1710,11 +1710,20 @@ rule looks correct.
### 22.5 Open
1. **The resting floor.** A VM that goes quiet loses capacity; if it wakes it may not
regain it fast enough. The obvious guard is a floor below which a quota cannot fall —
but that is a tuned number, which this design otherwise avoids. Decide it deliberately.
A principled alternative: floor a VM's quota at the mass of its pinned patrons, which is
not a tuned constant but a derived one.
1. ~~**The resting floor.**~~ **RESOLVED by item 1.2 (§25.2), 2026-08-04.** A VM that goes
quiet loses capacity; if it wakes it may not regain it fast enough. The obvious guard is a
floor below which a quota cannot fall — but that is a tuned number, which this design
otherwise avoids.
**Floor = max(mass of pinned patrons, one message-sized cell).** The first term is the
principled alternative this section already named: derived, not tuned. The second term
closes a gap the first term leaves open on its own — a VM with zero pinned patrons would
otherwise get a floor of zero, and a VM with zero quota cannot receive anything, including
the message that would be the reason for it to wake up and regrow via §22.1's
density-gradient feedback. That is a deadlock: no capacity to receive, no way to ever
regain capacity. One message-sized cell is itself derived, from §23.3's cell sizing rule
("size the cell so a typical message is exactly one cell"), not a second tuned constant —
so the discipline this section wanted to preserve still holds with both terms in place.
2. **What arbitrates a transfer, concretely?** §7 says Hera. Under §22.3 a transfer is
arithmetic on two integers, so the mechanism is trivial — but *when* she does it, and on
what signal, is not yet stated. It should read off the density gradient (§22.1) rather
@@ -2263,9 +2272,14 @@ document and committing that amendment as its own item.*
> Item 3.1 is now unblocked on this item; the ninth wire and the reserved header bytes
> (§23.3) are the concrete carry-forward.
- [ ] **1.2 — The resting floor.** Whether a VM's quota has a floor, and whether it is the
- [x] **1.2 — The resting floor.** Whether a VM's quota has a floor, and whether it is the
mass of its pinned patrons (derived) or a constant (tuned). *Refs:* §22.5 #1.
> **RESOLVED 2026-08-04.** Floor = max(mass of pinned patrons, one message-sized cell).
> Both terms derived, neither tuned — the second closes a reachability gap the first term
> leaves open for a VM with nothing pinned (zero quota means it can never receive the
> message that would let it regrow). Full argument in §22.5 #1.
- [ ] **1.3 — What triggers a capacity transfer.** Hera arbitrates; on what signal, and how
often. Should read the density gradient, not a schedule.
**Constraint, not optional:** arbitration mutates patron mass, so §18.5's invariant binds