diff --git a/work/projects/cpm-post-release-analysis-2026-10-27.md b/work/projects/cpm-post-release-analysis-2026-10-27.md
index 6ce514b6..5f102f7c 100644
--- a/work/projects/cpm-post-release-analysis-2026-10-27.md
+++ b/work/projects/cpm-post-release-analysis-2026-10-27.md
@@ -362,3 +362,9 @@ Re-cut of the post-release data (macOS 1.213.x, 26–27 Oct, matured since the s
 ### Notes
 - The "P3" lines above disagree: priorities say the baseURL fix is released; "What shipped" says P3 (#7493) is on main only and not in 1.213. Re-check before relying on either.
 - Scratch SQL runner and queries are in the session scratchpad; the harness test is not committed or pushed.
+
+### Addendum 28 Oct — error-page pixel and the sleep hypothesis
+- There is an error-page pixel: `m.mac.errorpageshown.other` (+ `.daily`, `pixel_id='m'`, params `d`/`e` = error domain/code, `pixelSource`), fired in `Tab.swift` when the error page is shown, plus `m.mac.errorpageshown.webkittermination`. macOS 1.213, 26–27 Oct: 7,511 shows (2,284 install-days; ≈0.4 per loaded install-day). Codes: DNS `-1003` 29%, TLS `-1200/-1202…` 26%, connection lost `-1005` 10%, `-1004` and `-1001` a few % each; **offline `-1009` only 1.6% (122)**. So error pages are mostly dead hosts and certificate problems, not "no network after wake".
+- Correlation with the wake group does not show up. Hourly counts correlate 0.88 with wake episodes and 0.88 with non-wake ones (both follow the rollout, so it says nothing). Per OS version (9 points) error pages per loaded install vs wake episodes per loaded install: r = 0.02 (vs 0.32 with non-wake). The pixel has no install id, so no per-install join.
+- Reasoning against the wake link: the error document never sends `init`, so it does not wake the background. A failure counted on an error page would carry the background state as it was (after >30 s idle: no view; otherwise an old view), not a view created in the last 30 s. If error pages matter, they would sit in the "no view" and "other" cohorts rather than in wake. Not tested.
+- The sleep/network-drop hypothesis above is therefore weak. The harness result (error pages are measured and counted as failures) stands as a monitor false-positive source; its size is bounded by the error-page rate (≤0.4 per install-day, most of it unrelated to wake). Filtering `.alternateHtmlLoad` in the monitor would remove it.