Default initiative should be conservative; users can opt into more autonomous behavior

What it is

Implicit features on a factory setting or a new account should stop at hint or suggestion, not execute. Higher autonomy is opt-in: opened after the user understands the consequence, not bundled under one master switch in the install wizard. A conservative default is not a crippled feature. It leaves execution on the human side until it is explicitly handed over.

Why it happens

Most people keep defaults. Setting the default at execute is an uninformed grant completed by inertia. Physiological implicit evidence is already invisible; default execute is a signature on an unknown cue. Opt-in puts the learning cost on people who actually want high initiative, and leaves everyone else at predictable low initiative. Grant granularity must face behavior: allowing “auto lights” is not allowing “auto-reply to messages.” One master switch binds autonomies of different cost; even a conservative default cannot hold that.

Studying it

Compare default-execute versus default-suggest plus opt-in, on conversion and regret. Factor: whether authorization copy names the concrete act. Outcomes: rate of keeping the default, disablement after opening higher initiative, surprise events. A forced choice in the install wizard (cannot proceed without picking) is not opt-in and should be coded separately. Long-run retention says more about whether the default was understood than first-day clicks.

Where it stops holding

If high initiative is an accessibility user’s only channel, a conservative default is a barrier; offer them one explicit, reversible high-initiative configuration rather than raising everyone. Safety-mandated automatic cutouts can keep an execute default but must be carved out of “convenience implicitness.” Opt-in on a child account should be completed by a guardian. An A/B test that only optimizes “autocomplete rate” will push the default toward execute and fight the conservative principle.

Applying it

• New accounts default to suggestion; execute needs its own permission that names the act.
• Forbid one “enable smart” switch from turning on several high-cost autonomies at once.
• A grant must be lowerable back to default at any time, effective immediately.
• Verify: with no settings changed after install, the system must not execute a user-perceptible high-cost act; that appears only after opt-in.

Related

• Same group: C9.12.1 System initiative can be graded; hint-only versus direct execution are different degrees of autonomy · C9.12.2 Higher initiative makes system behavior harder to predict and raises the cost of error · C9.12.4 The fitting initiative level for one function can differ by situation and should not be globally uniform
• Adjacent: C9.05 Implicit Interaction · C9.13 Informed Consent and Correction of Implicit Inferences
• Search: opt-in autonomy · conservative default · permission granularity