diff --git a/context/decomp-reference.md b/context/decomp-reference.md
index d8119ea..4d268f5 100644
--- a/context/decomp-reference.md
+++ b/context/decomp-reference.md
@@ -561,7 +561,14 @@ whenever the decomp shows an unexplained multiply/divide by `_DAT_0052140c`,
 it is per-second <-> per-frame conversion at the pod's 28 Hz.
 
 **So the pod's nominal simulation cadence was 28 fps, not the i860 board's
-30 Hz.**  Every "per tick with no dt" accumulation in the binary (the myomer
+30 Hz — and it was UNLOCKED.**  Corroborated testimony (2026-08-02): Oracle —
+the pod rate was "flipbook" territory, heavy fights "a slide show"; Lynx
+(original era) — "BT never had a locked frame rate in 1st release testing",
+RP targeted 30, Tesla 3.0 managed ~20 on a good day.  The engine pacer design
+agrees: fixed budget, background fill, NO overrun catch-up (APPMGR.cpp T0) —
+target 28, allowed to slip.  Consequence: any per-tick dt-LESS accumulator ran
+SLOWER during heavy combat on real pods; per-tick behaviors must be calibrated
+against the loaded effective rate (veteran bracketing), not the constant.  Every "per tick with no dt" accumulation in the binary (the myomer
 kinetic heat term; candidate: particle trail density) was calibrated against
 28 nominal — and less under load (the 18.2 fallback existing at all says slow
 paths were expected; the EFFECTIVE in-pod rate is an open question, see
diff --git a/game/reconstructed/myomers.cpp b/game/reconstructed/myomers.cpp
index 0e42dc9..6fbccf4 100644
--- a/game/reconstructed/myomers.cpp
+++ b/game/reconstructed/myomers.cpp
@@ -772,14 +772,23 @@ void Myomers::MyomersDriveHeat(Scalar time_slice)
 	// the ApplicationManager ctor (0x401189: push [0x52140c]).  So the pod's
 	// nominal Performance cadence was 28 Hz, byte-proven.  [T1]
 	//
-	// CALIBRATION FACTOR 0.5, testimony (Oracle, 2026-08-02): at the byte rate
-	// the veterans still report ~2x too much myomer heat -- "If you could
-	// please halve the myomer heat rate again.  We will bracket to something
-	// reasonable."  The plausible physical story is the pod's EFFECTIVE rate
-	// under load (a 486 host missing beats; the 18.2 fallback existing at all
-	// says slow paths were expected), which statics cannot settle.  Effective
-	// default therefore 28 * 0.5 = 14 Hz, explicitly marked testimony-
-	// calibrated [T3]; BT_MYO_HZ=<hz> overrides absolutely for bracketing.
+	// CALIBRATION FACTOR 0.5 -- the pod's EFFECTIVE rate under load, now
+	// corroborated from three directions (2026-08-02):
+	//   * Oracle (pod veteran), asked if the frame rate was rock solid:
+	//     "I think I could do as well with a flipbook"; heavy fights "would
+	//     turn to a slide show".
+	//   * Lynx (original-era): "RP had a target frame rate of 30FPS.  It
+	//     wasn't hard coded or locked.  BT never had a locked frame rate in
+	//     1st release testing... coming from 3.0, where 20FPS was a miracle."
+	//   * The engine's own pacer DESIGN: end_of_frame = Now() + frameDuration
+	//     with background fill and NO overrun catch-up (APPMGR.cpp, T0) --
+	//     "target 28 but allowed to slip" is the construction, and the
+	//     18.2065 BIOS fallback anticipated degraded timing.
+	// Corollary: a choking 486 generated LESS heat/s exactly during the
+	// biggest fights -- veteran memory of seek-4 endurance encodes the LOADED
+	// rate, so bracketing by their consensus is the correct instrument.
+	// Effective default 28 * 0.5 = 14 Hz [T2 multi-witness]; BT_MYO_HZ=<hz>
+	// overrides absolutely for bracketing.
 	static const Scalar kPodFrameHz    = 28.0f;	// byte-proven nominal [T1]
 	static const Scalar kSeekHeatCalib = 0.5f;	// Oracle bracket 2026-08-02 [T3]
 	static Scalar s_hz = -1.0f;