diff --git a/FABRIC.md b/FABRIC.md
index f7c7ad6..cf97352 100644
--- a/FABRIC.md
+++ b/FABRIC.md
@@ -1445,10 +1445,37 @@ decides where work goes; that remains capability-based routing.
 
 ### 20.5 Open
 
-1. **Bounding the VM population.** What is the outer Stadium's capacity, and what happens
-   at the bound — birth refused, or coldest VM reaped? The latter is consistent with §19.3
-   but means a VM can die because a new one was born, which needs to be an explicit,
-   stated behaviour rather than an emergent surprise.
+1. ~~**Bounding the VM population.**~~ **RESOLVED by item 1.5 (§25.2), 2026-08-04.** What is
+   the outer Stadium's capacity, and what happens at the bound — birth refused, or coldest
+   VM reaped?
+
+   **Correction first: "coldest reaped, consistent with §19.3" does not survive §20.2.**
+   §19.3's admission rule is *admit if denser than the least dense resident*. §20.2 already
+   decided every VM but Hera is born at heat zero. A newborn can never be denser than an
+   existing warm VM, so applying §19.3 literally at the outer level means births at the
+   bound would fail regardless — just silently, via a comparison that can never succeed,
+   instead of by an explicit refusal. Treating "coldest reaped" as automatic would also
+   require a bespoke, non-density rule that exists for VMs alone, which is exactly the
+   per-kind special case §11 warns against.
+
+   **Resolution: birth is refused at the bound.** Making room is Hera's own deliberate act —
+   she already reaps VMs (§20.1) — never an automatic side effect of someone else's birth
+   request. This is the explicit, stated behaviour the original text asked for.
+
+   **The bound itself: 4, Kconfig-tunable, explicitly a placeholder.** 4 matches Tripod's
+   own currently-known topology (Hera + two Hermes instances + Artemis) — the smallest
+   number that doesn't already contradict what this system is known to need, not a padded
+   estimate. It is expected to be too small for real workloads. The right way to find an
+   idealized default is empirical — a DoE campaign, the same discipline already used
+   elsewhere in this project (`experiments/bare_metal/`) — not a second guess made on paper.
+   Tracked as future work, not invented here. The constant is a Kconfig symbol (e.g.
+   `STADIUM_MAX_VM_COUNT`, named at implementation time in item 3.1 alongside the other new
+   symbols this phase introduces), not hardcoded.
+
+   **Fixed for the machine's lifetime once set at build** — resolves §22.5 #4 below in the
+   same stroke. The outer total does not itself flex at runtime; only per-VM quotas do
+   (§22). An outer bound that could grow or shrink live would mean §2's "inescapable wall"
+   is not actually inescapable.
 2. **Is a VM's mass its allocated share, or one cell?** §20.4 proposes the share. The
    alternative — every VM is one entry regardless of size — is simpler but throws away the
    distinction in the table above, which is the reason to do this at all.
@@ -1765,10 +1792,10 @@ inventing an unrelated number. 1000:1 against the virtual tick is comfortably pa
    pins down the amount. Reported rather than invented — it can become its own item if
    warranted, but is out of this item's scope.
 3. ~~**The exact timescale ratio**~~ **RESOLVED by item 1.4 — 1000:1.** See §22.4.
-4. **Does the outer Stadium's own capacity ever change?** §22 makes per-VM quotas elastic
-   within a fixed total. Whether that total is itself fixed for the machine's lifetime is
-   §20.5 #1, still open — and it should stay fixed, or §2's inescapable wall is not
-   inescapable.
+4. ~~**Does the outer Stadium's own capacity ever change?**~~ **RESOLVED by item 1.5 —
+   no.** §22 makes per-VM quotas elastic within a fixed total; the total itself is fixed for
+   the machine's lifetime, set once at build via the Kconfig bound §20.5 #1 introduces. See
+   §20.5 #1 for the full argument.
 
 ---
 
@@ -2344,9 +2371,17 @@ document and committing that amendment as its own item.*
   > number. Comfortably past §12 Q5's order-of-magnitude minimum. Kconfig-tunable at
   > implementation (item 3.1). Full argument in §22.4.
 
-- [ ] **1.5 — The outer bound.** The outer Stadium's capacity, and the behaviour at the
+- [x] **1.5 — The outer bound.** The outer Stadium's capacity, and the behaviour at the
   bound: birth refused, or coldest VM reaped. *Refs:* §20.5 #1, §22.5 #4.
 
+  > **RESOLVED 2026-08-04.** Bound = 4 (matches Tripod's known topology: Hera + 2 Hermes +
+  > Artemis), Kconfig-tunable, explicitly a placeholder pending a later DoE campaign to find
+  > an idealized default rather than a second guess made on paper. Fixed for the machine's
+  > lifetime once set at build. At the bound, **birth is refused** — not coldest-VM-reaped,
+  > which the original text called "consistent with §19.3" but which does not survive
+  > §20.2's cold-start birth rule (a newborn can never out-density an existing warm VM).
+  > Making room stays Hera's own deliberate act. Full argument in §20.5 #1.
+
 - [ ] **1.6 — A VM's mass: allocated share, or one cell.** *Refs:* §20.4, §20.5 #2.
 
 - [ ] **1.7 — Rule out recursion beyond two levels** — deliberately, not by omission.