Nodes, Ports & Execution Chains

Read a Flow Graph as authored routes that runtime chains can travel. Nodes define behavior, ports define compatible flow boundaries, branches define topology, and chains describe what is executing now.

Node responsibilities

A node is a visible graph unit with flow ports, settings, behavior, and optional Guard logic. Different node kinds own different responsibilities:

• Trigger and Enter nodes start chains.
• Action nodes run ordered Instruction lists.
• If/Else, Switch, Gate, and similar nodes choose routes.
• Wait, Delay, Retry, Loop, and timer nodes control timing or repetition.
• Module nodes provide FSM, Behavior Tree, Stack, or GOAP behavior.

An Instruction is not a graph node. It is an executable operation inside an Action-style list or another supported host.

Ports and branches

An input port receives execution. An output port continues execution. Connecting an output to an input creates a branch in the graph’s static topology.

Use branch for the authored route: “The Success branch connects to the reward Action.” Do not call the running execution a branch.

The main graph can hide auxiliary port rows until you expand Control Inputs or begin a compatible connection drag. This changes their visibility, not their identity or execution contract. Inspect the actual port name and existing connections before adding a control route.

Execution chains

A Trigger or Entry starts a chain. The chain moves through connected nodes until it completes, aborts, becomes invalid, waits, or starts another supported execution boundary.

Several chains can exist in one process. Busy-node behavior and module semantics decide whether repeated execution queues, bypasses, cancels, or proceeds independently.

Connections define both branches; Owner A’s active route is waiting for confirmation.

Read a route

For any visible behavior, answer these questions:

1. Which Trigger or Entry starts the chain?
2. Which output port does it use?
3. Which node receives that output?
4. Can a Guard reject that node?
5. Which result or output continues the chain?
6. Where is the observable result?

Design implications

• Give a node one readable purpose.
• Prefer visible handoffs between systems over hidden side effects.
• Put ordered operations in one Action only while they form one coherent step.
• Name important Entries, roots, states, and comments by responsibility.
• Add a visible verification result before adding more branches.

Common misunderstandings

Related

• Triggers, Entries & Payloads
• Branching, Guards & Execution
• Graph Editor