diff --git a/docs/notes/endpoint-telemetry-and-ui-phases.md b/docs/notes/endpoint-telemetry-and-ui-phases.md
index 754a9d9e..7b290a93 100644
--- a/docs/notes/endpoint-telemetry-and-ui-phases.md
+++ b/docs/notes/endpoint-telemetry-and-ui-phases.md
@@ -120,9 +120,22 @@ above an elevated remap has the same problem).
 All service-side, no session needed. Group these because they share the
 inventory-snapshot plumbing and one migration.
 
-- **Time sync offset and source** - collect; NOT surfaced in the UI. Wire for
-  alerting only. Kerberos fails past skew, so this is a high-value silent
-  predictor.
+- **Time sync offset and source** - CUT. Do not collect, do not surface.
+  w32time is Stopped on provisioned endpoints, confirmed on more than one box
+  (`get-service w32time` -> Stopped). The service appears to be stopped by
+  server-side policy after provisioning, so `w32tm /query /status` returns
+  0x80070426 "service has not been started" fleet-wide and there is no offset to
+  read. Collecting it would return null everywhere and produce an alerting
+  signal that never fires - worse than nothing, because a permanently-null
+  health check reads as "no problem found".
+
+  Implemented and then removed in this phase. If time skew becomes a real
+  suspect later, the prerequisite is getting w32time RUNNING on the fleet; the
+  collection is the easy part. One implementation note worth keeping: parse the
+  offset by LABEL, not by "first value ending in s". w32tm prints Root Delay and
+  Root Dispersion in the same seconds format BEFORE Phase Offset, so a
+  first-match parser silently reports network latency as clock skew. That bug
+  was written and caught here; do not rewrite it.
 - **Disk errors / SMART predictive failure** - collect and surface on the
   existing Storage card (Phase 4).
 - **NIC link speed and duplex** - collect, pair into the existing Network
@@ -130,9 +143,16 @@ inventory-snapshot plumbing and one migration.
 - **Boot type** - fast startup vs true cold boot. Explains why uptime lies and
   why a "reboot" did not clear a fault. Collect now; UI placement undecided,
   candidate for the Operating system or Hardware card.
-- **Windows Update history, last 5** - surfaced in Monitors (Phase 4) for
-  pinpointing update-induced breakage. Updates are corporate-managed; this is
-  diagnostic only, not control.
+- **Windows Update history, last 5** - PINNED, deferred out of Phase 2. The COM
+  update searcher is not cheap: it routinely takes seconds and sometimes tens of
+  seconds, which would make it the most expensive thing in an otherwise
+  WMI-and-registry `Collect()` running on the heartbeat path.
+
+  The blocking concern is broader than cost. Some endpoints host COM server
+  applications, and driving the update searcher through COM on those boxes risks
+  interfering with collections - or with the hosted application itself. Needs
+  its own investigation before any implementation, and if it lands it wants its
+  own cadence (hourly/daily), never the every-cycle path.
 - **Defender/AV health** - collect and persist, do NOT surface. Known to
   produce false positives in this environment; stored for future wiring.
 
@@ -181,7 +201,9 @@ Depends on Phase 2 data existing.
   new CSS. Room reserved for the future one-click fix action.
 - **Storage card** - add disk error / SMART predictive failure to the existing
   card rather than a new one.
-- **Windows Update card** - last 5 updates, in the System Monitors tab.
+- **Windows Update card** - BLOCKED, not scheduled. Depends on Phase 2 data
+  that is pinned pending a COM-interference investigation. Do not build the card
+  until the collection question is settled.
 - Boot type placement to be decided when the data is visible.
 
 ## Phase 5 - Header right-hand block (DEFERRED - revisit before building)