When ambiguity arises about user intent or consent, do assistants that first apply a user-visible ‘ambiguity resolution policy’ (e.g., “default to safest plausible interpretation”) and only then invoke hard rules lead to higher perceived fairness and lower frustration than assistants that invoke hard rules immediately without exposing any ambiguity-resolution step?

Answer

Assistants that surface a brief, user-visible ambiguity resolution policy before (or alongside) hard-rule application generally achieve higher perceived fairness and modestly lower frustration than assistants that jump straight to hard-rule refusals without acknowledging ambiguity—provided the policy is simple, clearly framed as user-protective, and consistently applied.

Key effects compared to “hard rules only, opaque ambiguity handling”:

• Perceived fairness: typically higher

  • Users see a two-step, principled process (“I first interpreted your request conservatively because consent was unclear; then an org privacy rule also applies”) rather than a single opaque “no”. This mirrors fairness gains from visible chains of command and labeled rule rationales (c38–c42, c28–c32).
  • Explicitly naming the ambiguity step (“I’m treating this as ambiguous consent and choosing the safest option”) signals that the assistant considered alternatives instead of reflexively blocking, which users interpret as more procedurally fair even when the outcome is the same.

• Frustration: generally modestly lower over time, with some short-term tradeoffs

  • In the moment, a short ambiguity explanation adds a bit of friction, but it reduces repeated attempts and “why won’t you just do it?” loops that arise when users don’t realize the assistant is reacting to perceived ambiguity.
  • Making the ambiguity policy visible also gives users a concrete way to adjust future behavior (e.g., “Oh, I need to give explicit consent or clarify the recipient”), reducing chronic frustration from recurring refusals for similar reasons.

Design conditions for the benefit to hold:

• The ambiguity resolution policy must be:
  • Very compact (label + one short sentence), so it doesn’t feel like lecturing or significantly extend task time (aligned with c38–c42 on efficient explanations).
  • Positioned as a preference-like default, not a new hard rule (in line with c1, c2, c5): users should understand that clearer instructions or explicit consent can override the conservative interpretation, subject to the existing hard rules.
  • Semantically consistent with other visible policy elements (e.g., chain of command, side-effect controls), or users may treat it as an arbitrary extra hurdle.

Failure modes:

• If the ambiguity step is verbose, inconsistent, or appears to be used opportunistically to justify hard-rule refusals, it can increase frustration and be perceived as cosmetic justification on top of the same opaque constraints.
• If users cannot see any way to resolve the ambiguity in future interactions (no guidance like “To proceed, please explicitly confirm X”), the visible policy becomes a dead end and does not deliver the expected trust or fairness gains.

Overall, surfacing a minimal, user-visible ambiguity resolution step before applying hard rules helps users distinguish between “I wasn’t clear enough” and “this is disallowed regardless,” which improves procedural fairness judgments and reduces repeated, frustrated override attempts compared to systems that only expose a hard-rule refusal without acknowledging the ambiguity decision that preceded it.