diff --git a/docs/AlarmTracking.md b/docs/AlarmTracking.md
index f6560a28..2dd68cfd 100644
--- a/docs/AlarmTracking.md
+++ b/docs/AlarmTracking.md
@@ -183,6 +183,16 @@ Two things worth knowing before changing this:
   and is the correct reading of "this input's source is unreachable", but it is a behaviour change beyond
   scripted alarms.
 
+⚠️ **The signal this hangs off does not currently fire for a mid-run device loss — see #527.** The #481 live
+gate on docker-dev found that `DriverInstanceActor.DisconnectObserved` has **no production sender**: the only
+paths into `Reconnecting` are a failed *initial* connect and an operator Force Reconnect. A Modbus driver
+whose fixture was stopped stayed `Connected` for >10 minutes publishing per-tag Bad, and did not recover when
+the fixture came back until the node was restarted. So the fan-out above — and the native `#477` Layer 2
+annotation it mirrors — are correctly wired to a signal that a dying device never raises. What partially
+covers the gap today is that Modbus publishes Bad *per tag* rather than going silent, so #478 Layer 3 does
+carry Bad into scripted input quality for that driver; that is a per-driver accident, not a guarantee, and it
+does nothing for native conditions or for recovery. Closing #527 is what makes this path reachable.
+
 **Cold start vs. a driver reporting Bad (#478 Finding 3, closed by #481).** `WorstInputStatus` used to skip
 every input whose *value* was null as "no data yet". A comms-lost driver produces exactly that shape — Bad
 with no value — so the skip was hiding the case that matters most. The upstream source now stamps a