diff --git a/docs/magicman-keyboard-luks.md b/docs/magicman-keyboard-luks.md
index 3600feb..03b8ca6 100644
--- a/docs/magicman-keyboard-luks.md
+++ b/docs/magicman-keyboard-luks.md
@@ -50,8 +50,10 @@ driver sends a deactivate command (0xF5) during init, which likely succeeds at d
 the keyboard even though the ACK times out. The subsequent enable command (0xF4) also
 times out without re-enabling it. The keyboard stays disabled at the hardware level —
 it queues keypresses in its small internal buffer (~16 keys) but doesn't send scancodes
-to the host until something re-enables it during full boot (likely during switch-root
-when udev re-processes devices).
+to the host until something re-enables it during full boot. This is NOT a timing issue —
+leaving the system at the LUKS prompt for several minutes does not fix the keyboard.
+Something specific that happens later in the boot process (likely during switch-root
+when udev re-processes devices) re-enables the keyboard.
 
 ## What Was Tried