Actuator Command Arbitration

When multiple controllers request the same actuator, L1 arbitrates by fixed priority so protection always outranks optimization.

The contention problem

An actuator can be the target of several requests: the fast stability loop, the MPC trajectory, and a protection action may all want a PF coil or a beam at once. L1 resolves this with deterministic arbitration — a fixed, inspectable priority that decides which request reaches the driver, with no ambiguity and no data-dependent ordering.

Priority order

• 1. Hardware failsafe / interlock: absolute, cannot be overridden.
• 2. Fast protection loop (e.g. disruption avoidance, quench response).
• 3. Fast stability loop (vertical/radial position, plug density).
• 4. MPC advisory trajectory (shape, DEC schedule optimization).

The order encodes the architecture's values: safety before stability, stability before optimization. A protection action pre-empts any optimization instantly; an MPC setpoint is honored only when nothing more urgent is asserting. Because the priority is static, arbitration adds a fixed, tiny latency and never a variable one.

Clean handover

Arbitration must not cause transients. When a higher-priority source takes over, the driver's inner loop bumplessly transfers from the previous command, and when control returns, the lower-priority source resumes from the current state rather than a stale target. This prevents the actuator from stepping when authority changes hands.

Auditability

Every arbitration outcome is timestamped to the L2 archive: which source held authority, when, and why it changed. This record makes the machine's behavior reconstructable after the fact. Arbitration sits below the interlock layer — interlocks decide whether any action is permitted at all, arbitration decides which permitted request wins — and above the drivers that execute it.