re: propose settle-instant posing -- and my control cannot validate it

The proposal: pose every element at the SCREEN's settle instant rather than
asking each element for its own resting pose. On the 2 249 fallback elements in
settling bundles the visible-pose rate falls 73.6 % -> 34.7 %.

But the control fails twice. Naive, over every plateau element: 46.6 %. That one
was misspecified and I caught it by asking what the number means physically --
rest() finds *a* held pose and many elements hold one during the build-in then
move on, so it answers a different question and disagreement proves nothing.
Restricted to elements HOLDING ACROSS the settle instant: 78.1 %, still not a
pass.

And the residual is ambiguous by construction: rest_plateau() picks one plateau,
so an element with two whose settle instant falls in the other will disagree --
and there pose_at(settle) is RIGHT. The control cannot separate 'the candidate is
wrong' from 'the incumbent is wrong'.

Recorded as the general point: comparing a candidate to the incumbent cannot
adjudicate when the incumbent is the thing under suspicion. It is the wrong shape
of experiment, not a tuning problem.

What does adjudicate is the oracle and it is the port's measurement, not mine --
publisher splash against a committed capture, settle-instant pose RMSE 2.17 /
0.01 % differing against --pose=rest 9.05 / 0.75 %. My numbers describe the
proposal's effect; they do not establish it.

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

docs/re/structures/ui-resting-pose.md

@@ -319,6 +319,45 @@ units brighter.
 **The element has no resting pose.** It is a flash; after it plays there is
 nothing. Neither answer is *derived* — one of them is merely harmless.
 
+### 🟡 A proposal — and my own control cannot validate it
+
+Three iterations have measured how badly the fallback behaves without proposing
+anything. The proposal is **pose every element at the *screen's* settle instant**
+(`UiBuild::settle_time()`, the midpoint of the longest keyframe-free interval across
+the build) rather than asking each element for its own resting pose
+([`../data/rest-vs-settle.txt`](../data/rest-vs-settle.txt)).
+
+**Effect**, on the 2 249 fallback elements in bundles that settle at all: the
+visible-pose rate falls **73.6 % → 34.7 %** — consistent with transient peaks
+disappearing.
+
+🔴 **But the control fails, and then fails better, and still is not a pass:**
+
+| control | agreement |
+|---|---|
+| naive — every plateau element | **46.6 %** |
+| fair — only those **holding across** the settle instant | **78.1 %** |
+
+The naive one was misspecified, caught by asking what 46.6 % means physically:
+`rest()` finds *a* held pose, and many elements hold one during the build-in then
+move on. Different questions; disagreement proves nothing.
+
+⚠️ **And the fair control's 21.9 % residual is ambiguous by construction.**
+`rest_plateau()` picks one plateau; an element with two, whose settle instant falls
+in the *other*, disagrees — and there `pose_at(settle)` is **right** and `rest()`
+wrong. The control cannot separate *"the candidate is wrong"* from *"the incumbent
+is wrong"*.
+
+🔴 **Comparing a candidate to the incumbent cannot adjudicate when the incumbent is
+the thing under suspicion.** No care with this control fixes that; it is the wrong
+shape of experiment.
+
+✅ **What adjudicates is the oracle, and it is the port agent's measurement, not
+mine**: its publisher splash against a committed capture, **settle-instant pose RMSE
+2.17 / 0.01 % differing** against **`--pose=rest` 9.05 / 0.75 %** — 75× the
+differing area, against the game. **That** is the evidence for the proposal; the
+numbers above describe its effect and do not establish it.
+
 ### 🔴 Losing the example did not close the question — it is larger than one element
 
 Disc-wide ([`../data/rest-fallback-census.txt`](../data/rest-fallback-census.txt)):