diff --git a/docs/re/structures/mission-objective-counter.md b/docs/re/structures/mission-objective-counter.md
index 81ffb349..14c8acf9 100644
--- a/docs/re/structures/mission-objective-counter.md
+++ b/docs/re/structures/mission-objective-counter.md
@@ -107,3 +107,46 @@ that is still *engaging*, which is the same constraint
 
 **Unchanged and still open:** what the counter counts, and whether an `OB`-badged
 entity carries a flag in its entity object. Nothing in this pass touched that.
+
+## 🟡 2026-08-23 (later) — a third run, a HUD-clean scan, and one candidate that is very hard to explain away
+
+With the launcher repaired the scan could finally be run the way the method
+asks. **HUD confirmed `004` immediately before *and* after the scan** (0.9 s), so
+the 39 596-entry candidate set is valid at that value; then filtered when the
+HUD was confirmed at `012`.
+
+| step | HUD | candidates |
+|---|---|---|
+| scan | `004` (confirmed both sides) | 39 596 |
+| filter | `012` (confirmed) | **17** |
+| later sample | — (see caveat) | 7 still 12 |
+
+**The survivor of interest is `0xbdb49668`** — the run-1 address `0xbdb59668`
+**minus exactly `0x10000`**, at the identical page offset `0x9668`.
+
+**That is not a cheap coincidence, and it was checked rather than admired.** Of
+all 39 596 words holding `4` at scan time, exactly **2** sit at page offset
+`0x9668`; one of those two is in the 17, and it is this one. A survivor landing
+there by chance is a ~5 × 10⁻⁵ event. The reading it suggests — the counter lives
+at a fixed offset inside an allocation whose **base moves by whole 64 KB pages**
+between runs — is a testable claim, not a story: a third scan should again land
+on `…9668`.
+
+**Why this is 🟡 and not ✅, stated plainly.** The corpus's own rule is that a
+candidate is believable once it tracks a transition it was *not* selected on,
+against the HUD. This one has not done that yet:
+
+* The "later sample" that killed 10 of the 17 was taken **during the GAME OVER
+  flash** — the escorted ACROPOLIS was lost at ~13 min — so the HUD counter was
+  not on screen. The ten that *moved* are genuinely refuted; the seven that did
+  not move are merely **unrefuted**, which is a much weaker thing, and the
+  counter may simply be frozen once the mission ends.
+* Between the filter and the mission end, `REMAINING OB` sat at `012` for about
+  ten minutes: `pilot.py` spent the window in EVADE/RETIRE at hull 822/1500 and
+  killed no objectives, so there was no transition to use.
+
+**The one experiment that settles it:** a run where the pilot is still engaging,
+scanning and filtering as above, then watching `0xbdb4·9668`-equivalent across a
+HUD-verified change. The blocker is the pilot's survival, not the method — and
+the same run would answer whether the page offset repeats, which is the stronger
+result of the two.