diff --git a/bridges/mm_ach_server.py b/bridges/mm_ach_server.py
index 2e2c2b0..fa2593a 100644
--- a/bridges/mm_ach_server.py
+++ b/bridges/mm_ach_server.py
@@ -12,11 +12,34 @@ and an inbound session is the worst place to break that.
 What this is for
 ----------------
 The inbound call-home session is the last unmapped part of the Series IV
-protocol — and it may well not be a separate protocol at all.  Series III's
-answer, from 72 captured sessions, is that the unit **dials in and then waits**:
-the server runs the ordinary handshake and drives with the ordinary command set.
-If Series IV behaves the same way, this file is just `MicromateClient` attached
-to an inbound socket, and the "unknown" evaporates.
+protocol.
+
+⚠ **No Micromate has ever been observed calling home.**  The 72 `ach_inbound_*`
+sessions in `bridges/captures/` are **MiniMate Plus**, and the Series III setup
+does not automatically transfer.  What we have for Series IV is prior, not
+observation:
+
+  * The THOR manual §6.2 and the firmware's own strings
+    (`CMD_EXIT_CALL_HOME_DELETE_EVENTS_START_MONITORING`, `Call Home Deleting
+    Events`) say the unit dials in and then **waits to be told what to do** —
+    server-driven, the same shape as Series III's pull model.
+  * UM12947's `0x2C` dial string reads literally `"RADIO RING"`, which is modem
+    *answer* vocabulary rather than a destination.  With the RV50 debug string
+    `ATQ1 ATE0 ATS0=2 … RADIO RING` — `ATS0=2` being auto-answer-after-2-rings —
+    that reads as the unit configuring the modem to **accept** calls, i.e. the
+    call-*up* path.  Which suggests the ACH destination lives in the **modem**,
+    as it does for Series III.
+
+**If both priors hold, this file is just `MicromateClient` on an inbound socket
+and the unknown evaporates.**  But there is a specific way it can fail:
+
+⚠ **Those AT strings prove the Micromate talks to the modem over serial.**  If it
+drives an AT dial for call-home, that exchange happens on the **serial link**,
+where a TCP listener sees nothing whatsoever.  So a null result here is
+informative but ambiguous — it means *either* the trigger did not fire *or* the
+interesting part is happening somewhere this tool cannot watch.  **If nothing
+arrives, the next step is a serial-level capture between the unit and the modem,
+not more fiddling with this server.**
 
 **The one question that matters is push vs pull**, and it cannot be answered by
 sniffing — only by connecting and keeping quiet.  So this server **says nothing
diff --git a/docs/micromate_protocol_reference.md b/docs/micromate_protocol_reference.md
index 561daaa..308fdea 100644
--- a/docs/micromate_protocol_reference.md
+++ b/docs/micromate_protocol_reference.md
@@ -2256,6 +2256,31 @@ A server that never issues the delete simply re-reads the same events forever.
 `ach_state.json` with `downloaded_keys` / `max_downloaded_key`, and erase as a
 separate deliberate step.  No new mechanism is needed for Series IV.
 
+> #### ⚠ But no Micromate has ever been observed calling home (noted 2026-10-03)
+>
+> The 72 `ach_inbound_*` sessions in `bridges/captures/` are **MiniMate Plus**.
+> The Series III setup is not known to transfer, and there is a concrete reason
+> it might not:
+>
+> | | Series III (observed, 72 sessions) | Series IV (inferred) |
+> |---|---|---|
+> | who dials | the **modem** (destination set in ACEmanager) | unknown |
+> | the unit's role | passive on serial until the socket exists | sends AT strings to the modem |
+> | session | pull — server runs the ordinary command set | pull, per manual §6.2 + firmware strings |
+>
+> ⚠ **The Micromate demonstrably talks AT to its modem** —
+> `ATQ1 ATE0 ATS0=2 … RADIO RING` from the RV50 debug, and `"RADIO RING"` is what
+> `0x2C`'s dial-string field actually contains on UM12947. `ATS0=2` is
+> auto-answer-after-2-rings, so that exchange is the unit arranging to *accept*
+> calls — the call-*up* path — which argues the ACH destination lives in the
+> modem after all.
+>
+> **But if the unit instead drives an AT dial for call-home, that exchange is on
+> the serial link and a TCP listener sees none of it.** So the first experiment
+> has an ambiguous null: no connection could mean the trigger did not fire, or
+> that the interesting part is invisible from the network. The escalation is a
+> **serial-level capture between unit and modem**, not more work on the server.
+
 So a homebrew receiver needs: accept the connection, identify the unit, walk the
 events (already solved — `0x08`/`0x1E`/`0x0A`/`0x5A`), keep our own high-water
 mark, and *optionally* erase.  **The erase opcodes are the only genuinely missing