Execution Model

NodeFox executes the workflow graph as a runtime contract. The canvas is not just a design surface. Node configuration, slot mappings, edge types, and execution flags directly control what can run, when it can run, and what data it can access.

What this page covers

Use this page as the short operational overview, then go deeper in the linked references:

• Deterministic Runtime
• Activation Edges
• Edges and Data Flow
• Runtime Planes
• How NodeFox Works

Core execution rules

NodeFox runtime behavior is driven by explicit rules:

1. Node eligibility is evaluated from slot state, edge state, and flags.
2. Data edges move payload values between slots.
3. Activation edges move permission-to-run signals without payload transfer.
4. Routing and branch transitions follow graph-defined logic, not hidden callback behavior.
5. Looping and retries should be bounded with explicit max/fallback controls.

Flag behavior that affects eligibility

The most important flags are:

• Optional (O, blue): per-slot flag that allows an input slot to be non-blocking for eligibility.
• Activated: per-node flag that requires an activation signal before execution is allowed.
• Keep (K, green): per-slot flag that preserves slot/state across cycles for controlled iterative behavior. Exception: on Buffer nodes, Keep applies across all slots when selected.
• Delay: per-node flag that defers eligibility by configured graph steps/cycles.

These are control semantics, not convenience toggles. Misusing them is one of the most common causes of unexpected runtime behavior.

Deterministic orchestration, probabilistic models

Model outputs can vary. NodeFox determinism applies to orchestration control: branch rules, eligibility checks, activation release, and fallback behavior remain explicit and repeatable for a given graph/run state.

This is what makes incident response, replay, and governance reviews practical at scale.

Related deep references

• Crucial Workflow Mechanics
• Nodes
• Use Cases