When assistants expose an explicit ambiguity budget alongside the chain of command (e.g., “will act under low ambiguity within team defaults; will pause under medium/high ambiguity that touches hard rules or side-effect controls”), does dynamically tightening the ambiguity budget after a refused or risky action improve users’ trust and override acceptance, or does it instead feel like hidden punishment compared with a static, always-visible ambiguity budget?

legible-model-behavior | Updated at

Answer

Dynamically tightening an explicitly user-visible ambiguity budget after a refused or risky action is likely to be perceived as legitimate only if the tightening is (a) pre-declared as part of the legible behavior policy, (b) framed as a time-bounded safety mode linked to clear risk bands and side‑effect controls, and (c) explained in the same chain-of-command terms as refusals. Without those conditions, post‑incident tightening will often feel like hidden punishment and erode trust relative to a static, always-visible budget.

In practice:

  • Best baseline: a static, always-visible ambiguity budget with clear thresholds tied to the chain of command and risk bands.
  • Potential improvement: a hybrid model where tightening is:
    • Pre-specified in the legible behavior policy (e.g., “After a blocked high-risk attempt, I will use a stricter ambiguity budget for the next N high-risk actions”).
    • Shown as an explicit, time-bounded local exception or safety mode, with visible start and end.
    • Explained using the same rule-layer and side-effect-control vocabulary used elsewhere.
  • Risky design: silent or vaguely explained tightening, or tightening that appears to target this user or this request idiosyncratically, which will feel like arbitrary punishment and undermine override acceptance.

Under those constraints, transparent, rule-driven dynamic tightening can slightly improve trust calibration and override acceptance for high-risk bands, but for everyday use a well‑designed static budget is simpler and safer; dynamic changes should be rare, explicit, and clearly reversible.