Skip to content

Engine Reference

Every setting below is documented in full somewhere else. What no other page does is put them together, so this one exists to be read in a single pass: what exists, where it lives, what it defaults to, and the one sentence that says when you would touch it.

Four scopes, in widening order of how much they affect: the Task, the Node, an input port, an output port.


SettingDefaultReach for it when
Status LevelNoneRaise it to see stops, resolved failures, or to debug. Ladder
Preserve state on re-runYesYou are re-running a Task that is already running and want it to start clean instead of restoring each Operation’s saved state. Details

Status Level is a property of the Task you edit and save. Preserve-state is not a stored setting at all — it is a question the confirmation dialog asks each time you re-run a Task that is already running.


SettingDefaultReach for it when
On ErrorStop this branchThis Operation’s failure should not take its branch down. Choose Continue with the last value or Continue with the fallback. An Operation that answers later applies the same verb to the answer. Details
Gate Inputnot connectedYou want an upstream condition to switch this Path on and off. Connecting it is the setting; there is no toggle. Details
TagemptyYou want this Node to carry a name of your own alongside its id.

A Node whose Operation can never err — no Input to check and no completion that can fail — shows no On Error control at all. The Operation’s page says so.

On Error is meaningful only where there are Outputs to carry a value to. An Operation with no Outputs — a sink — offers Stop this branch and Continue with the last value, and its dropdown lists only those two.


SettingDefaultReach for it when
ValidationAny valueThe Operation should not run unless its Input is ready. A value that exists, A value not used yet, A value whose last update succeeded, A value whose last update failed. Details
Accepted typesthe Operation’s own maskYou want to narrow what this port will take, so a value the Operation cannot read fails the Node instead of reaching it, and the Node’s On Error verb resolves that failure. Details
Mandatory / Optionalset by the OperationNot yours to change — it is the Operation’s declaration that a port must be connected. A Mandatory port left unwired is a compile error.

The four rules beyond the default answer four different questions: has this ever arrived?, is this one I have not run on yet?, did whatever produced it succeed?, and did whatever produced it fail? The last two see through a failure that a continuing verb resolved — one blocks on it, the other reacts to it.

A rule that is not satisfied stops the Node: it waits, its dependents do not run this firing, and nothing is written. Its On Error verb is not consulted — a wait is not a failure.


SettingDefaultReach for it when
FallbackNilThe Node’s On Error is Continue with the fallback. Every Output the Node would write needs one: the Editor refuses the Task otherwise. Details

The Fallback editor is always shown, whatever On Error says. It is read when the verb resolves to Continue with the fallback.


Worth knowing, so you stop looking for it.

  • No per-cause verb. One On Error setting covers every way a run can fail — an unconnected mandatory Input, a value type the Node cannot read, and the Operation’s own runtime error. You cannot continue on one and stop on another. A rule that is not satisfied is not among them: it stops the Node without asking the verb.
  • No per-output verb. The verb is per Node and applies to all of its Outputs uniformly. Only the Fallback value is per output.
  • No per-Node verbosity. Status Level is a single Task-wide setting.
  • No retry as a verb. Where a retry exists it is a number in the Operation’s own settings, spent before the completion fires. Nothing re-runs an ordinary Operation that failed; build the retry from counting and timing Operations if you need one.
  • A reaction branch is a Validation rule, not a port. A value whose last update failed on an Input runs the consumer because the upstream failed. On the upstream’s own Path it needs a continuing verb, because a Node that stops its branch never runs its dependents; a consumer that a different Trigger reaches passes behind any verb. The compiler hints on the settings alone.
  • No runtime state on the canvas. A Node’s frame and its corner dot are compile-time and Verify-time; neither says anything about a run. The runtime answer is the status feed. What you cannot see