Execution model
An instance progresses from explicit graph dependencies. A node becomes executable only when its active path and predecessors allow it; independent branches may advance in parallel, and a wait suspends the instance without losing state or replaying already-completed steps.
Instance lifecycle
| State | Meaning |
|---|---|
running | The instance can continue execution. |
waiting | The instance is waiting for a deadline, interaction, event, or child execution. |
stopping | A stop was requested while active execution still needs to yield cleanly. |
completed | The process reached successful completion and its output is available. |
failed | A terminal error prevents this attempt from continuing. |
retry_exhausted | A replayable operation exhausted its durable retry budget. |
superseded | A corrective continuation replaced this instance in its lineage. |
stopped | The instance was explicitly stopped. |
These states describe execution of a process_instance. They are not the business statuses of the order, invoice, Return, or any other resource handled by the process.
Persisted step states
An instance's durable history stores a step when a node reaches an observable result. The current persisted states are listed below; a node that has not yet been reached does not need a step
pending to be materialized.
| State | Meaning |
|---|---|
completed | The node completed and its durable outputs are available. |
waiting | The node materialized a wait and will resume when that wait is satisfied. |
failed | The node could not produce a usable output for this attempt. |
skipped | The node was not executed because its branch is inactive or an ancestor made this path impossible. |
cancelled | A wait or still-active step was interrupted, for example when stopping an instance. |
The editor or observability UI may visually represent a node as ready, running, or not yet reached. The persisted step contract remains centered on the durable outcomes above.
Dependencies and parallelism
After A, B and C have no dependencies on each other and may advance independently. D becomes available only once its active predecessors are satisfied.
In a linear path A → B → C, order is strict. When several active branches leave the same point and have no dependency between them, their execution may overlap; do not rely on implicit ordering between parallel branches.
At convergence, the downstream node waits for predecessors actually belonging to the active path. The same structure is used to verify guaranteed ancestors.
Routing and inactive branches
A router node selects an explicit continuation. Unselected branches are not executed; descendants that are no longer reachable become skipped. The selected route is part of this node execution's result and remains stable when the instance resumes after a wait.
An output produced only in a conditional branch does not therefore automatically become available after convergence. See Routing and decisions.
Suspension and resumption
A durable wait puts the relevant step and instance into waiting. State required for continuation is preserved; when the expected signal arrives, the instance resumes from that wait instead of restarting from the beginning.
| Famille | What can be awaited |
|---|---|
| Timer | Wait or durable retry until a deadline. |
| User action | Form, choice, display, or extension interaction presented to the participant. |
| Approval | Human decision carried by an `approval_request`. |
| Event | Wait for a correlated platform or extension event. |
| Subworkflow / Foreach | Wait for one or more child instances according to configured policy. |
| Agent Run | Wait for internal completion of an Agent task. |
| External Task | Wait for a typed result supplied by an authorized external service. |
A successful wait produces the node output, then unblocks continuations depending on it. Steps already
completed completed remain completed and are not replayed merely because the instance was suspended.
Errors and propagation
When a node fails definitively, its step becomes failed and continuations depending on that result are not executed. An independent branch already executable is not retroactively turned into failure because another branch encountered an error.
Before making failure terminal, Ormuz may schedule a durable retry when the error is explicitly classified as replayable and the operation is safe to replay. During that retry wait, the node remains
waiting. Retry budget and idempotency guarantees are detailed in
Errors, retries, and idempotency.
The runtime does not assume a write operation is safe to replay. An error must be recognized as transient and the operation must satisfy the replay guarantees required to enter durable retry.
Process state vs business state
Some process-owned resources — for example onboarding, dispute, or Return — keep the relationship with the instance handling them. This relationship never equates instance status with resource status.
completed means the process contract completed correctly; it must not be interpreted as “invoice paid”, “Return accepted”, or “onboarding approved” without the corresponding business transition. Likewise, stopping the instance does not automatically invent a business cancellation.