diff --git a/harness/mame/NETWORK_REPORT.md b/harness/mame/NETWORK_REPORT.md
index 5f2aeb7..430eb33 100644
--- a/harness/mame/NETWORK_REPORT.md
+++ b/harness/mame/NETWORK_REPORT.md
@@ -4691,7 +4691,38 @@ the state a payload leaves behind, and at real power-on `SP` is undefined
 anyway, which is the condition we reproduce.
 
 MAME evidence: after the reply, the PC leaves the payload (`0x018Cxxxx`) for ROM
-(`0x3FB43E40` at the next sample) and the payload stops answering. What is **not**
-shown yet is that the unit comes back *without a power cycle* — in MAME the OS
-was never down, so a warm restart is indistinguishable from the OS continuing.
-That test needs the real machine and is the reason the command exists.
+(`0x3FB43E40` at the next sample) and the payload stops answering.
+
+### 72.3 It works on the real machine — and a correction
+
+`reboot` was issued on the unit at **16:58:45** while the payload owned the LANCE.
+The reply came back (`control -> bit 0x3f200040`, status 0), the payload stopped
+answering, and the screen went black.
+
+**That is POST, not a hang.** Port 771 reopened **88 s** later, the unit answered
+ping, and a VRAM screenshot (`dwt/screenshot.py --real`) shows the machine fully
+back:
+
+```
+Terminal Manager V2.2   Copyright (C) 1991 Digital Equipment Corporation
+Messages:  Debug connection from IP host 100.103.255.254
+Ethernet Address 08-00-2B-16-4B-5A   IP 100.103.100.103
+LAT Host Name LAT_08002B164B5A      Memory Remaining: 4M
+```
+
+with the documented `Ethernet Port Error - 24` clean-boot banner (section 65).
+So a taken-over unit **can hand itself back without a power cycle**, which was
+the point of the command.
+
+**Correction, recorded on purpose.** An earlier reading of this same run called
+it "black and hung, needs a power cycle", because the observation was taken
+inside the ~90 s POST window. That conclusion was wrong, and it is the exact
+mistake this project's own rule 3 warns about — one sample, taken early, reported
+as a property. The screen being black is normal: the reset path reprograms the
+video window (`0xC00000B0`, `0xC0000100` in the trace above) and does not
+re-enable the display until POST is done.
+
+`vtcmd.py reboot` therefore prints the expected ~90 s and warns not to power
+cycle during it. `jump` and `reboot` both transmit their reply and wait for the
+descriptor to complete before transferring control, so the host always gets its
+acknowledgement first.
diff --git a/harness/udpstream/vtcmd.py b/harness/udpstream/vtcmd.py
index 8967cd1..b570e01 100644
--- a/harness/udpstream/vtcmd.py
+++ b/harness/udpstream/vtcmd.py
@@ -190,6 +190,10 @@ def main():
         return 0
 
     if a.cmd in ("jump", "reboot"):
+        if a.cmd == "reboot":
+            print("rebooting: the screen goes black while POST runs; the OS is")
+            print("  back in about 90 s (measured 88 s) and rdebug :771 returns")
+            print("  on its own. Do not power cycle it during that window.")
         cmd = 4 if a.cmd == "jump" else 5
         status, data = request(sock, a.iface, cmd, a.addr, 0, a.timeout)
         if status is None: