Process step reference #

A Process is a bounded graph of typed nodes. Each node has an id, a type, type-specific configuration, and explicit transitions where the path can diverge. The canvas is not an arbitrary code editor. Put protocol drivers, machine control, complex transformations, and hardware safety in qualified device software behind stable typed capabilities.

Use the canonical type identifiers on this page when inspecting or editing a node's JSON. Existing definitions may contain compatibility aliases, but those aliases do not add capabilities.

Transition fields #

Outcome	Configuration	Behaviour
Normal or successful	`next`	Continue to the named node. The runtime otherwise uses the next node in authored order and completes if there is none.
Failure	`on_failure`	Continue in compensation state after a step raises an error. Without this transition, the execution fails.
Timeout	`on_timeout`	Continue when an event or Command wait expires. Command invocation falls back to `on_failure` when `on_timeout` is absent.
True or false	`on_true`, `on_false`	Select one branch target. Existing `then` and `else` values are normalised to these fields.
Jump	`target`	Continue at the named node without executing intervening nodes. Existing `step` values are also accepted.

The visual flow labels a normal next transition as success when the node also has a failure or timeout path. This is a presentation label; the stored field remains next.

Flow and decision steps #

Type	Purpose and typed configuration	Transitions	Placement and failure semantics
`set_variable`	Store execution-local state. Set `name` and either `value` or an `expression`; the result is available to later templates through variables.	`next`; `on_failure`	Cloud and Edge. An invalid expression or missing name follows `on_failure`, otherwise the execution fails.
`branch`	Evaluate a declared `condition` or `expression`.	`on_true`, `on_false`; execution errors can use `on_failure`	Cloud and Edge. The selected Boolean path is explicit. A condition evaluation error follows normal step failure handling.
`goto`	Make an explicit graph jump to `target`.	`target`	Cloud and Edge. An unknown target is rejected during publish validation; a missing runtime node fails the execution.

Wait steps #

Type	Purpose and typed configuration	Transitions	Placement and failure or timeout semantics
`wait_duration`	Persist a duration using `duration_seconds` (`seconds` is accepted by the runtime).	`next`; `on_failure`	Cloud and Edge. The durable timer resumes at `next`; a non-positive value becomes an immediate timer.
`wait_until`	Persist a wait until `until` or `datetime`.	`next`; `on_failure`	Cloud and Edge. A past time resumes immediately. Invalid configuration follows normal step failure handling.
`wait_event`	Wait for the declared `event_type`; store its payload in `result_var`, defaulting to `event_payload`. An optional `timeout_seconds` bounds the wait.	`next`; `on_timeout`, falling back to `on_failure`	Cloud and Edge. A matching event resumes the Process. Expiry takes the timeout target; without one it resumes the normal target.
`wait_command`	Wait for the invocation in `invocation_var` or `invocation_id`. Optional `success_states`, `failure_states`, and `timeout_seconds` define the terminal contract.	`next`; `on_timeout`, falling back to `on_failure`	Cloud and Edge. Success resumes `next`. A configured failure state uses the recovery target; without one the execution fails.

Record steps #

Record steps operate on Product Application records and are Cloud-only.

Type	Purpose and typed configuration	Transitions	Failure semantics
`create_record`	Create a record in `model_key` from the `fields` or `data` object. Store its identifier in `result_var`, defaulting to `record_id`.	`next`; `on_failure`	Model, field, or record validation errors follow `on_failure`; without it the execution fails.
`find_record`	Query `model_key` with a `match` object. Optional `order_by`, `limit`, `required`, and `expect_one` constrain the result. Store one identifier in `result_var` and optionally all identifiers in `result_ids_var`.	`next`; `on_failure`	No match stores `null` unless `required` is true. Query errors and violated cardinality follow `on_failure`.
`update_record`	Update `record_id`, or the identifier named by `record_var`, with `fields` or `data`.	`next`; `on_failure`	A missing record or invalid update follows `on_failure`; without it the execution fails.

The merged runtime also contains the Cloud-only consume_record_balance and restore_record_balance nodes for atomic bounded record balances. They use a model, match, balance field, amount, and result variable. They are domain coordination primitives, not a financial ledger.

Existing paid-access definitions may also contain the specialised redeem_voucher and restore_voucher identifiers. New generic flows should use the record-balance nodes; voucher nodes remain accepted by merged runtime and authoring validation.

Invocation and device steps #

Type	Purpose and typed configuration	Transitions	Placement and failure or timeout semantics
`invoke_command`	Invoke `command_key` for a `device` with an `input` object. `result_var` defaults to `command_invocation_id`. `wait`, `success_states`, `failure_states`, `timeout_seconds`, and `wait_timeout_seconds` control waiting.	`next`; `on_failure`; `on_timeout` while waiting	Cloud and Edge. Edge uses this node for stable typed local capabilities. A waiting invocation is durable; failure, rejection, expiry, or cancellation takes recovery when configured. Device software still owns validation, deduplication, interlocks, and proof of physical outcome.
`invoke_operation`	Invoke `operation_key` with a typed `input` object and store the invocation identifier in `result_var`.	`next`; `on_failure`	Cloud-only. Invocation errors follow normal failure handling. The node records acceptance of the Operation, not proof of a physical outcome.
`invoke_integration`	Invoke `binding_key` with a `payload` object and store the response in `result_var`.	`next`; `on_failure`	Cloud-only. A non-successful integration invocation follows `on_failure`; without it the execution fails. Scenario runs use a deterministic stub instead of contacting the connector.
`write_setting`	Write `value` to `setting_key` for a `device`; `reported` selects reported rather than desired state.	`next`; `on_failure`	Cloud-only. This is a side effect and requires an explicit failure or timeout path during authoring validation.
`emit_event`	Publish `event_type` with a `payload` object.	`next`; `on_failure`	Cloud and Edge. Invalid event configuration or publication errors follow normal failure handling.

Resource reservation steps #

These Cloud-only steps coordinate a bounded resource account. They do not replace the authoritative domain ledger or remove the need for reconciliation.

Type	Purpose and typed configuration	Transitions	Failure semantics
`reserve`	Reserve `amount` from `account_key` or `account_id`; optional `unit` and `limit` initialise an account. Store the reservation identifier in `result_var`, defaulting to `reservation_id`.	`next`; `on_failure`	Reservation errors take `on_failure`. Authoring validation requires an explicit failure or timeout path.
`partial_commit`	Commit `amount` from `reservation_id` or the identifier named by `reservation_var`.	`next`; `on_failure`	A missing reservation or invalid amount follows normal failure handling.
`commit`	Commit all remaining reserved value, or an explicit `amount`.	`next`; `on_failure`	A missing or invalid reservation follows normal failure handling.
`release`	Release the remaining value held by a reservation.	`next`; `on_failure`	A missing or invalid reservation follows normal failure handling.

Alert steps #

Type	Purpose and typed configuration	Transitions	Placement and failure semantics
`open_alert`	Open a Product alert using `alert_key`, `message`, and `severity`.	`next`; `on_failure`	Cloud-only. Alert errors follow normal failure handling.
`resolve_alert`	Resolve the Product alert identified by `alert_key`.	`next`; `on_failure`	Cloud-only. Resolution errors follow normal failure handling.

Terminal steps #

Type	Purpose and typed configuration	Transitions	Placement and semantics
`complete`	Mark the execution completed. It has no additional required configuration.	None	Cloud and Edge. Stops execution successfully.
`fail`	Fail with the interpolated `reason`.	None	Cloud and Edge. Records a failed terminal attempt and marks the execution failed.
`enter_reconciliation`	Stop automatic progress because cloud or human reconciliation is required.	None during entry	Cloud and Edge. Marks the execution `awaiting_reconciliation`. A later correlated event can resume only when the execution has a declared reconciliation resume step.

Edge segments in Mixed Processes #

An edge_segment is available only in a Mixed Process. Its input must be an object and its non-empty steps array is a nested Edge graph. An optional target_binding_alias overrides the Process-level Edge binding; timeout_seconds, result_var, next, and on_failure configure the generated cloud dispatch.

The nested graph can contain only:

set_variable, branch, goto, wait_duration, and wait_until;
invoke_command, wait_command, wait_event, and emit_event;
complete, fail, and enter_reconciliation.

An Edge Process uses the same vocabulary directly. Edge and Mixed Processes require an Edge target binding. Cloud Processes cannot contain edge_segment. Record, integration, Operation, setting, reservation, and alert steps remain in the cloud part of a Mixed Process. Protocol-specific work and hardware safety remain in device software exposed as a typed capability.

Compatibility identifiers #

The merged runtime and authoring validator accept these existing identifiers:

Existing identifier	Canonical type
`set_var`	`set_variable`
`condition`	`branch`
`wait`	`wait_duration`
`set_device_setting`	`write_setting`
`create_alert`	`open_alert`
`close_alert`	`resolve_alert`
`call_integration`	`invoke_integration`
`call_operation`	`invoke_operation`
`publish_event`	`emit_event`

Use canonical types for new nodes. The compatibility identifiers have the same configuration, placement, transitions, and failure semantics as their canonical equivalents.

Authoring diagnostics #

Continuous validation returns a severity, stable code, message, and anchor. All currently merged authoring diagnostic codes below have severity error, so they block publishing.

Code	Condition	Anchor
`process.empty`	The Process has no nodes.	Process
`process.no_terminal`	No reachable `complete`, `fail`, or `enter_reconciliation` node exists.	Process
`process.unbounded_cycle`	A reachable graph walk finds an unbounded cycle.	Process node
`node.unreachable`	A node cannot be reached from the first node.	Process node
`node.unsupported_type`	A node type is outside the merged runtime vocabulary.	Process node
`side_effect.failure_path_missing`	A Command, integration, setting write, or reservation has neither `on_failure` nor `on_timeout`.	Process node
`binding.unknown_integration`	A literal integration binding key is unknown.	Process node, field `binding_key`
`binding.unknown_operation`	A literal Operation key is unknown.	Process node, field `operation_key`
`binding.unknown_command`	A literal Command key is unknown.	Process node, field `command_key`
`binding.unknown_model`	A literal model key is unknown.	Process node, field `model_key`
`binding.unknown_field`	A literal field key is absent from the referenced model.	Process node, field containing the reference

A Process anchor contains kind: process, the Process stable identifier or key, and a null node. A node anchor contains kind: process_node, the same Process value, and the node id. Binding diagnostics also include field. Selecting an anchored diagnostic focuses the corresponding node.

Publish validation also rejects missing or duplicate node IDs, transitions to unknown targets, and invalid Edge placement or vocabulary. The merged code reports those as publish or compatibility errors, not as stable structured authoring diagnostic codes, so no diagnostic code is assigned to them here. Publish change warnings such as a removed Process, a changed timeout, or an added branch are a separate acknowledgement contract from authoring diagnostics.