Two-Phase Action Commit

The rare actions that must span two coupled actuators atomically use a prepare-then-commit protocol with a safe abort on any failure.

L4 · Orchestration — its place in the stack (left, click any layer) and its internal components (right). Telemetry rises; control descends.

When one command is not enough

Most actions target a single actuator, but a few require two coupled changes to happen together or not at all, for example a coordinated adjustment of the burner's two end plugs, or a paired change to breeder coil currents that must move in step to preserve equilibrium. For these, Layer 4 uses a bounded two-phase commit so a partial application cannot leave the machine in an unsafe intermediate.

Prepare then commit

text

PHASE 1 PREPARE:
  ask each actuator adapter: can you reach setpoint X, within envelope+rate?
  each replies PREPARED (reserved) or ABORT
PHASE 2:
  all PREPARED -> COMMIT (both apply) 
  any ABORT / timeout -> ABORT all (release reservations, no motion)

Bounded and fail-safe

Unlike a generic distributed transaction, this protocol is used sparingly, has a hard timeout, and its failure mode is defined: on any prepare failure or timeout, nothing moves. It is not used on the fast L1 control loop; it coordinates the small set of supervisory setpoint changes that are physically coupled. A blocked or uncertain commit resolves to ABORT, the safe outcome.

Why not a saga here

Sagas suit long sequences where each step is independently safe and compensable.
Two-phase commit suits short, tightly-coupled pairs where an intermediate state is itself unsafe.
The two compose: a saga step may internally use a two-phase commit for a coupled pair.

Still fully gated

Both prepared setpoints pass the full gating pipeline before PREPARE, so a two-phase action is not a bypass of rules, envelope, or authorization; it only adds atomicity across two already-approved commands. The prepare, commit, and abort steps are all journalled to the lineage bus and are replayable.