diff --git a/docs/micromate_protocol_reference.md b/docs/micromate_protocol_reference.md
index 55cf545..a0d9c53 100644
--- a/docs/micromate_protocol_reference.md
+++ b/docs/micromate_protocol_reference.md
@@ -1322,6 +1322,55 @@ checked whether the unit cares."
 | Greys out send-to-unit while monitoring | **Thor policy** | The *reason* is real — a push to the active setup overwrites silently.  But "the button is grey and you figure it out" is a UX choice, not the only answer.  SFM could offer stop → push → restart as one operation, which is what an operator actually wants. |
 | Names the target with `0xDA` before a config write | **almost certainly required** | The unit has to know which file to write.  Closest thing here to a genuine protocol requirement. |
 
+### The schedule↔config coupling is Thor's, not the protocol's
+
+In Thor, putting "start monitoring" in a schedule forces you to attach a setup,
+and sending the schedule pushes that setup at the same time — overwriting
+whatever already has that name.  **The protocol does not require any of this.**
+
+The evidence, from the scheduler capture:
+
+- **The two writes are separate operations**, not one transaction.  The config
+  write ends at frame 18 (`0x72`), then Thor sends a fresh `POLL` preamble, and
+  only then opens the schedule for writing at frame 20.  Different commands,
+  different paths, no shared state:
+
+  ```
+  config    0xDA → 0x68/0x73 → 0x82/0x83 → 0x71/0x72
+  schedule  0x8D → 0x8E
+  ```
+
+- **The schedule stores a NAME, not a config.**  A length-prefixed filename is
+  all an entry carries.  It is a *reference*, and references do not require the
+  referent to be rewritten.
+
+- **The config Thor pushed was already on the unit, unchanged.**  Its 2,090-byte
+  `0x71` payload is **byte-identical** to the previous capture's — zero
+  differences.  Thor spent a full block write re-sending a setup the device
+  already had, purely to satisfy its own coupling.
+
+So the sequencing is a Thor UI decision, and a costly one.
+
+**What SFM can do instead, with today's protocol and nothing new:**
+
+1. Enumerate the unit's setups with `0x3F` / `0x40` — cheap, read-only, and it
+   yields the exact names a schedule may legally reference.
+2. Write **only** the schedule (`0x8D` / `0x8E`) when the referenced setup is
+   already present.
+3. Push a config only when it is actually missing, or when the operator
+   deliberately edited it — and say so explicitly rather than silently.
+
+That removes the write entirely from the common case: scheduling against a setup
+that already exists becomes a 524-byte schedule write instead of 524 bytes plus
+a 2,090-byte config overwrite.
+
+⚠ **And it removes a real hazard.**  Because the reference is by name, and
+because a same-name write overwrites silently with an indistinguishable ack,
+Thor's pattern means *scheduling* something can quietly rewrite a setup that
+other schedules — or the operator's own saved work — depend on.  Nothing in the
+protocol or the ack reports that this happened.  Validating the reference
+instead of rewriting the referent avoids the whole class of problem.
+
 ### What this implies for the build order
 
 The read path is fully known and needs no Thor-shaped decisions, so a read-only