Whether the system fires at the throw-out or after the return is an implementation choice, not a deduction from the action

What it is

A round-trip swipe as an action includes throw-out and return. Which frame the system event commits on cannot be read off that definition. The page may turn at the throw-out's speed peak, or only after the hand is back at rest. The first is fast, and the return may still be taken as a second command. The second is stable, and people say “I already swiped, why hasn't it turned.” Both are legal. They must be written as an implementation choice and told to the user. “This is a round-trip gesture” does not name a commit point.

Why it happens

The commit point allocates latency versus double-fire risk. Peak commit crushes latency into the first half of the ballistic; the page turns while the hand is still in the air. If the return is not explicitly swallowed, its mirror speed commits again. End-of-return commit closes the whole token before emitting, so double fires drop, but feedback lags the person's “I already swiped”—subjective end is usually at throw-out deceleration, not when the hand falls back to the hip. A third internal option commits as soon as direction stabilizes, not even waiting for the peak: faster, and easier to hit with a passing half-swipe. The action definition constrains which motion counts as one swipe, not which instant has a side effect on the world. If the side effect is hard to undo, commit late. If it is reversible browsing, commit may be early.

Studying it

Replay the same action recordings under three commit policies: peak, direction-stable, end-of-return. Measure event latency (against a user key of “I finished the swipe”), double-fire rate, and whether it “moved only after I swiped.” Factors: whether the vocabulary holds mirror pairs, whether feedback is given at the commit instant. Wizard-of-Oz can let people pick a preferred commit point before swapping in the algorithm, separating preference from recognizer ability. Do not “derive” which policy to use from the wording of the action definition; that pretends a specification question is a semantic one.

Where it stops holding

Continuous rate control (hand right, keep fast-forwarding) has no single commit point; this choice does not apply. Pinch-drag's side effects run continuously during the hold; that is not one commit. If teaching omits the return, end-of-return commit waits forever and the system looks dead; peak commit is then more honest. Network delay shoves every commit point further back and magnifies the subjective gap. High-consequence commands (power off, pay) should not use peak commit even if the action is still a round-trip swipe.

Applying it

• Nail the commit point in the spec: peak, direction-stable, or end-of-return, and say how the other stretch of motion is swallowed.
• Mirror the commit point in feedback: early commit pulses on throw-out; late commit pulses when the hand is back at rest. Do not leave a gap in which people produce a retry.
• Default a mirror vocabulary away from peak commit unless the return is explicitly masked. Accept on both full round-trips and no-return productions, checking event counts.

Related

• Same group: C4.07.1 A swipe is a throw-out plus a return · C4.07.2 A forearm-only flick is possible; shortness does not guarantee recognition · C4.07.3 Teaching must keep direction, sequence, and reset
• Adjacent: C4.03 Gesture onset and offset detection · C4.27 Decoupling gestures from consequence severity
• Search: commit point · swipe trigger timing · fire on peak