Fusion Indicator Suite — V1.0 Known Limitations & Workarounds

Last updated: 2026-06-20 · Applies to: V1.0

Fusion is a deep, multi-component system — a visual Builder that compiles to a portable SetupID, a live execution indicator (Fusion Indicator), an automated strategy (Fusion Strategy), an optimizer (Fusion Optimizer), and on-chart companions (Echo, Signal). The items below are the known edge cases in V1.0. Most users will never encounter them; each one has a workaround or is on the roadmap. This page exists so that if you do hit one, you get a straight answer and a path forward.

How to read each item: What you may see → Why it happens → Workaround → Status.

1. Multi-Timeframe & Secondary-Series Blocks (the “scalar” cases)

Fusion blocks are multi-timeframe aware, but how a block reads a secondary series (a different instrument or timeframe than the chart) depends on the block type. These are the places that shows.

1.1 SignalProcessor methods over a secondary timeframe

• What you may see: A SignalProcessor method fed from a secondary series whose timeframe differs from the chart can over-sample — its output looks like a smoothed/averaged version of the primary rather than the true secondary-bar reading.
• Why: The method’s internal window advances once per chart bar, not once per secondary bar.
• Workaround: To pull a value off a different timeframe, use a standard **Indicator block** pointed at that secondary series — Indicator blocks handle multi-timeframe correctly. Reserve SignalProcessor methods for same-timeframe inputs.
• Status: On the V1.1 roadmap (per-secondary-bar advance gating).

1.2 OrderFlow block → Result plot, differing volumetric timeframe

• What you may see: In the Builder, an OrderFlow block wired directly to a Result plot can appear one bar behind when its volumetric series timeframe differs from the chart. The live Fusion Indicator plots it correctly.
• Why: Builder plot alignment for a differing-timeframe volumetric series.
• Workaround: Match the volumetric timeframe to the chart timeframe, or read the value in Fusion Indicator / Fusion Strategy (correct there).
• Status: On the roadmap.

1.3 Multi-series Strategy — hosted indicator panel not drawn

• What you may see: When a Fusion Strategy uses a secondary series, the embedded “Fusion Indicator [Strategy]” sub-panel is not drawn on the chart. **Execution is correct** — the strategy trades on the configured secondary series.
• Why: NinjaTrader does not permit a chart-hosted indicator to add its own data series. Fusion adds the secondary at execution time instead, which means that instance cannot also render its own panel.
• Workaround: Drop a standalone Fusion Indicator with the same SetupID on the chart for visualization. The strategy’s own signal background stripes and SL/TP flags still render normally.
• Status: A chart-independent visualization path is on the roadmap.

2. Warm-up & Early-Bar Visuals

2.1 NaN warm-up feeding an accumulating indicator

• What you may see: A SignalProcessor/Math output that is undefined (NaN) during its warm-up, feeding an accumulating indicator (SMA / EMA / SUM), can blank that indicator for the whole session.
• Why: An accumulator folds the warm-up NaN into its running total permanently (NaN ± x = NaN).
• Workaround: Read the value through a Result block, or place the accumulator upstream of the warm-up source.
• Status: Hardened in Fusion Indicator; remaining Builder parity on the roadmap.

2.2 MIN / MAX transient floor on early bars

• What you may see: A windowed MIN/MAX fed directly by a warm-up source may show a brief 0.0 floor on the first few plotted bars; it self-heals once warm-up completes.
• Why: The window’s initial seed is MIN-absorbing during warm-up.
• Workaround: None needed — it self-corrects within the warm-up window.
• Status: Accepted V1.0 behavior.

2.3 Body parameter badge blank on default blocks

• What you may see: The small parameter badge on an Indicator / SignalProcessor block body (e.g. P:14) is blank until you edit that parameter once.
• Why: The badge reads the stored value; an untouched-default block has none to show.
• Workaround: Edit the parameter once to populate it.
• Status: Deferred to V1.1.

3. Builder Canvas Rendering

3.1 Presentation needs one chart click after F5

• What you may see: After an NT8 F5 reload, presentation fills / lines / markers in the Builder may not draw until you click the chart once.
• Why: A chart interaction is needed to kick the first presentation render after reload.
• Workaround: Click the chart once after F5. (The live Fusion Indicator renders the same SetupID without this step.)
• Status: On the roadmap.

3.2 Fill region flash

• What you may see: A fill region may briefly appear then disappear in the Builder. The live Fusion Indicator is correct.
• Workaround: Use Fusion Indicator / Echo for displayed fills if needed.
• Status: On the roadmap.

4. Fusion Strategy & Risk

4.1 Unique Entry signal names required (multi-entry)

• What you may see: A template with two or more Entry blocks is rejected (visible soft block) unless every Entry has a unique, non-placeholder Signal Name.
• Why: NinjaTrader’s managed protective orders are keyed per unique signal name; a duplicate name would cross-link stops/targets.
• Workaround: Give each Entry block a distinct Signal Name.
• Status: By design (safety).

4.2 One Fusion Strategy per account + instrument

• What you may see: Running two Fusion Strategy instances on the same account and instrument is unsupported in V1.0 — order names can collide and one instance’s exit can interfere with another’s protective exit.
• Why: Shared managed-order namespace on one account/instrument.
• Workaround: Isolate by instrument and/or account.
• Status: Unsupported in V1.0.

4.3 Position state across the historical → live transition

• What you may see: On the hand-off from historical backtest to live (or on enabling a strategy while an account position already exists), the strategy’s view of position can briefly differ from the account until it reconciles.
• Why: NinjaTrader replays history and then hands to realtime; reconciling a pre-existing (“hang-over”) position is inherently timing-sensitive. This is the same tradeoff space all NT8 strategies operate in.
• Workaround: Start strategies flat where practical. The Fusion Risk Engine and the strategy’s re-protect logic guard account-level risk during the transition.
• Status: Within standard NT8 strategy tradeoffs; refinements ongoing.

4.4 Risk AddOn flatten disables active strategies (NT behavior)

• What you may see: When the Fusion Risk Engine fires its account flatten, NinjaTrader disables active strategies on the targeted account/instrument.
• Why: This is NinjaTrader’s documented, intentional response to an account flatten — it is the kill-switch working as designed.
• Workaround: Re-enable strategies manually after the session resets.
• Status: By design (NT8 behavior).

4.5 Programmatic strategy enable/disable is not supported by NinjaTrader

• What you may see: The control-panel “Enable” indicator is a read-only run-state badge, not a button.
• Why: NinjaTrader provides no supported way to enable/disable a strategy from code.
• Workaround: Enable/disable strategies in NinjaTrader’s Strategies tab.
• Status: NT8 platform limitation.

4.6 Interactive Brokers

• What you may see: Interactive Brokers is not validated for V1.0.
• Workaround: Use a supported/validated connection for live automated execution.
• Status: Not validated for V1.0.

5. Data & Compatibility

5.1 Custom / third-party bar types

• What you may see: A custom or third-party NinjaTrader bar type referenced in a SetupID / data-source selector falls back to Minute.
• Why: V1.0 encodes only the standard NinjaTrader bar-period types.
• Workaround: Use standard NT bar types for secondary series.
• Status: On the roadmap.

5.2 OrderFlow blocks require an OrderFlow+ subscription

• What you may see: OrderFlow blocks produce blank/NaN output without an active NinjaTrader OrderFlow+ subscription. The control center shows a passive status row and the OrderFlow block properties show the notice.
• Why: Volumetric/OrderFlow data requires NinjaTrader’s OrderFlow+ entitlement.
• Workaround: Subscribe to OrderFlow+, or build without OrderFlow blocks.
• Status: Platform entitlement (by design).

5.3 Pre-V1.0 templates: re-save to regenerate the SetupID

• What you may see: A template created before V1.0 that uses a non-commutative Math/ Condition operation (e.g. only Input B wired, Close − SMA) may produce inverted output.
• Why: The SetupID format was finalized for V1.0.
• Workaround: Open the template in the Builder and save once to regenerate the SetupID.
• Status: One-time migration step.

5.4 Custom / third-party indicators may not plot in the exported product

• What you may see: An Indicator block pointing at a custom or 3rd-party indicator (one not built into NinjaTrader) may show no plot / no output when run from the exported product, even though it worked while you were designing in the Builder.
• Why: The exported product bundles NinjaTrader’s built-in indicators; a custom or 3rd-party indicator that lives only on your machine isn’t bundled, so it can’t be hosted at runtime. It does not crash — the block simply produces no output.
• Workaround: Use NinjaTrader indicators for exported strategies. If a signal never appears, the indicator likely isn’t compatible. (The Builder shows a note when it detects a likely 3rd-party indicator.)
• Status: Planned enhancement for a future version.

6. Companions (Echo & Signal)

6.1 Fusion Echo — presentation fills do not follow displacement

• What you may see: Echo mirrors plot lines with displacement, but |PRES: fill regions are drawn without displacement.
• Why: Displaced-fill support is deferred.
• Workaround: Use the Builder panel or Fusion Indicator for displaced-fill visualization.
• Status: Deferred to V1.1.

6.2 Fusion Signal is a design-time (Builder) companion

• What you may see: Fusion Signal pairs with the Builder for designing/visualizing a signal. Pairing it with a running Fusion Strategy’s embedded indicator is not a supported V1.0 workflow.
• Why: Fusion Signal reads a paired producer; in a multi-series strategy that producer is not chart-discoverable (see 1.3).
• Workaround: Use Fusion Signal with the Builder; for a strategy, drop a standalone Fusion Indicator and pair to that if needed.
• Status: Chart-independent pairing on the roadmap.

7. AI Studio & ONNX (optional / advanced)

7.1 Strict fail-closed feature mapping

• What you may see: An ONNX model whose required inputs are not all wired produces no output (NaN) rather than guessing.
• Why: Fail-closed is intentional — a model fed the wrong feature is worse than no output.
• Workaround: Wire every required model input, or choose a chart-data input source.
• Status: By design.

7.2 Target_Regime training metrics can be optimistic

• What you may see: AI Studio’s reported metrics for the Target_Regime family can look better than live performance.
• Why: That target is fit on the full dataset (not strictly forward-looking).
• Workaround: Treat Target_Regime results as educational; validate forward.
• Status: Documented; deferred.

7.3 Training export drops warm-up / incomplete rows

• What you may see: Exported training data has fewer rows than chart bars.
• Why: Rows where any required feature/label is NaN, blank, or in warm-up are dropped to protect training truth.
• Workaround: Expected behavior — none needed.
• Status: By design.

Reporting an issue or requesting a feature

If you hit something not listed here, or a workaround above doesn’t fit your setup, contact support with: your SetupID, the chart instrument + timeframe(s), any secondary series, and a screenshot. Most edge cases have a quick workaround, and confirmed reports help prioritize the V1.1 roadmap.