diff --git a/infra/PROD-PROVISIONING.md b/infra/PROD-PROVISIONING.md
index 30714f1..53c3b58 100644
--- a/infra/PROD-PROVISIONING.md
+++ b/infra/PROD-PROVISIONING.md
@@ -54,15 +54,25 @@ more RAM until this is understood** — see the warning at the end.
 | DMI (`dmidecode -t memory`) | **16 GB Samsung M471A2K43DB1-CTD in DIMM1 @ 2667 MT/s**, DIMM3 empty |
 | BIOS e820 map | reports ~16 GiB usable, incl. `0x100000000-0x42f7fffff` |
 | Kernel summary | `Memory: 2568544K/16546088K available (13958980K reserved)` |
-| `last_pfn` | revised **down** from `0x42f800` (~16.7 GiB) to `0xc3c10` (~3.06 GiB) in early boot |
+| `last_pfn` | two values, `0x42f800` then `0xc3c10` — **NOT a cap**, see the correction below |
 | Zones | `Normal` zone `present 3340288` pages (~12.7 GiB) but **`managed 0`** |
 | `MemTotal` | **2,753,284 kB ≈ 2.6 GiB** |
 | Memory blocks | 127 online, 128 MiB block size |
 
 **The DIMM is healthy.** It is present, correctly identified, and running at its rated speed. The
 kernel *sees* all 16 GB and then reserves 13.3 GiB of it. Everything below ~3 GiB is usable and
-everything above 4 GiB is present-but-unmanaged — the classic signature of **memory remapping
-above 4 GB not being applied**, not of failing memory.
+everything above 4 GiB is present-but-unmanaged.
+
+> **CORRECTION (2026-09-01).** An earlier version of this section cited the `last_pfn` line as
+> evidence of a memory cap, and called the pattern the signature of "memory remapping above 4 GB
+> not being applied". **The `last_pfn` reading was wrong.** x86 boot prints `last_pfn` twice: first
+> `max_pfn` from the full e820, then `max_low_pfn` — the end of RAM *below 4 GiB*. The e820 low
+> usable region ends at `0xc3c0ffff`, so the next PFN is exactly `0xc3c10`, which is the second
+> value observed. It matches to the byte and is entirely normal on any machine with >4 GiB. A
+> routine boot message was presented as a smoking gun.
+>
+> The real anomaly is narrower than first stated: the `Normal` zone is `present` but `managed 0`,
+> 13.3 GiB is reserved, and **nothing in the boot log explains by what**.
 
 Node 1 is the control: **identical** HP EliteDesk 800 G5 Mini, **identical** BIOS R21 Ver. 02.26.00,
 identical i7-9700T — and it addresses its full 31 GiB. So this is not a firmware-version defect; it
@@ -90,6 +100,11 @@ What the comparison ruled OUT as the cause:
   which rules out the classic "BIOS bug: MTRRs don't cover all of memory, losing N MB" path.
 - **`/proc/iomem` registers `100000000-42f7fffff` as `System RAM`** and 127 × 128 MiB memory
   blocks report `online`. The memory reaches the kernel and is then reserved.
+- **Integrated graphics is NOT the cause** (operator hypothesis, tested 2026-09-01). `/proc/iomem`
+  shows `c8800000-cc7fffff : Graphics Stolen Memory` = **exactly 64 MiB**, matching the BIOS
+  `Video Memory Size=64 MB` setting, and it sits **below** the 4 GiB line. The UHD 630 with `i915`
+  bound takes precisely what it is configured to take. It cannot account for 13.3 GiB, and it is
+  not even in the affected address range.
 
 Real BIOS differences found (node 1 = works, node 2 = broken):