Logical constraints require every related element to be visible; hiding any one defeats the inference

What it is

This principle adds the display condition to a logical constraint: users must be able to perceive the objects, slots, states, or used items involved in the inference. Hiding a set member, a remaining count, or a related state breaks elimination, and the interface degrades from “only one feasible action” to “guess from memory.”

Why it happens

Elimination requires the current set and the excluded set to be visible or held in working memory at once. A screen has no physical slot that prevents insertion, so pagination, collapse, permission masks, dialogs, and scroll regions force users to remember hidden members. Memory decay, interruption, and concurrent updates then destroy the relation. Visible does not mean everything permanently exposed; it means the deciding relation is perceivable at the decision point, or can be opened at low cost.

Studying it

Use controlled comparisons between a full relational view and obscured views of the same form or assembly task: show all candidates, hide the remaining count, collapse completed items, or delay state updates. Measure wrong choices, returns to earlier screens, external memory aids, interruption, and recovery time. Eye tracking or scroll logs can locate where users search for the missing relation.

Where it stops holding

Full visibility is not permanent exposure. Small screens, accessibility zoom, and complex enterprise data cannot spread every item at once; progressive disclosure remains useful when a clear entry point provides the relation at the decision point. Some secure workflows intentionally hide information. In those cases, logical constraint cannot protect the action and must be supplemented by confirmation, permission, or rule validation.

Applying it

• Show a relation summary at the action point, such as “3 attachments, 2 classified, 1 remaining without a format.”
• When completed items are collapsed, keep counts, types, and undo entry points; do not leave only an unexplained total.
• For multi-page flows, provide an expandable step diagram marking completed, available, blocked, and remaining branches.
• During walkthroughs, list every element participating in the current decision on each screen; if one is invisible without a low-cost entry point, mark the logical constraint as failed.

Related

• Same group: B2.22.1 Logical constraints arise from reasoning relationships among elements, as when the one remaining part must fit the one remaining place · B2.22.3 Natural mapping often supplies a logical constraint as a side effect, making the two hard to separate in design
• Nearby: B2.05 Constraints · B2.09 Discoverability
• Search terms: logical constraint · information visibility · progressive disclosure