NodeFoxData Node
What Data is and why it exists
Data is the structured extraction and iteration node. It takes incoming payloads and maps fields into explicit output slots so the rest of the graph can branch on reliable, typed values rather than brittle string parsing.
In real production workflows, Data is often the node that converts model output or API payloads into deterministic routing inputs. This keeps Decision logic simple and keeps Writer branches safer.
Execution behavior
Data can run as direct selector extraction or as controlled iteration over arrays. In selector mode, it emits mapped fields once. In iteration mode, it emits one element (or one mapped element structure) per cycle. Because NodeFox is a directed graph, iterative patterns should always be paired with explicit loop controls downstream.
Data is not a policy node. It shapes information so policy nodes can make clear decisions.
Variants and configuration details
Default variant
Default maps selectors to output slots using deterministic extraction paths.
| Field | What it controls | Practical guidance |
|---|---|---|
Selections | Selector-to-slot mapping | Keep mappings explicit and document expected payload shape near the node. |
Selector examples include $1.user.name, $1.items[0].id, and $2.metadata.score. Use stable selectors and avoid fragile assumptions about optional fields unless fallback handling is explicit.
For variant
For iterates through array payloads and emits one element (or mapped element fields) per execution cycle.
| Field | What it controls | Practical guidance |
|---|---|---|
Base Array Selector | Path to the array to iterate | Validate that the selector always resolves to array-like content or route to fallback. |
Property Selections | Optional per-element extraction map | Use when each element should be narrowed before branching. |
| Loop convergence branch | Downstream termination criteria | Always pair with bounded retry/termination logic in Decision. |
If Property Selections is empty, each element is emitted as-is. This is useful for generic pipelines but should still be paired with downstream validation.
Schema shorthand behavior
Data supports schema shorthand to accelerate selector generation. Patterns such as &SchemaName! or &SchemaName.path.to.object! can populate extraction mappings from defined schema contracts. This is useful for keeping extraction logic aligned with typed schema definitions as workflows evolve.
Schema shorthand improves speed, but teams should still review generated mappings before promotion.
Contract design guidance
Use Data as a contract-projection boundary. A strong pattern is to emit:
- one slot per branch decision input (
risk_score,policy_state,intent) - one slot for human-review context
- one slot for Writer payload envelope
This keeps branch semantics clear and avoids leaking unnecessary fields into high-risk branches.
Production usage patterns
A common pattern is Conversation(schema output) -> Data(Default) -> Decision(policy) so model output is normalized into deterministic fields before branch logic. Another pattern is Reader(list) -> Data(For) -> Conversation/Code -> Buffer(Stack) for bounded iterative processing.
When using iteration, avoid implicit re-entry loops without max bounds. Pair Data iteration with Decision max limits and explicit fallback branches.
Common mistakes to avoid
A frequent mistake is using Data to perform business decisions by overloading selector complexity. Keep Data focused on extraction and keep policy in Decision. Another issue is assuming arrays always exist; robust workflows route empty or missing arrays into explicit recovery branches.
The best Data nodes are boring on purpose: clear selectors, clear outputs, predictable behavior.
Metrics worth monitoring
- selector resolution failure rate
- empty-array iteration frequency
- schema-to-selector drift after schema revisions
- downstream decision fallback rates caused by missing Data outputs