diff --git a/docs/ARCHITECTURE.md b/docs/ARCHITECTURE.md
index a411352..0b1df77 100644
--- a/docs/ARCHITECTURE.md
+++ b/docs/ARCHITECTURE.md
@@ -147,16 +147,21 @@ re-dialling is the client's job. Noticing the loss and redelivering is the Orin'
 
 ### Link drops are routine, not exceptional
 
-Measured on the USB path (tablet ↔ PD hub ↔ Orin, 2026-10-09): every PD power
-change resets the hub's data port. The link flaps about three times and is back
-within 5–12 s, with no intervention. In the car this happens at every ignition
+Measured on the USB path (tablet ↔ PD hub ↔ Orin, 2026-10-09): cutting PD power
+resets the hub's data port, and the link is back within ~3.5 s with no
+intervention. Longer outages measured early on were the tablet sleeping on
+battery, not the link. In the car this happens at every ignition
 change. Design for it as normal operation. Requirements, not yet implemented:
 
 - **Failure detection on the Orin.** An app-level heartbeat with a timeout of a
   few seconds, not TCP alone. A connection on a link that went down can stay
   half-open long after the app has re-dialled. Reap dead connections and their
-  per-client queues promptly. Link state doesn't help either: when PD is plugged back
-  in, the Orin's interface stays up while the tablet goes silent for ~5 s.
+  per-client queues promptly. Link state doesn't help either: a tablet that has
+  fallen asleep on battery leaves the Orin's USB interface up while answering
+  nothing.
+- **The app keeps the tablet awake while it is the display.** Off charger, Android
+  suspends about a minute after screen-off. Then the link is gone in every way that
+  matters. Kept awake, a PD change costs only ~3.5 s (measured).
 - **Downstream (latest-wins):** unchanged. On reconnect, push current state; no
   resend, since stale samples are worthless.
 - **Reliable channel (TTS chunks, acknowledgements):** pending items survive a