Bounds on system initiative need to be user-settable

What it is

Once an implicit system starts acting for someone, there has to be a boundary the user can actually reach: which sensing may run, and how far counts as overreach. That boundary is not an engineer’s frozen default. It is settable—off, narrowed, swapped by place. Implicit interaction without a settable bound is a permanent grant of a life trajectory to the system.

Why it happens

After the symbol layer of input is removed, people cannot refuse by “not issuing a command.” Refusal needs a separate meta-control: scope of permission, a time window, a place window. Acceptability moves with social setting: auto-lighting at home can be fine; volume that follows breathing in a meeting is not. If the bound exists only in a privacy policy, with no runtime control surface, the only way to say “this far” is to pull power. Settable does not mean an expert slider per sensor; it requires at least one “stop” and one “suggest, don’t do” in ordinary language. The bound must also resist feature creep: when a new inference ships, the old grant must not silently cover the new behavior.

Studying it

Treat “runtime-adjustable bound present or absent” as a factor and watch disable rates, place switching, and repair after overreach. Scene cards (home / office / public) where people mark allowed implicit behaviors yield an acceptability set to compare with product defaults. Diary methods are more sensitive than a single lab session: a default that is harmless on day one misfires in front of a guest on day three. Measure time-to-find the bound control; unfindable equals unsettable.

Where it stops holding

Some accessibility users treat implicitness as their only channel; a master off-switch is deprivation. They need narrowing, not solely all-or-nothing. Bounds on a child account should be set by a guardian and protected from being dismissed inside a game flow. Legally required minimum sensing (some safety alarms) may omit an off control, but it must be carved out of “implicit convenience” and labeled on its own. Settable bounds also do not fix wrong inferences—that is a separate correction problem.

Applying it

• Before the system acts implicitly the first time, offer permission in everyday language: watch / suggest / do-for-me, and allow closing by room or calendar.
• Re-ask when a new inference or data source ships; do not reuse the install-time grant.
• Make “don’t take initiative tonight” a control at the same rank as brightness, not nested in settings.
• Verify by asking a new user to silence implicit action when a guest arrives; time whether that completes in a minute, and whether any UI still changes afterward.

Related

• Same group: C9.05.1 Implicit interaction does not require the user to issue an explicit command · C9.05.3 Users often have no way to correct a wrong implicit inference
• Adjacent: C9.12 Implicit Interaction and System Initiative · C9.13 Informed Consent and Correction of Implicit Inferences
• Search: initiative boundary · user-settable permission · implicit interaction control