If an assistant must refuse a user request due to a side-effect control, does presenting a short menu of policy-consistent alternatives (e.g., safer scopes or time-bounded variants) increase perceived fairness and acceptance of the refusal compared to providing only an explanation tied to the legible behavior policy?

Answer

Yes, presenting a short menu of policy-consistent alternatives alongside the refusal generally increases perceived fairness and user acceptance of the refusal compared to giving only a policy-based explanation, as long as (a) the alternatives are clearly within the same hard-rule constraints, (b) the menu is short and easy to scan, and (c) the refusal still names the specific side-effect control in the legible behavior policy.

More specifically, relative to explanation-only refusals:

• Perceived fairness

  • Users more often interpret the refusal as procedurally fair when they see the assistant actively search for what is allowed under the same side-effect controls (e.g., “I can’t edit all folders, but I can edit within this project or for the next 30 minutes”). This matches patterns where real, testable local control and exceptions increase fairness (c186, c187, c188, c189; c176, c177, c178, c179, c180).
  • Fairness is highest when the alternatives are explicitly framed as constrained by the same chain of command and hard rules that caused the refusal, so users attribute both the “no” and the “but I can…” to consistent rule application rather than arbitrary leniency.

• Acceptance of the refusal

  • Offering concrete, policy-consistent alternatives typically raises acceptance of the original refusal, because users can still make progress without feeling stonewalled; this is similar to how local policies and action budgets turn hard limits into manageable trade-offs (c186–c189; c176–c180; c139–c142).
  • Acceptance drops if alternatives appear cosmetic (e.g., obviously useless variants) or if they seem to contradict earlier explanations of the side-effect control, which users experience as fake control.

• Design constraints

  • The alternative menu should be small (e.g., 1–3 options) and clearly labeled by scope or duration to avoid cognitive overload and preserve the clarity of the refusal.
  • Each alternative should be explicitly tied back to the same side-effect control layer (e.g., “Within your org’s data policy, I can instead…”) so that users do not infer hidden, arbitrary exceptions.

Overall, compared with explanation-only refusals, a short, clearly constrained alternative menu tends to improve both perceived fairness and willingness to accept the refusal, provided the alternatives are genuine, visibly rule-consistent options rather than workarounds that undermine the legible behavior policy.