The current holder of control must be persistently visible

What it is

Whenever a shared object is in single-operator mode, "who is operating right now" must be shown as a persistent state — not a flash at handover, but a fixture on the interface until control changes hands. Shared-state attribution like this follows a general rule: when the ownership of a mode is not continuously visible, people cannot tell which one is in effect, and behavior goes wrong; applied to control, that means anyone can answer "who is driving" at any glance. This display is not decoration — it is the input to every decision a non-holder makes: whether to queue, how long to wait, whether typing does anything, and whom to find when something breaks.

Why it happens

Control ownership is a global state that can change at any moment, not always conspicuously: a handover can happen while you look down to type; a disconnect-reclaim can pass in seconds with no one noticing. If the state is announced only once at the moment of transfer, everyone joining afterwards (late, returning from another window, freshly connected) acts on a stale ownership model — addressing someone who already gave up the floor, sending input to a holder who no longer exists, or assuming nobody is operating and grabbing hastily. A persistently visible holder indicator drops the verification cost to zero: glance at the status strip and the model refreshes. It also disciplines the holder — with their name attached, operations are signed, both blunders and good moves are attributable, and this light sense of responsibility shapes operating behavior on its own. Placement and form decide effectiveness: a status buried in a menu is as good as absent; the working form is a persistent indicator in the same visual field as the operated object (shared-window border, tag next to the cursor, top-bar strip).

Where it stops holding

The intensity of persistence should scale with context. In high-frequency multi-party handovers, the indicator must be prominent and update instantly; in one-on-one remote assistance, both sides know who is who, and a muted display suffices — but never zero, because after a disconnect-reclaim, "nobody holds control" is itself a state that must stay visible. Granularity also decays with scale: small sessions show names, large ones show a role ("presenter holds") plus a count. Pure viewers (participants without operating rights) still need the holder information, because it does the attribution work of "why is the screen moving."

Applying it

• Show the holder (name or role) persistently at a fixed position in the same field of view as the shared object; mark the handover instant clearly (color change, brief highlight), then keep showing it.
• "No holder" (awaiting grant, mid-reclaim) is also a state — give it its own visible form rather than a stale leftover of the previous holder.
• Provide a reviewable timeline of holdings (who held what, when) for later tracing.
• Verification: pause the session at random moments and ask participants "who holds control now"; accuracy should approach perfect. The wrong answers will come precisely from those who missed the handover cue — proof that transfer-moment-only signaling is not enough.

Related

• Same group: V3.05.1 Scenarios allowing only one operator at a time need explicit control attribution · V3.05.2 Control handover needs request and grant as two independent actions · V3.05.4 Disconnecting holders need automatic control reclaim · V3.05.5 Forced seizure of control must leave a traceable record
• Nearby: V2.06 Editing Indicators · V3.04.4 Who follows whom must be visible to both sides
• Search terms: persistent visibility · floor holder indicator · mode awareness · shared state display