Skip to main content
An action passes through three distinct gates: admission (the world has received and validated the intent and tells the agent where it stands), permission (the world has decided the action may execute), and execution. Approval and queueing sit between admission and permission; they are states, not delays on the admission acknowledgement.

​
States

Invariant. rejected and any cancelled reached from a pre-execution state guarantee no side effects. failed, preempted, and cancelled reached through cancelling may leave partial effects, reported via aborted_at_progress.

​
Requirements

  • The world MUST send an action.status notification on every transition after admission. Terminal states are rejected, completed, failed, preempted, cancelled. Every action reaches exactly one logical terminal state. [AWP-LIF-001]
  • Admission acknowledgement. The action.submit result MUST report the post-validation state — pending_approval, queued, or accepted — together with received_ts_mono_ns, the session-clock time the world received the submission, and ts_mono_ns, the time of the reported transition; or it MUST return a JSON-RPC error, in which case the action is rejected. In streaming mode the result MUST arrive within 500 ms of receipt; in lockstep, before the result of the advance in which the submission was received. Waiting for approval or for a queue slot does not count against this bound. [AWP-LIF-002]
  • During executing, worlds SHOULD send progress updates (progress ∈ [0,1]) for duration: extended types at ≥1 Hz in streaming mode and at least once per tick in lockstep. [AWP-LIF-003]
  • failed, rejected, and cancelled statuses MUST carry a machine-readable reason from the status reason registry and MAY carry human-readable detail. [AWP-LIF-004]
  • Cancellation. action.cancel on a pre-execution action transitions it directly to cancelled (reason cancelled_by_agent). On an executing action the world MUST enter cancelling, complete its safe abort, then report cancelled with aborted_at_progress. cancelling is reported as a status like any other state. [AWP-LIF-005]
  • Replay. Undelivered action.status notifications MUST be replayed on session.resume according to the delivery contract. [AWP-LIF-006]
  • Streaming duration. duration: streaming actions (command channels) have no self-completion: they remain executing while their stream is live and terminate only via cancelling → cancelled, failed (reason watchdog, envelope, deadline_exceeded, e_stop, connection_lost), or preempted (AWP-CMD-004). [AWP-LIF-007]
  • Precedence. When several terminating causes coincide, the world MUST apply the first that applies in this order: e-stop → safe-state entry → action.cancel → deadline expiry → validity expiry or basis age (AWP-SAF-013) → approval decision → preemption by a newer submission. The reason reported is the cause that won. [AWP-LIF-008]
  • Transition vs delivery. A transition happens once, in the world, at a single ts_mono_ns. Its action.status notification MAY be delivered more than once (after reconnection, AWP-CTL-008). Receivers MUST deduplicate on (action_id, status_seq) and MUST NOT treat a redelivered terminal status as a second terminal transition. [AWP-LIF-009]
  • Abort bound. An action type MAY declare max_abort_ms; when it does, the world MUST report the terminal status of any cancelling action of that type within max_abort_ms of entering cancelling. action.cancel or a status pull naming an action_id the world has never seen, or has discarded after its retention period (AWP-ACT-006), fails with AWP_ACTION_UNKNOWN. [AWP-LIF-010]

​
Deadline origin

deadline_ms is measured from the world’s receipt of action.submit (received_ts_mono_ns in the admission acknowledgement) and spans approval waiting, queue waiting, and execution. Expiry in a pre-execution state → rejected, reason deadline_exceeded (no side effects). Expiry during executing → failed, reason deadline_exceeded, after the type’s safe-abort behavior (AWP-ACT-004). In lockstep, deadlines are advisory and MAY be ignored.

​
Terminal rules for pre-execution actions

Queued actions leave the queue in submission order when the group frees; each is re-checked against grants, envelopes, valid_until_ns, and max_basis_age_ms at the moment it becomes accepted, and MAY be rejected then.