Split observations from commands in a game-oriented BP semantics

The user’s concern that BP conflates events and commands is substantive. Classical BP deliberately uses one alphabet Σ #PBEYQU b-threads request and block labels, enabled labels are requested minus blocked #EX4TXE and a run is a sequence of selected/triggered labels #YCEFVW At the system boundary this makes a label ambiguous: the C++ example has a sensor thread translate an already-occurring physical input into a requested CoinInserted BP event #2K6PUU while an actuator waits for selected ProvideProduct and then performs the physical action #CSWC43 For a game-oriented coroutine BP, use a typed causal vocabulary: (1) Observation/fact—uncontrollable, injected from physics/input, broadcast and never blockable; (2) Proposal/intent—a controllable candidate requested by behaviors; (3) Decision/commitment—the scheduler’s selected proposal; (4) Outcome—uncontrollable completion/failure observation from execution; optionally (5) internal coordination signal. Formally partition Σ = Σ_u ⊎ Σ_c. Blocks apply only to Σ_c; external observations in Σ_u first advance interested b-threads, then the scheduler selects controllable proposals. Example: DeployPressed [OBSERVATION] -> DeployGlider [PROPOSAL] -> DeployGliderCommitted [DECISION] -> GliderOpened or DeploymentFailed [OUTCOME]. This preserves BP composition and trace semantics while making causality and authority explicit.