How QUANTHEON Lab works — the engine, explained

A technical, vendor-neutral account of the machine behind the no-code interface: how a plain-English idea becomes typed data, runs through a deterministic backtester that never reads the future, is stress-tested for overfitting, and — at the portfolio layer — how capital is allocated with the same anti-overfitting discipline. No proprietary parameters, prompts or datasets; just the shape of the system and the science it rests on.

1. A strategy is data, not code

When you describe a strategy in words, the AI does not write a program that then executes. It emits a typed abstract syntax tree (AST) — a validated data structure describing entries, exits, indicators, sizing and risk. Nothing the model produces is ever eval‑ed. Before a single bar is simulated the tree is checked for well‑formedness: types must line up, referenced indicators must exist, and degenerate rules are rejected — e.g. an entry condition identical to its exit condition (a position that opens and closes on the same bar) is provably meaningless and is refused, not silently run. Treating the strategy as data is what makes the rest of the guarantees possible: the same tree can be hashed, versioned, diffed, mutated by a search, and compiled to standalone code with verified parity.

2. The deterministic kernel — the future is never in scope

The backtester is a single‑pass, event‑ordered simulator with three non‑negotiable properties:

• No look‑ahead. A decision made on bar t can only use information available at t; it fills at the next bar’s open. Bar t never reads t+1. This is the single most common way backtests lie, so it is enforced structurally, not by convention.
• Warm‑up padding where a cold start would lie. An indicator that isn’t formed yet emits nothing, so no strategy ever trades on a half‑formed moving average. But refusing to trade is itself a bias when the window is short: an SMA(200) eats 200 bars, which is a sliver of a long in‑sample leg and most of a ~315‑bar out‑of‑sample fold. Cold, that asymmetry draws the exact shape of “the edge collapsed out of sample” — measured on a real SPY strategy, one fold went from 4 trades to 14 once it was warm. So every walk‑forward fold and optimizer sub‑window is compiled from a pad of past bars that is then trimmed off, leaving the simulated window exactly as requested. The plain backtest you run yourself is deliberately not padded: it is the window you asked for, and padding it would silently move every number already shipped in a saved study, a track record or a reproducibility receipt.
• Costs are charged per fill. Commission, slippage and borrow are deducted on every execution. A gross‑only curve is a marketing number; the engine reports the net one.

3. Point‑in‑time data

Prices are survivorship‑aware, and fundamentals are joined as of their publication date, never their fiscal date — so a strategy can’t “know” an earnings figure weeks before the market did. The serving layer is read‑only with daily staleness checks. Good data hygiene is unglamorous and decisive: most of the difference between a backtest and reality is smuggled in here.

4. The anti‑overfitting stack

A single backtest number is an anecdote. To separate a repeatable edge from a lucky fit, the same result is put through four independent lenses (each explained in depth in its own guide):

• Out‑of‑sample. Score only on data the optimizer never saw.
• Walk‑forward. Re‑optimise on a rolling window, trade the next unseen segment, repeat — a 100% out‑of‑sample curve.
• Monte‑Carlo. Reshuffle the trade sequence a thousand times by default, up to five thousand, to map the distribution luck alone could produce — not just the one path that happened.
• Deflated Sharpe ratio. Discount the Sharpe for the number of configurations tried, its skew and kurtosis, and the sample length. Testing many variants inflates the best one; deflation gives the selection‑bias‑adjusted number (Bailey & López de Prado, 2014).

New to this? Start with what overfitting is and how to detect it.

5. Allocation intelligence — the same discipline, applied to capital

Most tools stop at the single strategy. But a portfolio raises a second, subtler overfitting question: how do you split capital across holdings without fitting the split to one history? QUANTHEON Lab’s portfolio layer answers it with the same anti‑overfitting stance.

Shared capital, not independent backtests

Testing each holding in isolation with a full bankroll each is convenient and wrong — you cannot deploy 100% of the same dollars in ten names at once. The engine simulates one cash account where positions compete for capital bar‑by‑bar: a holding that steps to cash frees capital that is redistributed to the holdings that want it, subject to a gross‑exposure cap. What a return‑only blend hides — how much of the book is actually deployed at any moment — becomes an explicit, observable curve. The mechanism, in plain language: why a shared account is not a blend.

Allocation policies, computed without look‑ahead

Instead of static weights, capital can be allocated by a policy recomputed on a schedule from trailing risk only (never the future), with every holding held inside a [min, max] band:

• Equal weight (1/N) — the humble baseline.
• Risk parity (inverse‑volatility) — each holding contributes roughly equal risk.
• Inverse variance — a sharper de‑risking of the wild assets.
• Minimum variance and maximum Sharpe — the box‑constrained optimisations, offered but treated with suspicion (they chase the past).

The 1/N honesty test — which policy survives, not which wins

Here is the crux. Optimised allocations almost always look best in‑sample because they fit the realised covariance — the classic allocation‑level overfit. DeMiguel, Garlappi & Uppal (2009) showed that naive equal‑weight is a punishingly hard benchmark to beat out‑of‑sample for exactly this reason. So the engine doesn’t ask “which policy has the highest number?” — it asks “does any policy’s edge over equal‑weight clear the statistical noise, and does it hold up out‑of‑sample?”

One run evaluates every policy on the same book, net of transaction cost on the rebalancing turnover, then:

• splits the window and checks whether the in‑sample leader is still a leader out‑of‑sample;
• tests each policy’s Sharpe difference vs. 1/N for significance, using the standard error of a Sharpe ratio (Lo, 2002) — leaning deliberately toward “inside the noise” rather than crowning a fragile winner;
• returns a deterministic verdict (never an LLM): a policy is recommended over 1/N only if its edge clears the noise bar and generalises out‑of‑sample; otherwise the honest answer is the robust baseline. The recommendation is never allowed to be one the results themselves show is worse.

The frontier (return vs. risk, net of cost, with turnover and drawdown), a stacked view of how weights evolve, and per‑holding risk‑contribution bars (the proof that risk‑parity actually equalises risk) are all shown alongside — so the number is legible, not a black box.

The ceiling, and when the book is allowed to trade

Capital moves on three occasions only: a sleeve's own position changes, the roster changes, or a scheduled rebalance falls due — and even then only if what a sleeve is funded with differs from its mandate by enough to be worth trading on. A per‑holding ceiling caps how much of the account any one name may absorb when the others sit in cash and lend theirs; it is brought back inside at those same events rather than bar by bar, because enforcing a limit continuously means re‑cutting the book almost every bar and paying the cost of it. The drift above the ceiling in between is reported, not hidden.

To watch all of this happen on a real book, step by step: the Portfolio Lab walkthrough. For the single‑strategy analogue — one set of rules across many instruments, graded as an average rather than a blend — multi‑asset backtesting.

What the engine deliberately does not do: leverage (the holdings' shares are a partition of the account's own value, so deployed capital cannot exceed 100%), volatility targeting, and per‑asset parameter tuning — fitting a different parameter set to each instrument is overfitting each one.

6. The AI research desk — proposes, never decides

The language model is a research assistant, not an oracle. It translates ideas, evaluates results and proposes fixes — but it cannot manufacture an outcome. Every proposal it makes re‑enters the same typed‑AST gate and the same deterministic checks as anything a human builds; there is no privileged path. Promotions are gated by a deterministic veto, and nothing is auto‑promoted. If the model is wrong, the engine catches it exactly as it would catch a human’s mistake.

7. Regression armor

Correctness that isn’t pinned rots. 2,900+ tests gate every push — the engine suite and the interface suite, both, and one red blocks the deploy. Every bug that is ever fixed becomes a permanent test, red forever if it returns; and intended behaviour is pinned too, so it can’t be “fixed” away by a well‑meaning change. The origin story is a real one: an imported strategy once passed every structural check and still traded 7× too often. “It runs” and “it’s correct” are different pull requests — that incident is now a test that can never come back.

8. What we do not claim

Honesty cuts both ways. A backtest — however clean — is evidence, not a promise. The engine does not predict the future, does not guarantee live results, and does not remove market risk; it removes the self‑deception that makes a fragile idea look robust. Out‑of‑sample survival raises the odds an edge is real; it does not certify it. Forward‑tracking a promoted strategy on genuinely unseen bars is the only honest continuation, and the product treats it that way.

Keep reading