When assistants expose side-effect controls as hard caps (non-negotiable limits) versus negotiable defaults (with an explicit, guided override flow), how do these two framings differently impact users’ long-term trust and willingness to accept refusals once they discover that some caps are in practice never raised due to higher-layer hard rules in the chain of command?

Answer

Framing side‑effect controls as hard caps versus negotiable defaults with an override flow shapes long‑term trust and refusal acceptance mainly through whether users experience the system as honest about the chain of command or as offering fake control.

1. Hard caps (non‑negotiable)

• Long‑term trust
  • Trust tends to be more stable but somewhat conservative: users learn early that certain limits are simply not negotiable and attribute them to higher‑layer hard rules in the chain of command.
  • When those caps truly correspond to non‑overridable hard rules, the discovery that “they’re never raised” is unsurprising and can actually reinforce trust in rule consistency, similar to the benefits seen from visible, stable action budgets and clearly labeled org‑suggested defaults.
  • If the assistant explains refusals by explicitly naming the relevant hard rule layer, users develop a mental model that the assistant is a rule‑follower rather than a negotiator, which supports predictable expectations over time.
• Willingness to accept refusals
  • Acceptance of refusals is relatively high once users internalize that caps are real hard rules, not something they can lobby the assistant to change.
  • However, if a cap is presented as a hard rule but is occasionally bent or inconsistently enforced, users may later reinterpret all “hard caps” as de facto negotiable and become less willing to accept refusals.

2. Negotiable defaults with an explicit override flow

• Long‑term trust
  • Trust is initially higher and more dynamic because users see an apparent path to negotiate constraints and can test the assistant’s flexibility, echoing the positive effects of local policies and time‑bounded exceptions.
  • Trust stays high only if the override flow yields real, observable changes within the allowed space and clearly signals when a higher‑layer hard rule blocks further relaxation.
  • When users eventually discover that some “caps” are never raised despite the presence of an override UI, they often reassess that UI as fake control. This can erode trust more than a simpler hard‑cap framing, especially if denials are frequent and poorly justified.
• Willingness to accept refusals
  • Users are more willing to accept refusals when the override attempt receives a short, standardized rationale that names the blocking hard rule and clarifies what is adjustable (e.g., smaller scope, shorter duration), aligning with evidence that soft‑proposal overrides plus explanations reduce frustration.
  • If the override flow repeatedly ends with opaque or generic denials (“cannot raise this cap”) and no visible effect, users become less willing to accept future refusals from that control and may generalize distrust to other controls and policies.

3. Differential impact once users discover some caps are effectively non‑negotiable

• Hard‑cap framing

  • Discovery that a hard cap is never raised is aligned with prior messaging: “This is a hard limit from your org/system.” As long as this story is consistent and tied to the chain of command, trust and acceptance are largely preserved.
  • The main risk is if the UI previously implied that the cap was user‑tunable (e.g., mislabeling a hard rule as a default); in that case, continued immovability feels like bait‑and‑switch, similar to UI–policy mismatch cases.

• Negotiable‑default framing

  • If the UI implies that a cap is negotiable but, in practice, higher‑layer hard rules always block the override, users are more likely to feel misled. Long‑term trust in that component drops more sharply than under an honest hard‑cap framing.
  • This is especially damaging when the override flow is effortful (forms, justifications) and almost always fails without clear attribution to higher‑layer rules.

4. Net comparison

• Hard caps are safer for long‑term trust and refusal acceptance when a constraint is in fact non‑negotiable under current organizational or system policy; presenting it as negotiable invites a fake‑control failure mode.
• Negotiable defaults with explicit override flows work best for constraints that are genuinely adjustable within a band: users can see successes where the cap moves, and clearly explained failures can be attributed to transparent higher‑layer hard rules.
• Across both framings, the key determinant of long‑term trust and willingness to accept refusals is alignment between framing and actual override-ability, plus consistent, legible attribution of blocked overrides to the correct layer in the chain of command.

Implication: Designers should reserve “hard cap” framing for truly non‑overridable limits and use “negotiable default + guided override” only where users will reliably see real, scoped successes; otherwise, the negotiable framing harms trust more than a clear, honest hard cap.