Multi-Layer NEAT/LSTM Trading System — Hyperparameter Tuning & Performance Metrics/Optimization

Summary We currently have a complete multi-layer trading architecture primarily based on NEAT and designed for crypto, forex, and equity markets. The architecture is already implemented and functional. This engagement is not focused on building a new trading system from scratch. The objective is to optimize, improve, and validate the existing architecture while maintaining strict out-of-sample robustness requirements. Architecture Overview 1. LSTM Forecasting Layer This layer consists of LSTM-based forecasting models whose purpose is feature enrichment rather than direct trade generation. The models produce structured future-looking estimates, directional probabilities, expected movement metrics, and uncertainty-related outputs. 2. NEAT Decision Layer The core decision-making layer is based on NEAT. Forecasting outputs are not treated as trading signals. Instead, evolutionary agents learn how to utilize forecasting information together with market-derived features in order to generate trading behavior. The forecasting and decision processes are intentionally separated to reduce overfitting and future-data leakage. 3. Multi-Model Aggregation Layer Multiple independently evolved models are combined through an aggregation framework. Rather than relying on a single agent, the system combines models trained under different conditions, datasets, and market environments. 4. Context / Regime Layer A higher-level contextual layer evaluates market conditions, volatility environments, uncertainty levels, and broader regime information. This layer acts as a validation mechanism for lower-level decisions. 5. Execution and Risk Layer The final layer combines upstream outputs and determines trade execution, risk exposure, position management, and abstain/no-trade behavior. This architecture already exists. The purpose of this project is to improve performance, robustness, generalization quality, and out-of-sample behavior. Optimization Scope We are looking for someone with strong experience in quantitative trading systems, evolutionary algorithms, NEAT, machine learning for financial markets, and robust validation methodologies. Potential optimization areas include, but are not limited to: * NEAT evolution logic * Fitness design * Multi-model aggregation * Feature selection and feature engineering * Regime handling * Trade filtering * Risk management behavior * Generalization improvements * Overfitting reduction * Validation methodology improvements * Architecture-level optimization where appropriate The goal is not to redesign the system from scratch, but to improve the existing architecture while preserving its overall structure and design philosophy. Validation Methodology All optimization work must be evaluated using a strict walk-forward process. Historical data must be separated into train, test, validation, and holdout datasets. In addition, market regimes must be treated independently. Regime intervals are considered separate datasets and must not be merged simply because they belong to the same regime category. For example, if a market contains multiple bull-market periods occurring in different years, each bull-market interval must be treated as its own dataset rather than combined into a single larger bull-market dataset. Models should be trained using regime-specific datasets and evaluated only on appropriate unseen periods. The same overall methodology must also be applied to the aggregation layer. Regime-specific models and the higher-level aggregation logic should both be evaluated under the same train/test/validation/holdout framework. Validation periods may be used for experimentation, refinement, and optimization. However, final performance evaluation must be based exclusively on holdout data. If significant architectural or behavioral modifications are introduced during validation, additional unseen periods should be reserved for final confirmation testing in order to maintain a realistic separation between optimization and final evaluation. Holdout Evaluation Backtesting must be performed using non-cumulative position sizing. Performance evaluation should not depend on compounding effects, account growth, or equity curve amplification. The objective is to evaluate the quality of the decision process itself rather than the effects of compounding. The architecture must demonstrate robustness across multiple market environments. Final evaluation will be performed on crypto, forex, and equity markets. For each market category, multiple assets will be selected for final evaluation. Asset selection will occur after optimization work is completed and before final holdout testing begins. All final condition checks must be performed exclusively on holdout data. Performance Targets Performance will be evaluated using rolling 3-month holdout windows. For each 3-month holdout window: * If benchmark return is positive, system return must exceed benchmark return by at least +8 percentage points. * If benchmark return is negative, system maximum drawdown must not exceed 50% of the benchmark drawdown during that same period. These requirements apply to the holdout evaluation process and are the primary acceptance criteria for the optimization effort. The objective is not to maximize return at any cost, but to consistently demonstrate superior risk-adjusted behavior relative to the benchmark across different market conditions. Application Requirements When applying, please include: 1. Directly relevant experience with algorithmic trading systems. 2. Experience with NEAT, neuroevolution, genetic algorithms, or similar evolutionary methods. 3. Similar optimization, quantitative research, or trading-system projects. 4. What parts of the architecture you would investigate first. 5. Your approach to improving out-of-sample robustness and reducing overfitting. 6. Any experience with walk-forward validation, regime-based modeling, or portfolio-level evaluation. This project is intended for candidates who are comfortable working on an existing quantitative trading architecture and improving its performance under strict holdout-based evaluation criteria