diff --git a/FABRIC.md b/FABRIC.md
index fd7bfca..f7c7ad6 100644
--- a/FABRIC.md
+++ b/FABRIC.md
@@ -1708,6 +1708,23 @@ The exact ratio is a tuning question, but the *ordering* is not: capacity must b
 slower loop. Getting this backwards produces a system that thrashes while every individual
 rule looks correct.
 
+**RESOLVED by item 1.4 (§25.2), 2026-08-04 — 1000:1, grounded in an existing precedent, not
+picked from nothing.** `capsule_vm_physics.c:434-441`'s `vm_physics_heartbeat_tick()` already
+runs a fleet-level slow loop at `HEARTBEAT_INFERENCE_FREQUENCY` virtual ticks (default 1000,
+`starforth_config.h:72`) to recalibrate `fleet_transfer_slope_q48` — the rate `vm_physics_touch()`
+uses for heat transfers. Different mechanism (heat-transfer-rate recalibration, not
+capacity/mass transfer), but the identical shape item 1.3's capacity-tick needs: a coarse,
+fleet-level reassessment layered over the fine virtual tick, in the same file, same
+subsystem.
+
+The capacity-tick gets its **own** named constant rather than literally sharing
+`HEARTBEAT_INFERENCE_FREQUENCY` — they are conceptually separate concerns (inference-engine
+window/decay tuning versus capacity arbitration), and coupling them would mean retuning one
+silently retunes the other. But its **default is 1000**, matching this precedent rather than
+inventing an unrelated number. 1000:1 against the virtual tick is comfortably past §12 Q5's
+"order of magnitude apart" minimum. Named and made a Kconfig symbol at implementation time
+(item 3.1), same tunable-knob convention as item 1.1's containment-depth cap.
+
 ### 22.5 Open
 
 1. ~~**The resting floor.**~~ **RESOLVED by item 1.2 (§25.2), 2026-08-04.** A VM that goes
@@ -1747,7 +1764,7 @@ rule looks correct.
    says the mechanism is "arithmetic on two integers"; neither this section nor item 1.3
    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** in §22.4.
+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
@@ -2317,9 +2334,16 @@ document and committing that amendment as its own item.*
   > capacity moves per transfer — reported, not invented, out of this item's scope. Full
   > argument in §22.5 #2.
 
-- [ ] **1.4 — The heat/capacity timescale ratio.** The ordering is fixed (capacity slower);
+- [x] **1.4 — The heat/capacity timescale ratio.** The ordering is fixed (capacity slower);
   the ratio is not. *Refs:* §22.4, §22.5 #3.
 
+  > **RESOLVED 2026-08-04 — 1000:1.** The capacity-tick gets its own named constant,
+  > defaulted to 1000 virtual ticks, matching the existing precedent at
+  > `capsule_vm_physics.c:434-441` (`vm_physics_heartbeat_tick()`'s
+  > `HEARTBEAT_INFERENCE_FREQUENCY`-gated fleet recalibration loop) rather than an invented
+  > 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
   bound: birth refused, or coldest VM reaped. *Refs:* §20.5 #1, §22.5 #4.