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.

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.

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.

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 materialised 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.

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.

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.