Abstract

This research note documents the discovery stage of an Alpha Discovery Workbench used to surface candidate FX mean-reversion configurations from systematic Optuna searches. The process combines JForex backtesting, parameter search, PostgreSQL persistence, and structured candidate screening across multiple currency pairs and timeframes.

The objective is not to claim production-ready alpha at this stage. Instead, the discovery layer is used to identify a credible queue of candidate configurations worthy of deeper validation through SQL diagnostics, feature-space clustering, walk-forward analysis, embargo testing, veto eligibility review, coded retesting, and eventual demo-live promotion decisions.

The discovery stage has produced a credible queue of candidate configurations worthy of deeper validation.

Research Context

The Alpha Discovery Workbench is being developed as a repeatable engineering system for discovering, screening, validating, and promoting candidate trading configurations. The work is deliberately framed as empirical research rather than as a finished trading product.

Candidate discovery is only the first stage. A profitable backtest is not treated as sufficient evidence of deployable alpha. Each surfaced configuration must be passed through further validation before any consideration is given to live or demo deployment.

Engineering Stack

The research workflow is built around an industrial-style engineering stack rather than isolated spreadsheet analysis. The current environment includes:

• JForex-based FX strategy backtesting
• Optuna-driven hyperparameter search
• PostgreSQL persistence for run, pass, trade, and telemetry data
• SQL-based diagnostics and candidate screening
• GitLab CI/CD and version-controlled strategy code
• Docker / VPS deployment workflow
• Confluence and Jira for engineering documentation, delivery management and backlog control
• Planned downstream HDBSCAN, walk-forward, embargo, veto-lineage, and demo-promotion workflows

The working assumption is that durable alpha may emerge not only from individual strategy parameters, but also from the repeatable engineering process used to generate, screen, validate, and monitor candidate configurations.

Discovery Method

Each Optuna trial samples a candidate parameter configuration:

θ_i = {p₁, p₂, …, p_n}

where θ_i represents the parameter set for trial i. The backtesting process then produces a result vector:

R_i = {N_i, P_i, p̄_i, PF_i, WY_i, B_i, M_i}

Where:

• N_i = trade count
• P_i = net pips
• p̄_i = average pips per trade
• PF_i = profit factor
• WY_i = worst-year profit factor
• B_i = bad-year count
• M_i = active-month count

Candidate screening is not based on a single metric. Instead, each result is evaluated using a developing scorecard:

S_i = f(N_i, P_i, p̄_i, PF_i, WY_i, B_i, M_i)

The scorecard is intentionally treated as an evolving research control rather than a fixed production rule. At this stage it is used to rank candidates for deeper validation, not to approve them for deployment.

Backtest Data Versus Optuna Data

Optuna identifies candidate parameter sets and records the search path, trial values, and sampled hyperparameters. The backtest database explains those candidates by preserving the realised trade-level and run-level outcomes.

In practical terms, Optuna helps answer:

• Which parameter configurations were explored?
• Which trials scored well under the objective function?
• Which regions of parameter space appear promising?

The backtest and telemetry database helps answer:

• How many trades were generated?
• Was performance distributed across months and years?
• Were losses concentrated in identifiable cohorts?
• Did the candidate survive different market conditions?
• Is there enough trade density for cluster or veto analysis?

Optuna identifies candidates. The backtest database explains them.

Sample Candidate Queue

The following table shows a sample of surfaced candidates from the current discovery process. These candidates are not presented as deployable strategies. They are research-stage outputs selected for deeper analysis.

Candidate data shown above is a selected sample from the discovery process. Full candidate tables and run-level extracts may be published separately as appendices or downloadable artefacts.

Candidate Categories

Clean candidates

Clean candidates show positive headline performance, no bad years, and acceptable active-month coverage. In simplified form:

PF > 1,   WY > 1,   B = 0

High-volume candidates

High-volume candidates may have thinner edge per trade but provide enough observations for deeper statistical analysis, including clustering and cohort diagnostics.

N >> 500

Fragile candidates

Fragile candidates may show positive total performance but contain year-level weakness or other instability that prevents immediate promotion.

PF > 1,   WY < 1

The presence of fragile candidates is useful. It helps demonstrate that the Workbench is not designed to simply celebrate profitable backtests, but to classify candidates according to evidence quality and validation requirements.

Current Scorecard Items

The scorecard is evolving as the research system matures. Current discovery-stage screening considers:

• Trade count
• Net pips
• Average pips per trade
• Profit factor
• Worst-year profit factor
• Bad-year count
• Active-month coverage
• Instrument diversity
• Period diversity
• Suitability for SQL, cluster, and walk-forward validation

Later validation-stage scorecard items are expected to include cluster repeatability, walk-forward uplift, embargo survival, veto eligibility, post-veto profit factor, coded retest confirmation, live/demo drift, and cross-strategy correlation.

Next Stage: Validation Pipeline

The next stage is to take selected Optuna run identifiers and process them through the validation pipeline. The intended flow is:

1. Optuna candidate run_id selection
2. SQL diagnostic extraction
3. HDBSCAN feature-space clustering
4. Cluster stability review
5. Walk-forward / embargo validation
6. Veto eligibility scorecard
7. Java implementation of eligible vetoes or gates
8. Coded execution-engine retest
9. Demo-live promotion decision

These steps are outside the scope of the current discovery paper and form the basis of the next validation study.

Optuna candidate run_id
→ SQL diagnostic extraction
→ HDBSCAN feature-space clustering
→ cluster stability review
→ walk-forward / embargo validation
→ veto eligibility scorecard
→ Java implementation
→ coded retest
→ demo-live promotion decision

Limitations

The results presented in this note are discovery-stage outputs. They do not constitute a production trading system, a live trading recommendation, or evidence of future profitability. Backtested results may degrade materially under live execution due to spread, slippage, liquidity, latency, data quality, market regime change, or implementation differences.

Candidate configurations are therefore treated as inputs to further research rather than as final outputs. The purpose of this stage is to create a disciplined, auditable queue of configurations for deeper validation.

Conclusion

The Alpha Discovery Workbench provides a structured process for moving from broad parameter exploration toward evidence-ranked candidate selection. The current discovery process has surfaced multiple FX mean-reversion configurations across instruments and periods, including clean candidates, high-volume candidates, and fragile candidates requiring additional validation.

The results are intentionally framed conservatively. The discovery stage has produced a credible queue of candidate configurations worthy of deeper validation. The next stage is to examine whether these candidates survive SQL diagnostics, clustering, walk-forward testing, embargo controls, and execution-engine retesting.

Appendix

Appendix A — Optuna Dashboard Artefacts: EURUSD 1H Candidate T0012

Research Artefacts

Supporting artefacts may be added as the research note is finalised:

• Download Research Note 002 PDF — forthcoming
• Candidate extract CSV — forthcoming
• Related Research Note 001 — link to existing note