A customer release should stop when the evidence does not support the exact compiled EA and standalone setfile being shipped. This public taxonomy gives research and product teams a consistent language for recording those failures without disclosing proprietary strategy logic.
Published by JPTC Research Team under the JPTC editorial policy.
Evidence: Public validation framework, not a performance study. Reviewed 23 August 2026. Version 1.0.
Download the rejection taxonomyJPTC rejects an EA candidate when the available evidence does not support a customer release of the exact compiled EA and standalone setfile. A profitable-looking research result is not enough when the trade sample, execution assumptions, unseen periods, broker specifications or runtime settings remain unreliable.
A fast simulator can detect obvious weaknesses such as low activity, unstable results across periods and sensitivity to basic trading costs. It cannot validate a production capability that it does not reproduce, so broker-terminal testing remains the controlling release gate.
A profitable backtest can fail release because the result may depend on one period, a few trades, favourable execution or settings that differ from the shipped file. Release evidence must survive realistic costs, separate periods, broker specifications and a trade-path review in the intended terminal.
Customer release requires evidence tied to the exact compiled EA, standalone setfile, symbol, timeframe and documented runtime settings. The record should also identify the test period, broker conditions, execution assumptions, failure criteria and any material limitation.
The public dataset omits source code, setfiles, private thresholds, entry and exit rules, customer data and strategy-specific performance. It publishes the classification method so another team can audit its own evidence without receiving a reproducible trading system.
Another team can reuse the taxonomy by assigning a stable failure identifier whenever a candidate is rejected or returned to research. The identifier should be stored beside the release candidate, the observed evidence, the reviewer decision and the required response.
No. It is a public validation framework and contains no entry logic, setfile or production strategy rule.
No. Some findings require a corrected test or clearer release record, while structural failures may end the candidate. The required response in the dataset explains the minimum next step.
No. It helps teams classify missing or weak evidence. It cannot predict future outcomes or replace broker-terminal and out-of-sample validation.