Global Node

What Global is and why it exists

Global is the run-state coordination node. It gives workflows an explicit mechanism for reading and writing named variables that need to be shared across branches or across parent/child network boundaries.

Without Global, teams often create implicit coupling through fragile slot plumbing. With Global, shared state is intentional, named, and easier to audit.

Execution behavior

Global runs in two modes: Set writes values into named run-level variables, and Get retrieves those values back into output slots. The key design principle is explicit naming. If shared state matters, it should have a stable variable name and clear lifecycle semantics.

Global state should support orchestration clarity, not replace slot contracts. Use it where shared coordination is needed, not for every value transfer.

Variants and configuration details

Set mode

Set writes input values into named variables.

Field	What it controls	Practical guidance
`Variable Names`	Ordered variable names to write	Use consistent naming patterns like `domain.process.state`.
`Operation`	Must be `Set`	Keep Set usage close to the branch where state is produced.
Slot mapping	Which input slot updates which variable	Document slot-to-variable mapping in-network for maintenance clarity.

Get mode

Get reads named variables into output slots.

Field	What it controls	Practical guidance
`Variable Names`	Ordered variable names to read	Keep read expectations documented for dependent branches.
`Operation`	Must be `Get`	Pair with fallback handling if expected variables may be missing.
Output mapping	Which variable appears on which output slot	Keep output contracts narrow and typed for downstream Decision logic.

Production usage patterns

Global is commonly used with Wait for branch convergence. A standard pattern is each parallel branch setting branch_x_done=true, then Wait checking those variables before merge execution.

Global is also central to Network composition contracts where parent networks pass input variables into child networks and receive normalized outputs back.

Additional high-value patterns:

run-level policy context (policy_version, consent_state, risk_tier)
cost guardrails (budget_remaining, retry_budget)
cross-branch correlation IDs for audit and replay alignment

Naming and lifecycle rules that prevent drift

Use namespaced keys: team.workflow.variable.
Separate immutable run metadata from mutable status flags.
Define write ownership: one branch per mutable key when possible.
Reset or reinitialize shared keys at known run boundaries.

Common mistakes to avoid

The biggest mistake is overusing Global as a hidden data bus. That reduces graph readability and makes debugging harder. Keep Global usage focused on coordination state and explicit contract exchange. Another issue is inconsistent naming that creates collisions across large workflows.

A simple naming standard and clear ownership conventions prevent most Global-related problems.

Operational signals

missing-key read frequency in Get mode
conflicting-write incidents on shared keys
Wait timeout rate caused by stale or unset global flags
cross-network contract mismatches on shared variable names