re: the ten states are ONE PHASE of five -- and phase 0 is the splash

Chasing where the event code comes from turned up the level above and
corrected my own framing three sections running.

sub_821C6458 has exactly one caller, sub_821C7850, and that caller is
itself a dispatcher -- on a SECOND, outer state field at this+132, five
phases, gated on this+16 == 3. Phase 4 is the title/menu machine I have
been decoding. Phase 0 is sub_821C5690, which the iterate3E notes had
already fingered as the splash mechanics from a completely different
direction. That agreement is the useful check here.

So GamePart_Title has two nested state fields: a phase at this+132
choosing which sub-machine runs, and the state at this+136 inside phase
4. Everything I decoded over the last three iterations -- ten states,
eighteen edges, the event dispatch -- is phase 4 ONLY. Phases 1, 2 and 3
are untouched. I have called that out in REFUTED against my own earlier
wording rather than quietly restating it.

And the event code is forwarded, not created: all five phase handlers are
called with the same (this, r29, r28), where r28 is sub_821C7850's own
third argument passed through untouched. So the event vocabulary is
defined at least one level further up, and finding what 3, 5, 8, 10 and
25 mean means going up again. Not done.

docs/re/REFUTED.md

@@ -35,6 +35,10 @@ neighbourhood, not just the line.
 
 ## Screens, classes and RTTI
 
+* "`sub_821C6458` is `GamePart_Title`'s state machine" → **mine, imprecise.** It
+  is the machine for **phase 4** of a five-way outer dispatch at `this+132`;
+  phase 0 is the splash. The ten states and eighteen edges are phase 4 only.
+  [`boot-config-and-gamepart-registry.md`](boot-config-and-gamepart-registry.md)
 * "`sub_821CC860` is the game's by-name screen factory" → **mine, and wrong.** Its
   decoded arguments include `BG`, `BLACK`, `FADE`, `FILE`, `KEY`, `PAD`, `SOUND`,
   `GAMMA_RGB` — it is a **generic name-keyed lookup**, mostly config.

docs/re/boot-config-and-gamepart-registry.md

@@ -399,3 +399,45 @@ observation so the next person sees the shape; it is **not** a button→event ma
 * **what the event numbers mean** — button id, menu-item index, or message id;
 * **conditions on edges out of the other states** (`0 → 1` vs `0 → 2`, `6 → 7/9/2`);
 * states 1, 3, 5, 6, 7, 9, which install no named screen.
+
+
+## 🔴 Correcting my own framing: `sub_821C6458` is ONE PHASE, not the whole part
+
+Chasing where the event code comes from turned up the level above, and it revises
+what the previous three sections called "the title part's state machine".
+
+`sub_821C6458` has exactly one caller, `sub_821C7850`, and that caller is itself a
+dispatcher — on a **second, outer state field**:
+
+```
+821c786c  lwz    r11, 16(r30)      ; only runs at all when this+16 == 3
+821c7874  bne    cr6, <exit>
+821c787c  lwz    r11, 132(r30)     ; phase = this+0x84
+821c7880  cmplwi cr6, r11, 0x4     ; FIVE phases, 0..4
+821c789c  bctr                     ; table at 0x821C78A0
+```
+
+| phase | handler | |
+|---|---|---|
+| 0 | `sub_821C5690` | **the splash** — independently identified as the splash mechanics in the `iterate3E` notes, before any of this |
+| 1 | inline at `0x821c790c` | |
+| 2 | `sub_821C5818` | |
+| 3 | `sub_821C5EC0` | |
+| **4** | **`sub_821C6458`** | the title/menu machine — `TITLE_SCREEN` / `TITLE_MENU` / `LOADING` |
+
+So `GamePart_Title` has **two nested state fields**: a phase at `this+132` (five
+values) selecting which sub-machine runs, and the state at `this+136` (ten values)
+*inside phase 4*. Everything the previous sections decoded — the ten states, the
+eighteen edges, the event dispatch — is **phase 4 only**. Phases 0–3 are
+untouched, and one of them is the developer splash.
+
+That phase 0 lands on the function the corpus had already fingered as the splash,
+from a completely different direction, is the useful check here.
+
+### And the event code is forwarded, not created
+
+All five phase handlers are called as `(this, r29, r28)` with the *same*
+arguments, and `r28` is `sub_821C7850`'s own third argument, passed through
+untouched. So the event vocabulary is defined **at least one level above** this
+function. Finding what `3`, `5`, `8`, `10`, `25` mean means going up again, and
+that was not done.

docs/re/data/title-state-machine.txt

@@ -1,4 +1,26 @@
-GamePart_Title's screen state machine -- sub_821C6458, decoded statically.
+GamePart_Title has TWO nested state fields.
+
+OUTER -- sub_821C7850, the part's dispatcher
+  821c786c  lwz    r11, 16(r30)      ; only runs when this+16 == 3
+  821c7870  cmpwi  cr6, r11, 3
+  821c7874  bne    cr6, <exit>
+  821c787c  lwz    r11, 132(r30)     ; phase = this+0x84
+  821c7880  cmplwi cr6, r11, 0x4     ; five phases, 0..4
+  821c7888  lis/addi r12, 0x821C78A0 ; jump table
+  821c789c  bctr
+
+    phase 0 -> sub_821C5690   (the splash -- independently identified as the
+                               splash mechanics in the iterate3E notes)
+    phase 1 -> inline block at 0x821c790c
+    phase 2 -> sub_821C5818
+    phase 3 -> sub_821C5EC0
+    phase 4 -> sub_821C6458   (the title/menu machine, below)
+
+  All four call sites forward the SAME three arguments: (this, r29, r28),
+  where r28 is this function's own third argument -- an EVENT CODE passed
+  through unchanged from ITS caller.
+
+INNER -- sub_821C6458, the title/menu machine (phase 4 only)
 
 DISPATCH
   821c6474  lwz    r11, 136(r30)     ; state = this+0x88
@@ -67,7 +89,8 @@ THE CONDITION ON STATE 4's EDGES -- decoded
     event 25 -> block 0x821c6ed8 -> state 8   (LOADING)
 
 WHAT IS NOT DECODED
-  * what the event NUMBERS mean -- button id, menu-item id or message id;
+  * what the event NUMBERS mean -- they are forwarded unchanged from
+    sub_821C7850's caller, so the vocabulary is defined at least one level up -- button id, menu-item id or message id;
   * the conditions on edges out of states other than 4;
   * what states 1, 3, 5, 6, 7 and 9 do (they install no named screen);
   * state 3 is never a destination here, so something outside this function