· Acubic Research · 9 min read
What the Acubic Scenario Analysis Shows
Key takeaways
- The Acubic AI scenario simulation is a walk-forward backtest: it rebuilds the portfolio at every past rebalance date using only data that was available then, charges transaction costs on each trade, and reports the result as a hypothetical record.
- The output shows how the strategy would have behaved in the test window you choose, including a comparison to the S&P 500. These are measurements of one historical period, not predictions about the next one.
- Nine model limitations apply to the simulation output: they are published on the methodology page and include survivorship bias, execution cost gaps, and the possibility of regime change.
- A drawdown figure that exceeds your stated risk tolerance is useful: it means adjusting the inputs before connecting a broker, not discarding the method.
- Acubic does not promise returns and cannot predict short-term market moves. The scenario result is evidence about a historical period, not a commitment about the period ahead.
When you generate a portfolio in Acubic, the product can run an AI scenario simulation before you connect a broker account. The simulation shows how the strategy would have behaved on historical data, using the same construction rules as the live portfolio. A lot of users look at the output and wonder what exactly they are reading and how much weight to give it. The simulation is a tool for evaluating a strategy before committing real money, not a performance claim or a forecast. This article explains what the simulation produces, what each part of the output means, and how to use it sensibly alongside your risk constraints and the nine model limitations the methodology page publishes.
What the AI scenario simulation is
The Acubic AI scenario simulation is a walk-forward backtest. That phrase has a specific meaning: at every past rebalance date in the test window, the engine rebuilds the portfolio using only the data that was available on that date. It does not use prices, company financials or correlation estimates from later periods. It applies the same screen, rank and allocate steps as the live portfolio, buys the resulting weights, lets each position drift with its own returns until the next rebalance, and then repeats the process at the next rebalance date. Transaction costs are charged on every buy and every sell. The report shows what would have happened under those rules in that specific historical window.
This approach differs from a simpler backtesting method that fits a strategy once against the full historical period and reports how well it performed. Walk-forward testing repeatedly evaluates the strategy on data it has not yet seen at each step, making it considerably harder to produce an impressive result simply by adjusting parameters until they fit one particular period. The backtesting software page describes how the engine runs: for each rebalance date, it uses a rolling lookback window of data available up to that date, charges the transaction cost you can adjust (15 basis points per trade by default), and compares the result to the S&P 500. It also flags any known data limitations it encountered during the run.
The simulation is not a record of real trading. No money was placed, and nothing was actually bought or sold during the simulated period. The result shows what the construction method would have done, applied mechanically to historical data, subject to the costs and constraints described on the methodology page. Reading it as a record of what the strategy earned would misstate what backtesting can establish.
What the output shows
The simulation covers the test window you select. The key figures are:
- A cumulative return chart showing how the simulated portfolio would have grown over the test period, compared against the S&P 500 as a reference benchmark.
- A maximum drawdown figure: the largest peak-to-trough decline during the window, expressed as a percentage of the portfolio's value at the peak.
- A record of the transaction costs deducted across the full test period, based on the basis-point figure applied to every buy and sell.
- A note of any data limitations the engine flagged during the run, such as assets with insufficient history or points where the liquidity floor excluded an otherwise eligible holding.
These outputs describe what happened in that historical window. The cumulative return tells you what the strategy would have produced if it had been run mechanically on those exact dates with that exact data. The drawdown tells you the worst decline a hypothetical investor would have experienced during the period. None of these figures is a projection of what the same strategy will produce in the period ahead.
The comparison to the S&P 500 is a reference point, not an objective. The strategy is not designed to beat the index; it is designed to construct a risk-calibrated allocation based on your inputs and stated constraints. A period where the simulation underperforms the benchmark does not mean the construction method failed. It may mean that concentrated exposure to US large-cap equities, which the index represents, happened to be the dominant return source in that particular window. The question is whether the strategy behaved consistently with its design intent: managing risk across a diversified set of holdings according to your stated constraints. For more on how those constraints are applied, see how to read an Acubic portfolio proposal.
What the output does not show
The simulation cannot show what the strategy will earn in the future. No simulation can, because future prices are not in the data. The construction method uses historical returns, correlations and volatilities to build a risk-adjusted allocation; it does not project those inputs forward into price targets. Why Acubic does not predict the market explains this in detail: a rebalancing system closes a measured gap against a target; it does not place a bet on where any asset is heading.
The simulation also cannot show execution costs that it does not model. What the engine charges is a flat transaction cost on every buy and sell, plus any adjustments you make before running. What it does not model includes slippage, market impact, bid-ask spreads, partial fills, and each broker's own fees. Live orders face all of those frictions. The gap between the simulated cost and the live cost can be meaningful for strategies that rebalance frequently or hold many positions. The methodology page lists exactly what the simulation models and what it leaves out.
Similarly, the simulation cannot account for the data it cannot see. Its universe is built from instruments currently listed, which means companies that failed, were acquired or were delisted during the test window are absent from the data. Those companies are absent precisely because they performed poorly. Including only the survivors flatters the historical record: this is called survivorship bias, and there is no way to quantify exactly how much it affects any given result. The methodology page names this as one of its nine stated limitations.
The model limitations that apply
Nine model limitations are published on the methodology page. All of them apply to the simulation output. The ones most relevant to reading a scenario result are:
- Historical performance does not guarantee future outcomes. This is the most fundamental limitation. A simulation can show what the strategy would have done in one period; it cannot establish what it will do in the next one.
- Model assumptions may degrade in structural market regime changes. The correlation structure the allocation methods use is estimated from a rolling historical window. In severe drawdowns, correlations between risky assets tend to converge toward one, which is exactly the condition where diversification is expected to help most. The model adapts as new data arrives, but that adaptation is a lag, not an anticipation.
- Universes assembled from currently listed instruments carry survivorship bias, as described above.
- Execution quality in live markets can differ from simulated assumptions. Live orders fill at prices that differ from historical closing prices, and the difference tends to move against the direction of the trade.
- Testing many configurations against the same history raises the chance that a strong result reflects selection rather than signal. Walk-forward validation reduces this risk; it does not eliminate it. The article on backtest overfitting and walk-forward testing explains how to tell the difference between a strategy that captures something durable and one that fits historical noise.
These are properties of this class of model, not defects to be corrected. Any portfolio construction method that uses historical data has them. The methodology page publishes them because a user who understands them is better positioned to read the simulation output than one who does not.
How to read the simulation alongside your risk constraints
The most useful way to use the simulation is to check whether the drawdown in the historical record is consistent with the risk tolerance you stated in the risk quiz. If the worst historical drawdown for the strategy exceeds the decline you said you could accept, that is informative: the strategy's historical behavior was not consistent with your stated constraints, and adjusting the inputs is the appropriate response before connecting a broker.
The drawdown figure deserves more attention than the cumulative return. Return figures depend heavily on the specific period chosen. A simulation run over a window that happens to include a strong bull market will show higher cumulative returns than the same strategy run over a window that starts at a market peak. The drawdown figure is more stable across different windows, because it reflects properties of the strategy itself: how concentrated its holdings were, how correlated they became during the worst periods, and how the rebalancing frequency affected recovery time.
What to check when reading the output:
- Does the maximum drawdown fall within the range you said you could tolerate? If not, consider adjusting the risk level, the number of holdings, or the allocation method before connecting.
- Is the simulated turnover reasonable for your situation? A strategy that rebalances frequently generates more transaction costs in the simulation and will generate more of the unmodelled costs in live trading as well.
- Does the strategy's behavior in the simulation match what you would expect from the construction method you chose? A hierarchical risk parity allocation distributes risk across correlated clusters, so it will typically show lower drawdowns than a momentum-weighted strategy in periods when momentum reversed sharply. Knowing what each method is designed to do helps you read the output in context.
Re-running with different inputs
The simulation reruns when you change inputs. If the results suggest the strategy is not consistent with your constraints, adjusting the construction inputs is the right response: the ranking method, the lookback period, the allocation method, the number of holdings, or the risk constraints. Each change produces a fresh simulation from the updated inputs, and you can compare multiple runs to understand which choices drive which properties of the output.
What you should not do is adjust inputs until the simulation looks good and then stop. That is a form of overfitting: the inputs have been tuned to fit the historical period rather than to match your actual risk profile and investment goals. A result that required extensive adjustment to look acceptable deserves more scrutiny than one that looked consistent with your stated risk profile on the first run. The article on backtest overfitting and walk-forward testing covers this risk in detail, including why a large gap between how the strategy looked on the development data and how it performed on unseen data is a signal worth taking seriously.
The more productive question to ask when adjusting inputs is: what does this change do to the construction logic, and does that logic still match my actual goals? A shorter lookback window makes the construction more responsive to recent data; a longer one makes it more stable. A higher maximum concentration cap per asset allows the optimizer more room to weight positions according to their risk contribution. Each of those choices has a defensible rationale that is independent of what any particular simulation run showed.
Getting started
The AI scenario simulation is available after you generate a portfolio proposal. If you have not built one yet, the AI portfolio builder is the starting point. Set your goals and risk level, review the resulting allocation, and run the scenario simulation to see how the strategy would have behaved on historical data before connecting a broker account.
The simulation is one part of the evaluation process, not the whole of it. The methodology page documents the full construction method and all nine model limitations. Reading them before interpreting a scenario result is the intended path, not a precaution: the limitations do not make the simulation useless, but they do change what questions it can and cannot answer. Acubic does not promise returns and cannot predict short-term market moves. Use the scenario result as one input alongside your risk constraints and the documented method, and connect a broker when the proposal and its historical behavior are consistent with what you actually want.
Want to put this into practice? Explore the Acubic guides or see how the AI portfolio builder turns constraints into a structured portfolio.