Why We Prefer a Broad Candidate Pool Over Perfecting a Single EA

It is easy for an EA development project to become an effort to make one particular candidate pass. A weak session is filtered out, a losing weekday is removed, and another parameter change improves the backtest. It can become difficult to tell whether each change is improving the idea or merely keeping that candidate alive.

A broader candidate pool offers another option: reject the candidate and continue with a different idea. That is a practical reason to generate alternatives. It is not a reason to treat the number generated as evidence of quality.

Make rejection possible without abandoning the project

When only one candidate is available, every weakness creates pressure to repair it. Different entries, exits, filters and strategy families make it easier to separate the objective of finding a usable EA from the objective of completing one predetermined EA.

This does not make iteration wrong. It makes the stopping decision more important. A candidate should not receive an unlimited sequence of repairs simply because it was the first promising result or has already consumed substantial effort.

The pool is useful when it allows weak candidates to fail under consistent criteria. Its value is limited if the same favored candidates are protected regardless of how many alternatives exist.

Give the survivors a sequence of meaningful checks

The process discussed here is Generate → Screen → Robustness → Validation → Select. Generation creates hypotheses and candidates. Screening applies basic criteria such as trade count, PF and drawdown. Robustness checks challenge dependence on narrow settings, favorable trade paths or low execution costs. Later-period assessment then examines the survivors outside the development interval.

Each stage needs a defined role. The last stage should not become an opportunity to keep changing candidates until the reserved data produces an appealing answer. The objective is to assess what has survived, not to produce a predetermined number of winners.

AI-generated process illustration; candidate counts are hypothetical. The final check applies prior criteria, not a fresh ranking by OOS performance.

An exception changes the comparison

Suppose a hypothetical PF requirement is 1.30 and a candidate returns 1.29. Lowering the requirement to 1.28 for that candidate changes the basis of comparison. Waiving a sample-size requirement or a difficult cost test has the same problem.

These are examples, not the published acceptance levels of a product. They show how candidate-specific rescue can make the surviving set difficult to interpret. A process that claims common gates needs to apply those gates consistently.

There can be valid reasons to revise a methodology. That should be handled as a change to the method, with its implications made explicit, rather than as an exception for one EA that is too attractive to discard.

A larger search also creates more selection risk

Generating 10,000 candidates and choosing the prettiest historical curve does not resolve overfitting. It creates many opportunities to find something unusually well matched to the sample. Meaningful screening, robustness checks and reserved data are needed to interpret the winner in light of that search.

AI-generated process illustration; candidate counts are hypothetical. The final check applies prior criteria, not a fresh ranking by OOS performance.

If 1,000 Development candidates are tested on OOS and the highest performer is selected there, OOS has contributed to selection. It is no longer only a check of an already-selected EA. The candidate count makes it more important to describe what Development, Validation and any final period were permitted to influence.

The same caution applies to rejection statistics. “One survivor from 100,000 strategies” sounds selective, but the number is not useful without knowing whether the rejections addressed sample size, drawdown, tail behavior, execution costs, OOS deterioration or portfolio overlap.

What “selected from thousands” should mean to a buyer

Ask how weak candidates were removed, whether the standards changed for near misses, and what evidence remained unused after the main selection. These details let you assess the development process without needing access to the proprietary strategy definitions.

A broad pool can support disciplined selection, but cannot replace it. The important property is that the process can discard weak candidates for consistent reasons and still has a way to challenge what remains. Generating more candidates is useful only insofar as it serves that objective.

Product details and testing conditions

A development-process description is useful only alongside the evidence for the specific EA being considered.

Specifications, published historical results and operating limits: EdgeDriven Gold Portfolio — XAUUSD · EdgeDriven Dollar Yen Portfolio — USDJPY.

The examples in this article explain evaluation methods; they are not test results for those products. Historical simulations do not guarantee future results. Leveraged trading can cause substantial losses.