diff --git a/work/projects/cpm-extension-health-pixels-privacy-triage.md b/work/projects/cpm-extension-health-pixels-privacy-triage.md
index fefbd09f..1faab8d1 100644
--- a/work/projects/cpm-extension-health-pixels-privacy-triage.md
+++ b/work/projects/cpm-extension-health-pixels-privacy-triage.md
@@ -10,17 +10,27 @@ Status: **DRAFT**
 
 ## Pixels
 
-| Pixel                                                        | When it fires                                                              |
-| ------------------------------------------------------------ | -------------------------------------------------------------------------- |
-| `m_debug_web_extension_cpm_page_initialization_missing`      | A finished HTTP(S) page load does not receive the initial CPM status.      |
-| `m_debug_web_extension_cpm_page_initialization_recovered`    | CPM works on the next page load or reload without reloading the extension. |
-| `m_debug_web_extension_cpm_messaging_suspected_stuck`        | CPM fails repeatedly, including after a page reload and in another tab.    |
-| `m_debug_web_extension_cpm_messaging_recovered_after_reload` | CPM starts working after the app reloads the extension.                    |
-| `m_debug_web_extension_cpm_messaging_reload_failed`          | CPM still does not work after the app reloads the extension.               |
+| iOS pixel | Trigger | Frequency |
+|---|---|---|
+| `m_debug_web_extension_cpm_initialization_missed_after_session_restore` | CPM does not initialize during a restored-session navigation batch. | Daily |
+| `m_debug_web_extension_cpm_initialization_recovered_after_session_restore` | CPM initializes on the next independent navigation after the restored-session batch failed. | Daily |
+| `m_debug_web_extension_cpm_messaging_stuck` | CPM also fails on a later independent navigation, with no CPM success between attempts. | Daily + count, once per episode |
+| `m_debug_web_extension_cpm_messaging_recovered_without_extension_reload` | A stuck episode recovers before the extension is reloaded. | Daily + count, once per episode |
+| `m_debug_web_extension_cpm_messaging_recovered_after_extension_reload` | A stuck episode recovers after the app reloads the extension. | Daily + count, once per episode |
+| `m_debug_web_extension_cpm_messaging_extension_reload_failed` | CPM still fails after the app reloads the extension. | Daily + count, once per episode |
 
-macOS uses the same names with the `m_mac_debug_` prefix. iOS uses the standard platform and form-factor suffixes.
+macOS uses the same names with the `m_mac_debug_` prefix. iOS adds the standard platform and form-factor suffixes.
 
-The pixels send only the standard parameters: `appVersion`, plus `pixelSource` and `channel` on macOS.
+Only standard parameters are sent: `appVersion`, plus `pixelSource` and `channel` on macOS.
+
+## Detection Rules
+
+- Check only finished, current, main-frame HTTP(S) document navigations after a grace period.
+- Treat all `.sessionRestoration` navigations from one app launch as one batch, not one failure per restored tab.
+- A redirected restoration still belongs to the restoration batch when `.sessionRestoration` appears in its navigation history.
+- After restoration, any independent eligible document navigation can be the next attempt: reload, typed URL, link, new-tab navigation, or a real back/forward load.
+- Redirects do not count separately. Same-document, failed, non-HTTP(S), and BFCache navigations do not count when CPM is not expected to initialize again.
+- Any successful CPM initialization closes the episode. Pixels are fired for episode transitions, never for every failed tab.
 
 ## Privacy Questions
 
@@ -34,13 +44,13 @@ Yes. They use only existing standard parameters.
 No. No identifier is added.
 
 **Do the pixels include a URL or search query?**  
-No. They also do not include hostnames, page titles, tab IDs, document IDs, error text, or CPM rules.
+No. They also exclude hostnames, page titles, tab IDs, document IDs, navigation types, errors, and CPM rules.
 
 **Are the pixels temporary?**  
-The two page-initialization pixels are temporary diagnostics. The three stuck-state and reload-result pixels are permanent health monitoring.
+The two session-restoration pixels are temporary diagnostics. The stuck-state and recovery pixels are permanent health monitoring.
 
 **Why are the permanent pixels needed?**  
-To measure how often CPM messaging becomes stuck and whether reloading the extension fixes it.
+To measure how often CPM messaging becomes stuck and whether extension reload recovers it.
 
 **Do any parameters or suffixes fall outside the standard criteria?**  
 No.
@@ -48,8 +58,8 @@ No.
 **Do the pixels fire on sensitive user events?**  
 No. They report only CPM extension health states.
 
-**Can multiple occurrences be tied to the same user or a small group?**  
-No. The pixels contain no correlation identifier or browsing data.
+**Can occurrences be tied to the same user or a small group?**  
+No. There is no correlation identifier or browsing data.
 
 **Does this meet the self-service criteria?**  
 Yes.