Delay

The Delay operation stops the incoming execution path and starts a new one after a configurable timer expires. It accepts up to 20 data inputs whose values are forwarded to matching outputs once the delay elapses. Optionally, input values can be captured (snapshot) at the moment the delay begins rather than read at expiry.

Trigger

The Delay operation is a trigger. After the timer expires it initiates a new execution path independently of the original one.

Inputs

Port	Type	Required	Description
> (Gate)	Any	No	Controls whether the delay timer starts. The incoming path always stops at this operation regardless of the Gate value (the Delay is a Trigger boundary).
Reset	Boolean	No	When `true`, cancels a pending timer and stops the path. Reset is read before the Gate and before the Re-trigger Policy, so it wins over both.
In (variable, up to 20)	Any	Yes	Data inputs forwarded to corresponding outputs after the delay.

Outputs

Port	Type	Default	Description
> (Trigger)	Any	`false`	Untyped trigger pulse — fires `true` when the delay expires, starting the new execution path.
Out (variable, up to 20)	Mirrors paired input	`Nil`	Each output takes the type of the paired input. Value is the delayed or captured input value.

Properties

Name	Type	Default	Description
Delay (seconds)	Integer	`10`	Duration in seconds (`0`—`3600`). A value of `0` schedules execution as soon as the current work completes.
Capture Inputs	Boolean	`false`	When `true`, input values are snapshot at trigger time. When `false`, current values are read at expiry.
Re-trigger Policy	Combo	`Ignore`	What a new trigger does while a delay is already pending. `Ignore` drops it and stops; `Restart` cancels the pending timer and starts the full delay again.
On Error	Combo	`Stop this branch`	Per-op On Error verb. Delay’s Outputs belong to the Path it fires, so the Editor offers it the two verbs that write nothing: Stop this branch / Continue with the last value. See the Error Handling guide.

State on Reload

Outputs, captured values, and all active (unexpired) delays are preserved across restarts. Expired delays are triggered immediately on reload; active delays resume with adjusted timers. Saved state is discarded if the Capture Inputs flag or the number of data inputs/outputs changed. In that case all pending delays are dropped.

How It Works

Stop incoming path — The current execution path stops at this operation.
Gate check — If the Gate blocks execution, the timer does not start and outputs remain unchanged.
Capture (optional) — If Capture Inputs is true, all data input values are stored immediately.
Wait — The internal timer counts down for the configured Delay seconds.
Fire — When the timer expires, a new execution path begins. Output values are either the captured snapshot or the current input values, depending on the Capture Inputs setting.

Examples

Delay: 5 s Capture Inputs: true

At T=0, In 1 = "Hello at T0". The value is captured. At T=5 the timer fires.

Out 1: "Hello at T0" (the snapshot value)

Delay: 3 s Capture Inputs: false

At T=0, In 1 = "Initial". At T=2 it changes to "Updated". At T=3 the timer fires and reads the current value.

Out 1: "Updated"

Delay: 10 s Capture Inputs: true Gate: false

The incoming path stops, but the timer does not start. No new execution path is created.

Out 1: (unchanged from previous run)

Delay: 0 s Capture Inputs: true

In 1 = "Immediate". The incoming path stops and a new path is scheduled as soon as the current work completes.

Out 1: "Immediate"

Use Cases

Adding time-based pauses in automated workflows (e.g. “turn off light 5 minutes after motion stops”)
Throttling events to prevent rapid-fire actions
Decoupling execution paths — use delay 0 to break a long chain into independent segments

Error Handling

Delay raises no error of its own: every exit either arms the timer or ends the arriving Path by design — a true Reset, a closed Gate, or a re-trigger the Ignore policy drops. The Node still carries an On Error verb, because a value that fails a port’s type mask fails the Node and is resolved by that verb, while an Input whose Validation rule is not satisfied stops the Node and consults no verb.

Verb	What it does
Stop this branch (default)	This Node and its dependents stop; the Outputs keep their values, and the Node’s last attempt reads as failed — the engine’s record of the Node, not a mark on any port.
Continue with the last value	No timer is armed and no Path is fired; the Outputs keep their values, not stamped as new.

Delay’s Outputs belong to the Path it fires, so a failure on the arriving Path has nothing downstream to carry a value to. Continue with the fallback would write a value no firing produced and pulse the > output for a cross-path reader. Delay’s schema states the two verbs above, and the Editor offers only those.

Gate closure is not an error — a closed Gate stops the Path and consults no verb.

Limitations

One delay may be pending per Node. A trigger arriving while one is pending is settled by the Re-trigger Policy: Ignore drops it, Restart cancels the pending timer and starts the full delay again.
A Task may hold at most core.maxDelayPerTask Delay nodes (see Configuration).
Maximum delay is 3600 seconds (1 hour).

Configuration

One host setting bounds Delay. It is read at start-up from the host’s configuration file; see the Core configuration reference.

Key	Type	Default	Effect
`core.maxDelayPerTask`	Integer	`-1`	How many Delay nodes one Task may contain. Negative means unlimited.

The cap travels to the editor in the operation’s schema, so the editor refuses to add a Delay beyond it rather than letting you build a Task the server will reject. It counts nodes, not pending delays: how many delays one node may hold is settled by the Re-trigger Policy, which keeps at most one pending.