Confirmation should show the concrete objects that will be affected, not just the action category
Aliases: instance-level confirm · not “these files” · recognition not class attitude
What it is
A confirm that says “delete these files” or “send mail to customers” is a nod at a category. The one in the category that should not be touched is not handed over by the category label. Confirm shows instance not category requires affected objects to appear as openable concrete items: a filename, a recipient address, an order number — not “files,” “customers,” “selected items.”
“These” is a demonstrative, not an object. The object is Q3-forecast.xlsx.
Why it happens
A category launches an attitude toward that class of act: delete files, I know what that means. An instance launches recognition: is this the one I mean. Recognition is what pulls the wrong copy out of the right pile. Confirm-as-judgement’s minimum material asks for object and consequence; this steps one layer down: the object must be an instance. Writing “files” still counts as having an object column, but if the column has nothing recognisable the column is empty.
When a batch is large there will be many instances — that is whether the list can be inspected. For a single item or a few, there is no excuse to stop at the category.
Studying it
Hold the same delete, compare category copy (“delete 3 files”), a list of names, names plus preview. One of them should not be deleted. Dependent variables: rate of catching that one, decision time, whether filenames can be recalled after release. Independent variables: whether names are visible, whether they can be opened, whether a category count appears.
The primary endpoint is catching that one, not satisfaction with the confirm.
Where it stops holding
Objects without a stable name (a temporary blob, a stream) need a recognisable stand-in: a thumbnail, the first lines, a readable form of a hash — still an instance, not a category. When the count will not fit the dialog, do not fall back to category; switch to an inspectable list. How consequence is written, and whether reversible acts should move to undo, are not here.
Applying it
- The object column on a confirm allows only instances: names that open. A count may summarise; it may not be the object column’s only content.
- Words like “selected items,” “these records,” “customers” in the object column count as unfinished; do not light release.
- Check: plant one item that should not be touched among three, and write only the category in the object column. If that one is almost never taken off, you are still on the category. Switch to filenames and measure again — if it is then taken off, the gap was the instance.
Related
- Same group: L4.11.2 Batch confirmation needs an inspectable list; a count is not enough to judge · 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 · L1.05 Human in the Loop · L4.06 Permission Boundaries of Agents
- Search terms:
instance-level confirmation·recognition·pre-action confirmation
Cards in the same group
- L4.11.2Batch confirmation needs an inspectable list; a count is not enough to judge
- L4.11.3Confirmation fatigue strips high-frequency confirms of their protection; confirms must be graded by consequence
- L4.11.4Reversible acts are cheaper overall if post-hoc undo replaces pre-action confirm
- L4.11.5Outward acts should be treated as irreversible even if they can be deleted later