Execution order of a compound command changes the outcome

What it is

When several jobs share one sentence, which one runs first changes the world. “Turn the lights off then lock the screen” — if lock runs first, voice dies and the lights never hear the rest. “Set the AC to 26 then turn off the living-room lights” commutes. “Send this to Mom then delete it” — the order is the content. Running in skill-registry order, or all in parallel, produces a world the user did not ask for. The claim is how to sequence jobs already recognized, not whether they were all heard.

Why it happens

Spoken order is often intended execution order (iconicity): first said, first done. Some acts shut the channel for later ones (lock, shutdown, leave-home). Some have semantic preconditions (fill then boil). Some are social scripts (name the recipient, then delete the draft). Parallel execution flattens those dependencies. Internal priority (safety always first, media always first) overwrites the user's verb order with a product catalog.

A confirm parked before the first act while waiting for a nod on the second delays the first, and order is changed the same way. “Lights off right now, and set an alarm while you're at it” — the “right now” is eaten by the confirm turn. Order is not only the executor's queue; it is also where confirms and follow-ups are inserted.

Studying it

Build pairs: compounds whose swapped world differs (order-sensitive) versus compounds that commute. Measure whether the system keeps spoken order, and whether users recode a wrong order as “didn't hear” or as “heard and did it wrong.” Draw a skill-dependency graph: which acts mute voice, cut power, change permission. Dependents: outcome-match on order-sensitive pairs, and whether a reorder is spoken aloud.

In logs, find sentences with “first / then / after that” and compare actual execution timestamps. Lab scripts that split a compound into two turns are no longer testing order.

Where it stops holding

Two lights, two unrelated plugs — swap is free, default to commutative. “While you're at it” marks order as weak; the main act can go first. Safety policy may force an order opposite to speech (unlock before disarm), but it has to be said, or the user thinks the second act never ran. If the second job was never recognized, there is nothing to order. A new task inserted several turns later is park-and-resume, not in-utterance queuing.

Applying it

• Default to spoken order; reorder only when a dependency graph requires it. Say the reorder: “I need to unlock before I can turn the lights off — I swapped them.”
• List acts that disable later skills (lock, shutdown, airplane, leave-home). If a compound contains them, put them as late as speech allows, or refuse the combination and say why.
• Do not stall the first act to confirm the second: do what can run now, confirm the rest after.
• How to check: run “lights off then lock” and the reverse. If lock-first makes the second fail, the failure must name order, not just “couldn't turn off the lights.” Spoken “first / then” overwritten by internal priority with no explanation is a defect.

Related

• Same group: M2.13.1 A single utterance can carry several intents · M2.13.3 Partial success has to be reported item by item
• Nearby: M1.05 Topic switching and task nesting · M2.07 Dialogue flow and state design · M2.09 Matching confirmation to consequence
• Search terms: execution order · order-sensitive commands · skill dependency