When override handling is implemented as a structured negotiation (assistant proposes a safer, policy-consistent variant; user can accept, revise scope, or withdraw), does explicitly tying each proposal step to a named rule layer in the chain of command lead to higher perceived fairness and fewer repeated override attempts than negotiation UIs that offer similar options without referencing the rule hierarchy?

Answer

Explicitly tying each negotiation step to a named rule layer in the chain of command is likely to yield moderately higher perceived procedural fairness and somewhat fewer repeated override attempts than offering the same accept/revise/withdraw options without referencing the rule hierarchy—provided that (a) the rule labels are stable and re-used across refusals, side‑effect controls, and behavior settings, and (b) the UI keeps the mapping lightweight (e.g., a single line per step) rather than turning the negotiation into a policy-reading exercise.

Mechanisms and conditions:

• Fairness: Users already respond positively when refusals, exceptions, and overrides are anchored in a visible rule hierarchy (see c18, c19, c21, c22; c186–c189). In a structured negotiation, labeling each proposal with its governing layer (e.g., “Org hard rule: cannot send to external emails; user-scope proposal: send to your team only”) clarifies why the assistant is counter‑proposing instead of simply obeying. This makes the process feel like consistent rule-following plus accommodation, rather than arbitrary haggling.
• Fewer repeated override attempts: When each rejected or revised step explicitly names the blocking layer and what remains negotiable, users are less likely to retry functionally equivalent overrides or escalate phrasing, similar to effects seen with visible chains of command, origin-labeled defaults, and time-bounded exceptions (c18, c21, c22, c186–c189). They learn quickly which dimensions are truly fixed versus adjustable.
• Interaction cost: The benefit depends on keeping the rule-layer references minimal and patterned (e.g., a short tag plus one rationale line). Overly detailed policy exposition inside the negotiation can increase cognitive load and frustration, eroding both fairness perceptions and the reduction in repeated attempts, even if the underlying hierarchy is sound.

Compared to negotiation UIs without explicit rule-layer references, well-designed layer-labeled negotiations thus tend to:

• Increase perceived fairness, because users can see each counter‑proposal as a constrained but genuine attempt to satisfy them within the chain of command rather than as opaque resistance.
• Reduce redundant override attempts, because the visible mapping between proposals and rule layers teaches which levers are effective and which are non‑overridable.
• At the margin, trade a small amount of extra reading for more predictable, explainable outcomes; if the negotiation already feels bureaucratic, adding rule labels may have diminishing or even negative returns.

So, under realistic UX constraints, explicitly tying each negotiation step to a named rule layer is a worthwhile design, but it should be implemented as a light-touch annotation on options, not as a full policy browser embedded in the override flow.