Why Screener and Strategy Belong in One Optimization Loop

Most systematic stacks split the work in two. First, a screener ranks names and applies entry gates. Then a separate trading layer chooses stops, holding rules, and exits. Each piece is tuned on its own objective, then bolted together. The final portfolio is expected to inherit the quality of both halves.

That split is convenient for engineering owners and monorepos. It is a poor match for how portfolio risk actually forms. Selection tightness, exit timing, turnover, exposure, and drawdown move together. A candidate that looks sharp as a ranking model can look weak once stops and holding limits run. A stop policy that looks clean on a fixed signal stream can look brutal on a looser entry set.

KreamEdge does not train a screener first and hand its picks to a separately optimized strategy. It evaluates one candidate end to end. That candidate can change the score formula, the entry gates, the buy and sell rules, the stops, and the holding exits in a single trial. Fitness is assigned only after those choices produce dated signals, flow through a portfolio simulation, and hit return, drawdown, exposure, and sample-size constraints.

This note explains the design, the interactions it captures, the shared research and production path that reduces mismatch, and the search structure that keeps a large joint space honest. It is research and engineering methodology, not a claim of edge or a promise of future returns.

Key points

• Screener selection and trade management are one system in production. Optimizing them separately optimizes two proxies and assumes the composition holds.
• A candidate is one configuration applied to an entire universe. Nothing is fitted per ticker, and the timeframe is not a search dimension. This is not a symbol-by-timeframe sweep.
• In this stack a single trial changes score weights, entry gates, buy and sell rules, stops, and holding exits together. Fitness is assigned only after a portfolio simulation with costs, stops, and risk barriers.
• Research and live screening call one shared signal engine. That removes the common drift where a backtest reimplements the screener in a second dialect and slowly diverges from production.
• A naive joint search treats new categorical rule pairs unfairly, because each is first judged under weights fitted to the incumbent. The remedy is per-pair inner optimization, successive halving, then a final joint pass over the shortlist.
• The universe has to be built point in time. A joint optimizer running on a survivorship-biased universe just reaches a wrong answer more efficiently.
• Overfitting announces itself before the statistics do: the set of justifications keeps growing. Fix the decision space, the objective, and the acceptance thresholds before the run, not after seeing the curve.
• No head-to-head benchmark against a sequential screener-first pipeline is claimed here. The engineering wins cut evaluation cost; they do not certify edge.

What one candidate is, and what it is not

The most common question about this design is whether “screener plus strategy in one loop” means fitting a separate configuration for each symbol, or sweeping a strategy across symbols and timeframes to find the combinations that worked. It means neither, and the difference is worth stating plainly before any of the mechanics, because the two designs fail in unrelated ways.

A candidate here is one configuration applied to the entire universe. The same score weights, the same entry gates, the same buy and sell rules, and the same stop and holding policy run on every name the screener admits. The decision vector described below contains no symbol dimension. Nothing is tuned per ticker.

The timeframe is not a search dimension either. Bar size is fixed by the data preparation stage and held constant for the whole run, so the optimizer cannot go shopping for the resolution that happened to flatter a rule.

Inside a single candidate, the division of labor is:

• The screener decides what is eligible on each bar. It scores the universe, applies liquidity, volatility and slope gates, and hands on the admitted set.
• The strategy decides what happens to whatever the screener admitted: entry timing, stops, freeze windows, holding limits, exits.
• Neither half gets its own score. One fitness value comes back per candidate, and it is a portfolio outcome.

Contrast that with a per-symbol or per-timeframe sweep. That approach returns many configurations instead of one, and it leaves an unstated selection problem behind: something still has to choose which configuration to trade, and that choice is itself made on the same history that produced the candidates. It also multiplies the comparison count, so the best cell in a symbol-by-timeframe grid is the cell most likely to be luck. A universe-wide candidate scored once at the portfolio level has no such cell to pick, which is the whole point of the arrangement in the image above.

The mismatch tax of decoupled pipelines

A decoupled pipeline optimizes proxies, then hopes the composition holds. Typical failure modes:

• Proxy fitness. The screener is scored on ranking quality, hit rate, or chart attractiveness. None of those is identical to post-cost portfolio outcome under real exits.
• Frozen partner parameters. When you tune entries, exits stay fixed. When you tune exits, entries stay fixed. Interactions never enter the search.
• Research and live drift. The backtest reimplements screener formulas. A later live change: weight tweak, gate floor, rule dialect, does not automatically relocate into historical evaluation.
• Execution blind spots. Selection that ignores stop distance, freeze windows, and holding caps systematically understates turnover risk and overstates productive exposure.

Call this the mismatch tax. You pay it in recycled trials, false confidence from in-sample ranking metrics, and production trades that never quite match the notebook that approved them.

What “unified” means in this stack

Unified does not mean “dump every knob into one giant random search.” It means three concrete design choices.

1. One mixed decision vector

A trial is a complete configuration, not a patch on the previous one. The decision space mixes:

• 13 continuous screener weights that build the trend and quality score and set gates: NATR range, minimum score, long-term and medium-term slope floors, volume-slope floor.
• Categorical buy and sell rule expressions chosen from a domain-specific rule set.
• Trade-management variables: trailing stop, lookback stop, freeze settings, maximum holding duration, trend exit threshold.

The optimizer samples floats, integers, and categoricals in one trial, then decodes them into a full evaluation payload. The evaluation server restores a clean baseline before each candidate so trials stay coherent rather than path-dependent mutations of each other.

2. One shared signal engine for research and live screening

Live screening and historical evaluation both construct the same analysis object with the candidate’s weights, buy and sell rules, stops, and targets. Both call the same technical pipeline and the same signal function. Weights, DSL rules, liquidity and volatility gates, slope floors, long and short symmetry, and regime entry masking share one implementation.

That does not erase every live versus backtest difference. Live screening still reads the current close. A backtest normally executes a signal at the next bar’s open. The important win is narrower: you remove the common failure where the optimizer reimplements the screener in a second dialect and drifts away from production.

3. Fitness only after portfolio simulation

For every candidate the evaluator regenerates per-symbol signals across the universe, runs the portfolio time loop with costs and allocation, applies stops and holding exits inside position management, then builds a multi-metric objective. The returned vector includes a combined objective plus return and risk statistics: CAGR, drawdown, Sharpe, Sortino, Calmar, stability, win rate, trade count, capital efficiency, Kelly edge. Soft barriers penalize excess exposure, ulcer index, drawdown, and statistically thin trade counts.

Selection quality is never scored as “nice charts.” It is scored after execution realism and risk controls have had their say.

Why the coupling is not optional

Signal selectivity and exit policy are not independent knobs with additive effects.

• Raise the minimum score and you usually cut trade count. That only works if stops and holding limits still leave enough sample for the risk metrics to mean something.
• Loosen entry gates and average holding success becomes an exit problem: trailing stop distance, trend exit threshold, and freeze windows now dominate turnover and drawdown.
• Buy and sell rule pairs interact with the weight vector. A rule pair that looks weak under weights tuned for a rival pair can look strong once its own weights and stops are allowed to adapt.

A multivariate search that observes the full portfolio result can discover those interactions. A sequential “fit screener, freeze it, fit exits” pipeline holds the partner half constant by construction. The fair wording is careful: the architecture can surface interactions that sequential calibration holds constant. This note does not claim a measured alpha or latency uplift against a published sequential baseline. No such head-to-head lives in the current repository evidence.

The universe is a decision variable too

One coupling sits upstream of everything above. The joint loop scores a candidate against the universe it is handed. If that universe is built from the names that survived until today, the loop tunes selection rules against a set nobody could have screened at the time.

The point was made bluntly on the Better System Trader panel of February 2024. Mike, who has run a trend-following fund since 2011, put the selection layer in front of everything else:

You have to have a selection methodology that selects instruments available at the time. … You need to have this screener that scans all the markets available, and then goes into your when to buy, when to sell, how much to buy and sell.

Mike, trend-following fund manager, Better System Trader episode 223

His worked example was futures, where a test starting in 1980 or 1985 will silently omit contracts that traded then and no longer exist, and which a trader of the period would therefore have held. He then named the failure directly. A universe assembled today and replayed backwards is not a historical universe at all:

Why would you be selecting those in 1985? Why would you be selecting those in 1995, or five years ago, ten? You probably wouldn’t. So you need to have the selection methodology as well. You can’t be bringing your current markets back, because when you’re starting your test, you’re bringing them back from the future. Can’t do that.

Mike, trend-following fund manager, Better System Trader episode 223

The equities version came up immediately afterwards on the same panel: people backtest “the stocks in the S&P 500” while ignoring that index membership changes, so the compounders get counted and the delisted names never appear. Kashyap, a fundamental analyst on the panel, gave the retail-marketing version of the identical error, pointing at Indian mutual fund advertisements showing what a 2014 investment would be worth today, and at articles computing what a thousand dollars in Nvidia would have become. Nobody could have made that selection at the time, which is why he called the ads “completely out of context”. The same reader who supposedly bought Nvidia might equally have bought Pets.com.

Whether the bias is fixable at all depends on the asset class. Pavel of Robuxio, who runs systematic stock and crypto portfolios, drew the line at the point where the data runs out. Equity traders can buy a survivorship-bias-free database off the shelf for a few dollars from a vendor such as Norgate. The crypto equivalents, he noted, either do not exist or are obscure enough that most people never find them, which he considered a huge issue.

The consequence for a unified loop is direct. Screener weights, gate floors, and rule pairs will fit themselves to whatever survivorship the universe carries. An end-to-end objective makes that fit tighter, not safer. A joint optimizer over a contaminated universe is a more efficient way to reach a wrong answer.

Two requirements follow:

• Universe membership has to be evaluated per bar, not once at the start of the run. Delisted, merged, and demoted names must stay in the historical universe for the window in which they were tradable.
• Data availability differs sharply by asset class. Point-in-time constituent history for equities is a solved commercial problem. Crypto is not: listings, delistings, and dead pairs are poorly archived, so a universe rebuilt after the fact carries survivorship risk that no amount of joint optimization removes.

This note describes the optimization architecture, not the data layer. Treat point-in-time universe construction as a separate prerequisite. If it is not solved, the loop below measures something narrower than it appears to.

Overfitting has a tell: the justification set keeps growing

A joint optimizer is, structurally, a machine for adding justifications. Thirteen weights, a categorical rule pair, and a stop policy give a search many ways to explain a good equity curve. The same panel described the human version of that failure, which is worth borrowing because the tell is far easier to spot in a person than in a loss surface.

Pavel put the root cause first, and it is not a statistical mistake:

Curve fitting has a lot to do with novice traders that are trying to get rich on historical data. They just can never trade the history. When I’m talking with new traders, they are always thinking about historical data as if the future will be almost the same, which it never will be. It will always be very different.

Pavel of Robuxio, Better System Trader episode 223

Kashyap described how the fit announces itself before any statistic does, using the 2022 oil bulls as his case. The thesis started with two numbers, demand around 103 million barrels a day against supply around 102, so inventories draw down and price rises. Then it acquired a damaged pipeline, then natural gas disruptions, and eventually German and Norwegian power prices were being charted as part of the argument for a permanent oil bull market. His diagnosis of that drift is the transferable part:

When you see this kind of creep of the stats that you look at to justify your case, that’s when you know that you’re getting into that overfitting stage, because you are adding more and more news items which aren’t exactly relevant but they kind of help you make your case.

Kashyap, fundamental analyst, Better System Trader episode 223

He offered a second instance at a smaller scale. A mining newsletter with a strong record of finding small caps had, by its August 2007 issue, narrowed its argument to the availability of drilling rigs and assay labs. Once a case descends to that level of minutiae, he suggested, a top is usually close. Both examples share a structure worth naming: the evidence base grows while the conclusion stays fixed.

Mike supplied the operational test. It costs nothing, and it is precisely the check no search loop can run on your behalf:

Experience helps with this too. If you have an answer already in your mind that you want, you’re probably in trouble. You have to stay honest with “let’s see if this works” versus “I want this to work, so let’s make it work.”

Mike, trend-following fund manager, Better System Trader episode 223

Translated into this architecture, the risk is not that the optimizer holds many parameters. It is that the researcher keeps adding them after seeing the result, then reports the last configuration as though it had been specified first. Fixing the decision space, the objective, and the acceptance thresholds before a run is what separates a joint search from a growing justification set. That is the whole purpose of the constraints described further down under what stays fixed on purpose.

How one evaluation cycle runs

Strip the plumbing and the cycle is short:

1. Build one mixed decision space: weights, stops, duration and trend targets, freeze settings, buy and sell indices.
2. Sample one complete trial and decode it into an evaluation tuple.
3. On the evaluation server, restore a clean baseline, apply rules and trade-management settings, apply weights, run the stage evaluation.
4. Regenerate dated long and short signals across the whole universe with the shared signal engine.
5. Simulate the portfolio: allocation, costs, stops, holding limits, trend exits.
6. Return metrics plus barrier penalties as one objective vector for single-objective selection or a multi-objective Pareto run.

Compact flow:

[score weights + entry/exit rules + stop/holding parameters]
                |
                v
     shared signal generation (same as live screener)
                |
                v
      dated entries/exits across the universe
                |
                v
 portfolio simulation, costs, stops, allocation
                |
                v
metrics + risk / trade-count barrier penalties
                |
                v
      scalar objective or Pareto vector

Engineering that makes the loop practical

End-to-end evaluation only works if each trial is cheap enough to rerun often. The stack spends its compute once where possible:

• Prepare data and reusable indicators once before serving candidate jobs. Trials normally evaluate; they do not reload market history.
• Share prepared frames across workers with read-only, copy-on-write data so recycled processes skip preparation.
• Parallelize on two axes: concurrent trials from the optimizer, and per-symbol signal generation inside a trial.
• Cache complete candidate keys so duplicate configurations do not pay a redundant round trip.
• Fail fast on impossible regions (for example a NATR minimum that is not below the maximum) before signal generation.
• Precompute global regime state once per job from the broad market series and pass it into every symbol, instead of recomputing the same market context on each name.
• Use type-aware search operators: continuous crossover for weights and stops, categorical exchange for rule indices, so adjacent integer labels are not treated as near neighbors when the index order has no meaning.

These are computational advantages. They are not evidence that the resulting strategy is more profitable. Treat them as the cost structure that makes an honest end-to-end objective affordable.

Do not oversell a naive joint search

A frank unified design admits a real failure mode. If you free every buy and sell pair and every weight at once, search can get confounded. A new rule pair is often first tested under weights still adapted to the incumbent pair. It looks weak, gets discarded, and never receives a fair calibration budget. Historical runs in this codebase concentrated a large share of evaluations on one pair even after mixed crossover and parallel-sampling safeguards.

There is a harder version of this critique worth stating. On the same panel, Pavel of Robuxio described the opposite design: no parameter optimization at all.

I went to extreme oversimplification. I never optimize any parameter in a trading strategy. My strategies are one entry condition, one exit condition and one regime filter, and then some ranking. I’m trying to keep everything as simple as possible on one strategy level, and going a little bit more advanced on the portfolio level. This is how I got rid totally of the need of some kind of overfitting.

Pavel of Robuxio, Better System Trader episode 223

The complexity does not vanish under that design, it relocates. Stability gets built at the portfolio level, by running mean reversion alongside trend so that weakly correlated strategies can share the same capital. On his account the simplification followed from that discovery rather than preceding it: once portfolio-level combination was doing the work, strategy-level tuning stopped earning its keep.

He also pointed at a source of decorrelation that requires no new research at all, which is the part of the position hardest to argue against on cost grounds:

You can basically have the same strategy, and if you run it on the small time frame, like 3x more or so, the correlation coefficient can get to 0.3, 0.25, which is something which is very interesting. You don’t need to find anything else, you just can reuse the same strategy on slightly lower time frame and get quite different results.

Pavel of Robuxio, Better System Trader episode 223

The claim is that a strategy you never fit cannot be overfit, and that correlation between strategies is a more dependable lever than parameter quality. That position is coherent, and a smarter search loop does not answer it. Only out-of-sample evidence does: the fitted joint candidate has to hold up where the unfitted simple one does not. Worth noting that the 0.25 to 0.3 figure is one practitioner’s recollection on a live panel, not a published measurement, and correlation estimated on a short crypto history is itself unstable.

The failure at the other extreme deserves a mention too, because it is what an unconstrained objective looks like when someone stops asking questions. Jason of Against All Odds Research described a fund that believed it had removed losing years entirely:

They give me a call and they go, I figured out this system, it wins every single time, we always make money. I go, that’s impossible, and to me that sounds like you’re ready to blow up. And he goes, no no, it wins every time, it never loses money. So I go, send me what you’re doing and I’ll backtest it. I’m like, dude, this system actually blows up every four or five years, what are you talking about? He goes, oh, you just got to forecast recession, so then you’re fine.

Jason of Against All Odds Research, Better System Trader episode 223

The system did not win every time. It carried an unstated regime assumption, and that assumption was doing the work the backtest appeared to be doing. A joint objective only helps here if the barrier constraints and the evaluation window are wide enough to contain the regime the assumption hides inside. KreamEdge has not verified this account, and no fund is named on the panel; it is reported as told.

The practical remedy is a two-level workflow, not a retreat to fully decoupled objectives:

1. Give every candidate buy and sell pair its own inner optimization so weights and exits can adapt to that pair.
2. Use successive halving to keep the strongest pairs and drop the rest early.
3. Run the final joint optimization with weights, exits, and pair genes free, but only over that shortlist.

That is the defensible claim. Evaluate screener selection and trade management with the same end-to-end objective. Structure the search so categorical strategies receive a fair calibration budget. Unified objective first. Fair search geometry second.

What stays fixed on purpose

Not everything is a free variable, and that is intentional:

• Regime thresholds can sit as server-level context rather than per-candidate genes, so the optimizer does not quietly re-label market states to chase in-sample luck.
• Known-good weights can be frozen to cut dimensionality once a region has been stress-tested.
• Strategy expressions can only change when the preparation phase already materialized every required indicator family. Otherwise the job fails closed and asks for a restart with a sufficient preparation set.

Constraints like these keep the joint loop from becoming an unrestricted story factory.

What this changes for a builder

If you build your own systematic stack, the useful takeaways are operational, not doctrinal:

• Score selection after portfolio simulation, not before it.
• Share one signal implementation between research and live screening.
• Treat entry tightness and exit policy as one coupled system when you search.
• Pay the engineering cost of prepare-once, evaluate-many, or the joint loop stays too expensive to run honestly.
• If the space includes categorical rule pairs, give each pair a real calibration budget before the final joint pass. Successive halving is a practical pattern.
• Prefer multi-metric objectives and Pareto fronts when return and risk trade off. Hide less in a single arbitrary score.
• Build the universe point in time before you tune anything on it. Survivorship in the candidate set gets absorbed straight into the screener weights.
• Stress the winner by removing data, not only by holding out the tail. Cut a third of the history, shift the start and end dates, and rerun. A joint loop makes that check cheap to run against the full end-to-end objective instead of a ranking proxy.

That last item came off the panel as a rule of thumb rather than a formal test, and Mike stated it in the plainest available terms:

If you have two rules, if you remove a third of the data, how would it change? If the performance statistics don’t change very much, say 10%… change more than 10%, you might have something not so strong.

Mike, trend-following fund manager, Better System Trader episode 223

He extended it to the start and end dates as well: shift them, drop a large block of history, and look for results that cluster in the same region rather than scattering. He then paired it with a second check that a screener-driven stack should find distinctly uncomfortable, because it attacks the universe rather than the parameters. Hand the rules to someone else to run on instruments they were never tuned on. Rules fitted to a handful of recent high-momentum names rarely survive the transfer, because, in his phrase, “these rules are for these markets, this time”.

Neither check is a significance test, and neither replaces a walk-forward protocol. They are cheap first filters, and a unified evaluator makes them cheaper still, because the same end-to-end objective can be recomputed on a truncated history or a swapped universe without standing up a separate ranking benchmark to compare against.

None of that requires you to adopt this codebase. It does require you to stop pretending that a great ranking model plus a great exit model automatically compose into a great portfolio process.

Boundaries

Keep the claims inside the evidence:

• This is a description of an end-to-end optimization architecture proven enforceable in code, not a third-party benchmark tournament.
• No inspected head-to-head shows a numerical speedup or return uplift of “unified” versus a sequential screener-first pipeline. Do not invent one.
• Computational wins (prepare once, worker frame sharing, candidate cache, early rejection, regime precompute) reduce evaluation cost. They do not certify edge.
• Past portfolio metrics from any related backtest report remain historical. They do not guarantee future results.

The methodology spot for KreamEdge is robustness under execution realism. That only holds if the write-up stays as careful as the evaluator.

FAQ

What is joint screener and strategy optimization?

Joint screener and strategy optimization means a single search trial changes the selection layer and the trade-management layer at the same time, then receives one score. Score weights, entry gates, buy and sell rules, stops, freeze windows and holding limits are all part of one decision vector, and fitness is assigned only after those choices generate dated signals and run through a portfolio simulation with costs and risk constraints. The alternative, tuning a screener on ranking quality and handing its output to a separately tuned exit model, optimizes two proxies and assumes the two halves compose.

Is this the same as optimizing a strategy per symbol or per timeframe?

No. A candidate in this design is a single configuration applied to an entire universe: the same score weights, entry gates, buy and sell rules and stop policy run on every name the screener admits, and the decision vector contains no symbol dimension and no timeframe dimension. Bar size is fixed by the data preparation stage rather than searched. A per-symbol or per-timeframe sweep does the opposite, returning one fitted configuration per combination, which leaves a selection problem behind, because something still has to pick which configuration to trade using the same history that generated them all. It also multiplies the comparison count, so the strongest cell in a symbol-by-timeframe grid is the cell most likely to be luck rather than edge.

Why not optimize the screener first and the trading rules afterwards?

Because selection tightness and exit policy interact rather than add. Raising a minimum score cuts trade count, which only helps if stops and holding limits still leave enough sample for risk statistics to mean anything. Loosening entry gates turns holding success into an exit problem, where trailing stop distance and trend exit thresholds start dominating turnover and drawdown. A sequential pipeline freezes one half while tuning the other, so those interactions never enter the search by construction.

Does joint optimization increase overfitting risk?

It increases the number of ways a search can explain a good historical curve, so the honest answer is yes unless the protocol is fixed in advance. The mitigations that matter are declaring the decision space, the objective and the acceptance thresholds before the run, freezing regime thresholds and known-good weights as server-level context instead of free genes, applying soft penalties for thin trade counts and excess drawdown, and testing the winner by removing data rather than only holding out the tail. A larger search space is not the hazard; revising the specification after seeing the result is.

What is a point-in-time universe and why does it matter for a screener?

A point-in-time universe contains, on every historical bar, exactly the instruments that were actually tradable on that bar, including names later delisted, merged or removed from an index. It matters more for a screener than for a single-instrument strategy because selection rules fit themselves to whatever survivorship the candidate set carries. Point-in-time constituent history is a solved commercial problem for equities and largely unsolved for crypto, where dead pairs and delistings are poorly archived. An end-to-end objective running on a contaminated universe makes the wrong fit tighter, not safer.

How do you test whether a jointly optimized strategy is stable?

Two cheap checks come before any formal protocol. Remove a large chunk of the history, roughly a third, shift the start and end dates, and rerun; if the performance statistics move far more than about ten percent rather than clustering, the configuration is probably fragile. Then run the same rules on an out-of-sample basket of instruments they were never tuned on, since rules fitted to a handful of recent high-momentum names usually fail to transfer. Neither check is a significance test and neither replaces walk-forward analysis; they are first filters that a unified evaluator makes cheap to repeat.

Is a jointly optimized strategy better than a portfolio of simple unoptimized ones?

This note makes no such claim, and the opposing design is a serious one. Some practitioners never optimize a parameter, run one entry condition, one exit condition and one regime filter, and build stability by combining weakly correlated simple strategies at the portfolio level, on the argument that a strategy never fitted cannot be overfitted. A better search loop does not refute that position. Only out-of-sample evidence settles it, by showing whether the fitted joint candidate holds up where the unfitted simple one does not.

Sources

The practitioner arguments quoted above on point-in-time universes, survivorship bias, the overfitting tell, data-removal stability testing, and the no-optimization counter-position all come from a single public discussion:

• Better System Trader, episode 223, “The Trading Panel” episode 1, February 2024, hosted by Andrew Swanscott with Jason of Against All Odds Research, Pavel of Robuxio, Kashyap, Mike and Markets & Mayhem. Listen to the episode.
• Better System Trader on YouTube: the channel carries the video versions of the panel and the interview archive.

On the sourcing: material in block quotes and quotation marks is transcribed verbatim from the episode audio, cleaned for punctuation, filler words and evident transcription errors but never for meaning, with an ellipsis marking any omission. Everything else attributed to a panelist is a paraphrase of their argument in KreamEdge’s words. The recording carries no speaker labels, so attribution is inferred from direct address and self-identification in the conversation; where a turn was ambiguous, the point is reported without a name. Panelists are identified by the first name and affiliation stated on air, and no surname is attached beyond the ones the episode itself gives.

KreamEdge has no affiliation with Better System Trader or any panelist, and the citation is not an endorsement. The episode contains unpaid vendor mentions and a discount code for third-party backtesting software; none of those products are recommended here.

Closing

Screener selection and trade management are one system in production. Treating them as two clerked handoffs in research is a convenient fiction. Joint optimization with a shared signal engine, portfolio-level fitness, and a shortlist-then-joint search structure is how this stack removes the fiction without turning the search into an unbudgeted free-for-all.

If you want the surrounding research notes and community discussion of backtest methodology, join the free channels on the community page. Everything there stays informational and educational. Not financial advice.

Related KreamEdge research

• Why LLM trading backtests are (mostly) nonsense
• SPX liquidity deflator: correcting a silent bias in long backtests
• Position sizing null result
• Market-regime filter null result
• Combined US-equities + world-indices 1D portfolio (Backtest 332)
• Risk management after the AI rout: volatility and bias
• SSE in production: building a reliable signal feed