Don't commit later decisions to an unconfirmed optimistic result

What it is

Once an optimistic result is treated as true, people will do the next thing that is hard to take back on top of it: forward a “sent” message, check out on “added to cart”, open a secret page on “permission granted”. Stay cautious until the real result returns means: later decisions wait for confirm, or are marked still recallable, or are simply not offered inside the optimistic window.

This is not the same cut as “do not be optimistic on irreversible acts”. That forbids painting the irreversible act itself as done. This allows the earlier step to be optimistic, and forbids using the unconfirmed result as the foundation of a later act.

Why it happens

Inside the optimistic window the screen is true and the server may be false. A later decision writes the window’s value into another causal chain: a forward quotes a message that may still roll back, checkout quotes an SKU that may never have been added, navigation quotes a permission that may still be refused. When the window closes as failure, rollback can peel the first layer; the second has already run into someone else’s inbox, a payment gateway, or another route. The second layer has no symmetric rollback, so a tear appears: first layer down, second still standing.

Caution is not freezing the product. It splits later acts in two. One kind can read the optimistic value harmlessly (like again, glance at the new title). The other kind emits the optimistic value to the outside or to an unrecallable place. The second kind must see an “unconfirmed” latch: the control disabled, or enabled but copy says “sending, forward after confirm”, or the forward itself queued until confirm. The latch is a guard on the state machine, not decorative copy.

Where it stops holding

Purely presentational follow-ons (refreshing the nav label from an optimistic title) may change at once and change back on rollback. Decisions people make in their head (“I already sent it, I’ll do something else”) cannot be blocked; what can be blocked is the next door the product offers. In an offline queue, later decisions can explicitly target “pending send” rather than “delivered” — forwarding pending should be refused or marked “they cannot see this yet”. Local prediction of one’s own character in a game or collaboration is another class; the far side will correct. That is prediction, not submitting an unconfirmed result to a payment. A long confirm (human review) stretches the caution window to minutes or days; later acts should default to locked, not let people spend the result as done during review.

Applying it

• Mark every later door that reads an unconfirmed write: forward, checkout, share, a jump after grant. While unconfirmed, disable, or queue until confirm.
• If it must remain tappable, copy and state must say “based on a result not yet confirmed”, and rollback must stop the later act too.
• Do not fire external side effects (push, mail, webhook) on optimistic success. Side effects follow the authority.
• How to check: send a message optimistically, tap Forward before confirm. If the forward has already reached a third party and the original then rolls back, the tear holds. Optimistic add-to-cart then immediate checkout: checkout should wait for the add to confirm, or exit checkout with an explanation if the add fails. A secret page opened on optimistic permission: on authority refusal, leave that page at once, rather than staying in already-seen content and only changing a badge.

Related

• Same group: I3.09.1 Rollback must restore the pre-failure UI, not leave a pending ghost · I3.09.2 Stacked optimistic steps need a defined rollback radius · I3.09.3 A rollback notice must say why it failed and whether retry is possible
• Nearby: I3.02 Optimistic updates · I3.13 State-machine completeness and illegal states
• Search terms: unconfirmed state · decision on optimistic · causal chain