Readiness is a pending-predecessor counter on each task document, decremented inside the same ETag-guarded write that records the predecessor's completion. Two orchestrators racing the same completion cannot both dispatch the successor.
Orchestration is stateless and competing rather than one long-lived actor per execution. Any instance can advance any workflow, which is what lets the control plane restart, scale and deploy without draining executions.
A ready task that cannot start because the tenant is at its concurrency limit is deferred, not failed. Deferral is a state (WAITING_SLOT), so it is visible, alertable and fair rather than an invisible queue delay.
Concurrency semantics
Level-1 tasks are dispatched together; the platform makes no ordering promise among siblings. A workflow that needs ordering must express it as an edge, not assume it.
The join gate fires exactly once per successor, guaranteed by the counter transition rather than by a query for 'are all predecessors done', which would race.
Fan-out is bounded by the workflow's 500-task cap and by the tenant's concurrency lease, so a single execution cannot consume a tenant's whole allocation.
Risks
A deferred task depends on a slot-release signal. If that signal is lost, the task waits until a reconciliation sweep finds it — a 60-second sweep exists precisely because event-driven-only would be a liveness bug.
Very wide fan-out concentrates writes on one logical partition and can throttle at 10,000 RU/s. Above roughly 200 concurrent siblings this becomes measurable and is a load-test target.
Conditional branches and dynamic fan-out over a collection are not in V1. Every DAG is static once bound, which is a real functional limitation to confirm with users.
