diff --git a/emulator/NET-NOTES.md b/emulator/NET-NOTES.md
index 8923006..e6c7727 100644
--- a/emulator/NET-NOTES.md
+++ b/emulator/NET-NOTES.md
@@ -622,25 +622,35 @@ MEASURED BOTH CONSOLES: TeslaConsole = 3.4s AND Console 4.10 = 3.4s
 (lamp-ON to full-sweep-off). No egress-delay key exists in
 Console.ini / venue INIs (checked).
 
-**EGRESS DELAY FOUND IN THE BINARY (2026-07-10 disasm):** it is a
-HARDCODED ~30s constant in BTL4OPT.EXE's `StopMissionMessageHandler`
-@ 0x47b864 -- NOT an INI/env value. The handler: (1) calls
-mission-shutdown/EndMission (0x44eeb4); (2) calls the lamp routine
-(0x47bba8, named by the "LightsOut" string @0x4fd5ac) with flag=1 ->
-egress lamps 0x16/0x17/0x1e ON; (3) schedules a delayed state block
-(0xc,0xc,1) for `now + 30.0*timebase + 0.5` (30.0f @0x47b8e4, 0.5f
-@0x47b8e8, timebase global @0x52140c read across the whole sim) -- at
-which the lamps go off and the game exits into GO.BAT. Matches the
-operator's memory exactly: StopMission -> floor lights on -> ~30s hold
--> lights off -> exit -> BAT restart. The LightsOut lamp-off helper
-(0x47bb34, flag=0 branch) sweeps 0x16/0x17/0x1e off. RECONCILE: this
-30s vs the measured 3.4s -- the 154.9s full-lamp SWEEP we tapped was
-likely the teardown GeneralReset (a different event), with the true 30s
-timer firing past our tap window; timebase multiplier is runtime-set so
-wall-time can't be proven statically. TEST TO SETTLE: one mission with
-a 90s+ RIO tap window past mission end. Disasm tool: scratchpad
-btdis2.py (pefile+capstone, py -3.13). This is the authentic egress
-window; the earlier "print time" theory is superseded. Lamp
+**EGRESS DELAY = COMPILED IN, TWO-PHASE (2026-07-10 disasm; cross-build
+verified) -- NOT an INI/env value, and NOT a Rel410 regression.** The
+StopMission close path in BTL4OPT.EXE uses nested class handlers:
+- OUTER handler (runs for the pod, Rel410 @0x47c2c4) is re-entrant on a
+  flag @[this+0xd4]: FIRST call schedules ITSELF to re-fire in
+  `3.0*timebase + 0.5` ≈ **3 seconds** (3.0f @0x47c350) and returns;
+  the RE-ENTRY (3s later) runs cleanup (0x44e13c/0x44fa6c) then calls
+  the inner handler.
+- INNER handler (L4Application, Rel410 @0x47b864) calls base shutdown
+  (0x44eeb4), lights egress lamps 0x16/0x17/0x1e ON (0x47bba8 flag=1,
+  the "LightsOut"-named routine @0x4fd5ac), and schedules a **30.0s**
+  timer (30.0f @0x47b8e4) for lamps-off/exit.
+- timebase global @0x52140c (runtime-set, read sim-wide); ftol @0x4dcd94.
+
+**CROSS-BUILD: byte-identical in ALL four binaries** -- BTLIVE (May-96,
+handlers @0x489a08/0x48a3c0), BTRAVINE (Sep-96, @0x47b850/0x47c2b0),
+BTDAVE (@0x489a08/0x48a3c0), Rel410 (@0x47b864/0x47c2c4). So Rel410 did
+NOT cut a 30s hold; every build has both the 3.0 and 30.0 constants.
+
+**EFFECTIVE behavior = the 3s phase** (matches the measured 3.4s
+lamp-on->off exactly). The 30s phase-2 timer is scheduled AFTER cleanup
+has begun tearing the exe down, so the process is recycled by netnub
+before it fires -- true in every build, so the 30s is effectively dead
+in the actual run. The operator's remembered ~20-30s "lights on" is the
+ENTRY lighting (floor lamp on game-ready->drop, MEASURED 21s in our tap:
+1207s->1228s) plus the between-games boot/idle gap, NOT the post-mission
+egress phase. Tools: scratchpad btdis2.py + stopmission_cmp3.py
+(pefile+capstone, py -3.13). Supersedes the earlier "3.4s = print time"
+AND "authentic 30s hold" readings. Lamp
 state byte: flash bits0-1 (solid/slow/med/fast), ch1 bits2-3
 (off/dim/bright), ch2 bits4-5. Extraction tool: scratchpad
 lamp_read.py pattern (tap lines are one byte each).