diff --git a/docs/micromate_protocol_reference.md b/docs/micromate_protocol_reference.md
index b389601..e55a682 100644
--- a/docs/micromate_protocol_reference.md
+++ b/docs/micromate_protocol_reference.md
@@ -865,6 +865,54 @@ homebrew client needs no file-transfer primitive and no pre-existing target:
 That closes the last open question about whether Series IV setup management is
 reachable from outside Thor.  It is.
 
+### ✅ Overwriting is protocol-identical to creating (2026-09-24)
+
+The firmware carries strings that suggest an overwrite handshake:
+
+```
+Overwrite File                     MFS FILE EXISTS
+Cannot be Overwritten              Can Not Delete Active Setup File
+```
+
+**There is no such handshake on the wire.**  A second push to `TEST1.mmb` — a
+name that now existed, and which `SUB 0x41` confirmed was the *active* setup —
+produced a byte-for-byte identical command sequence:
+
+| | create | overwrite |
+|---|---|---|
+| SUBs, and their order | `5B 41 08 2E 1A DA 68 73 82 83 71 72` | **identical** |
+| every `offset` field | — | **identical** |
+| `0xDA` / `0x68` / `0x82` data | — | **0 bytes differ** |
+| `0x71` data | — | 18 bytes differ = the one edited note |
+| all seven write acks | 11 zero bytes | **identical, still all-zero** |
+
+No extra command, no confirm step, no error status, and **no dialog on Thor**.
+Those firmware strings belong to the on-device Save screen (the
+`CSaveSetupFile` UI class), not to the protocol.
+
+**The overwrite was verified on the unit itself** — the edited `General Notes`
+string is present in the setup on the device, so the write applied, silently and
+in place.
+
+This is the case that mattered most, and it landed the right way round: the
+target was the **active** setup, which is what a real remote config push would
+hit.  Being active bought it **no protection** — it was overwritten directly.
+A writer therefore needs no exists-check and no overwrite negotiation.
+
+⚠ That cuts both ways.  A remote push to the active setup of a **monitoring**
+unit changes the config it is recording with, with no prompt, no warning and no
+distinguishable ack.  Whatever SFM eventually exposes should gate this on the
+operator, not on the protocol — the device will not stop anyone.
+
+⚠ Two overwrite cases remain untested: a **non-active** setup file, and
+`factory.MMB`, which `Cannot be Overwritten` probably guards.  Neither blocks a
+writer — the active setup is the one worth pushing to.
+
+⚠ Note also that the write acks are **all-zero in every case observed**, across
+a create and an overwrite.  We have never seen this protocol report a *failed*
+write, so **do not treat a zero ack as proof a write was applied.**  Read the
+config back and compare; `SUB 0x41` plus `SUB 0x1A` make that cheap.
+
 ## Static analysis of the firmware (2026-09-23, solo session)
 
 ### Architecture