diff --git a/docs/provisioning.md b/docs/provisioning.md
index 20bc2ed..43c9d4f 100644
--- a/docs/provisioning.md
+++ b/docs/provisioning.md
@@ -71,6 +71,50 @@ The boot provisioning command never upgrades or reconfigures anything already in
 never touches a repository it did not add. Classroom software updates
 are the OTA channel's job, not this.
 
+## When a classroom updates
+
+**Every day at 03:00**, local time, spread over half an hour so the rooms
+do not all ask at once: `ekklesia-classroom-update.timer`,
+`OnCalendar=*-*-* 03:00:00`, `RandomizedDelaySec=30m`. It has been so
+since 0.1.5; the lab's installed stable machine logged its checks at 03:01
+on 26 September and 03:04 on 27 September.
+
+**A computer that was switched off at 03:00** checks once, soon after it
+is next switched on (`Persistent=true`). Measured on the lab's systemd
+with the machine really stopped across the time: the missed check ran 50 s
+after it started, once, and not again. Nothing else starts the check —
+no boot trigger, no repeat — so it cannot loop.
+
+Each check follows only the device's own `CHANNEL` (a stable room stays
+on stable), installs only a newer version, and only a package whose
+SHA-256, name and version are what the manifest says.
+
+**The reboot after an update waits for nobody to be using the computer**
+(since 0.2.6.5). It used to happen the moment the update was installed:
+harmless at 03:00, and a room restarting itself mid-morning after a night
+switched off. Now `classroom-reboot-when-idle` reboots once no keyboard,
+mouse, touchpad or touchscreen has been touched for 30 minutes *and* no
+sound has played for as long — a video to the room is not an idle
+computer. At 03:00 that is about 03:30. Switched off before then, nothing
+is lost: the update is installed and the next start is on it. Until the
+reboot the session carries on as it was; the only other thing an update
+starts at once, provisioning, does nothing on a machine that is already
+set up.
+
+Input is read from the kernel's input devices, whatever the desktop is
+doing; sound from the kernel's own playback state (`/proc/asound`). Both
+measured in the lab — a mouse made with `/dev/uinput` kept it from
+rebooting, and leaving it alone let it — except the sound card, which the
+lab does not have: that is a check on real hardware.
+
+The schedule is a file the package installs, not a configuration file,
+so every upgrade brings the packaged schedule. The release gate checks it
+after a fresh install and after each upgrade.
+
+    systemctl list-timers ekklesia-classroom-update.timer   # next and last check
+    journalctl -u ekklesia-classroom-update                 # what each check did
+    journalctl -u ekklesia-classroom-reboot-when-idle       # a reboot that is waiting
+
 ## Permanent download addresses
 
 ```
diff --git a/docs/testing.md b/docs/testing.md
index cf731fc..4f4c452 100644
--- a/docs/testing.md
+++ b/docs/testing.md
@@ -466,7 +466,15 @@ With `LIVE_ENABLED=true`:
 - [ ] `./update_canary.sh` publishes package first, manifest last
 - [ ] The endpoint on the canary channel picks the update up
 - [ ] SHA-256 verification passes
-- [ ] Install succeeds and the endpoint reboots
+- [ ] Install succeeds; `systemctl list-timers ekklesia-classroom-update.timer`
+      shows the next check at about 03:00 tomorrow
+- [ ] (0.2.6.5) Switched on in the morning after a night off, with an update
+      waiting: it installs, `journalctl -u ekklesia-classroom-reboot-when-idle`
+      says it is waiting, and it does **not** restart while you use it
+- [ ] Play a video with sound and leave the mouse alone for 40 minutes: no
+      restart while it plays; half an hour after it stops, it restarts
+- [ ] Left untouched with nothing playing, it restarts about 30 minutes after
+      the update, and comes back on the new version
 - [ ] Everything above still works after the update
 - [ ] Upgrade from 0.1.36 preserves every existing `device.conf` value
 - [ ] `LIVE_ENABLED=false` is appended exactly once on upgrade and remains