diff --git a/harness/mame/BRINGUP_LOG.md b/harness/mame/BRINGUP_LOG.md
index 5dc0cf9..50c0dba 100644
--- a/harness/mame/BRINGUP_LOG.md
+++ b/harness/mame/BRINGUP_LOG.md
@@ -689,8 +689,41 @@ Concrete calibration plan (uses only driver-side logging, which works):
 3. That single run fixes the units and the precedence, and every address in this document
    can then be normalised.
 
+### 2. Four address conventions, still not reconciled — and two instruments that DISAGREE
+
+**Proven this session:** map precedence is **last-wins**. A logging proxy over
+`0x00000000-0x0000FFFF` registered *after* the RAM entry fires (4458 hits, then 22734 over a
+longer run), while proxies registered over other ranges do not. So drivers can layer
+handlers over real regions — that part is settled and useful.
+
+**The contradiction that blocks everything else:**
+
+| instrument | range | result |
+|---|---|---|
+| catch-all (registered FIRST, shadowed by RAM under last-wins) | logged `0x400000`-`0x40D7FF` | claims those are **UNMAPPED** |
+| layered proxy, registered LAST | `0x00400000`-`0x00400FFF` | **zero hits** |
+| layered proxy, registered LAST | `0x00000000`-`0x0000FFFF` | **fires** |
+| layered proxy, registered LAST | `0x00200000`-`0x01FFFFFF` | **zero hits** |
+
+The catch-all says `0x400000` is unmapped; but the RAM map covers `0x00000000-0x01FFFFFF`,
+and under last-wins RAM must win there — so the catch-all should never have seen it. And a
+proxy over exactly `0x00400000` sees nothing.
+
+**Therefore the catch-all's logged addresses are not address-map addresses**, and the
+"video memory at 0x00400000" conclusion is **unreliable**. It may still be right, but it has
+not been established by a trustworthy instrument.
+
+The blitter's target read straight from the POST code is `0x3600400` (a bit address), which
+matches none of the candidate encodings either.
+
+**Until this is closed, no video-memory work can be trusted.** The next step is one *closed*
+cross-check: run the catch-all and a layered proxy over the **same** range in the **same**
+run, and see which one reports. Whichever is trustworthy calibrates the rest; the other gets
+fixed or discarded.
+
 ---
 
 ## Next steps
 
-FIX THE INSTRUMENTATION FIRST (see above), then model video memory.
+CLOSE THE INSTRUMENT DISAGREEMENT FIRST (one cross-check run).
+Then model video memory and re-run the level-1 check via the console capture.