Runtime, Planes, and Rules

Why this document exists

Most orchestration failures come from control ambiguity, not missing features. This guide explains how teams keep NodeFox behavior explicit, governable, and operable under change.

The five runtime planes

1. Authoring plane

Where intent is declared:

node graph shape
slot contracts and labels
schemas and template references
activation and policy gates

2. Runtime plane

Where workflow control behavior is applied:

node eligibility and route control
branch ownership and release boundaries
loop and fallback constraints
observable run lineage

3. Integration plane

Where external capabilities are connected:

Reader/Writer API boundaries
function and MCP tool attachment
auth scope and credential boundaries
fallback routing for dependency failures

4. Interface plane

Where users interact:

apps inputs
decision approvals
chat and UI artifact outputs

5. Governance plane

Where accountability is enforced:

schema-typed branch points
explicit approval routes
risk-tier routing
run-level evidence and review

JSON graph contract mindset

Treat the workflow as a declarative graph contract:

{
  "nodes": [{ "id": "writer-1", "flags": ["Activated"] }],
  "edges": [
    { "kind": "data", "from": ["decision-1", 1], "to": ["writer-1", 1] },
    { "kind": "activation", "from": ["decision-approve", 1], "to": ["writer-1", 1] }
  ]
}

When teams articulate contracts clearly, review and incident diagnosis become faster and less subjective.

Slot system reference

UI, template, and code indexing

Canvas keys 1..8 map to slots 1..8.
Canvas key 0 means bulk-connect mode.
$1 means slot 1 in templates and selectors.
inputs.get(0) means slot 1 in Code node APIs.

`$` expansion use cases

$ references are used across:

Conversation message content
Writer templates and replace rules
Decision expressions
Data selectors and Transform extraction fields
dynamic URLs and payload fields in API variants

Example expressions:

$1.customer.email
$1.items[0].sku
Ticket $2 for $1.account_name

Runtime control checklist

Before rollout, validate:

Entry nodes are reliably Ready at run start.
Optional slot intent is documented.
Sensitive writes are behind Decision + activation controls.
Loop branches are bounded.
Invalid outputs fail predictably.
Fallback paths exist for dependency failures.

Common production pitfall matrix

Symptom	Typical cause	Recommended correction
Node runs with incomplete context	Optional overused	Revert critical slots to blocking
Writer fires before approval	Missing activation gate	Add Activated + activation route
Unexpected slot value in Code node	Index mismatch	Reconcile `$1` vs `inputs.get(0)`
Loop never settles	No bounded branch rule	Add max iteration + fallback
Confusing branch history	Implicit mixed logic	Split into explicit Decision stages