diff --git a/docs/re/structures/ui-screen-runtime.md b/docs/re/structures/ui-screen-runtime.md
index 6b288fa..f3c17f6 100644
--- a/docs/re/structures/ui-screen-runtime.md
+++ b/docs/re/structures/ui-screen-runtime.md
@@ -153,15 +153,30 @@ Deriving the child order from the bundle is what the port needs, so the first
 step is data. Both live screen objects with more than one element, read off the
 title screen:
 
-**A 7-element bundle** (pivots `(640,360) (250,36) (260,46) (120,44) (130,55)
-(194,68) (204,78)` — three pairs 10 px apart plus a full-screen layer):
+**The developer-logo splash** — `GP_TITLE.pak` entries 11/14, identified by
+matching its pivots against every 7-element build on the disc. It is the
+GAME ARTS / SETA / studio anima screen, i.e. the one the emulator-era Milestone 1
+worked on:
+
+```
+0 palogo_eff0.prm (640,360)   1 palogo_gamearts (250,36)   2 palogo_gamearts_eff (260,46)
+3 palogo_seta (120,44)        4 palogo_seta_eff (130,55)
+5 palogo_anima (194,68)       6 palogo_anima_eff (204,78)
+```
 
 ```
 paint order (child slots): 0 2 4 6 1 3 5
 ```
 
-— the **even** declaration indices in order, then the **odd** ones. A stable
-partition into two groups, nothing more.
+— which, with the names, reads as **the full-screen `.prm`, then all three
+`_eff` glows, then all three base logos**. The glow behind, the logo on top:
+a semantic grouping, and one that the declaration table interleaves
+(base, glow, base, glow, …).
+
+**This refines the "grouped by sprite" reading.** Here every element has its own
+sprite, so the grouping cannot be by sprite identity — it is by *role*. In the
+title build the two readings coincide (the three `ptlogo1` instances share both a
+sprite and a role), so that build alone could not tell them apart.
 
 **The 24-element title build:**
 
@@ -191,6 +206,19 @@ paint order: 9 11 12 10 13 6 20 19 14 15 18 16 17 0 2 4 7 1 3 5 22 23 21 8
   (`ptbase2` is RATC child 4 and paints first; `ptlogo1` is child 0 and paints
   fourteenth).
 
-**Not settled:** the rule. Two permutations are enough to kill the simple
-candidates and not enough to build the real one — the group *contents* are
-explained (same sprite), the group *order* is not.
+### The order is deterministic
+
+Two independent boots, the same screens: **byte-for-byte identical
+permutations** (and identical object addresses). So the child list is not built
+in I/O-completion order or anything else run-dependent — it is a pure function of
+the bundle, and therefore derivable in principle. That was worth testing before
+hunting for a rule, because a load-order-dependent list would have made the hunt
+pointless.
+
+**Not settled:** the rule itself. What is known is that the list groups elements
+by role — glows before bases, instances beside their template — which the
+declaration table interleaves. What is not known is where that role comes from:
+no decoded field carries it, and the names (`_eff`) are suggestive but a loader
+sorting on a name suffix would be unusual. The next step is the loader — the code
+that appends to `+0x30` — which is now worth reading precisely *because* the
+order is deterministic.