batchLever

§4.4.5 — declare that a group of already-declared levers must be written as one act.

The element's ordering rule (decreases before increases) keeps the common case feasible at every intermediate point, and that is not the same as atomicity: between two writes a joint constraint can be momentarily violated, and a model that observes itself mid-action can see it. batchLever is the escape hatch for the cases where that matters. The library cannot provide atomicity itself — the writes have synchronous consequences inside the model, so buffering them under a lock would not help — so the model author supplies the one function that moves the whole group, and the element calls it once.

applyAll receives the group's values in the order the refs were given here, which is the same positional convention every other array crossing this boundary uses (§4.2.3). It receives a value for every member, including members that did not move: a batch is one call and cannot be handed a partial vector, so the elision rule that applies to individual settings does not apply within a group.

Validation and feasibility are unchanged. A batched lever is checked against its domain, envelope, narrowing, state-dependent set and any joint constraint exactly as an unbatched one is, and a rejected action writes nothing at all — batching changes how the values reach the model, not whether they are allowed to.