docs(series4): the Series III behaviour is firmware-conditional

The bench unit reports 11.0CB -- Instantel's *Blastware* firmware line. It
almost certainly answers Series III commands because it is in Blastware mode,
not because the Micromate natively speaks Series III. Instantel ships two
lines: 11.0CB (Blastware) and 11.0BD (THOR, Vision, Vision II).

That also explains the two-ACH-server problem as designed behaviour rather
than misconfiguration.

Corpus firmware audit: 932 event files from 11.0AK, 83 from 10.90GC. UM12947
itself produced 10.90GC files in production last year and reports 11.0CB now,
so units get reflashed and firmware is not stable per-unit over time.

Records the resulting strategic fork (standardise on the Blastware line vs
reverse-engineer the Thor line) with the four unknowns that decide it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ru8Lg9HkkYvX9VWWo65SmL

docs/micromate_protocol_reference.md

@@ -15,20 +15,77 @@ with no events stored**.
 
 ## The headline
 
-**The Micromate answers Series III command frames.**
+**A Micromate running the *Blastware* firmware answers Series III command
+frames.**
 
 An unmodified Series III `POLL` (`SUB 0x5B`), built by
 `minimateplus.framing.build_bw_frame` with no changes at all, produced a
-complete two-step probe/data cycle from a Micromate.  Ten Series III read
+complete two-step probe/data cycle.  Ten Series III read commands were then
-commands were then tried and **all ten answered**, every one obeying the
+tried and **all ten answered**, every one obeying the Series III response-SUB
-Series III response-SUB rule.
+rule.
 
-This is not a new protocol.  It is close enough to Series III that large parts
+⚠ **That qualifier is load-bearing, and it was discovered after the fact.**
-of `minimateplus/protocol.py` may apply more or less directly, and the work
+Instantel ships the Micromate in two firmware lines:
-ahead is mapping *divergence* rather than mapping from scratch.
+
+| firmware | Instantel's own description |
+|---|---|
+| `11.0CB` | "Utilize with **Blastware**" |
+| `11.0BD` | "Utilize with **THOR, Vision, Vision II**" |
+
+The bench unit reports **`11.0CB`** — the Blastware build.  So the clean
+Series III behaviour above is very likely *because the unit is in Blastware
+mode*, not because the Micromate natively speaks Series III.  **Nothing here
+should be assumed to hold on a `11.0BD` unit until tested.**
+
+This reframes the project.  The question is no longer only "what is the
+Series IV protocol" but **"which firmware line do we target, and does one of
+them let the existing Series III stack drive the whole fleet?"**
 
 ---
 
+## Firmware — the variable nobody knew was a variable
+
+This explains a production problem TMI has lived with: two ACH servers, two
+machines, and units that will not cross over.  It is not a misconfiguration.
+**Instantel ships different firmware for different host software**, and the
+wire protocol differs with it.
+
+Versions observed so far:
+
+| where | version | notes |
+|---|---|---|
+| bench unit UM12947, today | **`11.0CB`** | Blastware line — answers Series III |
+| corpus, 932 event files | `11.0AK` | produced Thor-collected `.IDFW`/`.IDFH` |
+| corpus, 83 event files | `10.90GC` | older; UM12947's own files from Sept 2025 |
+
+Note UM12947 produced `10.90GC` files in production last year and reports
+`11.0CB` on the bench now — so **it has been reflashed at some point**, and
+firmware is not stable per-unit over time.  Any fleet-wide claim needs a
+per-unit firmware audit first.
+
+The version is readable over the wire from `SUB 0x01` as two separate ASCII
+runs — `"0CB"` then `"11"` — with no single concatenated string.
+
+### The strategic fork
+
+- **Option A — standardise the fleet on the Blastware line.**  Every unit,
+  MiniMate and Micromate alike, then speaks Series III, and the existing
+  `minimateplus/` stack drives all of it.  One protocol, one call-home
+  receiver.  Dramatically cheaper *if* it holds up.
+- **Option B — reverse-engineer the Thor line (`11.0BD`) and support both.**
+
+Option A is the shortcut, but it is unproven and carries real unknowns, all
+of which are cheap to answer on the bench and expensive to discover later:
+
+1. **What file format does a `11.0CB` unit produce?**  If it emits Blastware
+   binaries rather than `.IDFW`/`.IDFH`, the (now exact) Series III decoder
+   applies and the IDF codec becomes a legacy path.  Not a loss — we have
+   both — but it changes what the ingest pipeline sees.
+2. **Does Thor still work with a `11.0CB` unit?**  If not, flashing a
+   production unit breaks data collection until the replacement path exists.
+3. **Are any Micromate-specific capabilities lost** on the Blastware line?
+4. **Is the flash reversible in the field**, and what does it cost in downtime?
+
 ## How this was obtained
 
 No Thor, no modem, no Windows machine.  The Micromate exposes its protocol on
@@ -221,9 +278,13 @@ Also unknown:
 
 ## Session provenance
 
-Unit **UM12947**, on the bench via USB, **zero events stored** (memory free ==
+Unit **UM12947**, firmware **`11.0CB`** (Blastware line), on the bench via
-total).  Read commands only.  Every response in this document was checksum-
+USB, **zero events stored** (memory free == total).  Read commands only.
-validated.
+Every response in this document was checksum-validated.
+
+⚠ Firmware is the single biggest caveat on this document.  Every finding here
+is from one unit on the Blastware build.  A `11.0BD` unit has not been
+touched.
 
 An empty unit is a real limitation: `0x08`, `0x1E`, `0x0A` and `0x06` all have
 event-dependent payloads that could not be exercised.  Recording a couple of