diff --git a/docs/micromate_protocol_reference.md b/docs/micromate_protocol_reference.md
index a0d9c53..5a0cd30 100644
--- a/docs/micromate_protocol_reference.md
+++ b/docs/micromate_protocol_reference.md
@@ -1371,6 +1371,53 @@ other schedules — or the operator's own saved work — depend on.  Nothing in
 protocol or the ack reports that this happened.  Validating the reference
 instead of rewriting the referent avoids the whole class of problem.
 
+#### The schedule has a setup-less start action — Thor just never uses it
+
+The coupling above looked like it might be a workaround for the unit crashing on
+a missing setup.  The firmware says otherwise: **there are two distinct
+start-monitoring actions**, and only one of them involves a setup file.
+
+```
+_PSA() case DUTYCYCLE_START_MONITOR
+_PSA() case DUTYCYCLE_START_MONITOR_WITH_SETUP
+```
+
+The full duty-cycle action set, from the scheduler task's own dispatch strings:
+
+| action | notes |
+|---|---|
+| `DUTYCYCLE_START_MONITOR` | **no setup involved** — uses whatever config is loaded |
+| `DUTYCYCLE_START_MONITOR_WITH_SETUP` | the variant Thor always emits |
+| `DUTYCYCLE_STOP_MONITOR` | |
+| `DUTYCYCLE_CALLHOME` | `send ==> CMD_SCHEDULE_CALL_HOME` |
+| `DUTYCYCLE_SELF_CHECK` | `call DailySelfCheck()` |
+| `DUTYCYCLE_ON` / `OFF` / `NEXT` | scheduler state, not per-entry actions |
+
+So the schedule↔config coupling is not a crash workaround — **Thor picks the more
+demanding of two available actions, every time.**  SFM can emit
+`START_MONITOR` and skip the config entirely.
+
+On whether a missing setup *would* break the unit: the firmware suggests
+graceful degradation rather than a crash — `Setup File Not Found` exists, and so
+does `Invalid parameters reset to factory default - please review setup`, which
+is a deliberate fallback.  ⚠ **Untested**, and not worth relying on until it is.
+
+⚠ **Hypothesis, not a finding:** the schedule entry's leading byte may be the
+action code — the one captured entry reads `03 00 00 00 0f 03 02 [namelen]
+[name]`, and `03` would fit `START_MONITOR_WITH_SETUP` in an enum of the above.
+Unverified; there is one entry and nothing to diff against.
+
+**The capture that would settle it** (more valuable than the `0x47`
+disable/enable test): build a schedule whose entry is **stop monitoring** or
+**call home** — an action with no setup attached.  That would (a) confirm or kill
+the action-code hypothesis, since a setup-less action should change the leading
+byte and drop the name, and (b) prove from the other direction that a schedule
+can be sent with no config push at all.
+
+Note also `DUTYCYCLE_CALLHOME` → `CMD_SCHEDULE_CALL_HOME`: **a scheduled
+call-home is a way to make a unit dial out on demand**, which is the one
+remaining lever on the unsolved call-home direction.
+
 ### What this implies for the build order
 
 The read path is fully known and needs no Thor-shaped decisions, so a read-only