Who currently holds control of an output needs to stay visible all the time, not just at handoff

What it is

Control authority identifies who or what currently determines an output: an automatic controller, a local field operator, a remote workstation, or a supervisory system. It needs to stay visible continuously, not just flash once at the moment of transfer, because the same command has completely different effect depending on authority — a setpoint written under automatic mode may be ignored or queued by the controller, while the same write under local manual mode may execute immediately and override a command another workstation just issued.

Why it happens

Authority is a state that changes over time, not a comparatively static attribute like a login role or permission level. Transfer, automatic recovery after a communications outage, and forced takeover triggered by protection logic can all change who holds authority without anyone deliberately acting. If the interface only pops a one-time notice at the moment of transition, an operator can easily forget the current state minutes later and keep acting on the pre-transfer model — believing they are issuing a manual command when the system already switched back to automatic, or assuming the automatic controller is still in charge when a communications failure has already handed authority to local protection logic. Continuous display turns authority from a one-off event into a state that can be checked at any time, keeping the operator's mental model synchronized with the system's actual state.

Where it stops holding

A complex system is rarely a single global automatic/manual choice; authority can be assigned per loop or per subsystem, and having some loops automatic while others are manual on the same unit is normal. A single global label oversimplifies this and hides exactly the loops whose authority state most needs attention. Continuous visibility also solves "who knows who is in control," not "who should be allowed to control" — visibility cannot substitute for permission enforcement, and displaying authority is not a reason to relax technical limits on unauthorized action.

Applying it

An authority change should not stay only on the workstation that triggered it; it must also reach a shared team overview, or different workstations will hold contradictory beliefs about the same loop — field staff thinking they hold control while the control room still believes it is automatic.

• Show, beside every controlled object, the current authority holder, the source of the most recent command, the time of the last transition, and any pending command not yet in effect.
• Keep the presentation of authority consistent across workstations and levels — not one icon set in the control room and another on a field handheld.
• How to check: stage an unannounced automatic switch and a recovery from a communications outage, and test whether operators can correctly predict, from the display alone and without relying on memory, whether a command they issue right now would actually take effect.

Related

• Same group: Y3.09.2 Setpoint bump during transfer · Y3.09.3 Manual-side tracking before takeover · Y3.09.4 Frequent mode switching as a diagnostic signal
• Nearby: Y3.02 Automation mode confusion · Y4.07 Emergency reach and inadvertent-activation protection
• Search terms: Continuous control-authority indication · process control interface · industrial human factors