What the transient columns cannot see

The probe measures the frame, not the parameter. It reads pixels, so it can only see easing through whatever curve the scene puts between a bound value and its output — and for most scenes that curve is neither linear nor even monotone. Two consequences, both real and neither fixable by measuring harder:

• A saturating response reads flat. rose_trails is the worked example: its 1.25 spin against a max-decay feedback drives the frame to the same place whatever thickness says, which is why the content lane once rendered five values from 1.10 to 2.30 — including the untouched original — and could not tell them apart. A preset like that will report a transient that has nothing to do with its [smoothing] table, and no column here will warn you.
• The scene’s own motion is measured too. A fragment field’s fold, a feedback trail and a particle cloud all keep changing while the parameter settles, and the probe cannot separate that from the response. Over the shipped library this shows up as presets reporting fall below rise, which is backwards for any easing.

Measured over the shipped set on 2026-07-27 — a snapshot of what the probe sees, not a figure anyone maintains — presets carrying at least one { attack, release } entry had a median fall / rise of 1.02, with fall > rise in about half of them; presets with only scalar entries sat at 0.60, with barely any. So the columns separate the two populations directionally and lose the magnitude almost entirely: Smooth Pulse, the worked asymmetric example with a 0.60 s release, reads 26 / 31 where a purpose-built near-linear fixture at a 0.5 s release reads 3 / 61.

Those numbers were taken before the + marker existed, and every one of them would carry it today (Plan 0038 Phase 8). They were produced by exactly the defect this section goes on to describe: at PROBE_WINDOW = 48 a 0.60 s release is 1.33 τ, leaving ~26 % of the travel undone, and the fixture’s 3 / 61 is now known to be 3 / 69 when measured to settlement. Read the snapshot for its shape — two populations, separated directionally, magnitude lost — and not for its magnitudes, which is the same warning the rest of this section gives, now with the arithmetic behind it. It has not been re-taken: re-snapshotting is not what makes the columns trustworthy, marking them is.

Read the columns as evidence, not as a verdict. A wide fall / rise gap is good evidence the easing is working. A narrow one is not evidence it is broken. The place easing is proven is core/tests/suite/easing.rs, against fixtures built to have a near-linear response precisely so the measurement is of the easing and not of a scene; everything else is a preset-shaped approximation of that.

One smaller limit, and it is sharper than it was first written: the probe’s window is 48 frames (0.8 s) each way, so a release constant longer than about 0.35 s does not fully settle inside it. This page used to say such a response “reads clamped” — it does not, and that word was the trap. frames_to_settle normalizes against the segment’s own last frame, so when that frame is still travelling the measured total is short and every threshold is crossed early. The number that comes back is not pinned at the window length and is not obviously wrong; it is a plausible, smaller frame count. Worse, the bias is uneven — the 0.9 threshold is pulled in harder than the 0.5 one — so a truncated fall also reads as a more even fall than it is.

That is not hypothetical. Plan 0038 Phase 3 measured two easing orderings, one of which had an effective time constant of 1.0 s against a 1.6 s window, and read the truncation as a difference in the shape of the two falls. Measured to settlement the two shapes are identical and differ only in speed — 73 frames against 145, where the truncated run said 61 against 78. See ADR-0040’s Outcome.

The rule, and the function that enforces it. frames_to_settle cannot detect this about itself: normalizing against the last frame guarantees the threshold is crossed inside the segment, so frames_to_settle(seg, f) < seg.len() is a tautology rather than a check. Before trusting a frame count, gate it on metrics::segment_settled(segment, tol), which extrapolates the geometric tail from three points spread across the segment and answers whether the last frame is within tol of the asymptote. Sample widely rather than from the end: captures are 8-bit, and a response slow enough to outrun its window moves by less than one code value per frame near the end, so adjacent frames decode as identical and read as settled exactly when they are not.

So --report marks rather than pretends (Plan 0038 Phase 8). A transient cell carries a + when segment_settled cannot certify the response arrived — 61+ means at least 61 frames, never 61. Each family’s table then names how many of its presets marked. --json carries the same fact as rise_settled and fall_settled booleans, so a consumer reading only the counts cannot mistake a truncated response for a settled one.

Expect most of the shipped set to mark, and for two different reasons the suffix does not separate. One is the window, above. The other is far more common here and is not a defect in the probe at all: a scene whose own motion never stops — a fragment field’s fold, a feedback trail, a particle cloud — has no asymptote to settle to, so segment_settled correctly declines to certify one. That is the same limitation this page already describes as “the scene’s own motion is measured too”; the mark just moves it from a caveat you have to remember into the cell itself. A preset whose cells are unmarked is the interesting case: it means the number is a measurement.

Widening the --report window does not fix that table’s separation problem, which is a different thing — measured at 96 frames the scalar-only median got worse (0.60 → 0.92) for double the wall clock. Scene saturation is what hides the magnitude there. Window length is what corrupts a slow response’s shape, and the two are not the same defect.