When assistants show a compact ‘chain-of-command trace’ for each non-trivial action (e.g., “allowed because: org rule A + your project policy B + default C”), does this per-action trace improve users’ mental models and reduce incorrect override attempts more than showing the same rules only in a static behavior-policy page?

Answer

Per-action chain-of-command traces usually improve users’ mental models and reduce incorrect override attempts more than showing the same rules only on a static behavior-policy page, provided the traces are compact, selectively shown for non-trivial actions, and consistently reuse the same rule labels as the static policy.

Reasoning and conditions:

• Mental models

  • Inline traces turn the abstract rule hierarchy into concrete, repeated examples (“this action was allowed because of org rule A + project policy B + your default C”), reinforcing how hard rules and defaults interact in practice. This mirrors how visible chains of command, labeled defaults, and action budgets help users attribute outcomes to specific layers rather than to arbitrary assistant choices (c18, c19, c20, c21; c28, c29, c30, c31).
  • Because each non-trivial action carries a short explanation, users see patterns across actions (e.g., org rules always appear at the top, personal defaults at the bottom), which sharpens their mental model more effectively than a one-time read of a static page.

• Incorrect override attempts

  • Incorrect overrides—where users try to change a default or setting that cannot affect the outcome because a higher-layer hard rule governs it—tend to drop when each constrained or allowed action explicitly cites the governing hard rule and any subordinate defaults. This is analogous to how visible origin labels on defaults redirect overrides toward the right layer (c28, c29, c30, c31, c32) and how explicit justifications for rejected overrides reduce repeated, misdirected attempts (c111, c112, c113, c114, c115).
  • Static behavior-policy pages alone are easy to misremember or ignore; users often revert to trial-and-error overrides. Inline traces at the moment of action provide immediate feedback about where an override would need to apply (e.g., "blocked by org rule X; your project policy already allows this"), which discourages futile attempts to change local settings when only higher-layer rules matter.

• Interaction with static behavior policies

  • The best outcomes come from combining a simple static policy page (for orientation) with per-action traces that reuse the same names and labels for rule layers, defaults, and side-effect controls. The static page teaches the vocabulary; the traces instantiate it. This pairing supports legible behavior policies without overwhelming users.
  • If per-action traces use different terminology or omit key layers that appear on the static page, they can create confusion and potentially increase override attempts, similar to the problems caused by mismatches between visible policies and actual constraints (c143, c144, c145, c146).

• Design constraints

  • Traces should be compact (e.g., 1–2 lines, with an optional “details” affordance) and reserved for non-trivial actions—those involving side-effect controls, safety-relevant constraints, or notable use of local policies—to avoid habituation and cognitive overload.
  • Refusals and constrained actions benefit most from traces that explicitly name the blocking hard rule and any relevant local policies, aligning with evidence that citing the chain of command and offering clear rationales improves fairness and acceptance (c186, c187, c188, c189; c176, c177, c178, c179, c180).

Net: When carefully designed and aligned with a legible static behavior policy, per-action chain-of-command traces are likely to produce more accurate mental models and fewer incorrect override attempts than static policy pages alone, because they repeatedly ground the abstract rule hierarchy in concrete decisions at the moment users care about them.