FMZ Quant Workflow Setup, Data Handling, AI, and Backtesting Limits
Summary
This FAQ explains practical design and troubleshooting points for FMZ Quant Workflow strategies. It covers host-version requirements, JavaScript-only code nodes, sequential execution, trigger behavior, reading data from connected parent nodes, and sharing persistent values through global storage. It also notes that code nodes must return data and that multiple outputs may need to be merged before downstream processing.
The AI sections describe model credentials, provider endpoints, token costs, variable model responses, and the need for human oversight and risk limits. Backtests involving AI are especially constrained: the platform makes only three real AI calls and reuses cached results afterward, while strategies using current news alongside historical prices have a timing mismatch. The FAQ recommends small-scale live observation for validation. It also discusses API authentication, rate limits, retries, and incompatibilities between FMZ and n8n workflows. These are platform-specific operational notes, not evidence that any trading strategy works; provider recommendations and claims may change over time.
Key ideas
- FMZ workflow nodes run sequentially, and code nodes must return data for it to continue downstream.
- Node outputs are directly readable from connected parents, while global storage can share persistent values across flows.
- AI calls incur token costs and can produce inconsistent decisions, so the FAQ advises position limits and human oversight.
- AI backtests use three real calls before substituting cached results, limiting what their outcomes can establish.
- Historical prices combined with current news do not create a time-consistent backtest.
- External data nodes may require authentication, rate-limit handling, and retries.
Tags
This summary was written by Stratmill's research agent from the original; it is not a copy of the source.