The system needs to distinguish participants from third parties who are merely passing through

What it is

Keeping bystander motion out of commands and bystander pixels out of storage both first need an answer: is this body on stage a participant or a third party passing through. Misclassify, and filtering and privacy policy both plug into the wrong pipe. This is not identifying among two people already engaged; it is the line between “using” and “only passing.” The line should rest on observable engagement evidence (facing, dwell, an enter action), not on a later judgment of whether they look like someone who would gesture.

Why it happens

Participants usually face the device, have near-zero speed, stay in the interaction volume, and have performed an enter action. Passers-by have a crossing trajectory, face the aisle, dwell briefly. Speed and facing can cut obvious crossings first. The hard case is “standing beside, watching”: speed zero, maybe facing the screen, no enter. Label that third party as participant and their hair-smoothing becomes a command; label every still body as passer-by and a true user is dropped the moment they plant their feet. Enter action, or a combination of dwell plus facing, has to count as engagement evidence; companions stay third-party until they enter themselves. The class must update continuously: a participant who walks away becomes third-party; a passer-by who stops and enters is promoted.

Studying it

Label every body on stage as participate / accompany / cross. Classify from facing, speed, dwell in volume, and whether an enter action occurred. Report both errors: companion labeled participant, participant labeled crossing. Script “one operates, one stands watching, one walks through.” Do not substitute a face-to-face two-operator task—those are both participants. Vary camera height and crowd density to see when facing estimates fail.

Where it stops holding

On a machine used in a queue, the next person stands still for a long time before becoming a participant, and is easily labeled companion or participant; that needs a queue mode. Child companions and child users are close in size; an enter action scaled for adults will leave child users as third-party for a long time. A headset wearer is almost always a participant and people in the outward camera almost always third-party; hardware simplifies the class. Facing estimates degrade in the dark; lean more on enter action than on which way the face points.

Applying it

• Keep a participant / third-party tag on each tracked body, default third-party, promote only on enter evidence.
• Both commands and outbound data should read this tag; do not write separate heuristics for each.
• Accept a three-person script: operate, accompany, cross. The companion’s hand must not fire; the crossing must not enter outbound imagery; the operator’s hand must still work. One body wrong is a classification failure.

Related

• Same group: C4.30.1 Actions of bystanders in the capture range should not be treated as user input · C4.30.2 Bystander appearance and motion data also constitute privacy collection and need a handling policy · C4.30.4 Capture notices aimed at bystanders should be more conspicuous than those for users, because bystanders did not initiate the interaction
• Adjacent: C4.17 Input attribution and multi-user arbitration · C4.15 Conditions for entering engagement
• Search: participant · passerby · engagement gate