Stalled progress should explain why rather than resemble failure

What it is

A progress stall explanation distinguishes waiting for a person, resource, permission, or safety condition from retry and failure. No progress is an observation; its cause determines whether someone waits, supplies input, clears an obstacle, or cancels.

Why it happens

Different internal states produce the same frozen indicator. People infer failure from elapsed time and may duplicate commands or restart. Cause, elapsed wait, and release condition create a causal model. If diagnosis is uncertain, “diagnosing” plus safe options is more truthful than a guessed cause.

Studying it

Resource queue, human input, protective wait, retry, and deadlock can compare no explanation, cause label, and actionable explanation on duplicate action, waiting, recovery, and wrong restart. Explanation accuracy needs audit. Long delays and shift handoffs reveal persistence problems.

Where it stops holding

Diagnosis evolves, so initial explanations should not pose as root cause. Protective waiting is distinct from ordinary processing. Sensitive detail can be role-gated. Brief pauses need no interruption, but task-specific thresholds should create an explicit blocked state.

Applying it

• Connect stall detection to a blocked-state model showing cause, awaited actor, attempts, and next update.
• Offer one safe action when the user can resolve it; otherwise expose wait, cancel, or escalation.
• Compare displayed cause with logged root cause under fault injection, counting duplicate commands, wrong restart, and ownerless blockage.

Related

• Same group: X3.05.1 Long tasks need visible progress rather than silent execution · X3.05.2 Remaining-time estimates support waiting decisions better than completion percentage alone · X3.05.4 Progress precision must match task predictability; false precision misleads
• Adjacent: X3.04 Failure and help-seeking · X4.08 Responsibility allocation
• Search terms: progress stall · blocked state · causal status explanation