When an assistant must resolve ambiguous instructions that could trigger side effects (e.g., “clean up these files” or “notify the team”), how do three different, user-visible ambiguity-resolution policies—(a) ‘always ask before acting’, (b) ‘act conservatively within a narrow default scope’, and (c) ‘act broadly but summarize and allow quick rollback’—compare in terms of user trust, perceived fairness, and override attempts in real workflows?

Answer

(a) “Always ask” tends to maximize perceived safety and procedural fairness but lowers trust in the assistant’s autonomy for routine tasks and increases friction; override attempts are low but users more often relax the policy if allowed. (b) “Conservative narrow scope” usually gives the best overall trust–efficiency tradeoff: users see the scope as a stable default, accept most actions, and reserve overrides for scope changes; fairness is high if scope and hard limits are clearly shown. (c) “Broad + summarize + rollback” can feel powerful and efficient to expert users but harms trust and fairness if rollbacks are imperfect or side effects are hard to see; override attempts shift toward tightening future behavior or disabling autonomy after bad surprises.

In real workflows:

• For high-risk or multi-user side effects (org notifications, repo-wide edits), (a) or (b) with visible scope and hard-rule labels tends to sustain trust and fairness better than (c).
• For low-risk, easily reversible tasks, (c) can work well if summaries are clear and one-click rollback is reliable; otherwise, (b) is a safer default with optional per-task upgrades toward (c).