diff --git a/docs/micromate_protocol_reference.md b/docs/micromate_protocol_reference.md
index 324faf9..e948a44 100644
--- a/docs/micromate_protocol_reference.md
+++ b/docs/micromate_protocol_reference.md
@@ -1091,7 +1091,7 @@ zero-data response.  Thor follows each with a `SUB 0x1C` status read to confirm.
 ### `SUB 0x1C` — monitor status, 55-byte data
 
 ```
-data[12]        monitoring flag   0x0E monitoring / 0x00 idle
+data[12]        monitoring flag   NON-ZERO = monitoring, 0x00 = idle
 data[13]        day
 data[14]        month
 data[15:17]     year, uint16 BE
@@ -1103,8 +1103,11 @@ data[-8:-4]     memory total, uint32 BE   = 15,000,000 bytes exactly
 data[-4:]       memory free,  uint32 BE
 ```
 
-⚠ **The monitoring flag is `0x0E`, not Series III's `0x10`.**  Do not reuse the
-Series III constant.  Only five bytes differ between the monitoring and idle
+⚠ **Test `data[12]` for non-zero — do NOT compare against a constant.**  It read
+`0x0E` on 2026-09-24 and `0x0C` on 2026-09-25, both while monitoring, so it
+carries sub-state in its low bits rather than being a flag.  Series III's `0x10`
+does not apply either.  `SUB 0x49` `data[11]` read `0x02` in every monitoring
+sample so far, but the same caution applies until more values are seen.  Only five bytes differ between the monitoring and idle
 responses: the flag, `data[17]`, the clock, and the memory-free field.
 
 Memory free dropped by exactly **4,096 bytes** across the ~70-second monitoring
@@ -1877,6 +1880,33 @@ It explains, too, why the field symptom resisted characterisation.  The unit is
 perfectly reachable throughout.  Poke it and it answers.  Nothing is wrong with
 the unit, the modem, or the link.
 
+### The stale display extends to monitoring state — a live unit shown as Idle
+
+The operator's own test: start monitoring **from the unit's keypad**, and see
+whether THOR ever notices.
+
+At **13:21:15**, verified by an independent probe through the same relay:
+
+```
+unit, on the wire   SUB 0x49 data[11] = 0x02   MONITORING
+                    SUB 0x1C data[12] = 0x0c   MONITORING
+                    device clock 13:21:14
+THOR's last contact 13:10:37   (a stop-monitoring command it issued itself)
+THOR's display      Connected · Monitoring Mode: Idle · Last Updated 1:04:22 PM
+```
+
+**A unit is actively recording and THOR shows it as Idle.**  Had an event
+triggered in that window, THOR would not have known and would not have collected
+it.  This is the operational consequence of the wedge: not merely a wrong
+indicator, but a monitoring system that has silently stopped monitoring its
+monitor.
+
+One further detail.  THOR **did** contact the unit at 13:10:37 and read
+`MONITOR_STATUS` — yet `Last Updated` still reads 1:04:22.  So a successful
+exchange does not refresh that timestamp; only the full status check does.  The
+single honest field on the screen is honest about the wrong thing, which makes it
+useless as a staleness indicator precisely when staleness is the problem.
+
 ### Design consequences for SFM
 
 0. **Connection status must EXPIRE.**  The single highest-value fix here.  If the