diff --git a/emulator/render-bridge/pod_render_gait.conf b/emulator/render-bridge/pod_render_gait.conf
new file mode 100644
index 00000000..f9bd9cad
--- /dev/null
+++ b/emulator/render-bridge/pod_render_gait.conf
@@ -0,0 +1,89 @@
+# pod_render_norio.conf -- pod_render_rec with the RIO serial port OFF.
+#
+# The emulator log shows a steady stream of serial1 RX OVERRUN errors on
+# the RIO pipe, and controls post their events at HighEventPriority
+# UNCONDITIONALLY (CONTROLS.HPP:250) -- so a chattering RIO port would
+# flood a priority the background pump always serves first, starving the
+# priority-0 renderer events the load gate waits on.  This conf tests that
+# by removing the port entirely.  Everything else is identical to the rec
+# conf, so a launch here and a hang there isolates the RIO.
+#
+[sdl]
+output=opengl
+# higher,higher not highest: HIGH_PRIORITY_CLASS starved the host desktop;
+# with the retry patches a rare dropout self-recovers (see gauge_rio.conf).
+priority=higher,higher
+[dosbox]
+memsize=32
+machine=svga_s3
+[cpu]
+core=dynamic
+cputype=pentium
+cycles=max
+[sblaster]
+sbtype=sb16
+sbbase=220
+irq=5
+dma=1
+hdma=5
+[mixer]
+# match the EMU8000s' native rate (no resample) and buffer ~60ms so brief
+# emulation-thread stalls (RIO retry recovery) don't audibly chop
+rate=44100
+blocksize=1024
+prebuffer=60
+[serial]
+# RIO on COM1 with the low-latency options (rxpollus/rxburst) so the board's
+# few-ms ACK deadline is met; plasma display on COM2 (real pod has both).
+# VWE fork namedpipe backend (com0com/realport retired -- COM1/COM2 gone):
+# DOSBox = pipe client (retry), vRIO/vPLASMA apps = servers; an unconnected
+# pipe behaves as an unplugged cable so the mission still runs. serialnamedpipe.h
+serial1=disabled
+serial2=namedpipe pipe:vplasma
+# live UNBUFFERED game output: DOS char devices are not buffered, so
+# redirecting stdout to COM3 lands every line immediately.  A normal
+# '> file' redirect stays 0 bytes until the process exits, which hides
+# all progress on a run that does NOT crash.
+serial3=file file:C:\VWE\TeslaRel410\emulator\render-bridge\podlog.txt
+[autoexec]
+mount c "C:\VWE\TeslaRel410\ALPHA_1"
+c:
+cd \REL410\BT
+set VIDEOFORMAT=svga
+rem production pod card init (PARAMETR.BAT:181-186): DIAGNOSE + AWEUTIL per
+rem card -- AWEUTIL /S does the EMU8000 bring-up and DRAM detect the HMI SOS
+rem driver relies on; skipping it left the cards uninitialized (silent).
+rem aweutil /s SKIPPED for now: it verifies the AWE32 GM ROM, which the
+rem emulated cards lack (hangs in a retry loop) -- restore once the ROM is
+rem dumped from a real card. diagnose /s kept (passes, sets mixer config).
+set BLASTER=A220 I5 D1 H5 P330 T6
+c:\sb16\diagnose /s
+set BLASTER=A240 I7 D3 H6 P300 T6
+c:\sb16\diagnose /s
+set BLASTER=A220 I5 D1 H5 P330 T6
+set TEMP=c:\
+rem arena1 city mission (TESTARN.EGG: map=arena1, time=day) with the RIO
+rem attached; stdout redirected so mission-load progress survives kills.
+set BT_JOINTS=1
+set L4VIEWEXT=1
+set BT_STACK_LOG=1
+set BT_MECH_LOG=1
+
+set BT_GAIT_LOG=1
+
+
+set BT_GAUGE_LOG=1
+
+set BT_FORCE_TURN=0
+set BT_FORCE_THROTTLE=1.0
+set HEAPSIZE=15000000
+set L4GAUGE=640x480x16
+call setenv.bat r s n p
+32rtm.exe -x
+BTL4REC.EXE -egg testarn.egg > COM3
+
+echo GAME-RC=%errorlevel% >> RC.TXT
+32rtm.exe -u
+echo ALPHA1-RUN-DONE
+pause
+
diff --git a/restoration/source410/BT/MECH.CPP b/restoration/source410/BT/MECH.CPP
index 73393b4b..5dd19fd8 100644
--- a/restoration/source410/BT/MECH.CPP
+++ b/restoration/source410/BT/MECH.CPP
@@ -1502,6 +1502,32 @@ void
 			<< " accel=" << bodyAcceleration.Length()
 			<< " unstable=" << unstablePercentage << endl << flush;
 	}
+
+	//
+	// The GAIT readout: where the speed shortfall actually lives.  Prints
+	// only on a state change so a long run stays readable.
+	//
+	if (getenv("BT_GAIT_LOG"))
+	{
+		static int s_lastLeg = -1, s_lastBody = -1;
+		int leg  = (int)legStateAlarm.GetLevel();
+		int body = (int)bodyStateAlarm.GetLevel();
+		if (leg != s_lastLeg || body != s_lastBody)
+		{
+			s_lastLeg = leg;
+			s_lastBody = body;
+			DEBUG_STREAM << "[gait] leg=" << leg << " body=" << body
+				<< " legCycle=" << legCycleSpeed
+				<< " bodyCycle=" << bodyCycleSpeed
+				<< " speed=" << currentBodySpeed
+				<< " target=" << bodyTargetSpeed
+				<< " standSpeed=" << standSpeed
+				<< " runCap=" << runSpeedMax
+				<< " clip6=" << animationClips[6]
+				<< " clip8=" << animationClips[8]
+				<< endl << flush;
+		}
+	}
 }
 
 //
diff --git a/restoration/source410/BT/MECH4.NOTES.md b/restoration/source410/BT/MECH4.NOTES.md
index 709cd389..56ab6302 100644
--- a/restoration/source410/BT/MECH4.NOTES.md
+++ b/restoration/source410/BT/MECH4.NOTES.md
@@ -591,3 +591,42 @@ NOTE ON PROVENANCE: the binary's own scale SITE was not located in code;
 the /100 is inferred from the field name plus authored data that is
 unambiguous.  Recorded as such rather than claimed as a byte-verified
 decode.
+
+## 5.3.134 -- THE "GAIT SHORTFALL" WAS A CONFOUNDED MEASUREMENT
+
+The top open question from 5.3.128 -- "the mech demands 35.9 u/s and the
+gait delivers 7.0, authentic acceleration or a gait shortfall?" -- is
+answered: **authentic acceleration, and the measurement was confounded by
+my own soak harness.**
+
+The run I drew that reading from was `pod_render_telem`, which still had
+`BT_SUPERSTOP_SOAK` driving the throttle to -0.5 every six seconds.  The
+mech was never given time to reach top speed; every sample caught the
+first seconds of a climb that was about to be thrown into reverse.
+
+`BT_GAIT_LOG` (new, state-change-triggered) on a clean full-throttle run
+shows the ladder working exactly as designed:
+
+    leg=5  speed=0      -> stand-to-walk
+    leg=7  speed=5.69
+    leg=6  speed=17.0   -> the walk-to-run step
+    leg=11 speed=17.7
+    leg=12 speed=25.5
+    leg=13 speed=35.7
+    leg=12 speed=44.35  target=44.837   legCycle=bodyCycle=44.837
+
+The mech accelerates 0 -> 45 u/s through six clip transitions and settles
+on its demand.  `runSpeedMax` reads 80.06, raised off its unsourced
+default by the myomers -- the 5.3.129 landing doing its job.  Both
+run-clip slots are bound (clip6=344, clip8=345).
+
+So the instability model pinning high during a climb was CORRECT all
+along: a mech demanding far more speed than it has IS gunning the engine.
+Nothing to fix in the gait or the instability model.
+
+**METHOD LESSON, the expensive kind:** I took a measurement from a rig
+whose harness was actively fighting the thing being measured, and wrote
+the result into the notes, a commit message and memory as an open defect.
+The hedge ("authentic or shortfall?") was the only thing that saved it
+from becoming received wisdom.  Before recording a number as evidence,
+check what else the conf is driving.