re: the AA_/AV_ selection is BLOCKED for static RE, with the mechanism

Route 3 (call-graph bound): sub_821A6CF0 and sub_821AB650 each read 196/200/204
off THREE different base registers -- three unrelated objects, not the block.

Route 4 (data-flow bound): the definition object lives in the global at
0x828F358C; 18 functions touch it, 9 also touch block offsets.  The two best
are refuted -- sub_8230D1F8 is the rank/score loader storing
CraftScore_Adjustment, FFPenalty_Zessel_Maximum and RankScore_S/A/B at exactly
256/320/324/328/332, and sub_82398CC0 uses r19 as a float-constant pool.

So the offset region is shared by two unrelated objects and a constant pool:
offset-based discrimination is contaminated by construction, which is why it
has now failed three times.  Catching the selection needs a runtime watch.

Side finding, unowned by the corpus: sub_8230D1F8 is the rank/score loader.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE

docs/re/BACKLOG.md

@@ -4476,3 +4476,51 @@ that is the next handle. **"Anti-air vs anti-vessel" stays a reading**, exactly
 name→offset mapping when a scripted `addi`→`stfs` pairing (which I then wrote
 anyway) gave the same 20 lines. Script the extraction first; never eyeball a
 4.5 KB function.
+
+---
+
+## 🔴 2026-08-27 — the `AA_`/`AV_` selection is BLOCKED for static RE
+
+Continues the entry above. Two more routes tried, both refuted with their cause
+shown; per the standing rule, when every route has a control and they all read
+zero, the item is blocked — writing it down and moving on.
+
+**Route 3 — call-graph bound.** The only two functions reachable from the
+loader's owner, `sub_821A6CF0` and `sub_821AB650`, each read `196`/`200`/`204`
+in three consecutive instructions off **three different base registers**
+(`r25`/`r24`/`r11` and `r30`/`r29`/`r11`). That is three unrelated objects
+contributing one float each — not the AA/AV block. Refuted.
+
+**Route 4 — data-flow bound.** The definition object lives in a global: the
+loader is fed by `lwz r3, 13708(r26)` with `r26 = 0x828F0000`, i.e.
+`[0x828F358C]`. **18** functions touch that global and **9** of them also touch
+block offsets — a far better bound than the 39 from offset shape alone. The two
+best candidates are both refuted:
+
+* `sub_8230D1F8` is a **different loader**. Resolving its field names the same
+  `addi`→`stfs` way gives `+256 CraftScore_Adjustment`,
+  `+320 FFPenalty_Zessel_Maximum`, `+324 RankScore_S`, `+328 RankScore_A`,
+  `+332 RankScore_B` — it *stores* at exactly the offsets the unit definition
+  uses for `AA_Roll_Min` and the four `AxisMode` fields.
+* `sub_82398CC0` uses `r19` as a **float-constant pool** (`320(r19)` next to
+  `272(r19)` and `-656(r19)`), not as a definition pointer.
+
+🔑 **This explains the whole pattern of failure.** The offset region is shared by
+at least two unrelated objects *and* by a constant-pool base, so every
+offset-based discriminator is contaminated **by construction** — that is the
+third time the offset route has failed on this corpus, and now with a mechanism
+rather than just a count.
+
+🔴 **BLOCKED.** Catching the selection needs a runtime watch on the definition
+object's `+196`…`+332` during flight — emulator work, NEEDS-HUMAN, not a disc or
+image read. The layout finding stands; "anti-air vs anti-vessel" stays a reading.
+
+❔ **Side finding, unowned:** `sub_8230D1F8` is the **rank/score table loader** —
+`RankScore_S`/`_A`/`_B`, `FFPenalty_Zessel_Maximum`, `CraftScore_Adjustment`.
+Grep confirms nothing in `docs/re/` mentions any of those names. A cheap item for
+a future iteration.
+
+**Method slip, second time in two iterations:** I dumped ~400 instructions of
+`sub_82398CC0` by eye before writing the six-line name-resolution script that
+settled both candidates. **Write the script first** — it is in the standing rules
+and I broke it again.