Subtask boundaries are cheaper moments to interrupt

What it is

The same notice costs more mid-sentence than after a paragraph is saved. A subtask boundary (breakpoint) is the seam where a small goal has just completed and the next is not yet loaded: mail sent, a page submitted, the next item started, a pre-roll ended. Aiming deferrable delivery at those seams is a timing policy. It does not regrade urgency, and it does not by itself send less.

This entry is only about when a cut-in is cheaper. It does not claim that low-value items should never sound—that is a different policy—and it does not flatten "wait for idle" into "don't send at night."

Why it happens

Working memory updates in chunks. At the end of a subgoal, intermediate results are unloaded or written out (document saved, form submitted) and the next chunk is not yet expanded. An insertion then has the least to rebuild. Mid-subgoal, the person must hold place, handle the notice, and keep the two intents apart; resumption often resumes the wrong step.

Interfaces can observe a crude proxy: submit succeeded, playback paused, edit mode left for browsing, lock screen, an input blurred with no keystrokes for a while. What they cannot observe is an inner period. Engineering therefore catches detectable breakpoints, not the phenomenology of wanting a rest. Deferral has a ceiling: time-critical events cannot be hoarded forever waiting for a seam.

Studying it

Insert the same interruption mid-subtask versus at a boundary and compare resumption lag and later errors. Boundaries can be defined by task structure (after each solved item) or by a behavioral proxy (five seconds without typing).

Independent variables: insertion point (mid / boundary), deferral ceiling, whether the primary task has a clear external completion mark. Dependent variables: resumption lag, omitted steps, delay until the notice is handled, total time on the primary task.

Lab tasks have clean seams (item by item); real editing does not. Treating "stopped typing" as a boundary misreads thinking pauses as idle, so the chime fires during thought. Split "successfully deferred to a boundary" from "ceiling hit, forced flush"—the latter is no longer a boundary strategy.

Where it stops holding

Continuous tasks with no detectable completion (long video, driving, a call) barely expose seams; hunting for one becomes random insertion. Second-scale safety events cannot wait. People who process notices in fragments experience the boundary as "already in fragment time"; deferral then dumps the pile onto the doorstep of the next deep block. Games and full-screen presentations that suppress system breakpoint detection also stall an app's deferral queue; a fallback flush is required.

Applying it

• Give deferrable types a short window (minutes, not hours) and flush first on submit-success, save, pause, or return to home.
• When the window expires with no breakpoint, deliver at the original tier; do not hide time-critical events until the next app open.
• Do not treat any inactivity as a breakpoint: reading and thinking are engagement. Prefer explicit completion events.
• Verify by inserting the same type mid-field and after submit-success in a form, and comparing time to resume the next field. If the two are equally long, deferral was random delay, not boundary alignment.

Related

• Within the group: H5.02.1 Interruption cost rises with how deep the task has gone · H5.02.3 Low-value notices should not interrupt
• Adjacent: H5.10 Push frequency and quiet hours · H5.03 Do not disturb and focus · H5.01 Urgency grading
• Search terms: subtask boundary · breakpoint deferral · interruption timing