diff --git a/restoration/source410/BT_L4/BTL4GAU2.CPP b/restoration/source410/BT_L4/BTL4GAU2.CPP
index 5ca9b12d..d05ef278 100644
--- a/restoration/source410/BT_L4/BTL4GAU2.CPP
+++ b/restoration/source410/BT_L4/BTL4GAU2.CPP
@@ -2027,6 +2027,8 @@ SubsystemCluster::SubsystemCluster(
 				<< " placement=" << clusterPlacement
 				<< " bg='" << (clusterBackgroundName ? clusterBackgroundName : "(none)")
 				<< "' port=" << mfd_port
+				<< " engPortName='" << (eng_port_name ? eng_port_name : "(null)")
+				<< "' engPort=" << renderer_in->FindGraphicsPort(eng_port_name)
 				<< " x=" << x << " y=" << y
 				<< " title='" << (title ? title : "(null)")
 				<< "' banner=" << (titleBanner ? 1 : 0) << "\n" << flush;
diff --git a/restoration/source410/BT_L4/GAUGE-BLOCK.NOTES.md b/restoration/source410/BT_L4/GAUGE-BLOCK.NOTES.md
index 2b53e496..934e48af 100644
--- a/restoration/source410/BT_L4/GAUGE-BLOCK.NOTES.md
+++ b/restoration/source410/BT_L4/GAUGE-BLOCK.NOTES.md
@@ -936,3 +936,58 @@ WHAT IS STILL OPEN, IN THE ORDER I WOULD TAKE THEM:
 
   4. MFD remainders: ~270 missing / ~34 extra across the three heads, mostly
      the same leak hatch as (2).
+
+================================================================================
+5.3.40 -- A CORRECTION: the "exact" heads are exact only on lucky runs
+================================================================================
+THE HEADLINE NUMBERS IN 5.3.39 ARE MEASURED ON RUNS WHERE AN INTERMITTENT
+DEFECT DID NOT FIRE.  Same binary (md5 verified identical), different run:
+
+    run              Eng1     Eng2     Comm
+    big/own/arc      17981    17981    15656     <- matches shipped exactly
+    t_a/t_b/t_c      19011    19011    16909     <- +1030 / +1030 / +1253
+    shipped x3       17981    17981    15656     <- STABLE across three runs
+
+The shipped binary does NOT vary; ours does.  So this is our defect, it is
+per-RUN (stable across captures 75s apart within a run, decided by the time
+of the first capture at +60s), and the dirty numbers are EXACTLY the pre-gate
+numbers from 5.3.32 -- the same artifact recurring, not a new one.  Eleven
+consecutive clean runs followed by dirty ones is what let it hide.
+
+WHAT IT ACTUALLY IS -- read off the raw words, not inferred.  In the artifact
+rect (fb x 526..538, y 228..279, a 13x52 vertical bar = the coolant column):
+
+    shipped writes   0x4000 = Heat          0x002D = sec        0x0500 = Mfd1+Mfd2
+    ours writes      0x8BD6 / 0x8AD6 / 0x8AED / 0x8AC0
+                     = sec + overlay + Mfd1 + Eng1 + Eng2 + Comm, all at once
+
+Shipped writes ONE masked plane bit per pixel.  We write arbitrary 16-bit
+words that light six planes at once -- raw values going into a plane-packed
+buffer.  That is why a single bad draw shows up as "extra pixels" on Eng1,
+Eng2, Comm, overlay, sec AND Mfd1 simultaneously, and why Heat is
+simultaneously MISSING 483 (the bit that should have been set there never
+was).  The A-button garble at (67..99, 3..34) is the same failure in a second
+spot; the clusters at 113/102/69/36/34 px are its fragments.
+
+WHY INTERMITTENT: these widgets are CHANGE-DRIVEN (they redraw only when
+their value moves).  On runs where the coolant value never moves after the
+first paint, the bad draw never happens and the head reads exact.  On runs
+where it moves, the garbage lands and nothing ever erases it.
+
+WHAT THIS DOES AND DOES NOT INVALIDATE:
+  * The six FIXES of 5.3.33-39 are real and independently measured -- the
+    MissileLauncher tables, the strip art, the ammo feed, the loop lamp, the
+    arc span and the Comm own row all moved specific, attributable pixels.
+  * The CLAIM "Eng1/Eng2/Eng3/Comm are exact" is only true on clean runs.
+    Restate it as: exact when the plane-write defect does not fire.
+  * The rig needs a RUN-VARIANCE check before any per-head number is
+    believed.  Shipped is stable, so a shipped baseline can be captured once;
+    ours must be captured at least twice and the counts compared.
+
+NEXT STEP: find the write path that emits an unmasked word.  Both known
+instances are on the Heat/coolant column and the generator-select button, and
+the engPort resolution is NOT the cause (traced: eng1/eng2/eng3 resolve
+correctly to 3/5/7).  Suspect the tile/strip blit for VertTwoPartBar-family
+widgets writing tile pixel VALUES rather than using them as a mask with the
+port colour -- the same widget draws correctly on the MFD heads, so it is
+specific to this port or this call site.