diff --git a/docs/port/HANDOFF.md b/docs/port/HANDOFF.md
index b5ab0400..7c43cbba 100644
--- a/docs/port/HANDOFF.md
+++ b/docs/port/HANDOFF.md
@@ -343,6 +343,21 @@ authored version can be deleted.
   splashes; composite statically for title / main menu / `EXTRAS`.**
   [`structures/ui-resting-pose.md`](../re/structures/ui-resting-pose.md)
 
+* ❔ **A group's DURATION is in the data; its START TIME is not.** Testing whether
+  the splash timeline *played* reproduces the capture: each element is on screen
+  for its declared span to within 2 % (glows 44 units observed vs 45 declared;
+  logos 192 vs 195). But every glow declares the same times `15,30,45` and every
+  logo the same `15,30,190,194,206,210`, so on one clock they would overlap almost
+  entirely — and they **do not overlap at all**. The glows run frames 94–115, the
+  logos 116–211, strictly sequential.
+  🔴 The obvious candidate is dead: each group header carries an undecoded
+  **lead-in word**, and it is `0x00000000` for all seven elements. Not the
+  keyframe times, not that word, not declaration order, not the RATC child order.
+  ⚠️ **So you must author the sequencing.** The observed order on the developer
+  splash — both glows, then both logos — is *measured for one screen*, not a
+  decoded rule.
+  [`structures/ui-group-start-time.md`](../re/structures/ui-group-start-time.md)
+
 * **Menu order is geometric.** Buttons sorted top-to-bottom by resting Y. This is
   ✅ correct for a vertical menu and is **not** a decoded neighbour graph — the
   disc's real navigation structure is unknown, and `opt ` is *not* a focus link
diff --git a/docs/re/METHOD.md b/docs/re/METHOD.md
index 10be9a71..d7fae5e6 100644
--- a/docs/re/METHOD.md
+++ b/docs/re/METHOD.md
@@ -795,3 +795,10 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
   a plateau mid-animation is not evidence the element is on screen at rest. An
   edit that improves one set of cases is only interesting once you have shown it
   damages the cases where it should.
+* **When a model reproduces durations but not positions, the missing piece is an
+  origin, not a rate.** Playing the splash timeline matched every element's
+  on-screen *length* to within 2 % while placing the elements in the wrong part
+  of the run. That pattern names the gap precisely — the rate and the shape are
+  right, so what is absent is a per-group start — and it pointed straight at the
+  one undecoded word in the group header. (Which was zero, but the diagnosis was
+  still what made the next step obvious rather than a search.)
diff --git a/docs/re/REFUTED.md b/docs/re/REFUTED.md
index 761ef09c..e8e54640 100644
--- a/docs/re/REFUTED.md
+++ b/docs/re/REFUTED.md
@@ -563,3 +563,12 @@ neighbourhood, not just the line.
   element is held at that point in the timeline, not that it is on screen once the
   screen has settled — and where a screen does settle, the rule is right.
   [`ui-resting-pose.md`](structures/ui-resting-pose.md)
+* "the group header's undecoded lead-in word carries a per-element start offset"
+  → **refuted immediately.** It is `0x00000000` for all seven elements of the
+  developer splash — glows and logos alike — while those two families are
+  observed to run sequentially (frames 94–115 and 116–211) despite declaring
+  overlapping times. [`ui-group-start-time.md`](structures/ui-group-start-time.md)
+* "the splash elements share one clock origin" → **refuted.** Fitting a single
+  origin needs f₀ ≈ 93.5 for `palogo_gamearts_eff` and f₀ ≈ 103 for
+  `palogo_gamearts`, ~19 units apart, and aligning one throws the other off by
+  ~9 frames at both ends. Durations match (97.8 %, 98.5 %); starts do not.
diff --git a/docs/re/structures/ui-group-start-time.md b/docs/re/structures/ui-group-start-time.md
new file mode 100644
index 00000000..49a172ae
--- /dev/null
+++ b/docs/re/structures/ui-group-start-time.md
@@ -0,0 +1,62 @@
+# ❔ A group's DURATION is in the data; its START TIME is not
+
+**Status:** ✅ the durations are measured and match; ❔ the start offset is
+**undecodable from the placement data**, with the obvious candidate refuted.
+
+Found while testing whether the splash timeline, *played*, reproduces the
+capture sequence — the last gap in the animation model.
+
+## The durations are right
+
+From the 235-frame draw capture of the developer splash, at the settled
+2 units/frame, under the shifted time reading:
+
+| element | drawn on frames | = units | declared visible span | match |
+|---|---|---|---|---|
+| `palogo_gamearts_eff`, `palogo_seta_eff` | 94–115 (22) | 44 | ~0 … 45 = **45** | **97.8 %** |
+| `palogo_gamearts`, `palogo_seta` | 116–211 (96) | 192 | 15 … 210 = **195** | **98.5 %** |
+
+(The logos are `a = 0` until t=15, so they are *drawn* for 15…210; the glows fade
+in from their untimed first keyframe.) **Each element is on screen for its
+declared span, to within 2 %.**
+
+## 🔴 But they do not share a clock origin
+
+Every glow declares the same times — `15, 30, 45` — and every logo the same
+`15, 30, 190, 194, 206, 210`. On one clock they would overlap almost entirely:
+both families start at 15.
+
+**They do not overlap at all.** The glows run frames **94–115** and the logos
+**116–211** — strictly sequential, the logos starting the frame after the glows
+end. Fitting a single origin bears this out: `gamearts_eff` needs f₀ ≈ 93.5 and
+`gamearts` needs f₀ ≈ 103, about **19 units apart**, and the same edit that
+aligns one throws the other off by ~9 frames at both ends.
+
+## 🔴 The obvious candidate is refuted
+
+`parse_placements` reads each group header as `(element index, keyframe count)`
+followed by **one undecoded lead-in word**. That is exactly where a per-group
+start offset would live. It is **`0x00000000` for all seven elements** of the
+developer splash — glows and logos alike. It carries no offset.
+
+## ❔ So where does the start come from?
+
+Not from the keyframe times (identical across each family), not from the group
+header's spare word (zero), and not from declaration order (`eff0.prm`, gamearts,
+gamearts_eff, seta, seta_eff, anima, anima_eff — which interleaves logos and
+glows, while the observed sequencing groups them). The RATC child order does not
+match the observed order either.
+
+Reach: three places looked, all negative. What remains is that the sequencing is
+**driven by code**, consistent with what
+[boot-config-and-gamepart-registry](../boot-config-and-gamepart-registry.md)
+already concluded for the boot order — *the driver is code, not data*.
+
+## ⚠️ What a port needs to know
+
+A group tells you **how long** an element's animation runs and what it does; it
+does **not** tell you **when** that animation starts relative to other elements
+on the same screen. On the developer splash the observed order is: both glows
+together, then both logos together. That is a **measured** sequence for one
+screen, not a decoded rule — a port animating a screen has to author the
+sequencing, and should know it is authoring.