Nesting depth needs a hard cap

What it is

A taxi is suspended for weather; weather is unfinished when a text to mum starts; halfway through the text, “what’s two plus two.” Each layer is reasonable alone. Stacked, neither party can still answer “which job is live.” A nesting-depth cap puts a hard top on the task stack: past it, refuse another push, or collapse the outer layer to a draft, rather than taking everything. The cap protects trackability, not spoilsporting.

Why it happens

Each nested layer leaves a “parenthesis still open” mark in working memory, and a parent pointer in system state. People can roughly hold one parenthesis; at two they start losing which layer is waiting. The system can remember many layers, but a stack the user cannot follow is random from their side. Depth also multiplies resume cost: popping from layer three needs two joins in a row; drop one join and the middle layer becomes a ghost task — still occupying state, never reachable. Products that allow unbounded push usually are not maintaining a stack at all; each insert overwrites, and depth exists only in the wording. A hard top forces a design choice: the new request replaces the current layer, is refused, or the current layer is committed as a half-product. With no top, the choice is deferred until the beat where the user is already lost.

Studying it

Wizard-of-Oz forced depth: on one main task, nest 1, 2, then 3 unrelated short tasks, complete each layer, pop as designed. Dependents: whether people can name the layer now in play, wrong-layer pops, main-task completion. Independents: duration of each layer, whether layers share a domain (all lookup versus lookup plus control).

On logs, maintain an inferred stack depth per session and watch completion and “what are we doing” clarifications against depth. If the lab lets people see a task list, the measure is depth under external memory, not depth in screenless talk.

Where it stops holding

Experts on a fixed workflow who “check and come back” may use two layers as habit; the cap can loosen slightly, but a third should still trigger “put the taxi down first?” If the new layer is only a substep of the current task (“where is the office” during a taxi), that is slot refinement, not nesting depth. Screenless, depth costs more, so the cap should be tighter than with a screen — a screen can show the stack, the ear cannot. Implementing the cap as “the system does not support multitask” injures one legal insert; the top sits at two, not at zero.

Applying it

• Hard-cap the task stack (suggested 2: one parent plus one insert). On a third insert, ask which layer to put down; do not push silently.
• When refusing a push, name the tasks already hanging so the user can replace, not guess which job is live.
• Once at the cap, resume only by popping layer by layer; do not jump from three to one and leave two as a ghost.
• How to check: with the main task unclosed, insert two new skills, then a third. If the third is silently accepted, or a pop skips the middle layer, the cap is not working.

Related

• Same group: M1.05.1 People insert new requests in the middle of a task · M1.05.2 After the insert, the original task has to resume · M1.05.4 A topic switch and a correction are different intents · M1.05.5 A suspended task must keep its full mid-state · M1.05.6 Abandoning a task needs an explicit exit
• Nearby: M2.07 Dialogue Flow and State Design · M1.02 Memory Load of Screenless Interaction · M2.13 Multi-Intent and Compound Commands
• Search terms: nesting-depth cap · dialogue stack depth · task tracking