diff --git a/restoration/source410/MUNGA_L4/L4GREND.NOTES.md b/restoration/source410/MUNGA_L4/L4GREND.NOTES.md
index 2e159476..c4b096e6 100644
--- a/restoration/source410/MUNGA_L4/L4GREND.NOTES.md
+++ b/restoration/source410/MUNGA_L4/L4GREND.NOTES.md
@@ -75,24 +75,43 @@ out: it is an inert stub returning NULL, so `recoloredMech` never blits in our
 build. Unattributed. The fix covers it either way, since it zeroes the whole
 tail regardless of who indexes it.
 
-**The colour mappers may be a second exposure, in-mission.** `L4GAUGE.CFG`
-carries **1345** colour-mapper entries — 656 `cmCrit`, 662 `cmHeat`, 27
-`cmArmor` — and `BT_VIS_LOG` puts all of them on **port 0**, the six-bit head,
-at 50,0. Their mode is literally `ModeSecondaryCritical`. They name
-`adpal.pcc`, `adpal2.pcc`, `heatpal.pcc`, `heatpal2.pcc`, three of which the
-sweep flags as out-of-range (`ADPAL`/`ADPAL2` are 2×5 and **entirely** index
-99; `HEATPAL` has one pixel at 100).
+That the boot cockpit lights only 1030 pixels says the avatar art is not being
+drawn on that screen. It does not say anything about a live mission — the
+`*CRIT`/`*HEAT` silhouettes carry 1500–2500 pixels of index 231 apiece, so if
+something blits them on port 0 the in-mission artifact is several times the
+size of the bar. Which widget blits them is not yet established.
 
-Whether that matters depends on something not yet established: these are tiny
-swatch files, and a colour mapper plausibly reads their **VGA palette** rather
-than blitting their pixels. Do not repeat this as a finding until someone has
-read the mapper's implementation. It is recorded because if the pixels *are*
-used as colour indices, every one of 1345 mappers writes an out-of-range index
-on the six-bit head — which would dwarf the 676px bar and would fire
-in-mission, matching where the operator sees the artifact.
+## Closed hypothesis: the colour mappers are NOT a second exposure
 
-That the boot cockpit lights only 1030 pixels says the avatar/mapper art is not
-being drawn on that screen. It does not say anything about a live mission.
+Recorded because it was raised as a serious escalation and then killed, and the
+kill is worth keeping so nobody re-raises it.
+
+The worry: `L4GAUGE.CFG` carries **1345** colour-mapper entries — 656 `cmCrit`,
+662 `cmHeat`, 27 `cmArmor` — `BT_VIS_LOG` puts every one of them on **port 0**,
+their mode is literally `ModeSecondaryCritical`, and they name `adpal.pcc`,
+`adpal2.pcc`, `heatpal.pcc`, three of which the sweep flags (`ADPAL`/`ADPAL2`
+are 2×5 and **entirely** index 99). If those pixels were blitted as colour
+indices, 1345 widgets would each be writing out-of-range on the six-bit head.
+
+They are not blitted. `ColorMapper::ColorMapper` (`BTL4GAUG.CPP:389`) takes the
+two names into the **`palette8Bin`**, not a pixelmap or bitmap bin, and the
+execute path (`:526`) is
+
+```c
+Palette8 *palette = warehouse->palette8Bin.GetIfAlreadyExists(paletteName[paletteToggle]);
+PaletteTriplet &entry = palette->Color[currentColorIndex];
+...
+graphicsPort->SetColor(&entry, colorSlot);
+```
+
+It reads the file's **VGA palette**, takes one RGB triple, and pushes it into a
+hardware colour slot. No pixel of `ADPAL` ever reaches a framebuffer, so their
+index-99 content is irrelevant. The two-palette pair is a flash/toggle
+(`paletteToggle` alternating each frame), which is also why `twoColorMode`
+compares the two names.
+
+**Conclusion: negative.** The mappers are not an exposure, and the search for
+the in-mission source has to go elsewhere.
 
 ## A shipped data bug, found in passing — do NOT fix