diff --git a/docs/micromate_protocol_reference.md b/docs/micromate_protocol_reference.md
index 0fe5332..88e45f5 100644
--- a/docs/micromate_protocol_reference.md
+++ b/docs/micromate_protocol_reference.md
@@ -50,18 +50,50 @@ 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:
+### Fleet audit (physical, 2026-09-22/23)
 
-| 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 |
+| unit | firmware | line | location |
+|---|---|---|---|
+| UM11719 | `11.0CB` | Blastware | Ped Bridge Loc 2 |
+| UM6047 | `11.0CB` | Blastware | Brookville Loc 9 |
+| UM12947 | `11.0CB` | Blastware | **bench** |
+| UM14133 | `11.0CB` | Blastware | Pitt-Music Bldg Loc 1 |
+| UM11402 | `11.0BD` | Thor | Ped Bridge Loc 1 |
+| UM20147 | `11.0BD` | Thor | **bench** |
+| UM13981 | `11.0AK` | pre-split | RKM Loc 1 |
+| UM20146 | `11.0AK` | pre-split | Karns Loc 2 |
+| UM12420 | `10.90GC` | pre-split | RKM Loc 2 |
 
-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.
+**4 Blastware / 2 Thor / 3 pre-split.**  The Blastware line is already the
+plurality, which makes "standardise on Blastware" less disruptive than it
+first appeared.
+
+A store-derived audit (firmware is recorded in every `.sfm.json` sidecar as
+`extensions.idf_report.version`) agreed with the physical audit on **7 of 9**.
+The two that differed — UM6047 and UM14133 — are the most recently deployed
+units, reflashed after their last stored event.  Useful technique: the fleet's
+firmware history is reconstructable from the store without touching a unit,
+but it lags reality by one deployment.
+
+Firmware is **not stable per-unit over time** — five of nine have been
+reflashed at least once.  Any fleet-wide claim needs a fresh audit.
+
+### ⚠ Retraction: firmware line does NOT determine Thor compatibility
+
+An earlier draft of this document suggested that UM12947's trouble with Thor
+was explained by its being on the Blastware build.  **That is not supported.**
+
+Ped Bridge runs UM11402 (`11.0BD`) and UM11719 (`11.0CB`) side by side, both
+deployed 2026-04-20, and **both call Thor successfully** — UM11719 has 331
+Thor-collected events in the store while on `11.0CB`, through 2026-08-23.
+
+So a Blastware-line unit does feed Thor.  Whatever the CB/BD split changes, it
+is not "which host software can collect from it", and UM12947's specific
+problem remains unexplained.
+
+**What is actually established:** a `11.0CB` unit answers Series III command
+frames.  Whether a `11.0BD` unit does is **untested** — and UM20147 (`11.0BD`)
+is on the bench, which makes that a direct A/B away.
 
 The version is readable over the wire from `SUB 0x01` as two separate ASCII
 runs — `"0CB"` then `"11"` — with no single concatenated string.