When assistants expose both a visible chain of command and editable behavioral defaults, does explicitly labeling certain defaults as “suggested by the org” versus “purely personal” change how often users attempt overrides, and how they interpret refusals that cite higher-layer hard rules?

Answer

Yes. When assistants already expose a visible chain of command and editable behavioral defaults, explicitly labeling some defaults as “suggested by the org” versus “purely personal” reliably changes both (a) how often users attempt overrides and (b) how they interpret refusals that cite higher-layer hard rules.

Effects on override attempts

• Users attempt fewer overrides on defaults labeled as “suggested by the org,” especially when those defaults are framed as conservative or safety-oriented. The label signals alignment with higher layers in the chain of command, so users are less likely to spend effort fighting them and more likely to treat them as semi-hard rules.
• Users attempt more, and more targeted, overrides on defaults labeled as “purely personal.” These settings are seen as the legitimate place to customize behavior, which helps redirect override energy away from hard rules and toward tunable knobs (similar to the effects of visible local policies and exception mechanisms).
• Ambiguity about origin (no label) yields a mix: some users over‑treat unlabeled defaults as hard rules (lower, but frustrated, override rates), others assume everything is personal and repeatedly attempt overrides that will never fully succeed.

Effects on interpretation of refusals citing higher-layer hard rules

• When a refusal cites a higher-layer hard rule and the relevant default is clearly marked as “org-suggested,” users are more likely to attribute the refusal to the chain of command rather than to the assistant or their own settings, which increases perceived procedural fairness and acceptance of the refusal.
• When the same refusal follows from a context where users have tuned “purely personal” defaults, they are less likely to blame their own preferences for the refusal and more likely to see it as a legitimate boundary where their personal settings stop and non-overridable rules begin. This reduces the “fake control” feeling that arises when users think a default is fully under their control but discover hidden hard constraints only at refusal time.
• If defaults are not labeled by origin, refusals that reference higher-layer hard rules are more often interpreted as arbitrary or inconsistent, especially when users recall changing a related setting but do not see why it failed to affect the outcome.

Design implications

• Labeling defaults by origin (e.g., “Org safety default,” “Team norm,” “Your personal default”) should be integrated into the legible behavior policy and reused in refusal explanations. This reduces naive override attempts on org-aligned defaults and channels customization through clearly “personal” controls.
• To avoid users misreading “org-suggested” as a hard rule, UIs should make the hard-rule vs. default distinction explicit: for example, by visually distinguishing non-editable hard rules from editable org-suggested defaults and by using consistent language in override handling (“You can change this default, but this particular action is still blocked by an org hard rule above it.”).
• The combination of a visible chain of command, origin-labeled defaults, and standardized refusal rationales tends to lower confused or repeated override attempts, while improving users’ sense that refusals reflect stable, knowable policies rather than opaque assistant choices.