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/structures/unit-datasheet-static.md

@@ -143,15 +143,39 @@ description, not a rule.
 `0x8209F674…`. The loader uses the second block; **the first 20 are referenced by
 nothing**.
 
-### 🔴 The selection is still not found
+### 🔴 The selection is BLOCKED for static RE — four routes, all with controls
 
-Looking for the consumer by offset does not work here: functions loading two or
-more of `+196`/`+204`/`+320`/`+328` number **39** across the image, and those
-offsets are far too common to identify anything — the same trap the corpus has
-paid for before. Only two of the 39 are call-graph-reachable from the loader's
-owner (`sub_821A6CF0` itself, and `sub_821AB650`); that is the next handle, and
-it was not followed this iteration. **So "anti-air vs anti-vessel" remains a
-reading.**
+| route | result |
+|---|---|
+| 1. string xref on the field names | ✅ **only** `sub_822F9498` references them — this gave the layout above, and nothing else in the image touches an `AA_`/`AV_` string |
+| 2. unbounded offset intersection (`+196`/`+204`/`+320`/`+328`) | 🔴 **39** functions image-wide; pure coincidence |
+| 3. call-graph bound — the loader's owner `sub_821A6CF0`, and `sub_821AB650` | 🔴 both read `196`/`200`/`204` off **three different base registers** in three consecutive instructions: three unrelated objects contributing one float each, not the block |
+| 4. data-flow bound — the definition object lives in the global at `[0x828F358C]` (`lwz r3, 13708(r26)` feeds the loader); 18 functions touch it, 9 also touch block offsets | 🔴 the two best are both refuted, below |
+
+**Why route 4's best candidates fail, and it is instructive:**
+
+* `sub_8230D1F8` is a **different loader entirely** — a scoring table. Resolving
+  its field names the same way gives `+256 CraftScore_Adjustment`,
+  `+320 FFPenalty_Zessel_Maximum`, `+324 RankScore_S`, `+328 RankScore_A`,
+  `+332 RankScore_B`. It *stores* at the very offsets the definition object uses
+  for `AA_Roll_Min` and the four `AxisMode` fields.
+* `sub_82398CC0` uses `r19` as a **float-constant pool** (`lfs f0, 320(r19)`
+  alongside `272(r19)` and `-656(r19)`), not as a definition pointer.
+
+So the offset region is shared by at least two unrelated objects **and** by a
+constant pool. That is *why* every offset-based discriminator has failed here:
+the contamination is structural, not bad luck.
+
+🔴 **Marking this blocked for static RE.** The selection would have to be caught
+at runtime — a watch on the definition object's `+196`…`+332` during flight —
+which is emulator work, not a disc or image read. **"Anti-air vs anti-vessel"
+stays a reading**, as `unit-datasheet-static.md` has always had it; what is new
+is the layout, and that the selector must be a `+0`/`+8` offset.
+
+*Side finding, unowned by the corpus:* `sub_8230D1F8` is the **rank/score
+table loader** — `RankScore_S`/`_A`/`_B`, `FFPenalty_Zessel_Maximum`,
+`CraftScore_Adjustment`. Nothing in `docs/re/` mentions those names. Not pursued
+here.
 
 ## `Effect`