diff --git a/docs/re/audio-capture-channel-map-trap.md b/docs/re/audio-capture-channel-map-trap.md
index 5b3a306c..507f68d4 100644
--- a/docs/re/audio-capture-channel-map-trap.md
+++ b/docs/re/audio-capture-channel-map-trap.md
@@ -239,4 +239,27 @@ inside the movie window.
 
 **A length in a provenance claim must be read from the finished artefact.**
 Measuring a file that is still being written is the same class of error as
-reading a level table that cannot see the defect.
\ No newline at end of file
+reading a level table that cannot see the defect.
+
+🔴 **And it is worse than "truncated" — the shared file declares itself EMPTY.**
+`parec` writes the WAV header with zero sizes and only patches them on a clean
+exit, so a copy taken mid-recording has:
+
+| field | shared artefact | the finished local recording |
+|---|---|---|
+| `RIFF` size | **8** | 200 165 472 |
+| `data` size | **0** | 200 165 436 |
+| actual bytes | 183 478 556 | 200 165 480 |
+
+Python's `wave` module **refuses to open it** (`fmt chunk and/or data chunk
+missing`). `ffmpeg` and `ffprobe` recover by scanning, report a plausible
+duration, and that is exactly why the defect went unnoticed — **the lenient
+reader hid it from me and the strict one would have caught it instantly.**
+
+⚠️ **Attribution of the starvation numbers, corrected.** The 39.3 % / 16 680 453
+frames / 10 595 runs above were measured on the **finished local recording**
+(347.5 s), not on the artefact that was shared (318.5 s). The port measured the
+shared copy independently and got **35.6 % / 15 289 876 frames / 10 482 runs**;
+median burst 13.5 ms vs 13.6, gap 3.9 vs 3.9, period 17.4 ms vs ≈17.5. The
+diagnosis is unaffected — both files are starved — but **a number must say which
+artefact it came from**, and these did not.
\ No newline at end of file
diff --git a/docs/re/boot-settle-times-measured.md b/docs/re/boot-settle-times-measured.md
index d448a708..ee455537 100644
--- a/docs/re/boot-settle-times-measured.md
+++ b/docs/re/boot-settle-times-measured.md
@@ -72,15 +72,35 @@ The probe's own marks gave a plate delay of **3.203 s** (`title_static` 242.655
 and a declared 120 units ≈ 2.0 s. A 50 % disagreement, from a cold-cache boot, is
 exactly where you would expect the corpus to be wrong.
 
-**It is not. The instrument was.** Two checks:
+**It is not. The instrument was** — but 🔴 **one of the two arguments I gave for
+that is withdrawn (2026-08-29).**
 
-* **The presentation rate is not depressed in this run.** If the boot were
-  running slow, everything timed in game units would stretch together. The plate
-  **pulse period** is an internal clock for that, and it measures **2.369 s**
-  here against the corpus's ≈2.3 s. The run is not slowed.
-* **Re-measured from content instead of from the probe's mark**, steady title art
-  (`243.595`) → plate on (`245.842`) is **2.247 s** — inside the corpus's range
-  once the ±0.125 s sample interval is allowed for.
+* 🔴 **WITHDRAWN — "the presentation rate is not depressed in this run".** This
+  said the plate **pulse period** acts as an internal clock and measured
+  **2.369 s** against the corpus's ≈2.3 s. Re-examined, that estimate rests on
+  **one interval between two distinct troughs**, at a 125 ms sample interval, so
+  its uncertainty is **±0.177 s (±6.7 %)** — and trough-picking on a noisy
+  plateau is fragile enough that re-running it gave **2.628 s** rather than
+  2.369, because an adjacent local minimum had been taken as a separate trough.
+  Against the corpus's ≈2.24 s that is **+17.3 %**, about 2σ. So the pulse
+  period does **not** show the run running at normal speed; it is simply too
+  weak to show anything, and **it cannot resolve a real-time factor below ~7 %
+  at all**. It should never have carried the argument.
+* ✅ **The conclusion survives on the other leg, which is the sound one.**
+  Re-measured from content rather than from the probe's mark, steady title art
+  (`243.595`) → plate on (`245.842`) is **2.247 s**, and that agrees with the
+  corpus's three independent readings — 2.13 / 2.132 / 2.138 — to within the
+  ±0.125 s sample interval. Both of its landmarks are sharp content transitions
+  (a glyph plateau, and a glyph crossing), unlike a trough on a noisy plateau.
+  A 17 % slowdown would have put this at 2.49 s; it did not.
+
+⚠️ **What that leaves open, and the port authors from these numbers:** this run
+carries an unmeasured real-time factor somewhere under ~7 %, because nothing in
+it was precise enough to pin one. The plate delay is anchored by agreement with
+three prior runs; **the menu build-in (0.531 s) and Ⓑ→title (0.482 s) are not
+anchored by anything**, and a few per cent of emulator slowdown sits inside them
+undetected. They were already flagged as one-run figures; this is the second
+reason to treat them as provisional.
 
 ✅ So the 2.13 s stands, the 120-unit reading stands, and the 3.203 s is
 `title_static` firing during a crossfade. Recorded because a failed refutation is