Batch confirmation needs an inspectable list; a count is not enough to judge

What it is

When many objects move at once, a confirm that only reports “12 files will be deleted” or “48 customers will be mailed” cannot tell whether the twelve contain one that should not be touched. A count is scale, not content. Batch confirm needs an inspectable list: every item can be seen, opened, taken off, and the person does not have to read the whole set once to spot-check.

“12” can even be the right length on the wrong set. A count checks length, not membership.

Why it happens

Working memory will not hold a dozen names, and reading every item turns confirm into a second working day. Spot-check is the compromise: the list is there, people scan for anomalies by heuristic (an unknown name, the wrong domain, a bad date) and can take those items off. Without a list the heuristic has nowhere to land, and people make an attitude judgement on the count — 12 sounds reasonable, so release. The instance rule is enough for a single item; a batch has to turn instances into a scrollable, filterable, deselectable set, or the instance is eaten by a numeric summary.

An uninspectable “see details” behind a second click equals no list: people in fatigue will not click.

Studying it

Plant several anomalous items in a batch, compare: count only, first three names truncated, a full filterable list, a list folded by default. Dependent variables: share of anomalous items taken off, time to spot-check, whether anyone opens the list. Independent variables: whether search exists, position of the anomaly (front / middle / back), whether the count is visually loud.

Finding anomalies still in the middle and back is what makes it inspectable. Finding only the first three is truncation, not a list.

Where it stops holding

Two or three items is not a batch; list them directly. If objects have no distinguishing field, filtering will not help — give a recognisable instance first. A count may be a title; it must not replace the list. Fatigue should be cut by grading how often you ask, not by hiding the list to cut reading — hide it, and batch confirm is spent.

Applying it

• Batch confirms expand the list by default, with search and deselect. The count sits in the title; the list is the judgement surface.
• Any item can be taken off before release; the count must follow, so it does not look changed while the set is not.
• Check: put an anomalous item in slot eight and see whether it is taken off. If the middle and back are always missed, the first three are still standing in. Fold the list by default and measure open rate — near zero, and the second click has cancelled the spot-check.

Related

• Same group: L4.11.1 Confirmation should show the concrete objects that will be affected, not just the action category · L4.11.3 Confirmation fatigue strips high-frequency confirms of their protection; confirms must be graded by consequence · L4.11.4 Reversible acts are cheaper overall if post-hoc undo replaces pre-action confirm · L4.11.5 Outward acts should be treated as irreversible even if they can be deleted later
• Nearby: L4.07 Pre-action Confirmation · L3.01 Generating Multiple Options · L4.06 Permission Boundaries of Agents
• Search terms: batch confirmation · inspectable list · spot check