For autonomous actions with potential side effects (file edits, notifications, purchases), how does explicitly marking certain behaviors as ‘non-negotiable defaults’ versus ‘user-tunable defaults’ in the visible behavior policy change users’ willingness to pre-authorize actions and their reactions when the assistant refuses or rolls back an action?

Answer

Explicitly marking behaviors as ‘non‑negotiable defaults’ versus ‘user‑tunable defaults’ in a legible behavior policy generally increases willingness to pre‑authorize actions that sit under user‑tunable defaults, while making users more accepting—but sometimes more strategically cautious—about refusals and rollbacks driven by non‑negotiable defaults.

Effects on willingness to pre‑authorize side‑effectful actions

• Users are more willing to pre‑authorize actions when:
  • The policy clearly labels the relevant rules as user‑tunable defaults (e.g., “auto‑apply small file fixes within this folder” or “send low‑priority notifications without asking”) and shows that they can later tighten these settings.
  • The chain of command makes it clear that pre‑authorization cannot accidentally override higher‑layer hard rules (system/org), reducing fear of “signing a blank check.”
• Users are less willing to broadly pre‑authorize actions governed by visible non‑negotiable defaults, but more willing to grant narrow, scoped pre‑authorizations inside the allowed space (e.g., pre‑authorizing only reversible file edits or capped purchases) because they understand that hard rules and budgets still constrain worst‑case outcomes.

Reactions to refusals and rollbacks

• When a refusal or rollback is tied to a labeled non‑negotiable default:
  • Users are more likely to interpret it as rule‑following rather than the assistant being unhelpful, similar to how visible chains of command and budgets reduce perceived arbitrariness.
  • Frustration is front‑loaded: users may dislike the constraint but are less surprised when it triggers, and they direct complaints toward the owning layer rather than treating the assistant as capricious.
• When a refusal or rollback is tied to a labeled user‑tunable default:
  • Users are more likely to respond by adjusting settings or proposing scoped exceptions than by repeatedly re‑issuing the same command, because they can see that the behavior is governed by a preference they control.
  • If the assistant rejects an attempted tuning (because it would conflict with a hard rule) and explains this in the same vocabulary, users more readily accept that some limits are genuinely non‑negotiable.

Net result

• Clear, visible separation between non‑negotiable and user‑tunable defaults tends to:
  • Increase pre‑authorization for actions that are clearly preference‑governed and reversibly bounded.
  • Make refusals and rollbacks less surprising and more tolerable, especially when they are consistently attributed to the correct rule layer.
  • Reduce “fake override” frustration, because users see from the outset which defaults they can actually relax and which behaviors are protected by higher‑priority, non‑editable rules.