diff --git a/docs/micromate_protocol_reference.md b/docs/micromate_protocol_reference.md
index c124e4a..c3154be 100644
--- a/docs/micromate_protocol_reference.md
+++ b/docs/micromate_protocol_reference.md
@@ -2086,10 +2086,20 @@ usbHostDelete_HUB / HC / USBH
 strings in each, and **zero** matches for `prolific`, `pl2303`, `cp210`, `ch34`
 or `silabs` in either.  The firmware line makes no difference here.
 
-⚠ **So a Prolific PL2303 cable (VID `067b`) cannot work with a Micromate.**  The
-unit has no driver, never enumerates the device, and the serial path simply does
+⚠ **So a Prolific PL2303 cable (VID `067b`) very probably cannot work with a
+Micromate** — no driver, so the device never enumerates and the serial path does
 not exist.  Use an **FTDI** cable (VID `0403`) or a CDC-ACM one.
 
+**Calibration.**  This rests on *absence of strings*, plus the observation that a
+laptop answers on the same cable where the unit does not.  `usbHostDelete_*` reads
+like a complete per-class list, which is good evidence — but driver code can exist
+without a matching string, and the USB enumeration path has not been
+disassembled.
+
+**The test that would remove the inference: try an FTDI cable on the same modem.**
+Either it works or it does not, and nothing is left to argue about.  Until then
+this is well-supported, not proven.
+
 ### How this was isolated — the method is reusable
 
 A Micromate on an RX55 was unreachable from THOR.  Rather than guess, each layer
@@ -2116,7 +2126,7 @@ device with something known-good and re-run the same test.**  It converts "the
 unit is not answering" into "the unit is not receiving", which are very
 different problems.
 
-⚠ This explains the **bench** setup conclusively.  Whether it explains the
+⚠ This is the best explanation for the **bench** setup.  Whether it explains the
 2026-09-22 field outage is **not** established — that unit reportedly worked at
 first and degraded, which a wrong cable would not do.  Treat them as separate
 until the field unit's cable is identified.