L4.05.3partial completion must be explicitdesignresearch

A partially completed state must be made explicit

Aliases: partial agent state · wreckage inventory · what is true after abort

What it is

After abort or failure, a task rarely returns to the start. The world sits in an intermediate: some objects changed, some not, some halfway. Partial completion must be explicit requires the UI to account for that intermediate with a checkable list, not to flatten the differences under a percentage or a “cancelled” badge.

“Cancelled” is a process state. “Mail three went, mail four did not, the draft is still there” is world state.

Why it happens

What a person needs in order to choose rollback, finish, or accept is each object’s current value, not a task-level label. The agent’s internal “cancelled” means nothing to an external inbox, a filesystem, a permission service. If the UI only syncs the internal label, people act as if nothing happened, then hit the part that did. This is not progress visibility: progress visibility is for following while it runs; this is accounting for wreckage after it stops.

An inexplicit intermediate also lets the next agent run take wreckage as new input, repeating or overwriting.

Studying it

Abort halfway, compare three presentations: “cancelled” only, a percentage, an object-level list (each item: untouched / done / half / already in effect outward). Dependent variables: whether the person’s next choice matches the real world, how often they repeat an act they thought had not happened, whether they can point at items that need cleanup. Independent variables: whether the list distinguishes internal from external, how half-done is shown.

Use the external system as ground truth. Count of mismatches between product copy and ground truth is the primary endpoint.

Where it stops holding

An atomic act that either fully commits or fully does not has no partial. If rollback has already taken the world back to the start, the intermediate is gone and this entry is idle for a moment — but residue left by a failed rollback still has to be stated. How steps are shown while running is not here. Whether an escalation should attach a cleanup request is a reporting question.

Applying it

  • After abort, failure or timeout, force an object list: current value of each, whether it has taken effect outward, whether it can still be rolled back. A task-level badge can be a title, not the only account.
  • “Half” must land on an observable fact (the file wrote the first half, the mail sits in outbox unsent). A progress bar is not a substitute.
  • Check: after abort, put the product away and give the operator only this list to verify against the external system. Every mismatch is an intermediate that was not made explicit. Then leave a half-written file on purpose and see whether the list marks it on its own — if not, a task-level label is still doing the lying.

Related

  • Same group: L4.05.1 Long tasks must be stoppable at any time · L4.05.2 Steps already executed must be rollable back
  • Nearby: L4.13 Agent Failure Reporting and Escalation · L4.08 Visibility of Task Progress · L4.12 Task Progress and Intermediate-state Visibility
  • Search terms: partial completion · intermediate state · abort

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/L4.05.3