Connections & DAG Rules

Connections (edges) are the directed links between nodes that define data flow through your strategy. Each connection:

• Starts from a source node’s OUTPUT handle (right edge of the source node)
• Ends at a target node’s INPUT handle (left or top edge of the target node)
• Carries a specific type of data (numeric value, boolean signal, price level, etc.)
• Is visually rendered as a colored line matching the source node’s color
• Can only be created between compatible handle types

Creating a Connection

Click and drag from an output handle (small circle on the right side of a node) to an input handle (small circle on the left/top side of another node). Valid targets highlight as you drag. Release to create the connection. The connection is immediately validated against the connection rules.

Deleting a Connection

Click the edge to select it (it highlights), then press Delete or Backspace. Or right-click the edge for a context menu with the option to remove.

Edge Styling

Selected edges render thicker (3px stroke) with a subtle animation. All edges use the source node’s color, making it easy to visually trace the signal flow through your strategy. Hovering over an edge displays the handle names and the type of data flowing through it.

Directional Flow

All connections flow strictly left-to-right. This enforces a clean DAG (Directed Acyclic Graph) structure. You cannot create a connection that goes from right to left — the canvas prevents circular references at the interaction level. The flow is:

Data Source → Indicators / Patterns / Market Structure → Conditions → Logic Gates → Entries / Exits

Every output handle has a type that determines which input handles it can connect to. The system enforces this via the VALID_CONNECTIONS map, which defines every legal source-handle-to-target-handle pair.

Invalid Connection Feedback

When you attempt to connect incompatible handle types, the system provides immediate visual feedback: the target handle does not highlight during drag, and releasing over an incompatible handle does nothing. If the connection would be semantically close but technically wrong (e.g., a level handle to a condition’s left), the system auto-redirects to the correct handle instead of silently rejecting.

The following table documents every node type’s accepted inputs, produced outputs, and key behavioral notes. Use this as a quick reference when designing your strategy.

The Strategy Builder has smart auto-connection behaviors that save you from manually selecting the right handle every time. These behaviors operate transparently as you connect nodes.

Numbered Handle Resolution

Handles in the same “family” auto-resolve to the first free slot. The system tracks which numbered handles are occupied and assigns the lowest-numbered available slot:

• cond-0 through cond-4 (Entry/Exit): First connection → cond-0, second → cond-1, etc.
• in-0 through in-4 (Logic AND/OR): First connection → in-0, second → in-1, etc.
• filter-0 through filter-4 (Entry/Exit): First connection → filter-0, etc.

If you connect to a node and don’t explicitly target a handle (e.g., you drop the connection near the node rather than on a specific handle), the system assigns the lowest-numbered free handle automatically.

Condition Handle Auto-Redirect

When connecting to a Condition node, the system intelligently routes the connection to the appropriate side based on the source handle type:

• value or signal handles dragged to the condition → always assigned to left if free, or right if left is already occupied and right accepts value types.
• level handles dragged to the condition → always assigned to right, never left(since level comparisons happen on the right side).
• If you explicitly target a handle that’s incompatible, the system auto-redirects to the correct one without rejecting the connection outright.

Auto-Population on Connect

When a connection is created, the system calls autoPopulateTargetNode() to pre-configure the target node based on what was connected:

1. Source value → Condition left: Auto-detects the left type (indicator/price/pattern/etc.), resolves the condition’s behavior from the registry, and pre-selects an appropriate operator and right-side configuration.
2. Source level → Condition right: Auto-sets left.type to “price”, switches to level-compatible operators, and displays the level value as read-only.
3. Source indicator → Trend Filter filter-indicator: Auto-sets the filter’s indicator reference so it knows which indicator to evaluate.
4. Source Data Source → Filter filter-ds: Links the data stream so the filter can compute its metric (volume, volatility, regime) on the correct data.

Single Connection Per Handle

Each input handle accepts exactly one incoming connection. If you attempt to connect to an already-occupied handle, the connection is rejected. You must disconnect the existing edge first before connecting a new source. This is enforced at the React Flow level and prevents ambiguous signal routing.

The validateDag() function checks your strategy before saving, backtesting, or optimizing. It returns:

ERRORS block the action entirely — the strategy cannot be saved, backtested, or optimized until they’re resolved. WARNINGS are advisory and do not block the action, but should be reviewed.

Rule 1: Data Source Required

The strategy must have at least one data-source node. Without it, there’s no price data to analyze — every indicator, pattern, and condition needs price data to evaluate.

Fix: Drag a Data Source block from the library onto the canvas. It will appear at the far left and serve as the root of your DAG.

Rule 2: Entry Required

At least one entry node must exist. Without an entry, the strategy never opens positions — it has all the analysis logic but no way to act on it.

Fix: Drag an Entry Long or Entry Short block from the library and place it at the far right of the canvas. Connect condition edges and filter gates to it.

Rule 3: Exit Recommended

At least one exit node is strongly recommended. Without an exit, positions theoretically never close (though the backtest may apply a default timeout or end-of-day closure).

Fix: Add an Exit (signal) or Exit (risk management) node. Exit (signal) uses condition logic to determine when to close. Exit (risk management) uses fixed stop-loss/take-profit percentages.

Rule 4: Alias Uniqueness

Every node must have a non-empty alias, and no two nodes can share the same alias. Aliases are used internally as unique identifiers to reference nodes — duplicate aliases cause ambiguity in the serialized strategy.

Fix: Check all nodes for duplicate or empty aliases in their inspectors. A good convention is to use descriptive aliases like “SMA 50 4h” or “RSI oversold check”.

Rule 5: Node Selection

Certain node types must have their key configuration completed. A node on the canvas is not enough — it must be fully configured with the specific resource it references:

• Indicator nodes: Must have a name selected (not blank). The indicator name determines which computation to run.
• Pattern nodes: Must have a pattern selected from the available pattern library.
• Classifier / Regressor: Must have model_info.id != 0 — a trained model must be selected from the model registry.
• Strategy: Must have strategy_id set — the strategy it references must exist in your account.

Fix: Open each node’s inspector panel and complete the required selections. Nodes with missing configuration show a warning indicator (orange dot) on their title bar.

Rule 6: Edge Connection Validity

Every connection’s sourceHandle → targetHandle pair must exist in the VALID_CONNECTIONS map. This prevents type-mismatched connections — you cannot connect a level output to a logic gate input, or a data stream to a condition’s left handle. The system enforces this at connection time, but validation re-checks all edges.

Fix: Remove invalid edges. Check that you’re connecting compatible handle types. Refer to the Handle Types table in Step 1 for a complete reference of valid pairings.

Rule 7: Filter Data Inputs

Filters require specific data inputs to function. Each filter type has its own requirement:

• Trend filters MUST have an indicator connected to filter-indicator — the filter evaluates the indicator’s value to determine trend direction. (Exception: When MTF is enabled on the filter, it can fetch its own indicator data.)
• Volume / Volatility / Regime filters MUST have a data source connected to filter-ds — the filter computes its metric from the price data. (Exception: MTF-enabled filters can self-fetch.)
• Time filters are exempt — time is universal and does not require a data connection.

Fix: Connect the required data source or indicator to the filter node. Or, if you intend the filter to work independently, enable MTF on the filter.

Rule 8: Data Source Connectivity

Indicator, Pattern, Fibonacci, Pivot Points, Price Levels, Volume Profile, and SMC nodes must have a data source connection on their left handle. These nodes cannot compute without price data.

MTF relaxation: When Multi-Timeframe (MTF) is enabled on the Data Source, this requirement is relaxed. MTF-configured nodes can independently define their own data source (symbol, bar type, timeframe) and do not need the physical edge connection. The node fetches its own data at its configured resolution.

Fix: Connect the data source’s data handle to each node’s left handle, or enable MTF and configure per-node data source overrides.

Rule 9: Condition Inputs

Every condition node must have at least one edge connected — either to left or right handle. An empty condition evaluates to nothing meaningful and cannot produce a signal.

Fix: Connect at least one source to the condition. Typically this is a left connection (from an indicator or signal source). For level-based conditions where left is auto-set to “price”, you only need to connect a level to the right handle — the system handles the left side automatically.

Rule 10: Disconnected Nodes

Every node (except Exit nodes) must have at least one incoming or outgoing edge. Nodes with zero connections are “orphans” that don’t participate in the strategy — they’re just floating on the canvas consuming space without contributing to the signal path.

Fix: Either connect the orphan node into the DAG (add edges linking it to upstream/downstream nodes), or delete it. Exit nodes are exempt because Exit (risk management) is self-contained and requires no connections.

Validation Trigger Points

DAG validation runs automatically at these key moments:

• Before saving a strategy to the server
• Before submitting a backtest
• Before opening the optimization modal
• (Optionally) on-demand via a “Validate” button in the toolbar, if present

The validation result is displayed in a modal or toast, listing each error and warning with a description and (where possible) the specific node or edge causing the issue.

Mistake 1: Level node connected to condition’s left handle

Symptom: Connection rejected or auto-redirected to right.

Fix: Level nodes (Fibonacci, Pivots, Price Levels, Volume Profile) must connect to the condition’s right handle. The system auto-redirects if you try the wrong handle, so this mistake is usually caught transparently. If auto-redirect is disabled or the handle is occupied, you’ll need to manually rewire.

Mistake 2: Multiple nodes connected to the same input handle

Symptom: Second connection rejected — no visual feedback on drop.

Fix: Each input handle accepts only one incoming connection. Use a Logic Gate (AND/OR) to combine multiple signals before feeding into a single entry condition slot. For example: two indicators both signaling “enter” can be combined through an AND gate, and the gate’s output connects to a single cond-0.

Mistake 3: Forgetting to connect data source to indicators

Symptom: Validation error “Data source connectivity” (Rule 8).

Fix: Connect the data source node’s data handle to every indicator/pattern/market-structure node’s left handle. Or enable MTF on the data source and configure per-node data source overrides so each node fetches its own data.

Mistake 4: Circular connections

Symptom: DAG cycle detected — the canvas may visually prevent this at drag time, or validation catches it.

Fix: The strategy must flow strictly left-to-right. The data flow path is: Data Source → Indicators → Conditions → Logic → Entry/Exit. Never connect a downstream node’s output back to an upstream node’s input. If you need feedback loops (e.g., an indicator that depends on a signal), use a different architecture: multiple strategies with Strategy Reference nodes, or a custom composite indicator.

Mistake 5: Empty condition

Symptom: Validation error “Condition inputs missing” (Rule 9).

Fix: Every condition needs at least a left-side input. If you only need a right-side level comparison (e.g., “Price crosses above daily pivot”), connect the level to right and the system auto-sets left to “price”. You don’t need to manually connect anything to left in that case.

Mistake 6: Filter not connected to entry

Symptom: Filter has no effect — backtest results look identical with or without the filter.

Fix: Filters must connect to an Entry/Exit node’s filter-* handles. A floating filter with only an input connection (e.g., a trend filter connected to an indicator) doesn’t do anything — it’s the gate output that blocks or allows entries. Make sure the filter’s gate handle connects to one of the entry’s filter-0..4 top handles.