Breakpoints come in coarse and fine grain, and the subtask boundary is only one coarser level

What it is

A task is not one indivisible block; it is a nested goal structure — a report breaks into sections, sections into paragraphs, paragraphs into sentences; filling a form breaks into the whole form, individual fields, individual keystrokes. The instant each level of goal completes is a candidate moment to interrupt, called a breakpoint. These candidate moments are not equivalent — completing a whole subtask is one kind of breakpoint, completing a single action inside that subtask is another. The subtask boundary is just one coarser rung on this ladder, neither the only one nor the finest one.

Why it happens

Executing a task depends on holding a stack of unclosed goals in working memory: an overall task goal at the top, a current subtask goal below it, and the concrete step being executed below that. Which layer of that goal stack a given breakpoint closes determines how "clean" the breakpoint is. At a coarse breakpoint — a subtask fully finished — that layer and everything nested under it is emptied out, so an interruption there leaves the least pending state to maintain in working memory. At a fine breakpoint — one step inside a subtask just completed — only the innermost sub-goal closes; the outer subtask's goal state is still sitting in working memory, exposed to being overwritten or flushed by whatever comes next. The coarser the grain, the more layers of the goal stack get closed, and the cleaner the breakpoint.

Studying it

Research on this typically starts with a hierarchical task decomposition: writing the task out as a goal tree and marking the start and end of every sub-goal level — those start/end points are the candidate breakpoints. Candidates are then classified by which goal layer they close, into coarse (e.g., subtask or phase boundaries) versus fine (e.g., single-step boundaries inside a subtask), and external interruptions are inserted at each grain to compare post-interruption task performance, error rate, and self-reported annoyance.

Common independent variables: which layer a breakpoint sits at, and the depth of the task's own hierarchy. Common dependent variables: task-time increment after interruption, error rate, and post-hoc annoyance ratings.

Methodological caveat: hierarchical decomposition depends on the researcher's own reading of task structure, and different researchers rarely carve the same boundaries. This approach works best for structured, procedural tasks (form filling, document editing, coding) where boundaries are legible; for open-ended, exploratory tasks (free writing, brainstorming) the boundaries themselves are fuzzy, and the grain distinction loses much of its force.

Where it stops holding

• This holds only when the task has a recognizable hierarchical structure. For flat tasks without clear nested sub-goals — sustained free association or ideation — coarse-versus-fine has no stable anchor.
• Grain classification is relative, not a fixed two-tier split. A sufficiently complex task can have three or more levels; "coarse" and "fine" only make sense relative to that task's own depth, not compared across different tasks.
• This entry only establishes that breakpoints vary in grain. What cost-versus-latency tradeoff a given grain buys is a separate claim.

Applying it

• Before building any system that needs to sense task boundaries — notification scheduling, autosave, collaborative prompts — run a hierarchical decomposition of the target workflow first, to see which levels candidate breakpoints actually occur at, rather than assuming a page transition or a submit click is the only boundary that exists.
• Match urgency to grain: information that is costly to deliver but can wait should look for a coarser breakpoint; low-cost, time-sensitive information can tolerate a finer one.
• Verification: tag candidate breakpoints at different hierarchy levels in real usage logs, insert interruptions at each level, and compare the delay and error rate in the steps immediately following resumption. That gap tells you whether the grain distinction actually holds for this task, and which level is the right one to target.

Related

• Same group: A5.14.2 Fine boundaries occur earlier but protect less · A5.14.3 Batching notifications to the next boundary costs less overall than immediate delivery · A5.14.4 User-set do-not-disturb windows compensate for limited automatic boundary detection
• Adjacent: A5.08 Interruption cost and task resumption · A6.02 Working memory capacity
• Search terms: interruption breakpoint · task boundary · hierarchical task decomposition · opportune moment for interruption