HX105 Research And Validation

HX105 turns a strategy from code into a research workflow. A strategy is not proven because it compiles or wins one test.

Public-package status

The active 1.1.10 release-candidate source contains product-owned defaults and installer-manifest entries intended to correct the earlier Validator and Optimizer clean-install gap. The exact clean, signed installer has not yet passed installation, discovery, and workflow smoke tests. These exercises remain unavailable on a fresh public installation until that validation passes. Do not copy modules from an untrusted source as a workaround. Track the boundary in Backtesting, Validation, and Optimization.

Lesson 1: Backtest Inputs

Before reading results, define:

• Instrument and connection.
• Data series type and value.
• Date range.
• Commission model.
• Historical fill model.
• Slippage limitation.
• Quantity or risk model.
• Leverage/margin settings when testing perps.

If these are wrong, the results are not useful.

Ordinary Validator and Optimizer runs do not expose a configurable slippage model in the current release. Record that limitation rather than entering a value that the run does not apply.

Lesson 2: Metrics

Do not rank by net profit alone. Review:

• Total trades.
• Net profit.
• Max drawdown.
• Profit factor.
• Average trade.
• Average winning trade.
• Average losing trade.
• Long/short split.
• Commission.
• Time in market.

Low trade count plus high net profit usually means the test needs more data.

Lesson 3: Optimizer Workflow

Use optimizer to explore, not to force-fit.

Good workflow:

1. Choose two or three parameters.
2. Use broad ranges first.
3. Find stable regions, not one perfect value.
4. Re-test nearby values.
5. Run out-of-sample dates.
6. Save the result and keep a separate research record with the settings needed to reproduce the test.

Bad workflow:

• Optimize every parameter at once.
• Pick the highest net profit row without checking drawdown.
• Ignore commission, fill-model, and slippage limitations.
• Trust a result with only a few trades.

Lesson 3A: Brute Force vs Genetic

Teach the optimizer types as a tradeoff:

Optimizer type	Use when	Risk
Brute force/default	The parameter space is small enough to test every combination.	Can be slow when ranges and step counts are large.
Genetic	The parameter space is large and you need fast exploration.	May miss edge cases or narrow parameter islands.

For new users, start with small brute-force tests. Use genetic search only after the user understands the parameters and result metrics.

Lesson 3B: In-Sample And Out-Of-Sample

Teach every optimization as two questions:

• In-sample: what parameters performed best on the training range?
• Out-of-sample: did those parameters still work on data the optimizer did not use?

If in-sample is strong and out-of-sample is weak, the strategy is likely overfit. The selected parameters should survive outside the range that selected them.

Lesson 3C: Saved Results And Database

Saved results preserve useful identifying information, dates, headline metrics, and result artifacts, but they are not a complete reproducibility package.

Depending on the result type, the database can preserve:

• Strategy name and version.
• Instrument and data series.
• Date range or period information.
• Headline metrics.
• Stored trade artifacts and a storage path.

It does not consistently preserve full parameter values and ranges, optimizer and fitness configuration, commission configuration, starting capital, application/build version, or every order/chart/risk view.

Keep those settings in a separate research record with the strategy source or source-control revision. Reopening a result is not the same as reproducing the run exactly. See Performance Database.

Lesson 4: Validator Workflow

Use validator when you need to test:

• One strategy across many instruments.
• Many data series combinations.
• Portfolio-style results.
• Parameter presets across multiple symbols.

Each validator test set should have a clear purpose. Do not mix unrelated instruments just to get a nicer equity curve.

When reviewing validator results:

• Start with aggregate performance.
• Drill into each instrument.
• Compare long and short trades.
• Check whether one instrument explains most of the profit.
• Re-run changed items instead of mixing old and new result states.

Lesson 5: Strategy Debug Checklist

When a strategy does not trade:

• Confirm Enabled is true.
• Confirm enough bars loaded.
• Confirm filters are not blocking all trades.
• Print signal values before order code.
• Verify LastPosition.MarketPosition.
• Confirm account/connection selection.
• Confirm order quantity is valid for the instrument.
• Confirm stop/target prices are on the correct side of the market.

When results look wrong:

• Check tick size and multiplier.
• Check commission.
• Check the selected historical fill model.
• Remember that ordinary Validator and Optimizer runs do not model configurable slippage.
• Check quantity/leverage assumptions.
• Check whether entries fill on next bar or intra-bar.
• Check if limit and stop orders are being cancelled too early.
• Review long and short trades separately.

Lesson 6: Course Capstone

Build a full MA cross system:

• Fast and slow moving average parameters.
• Time filter.
• Optional trend filter.
• Market entry.
• Fixed stop and target.
• Optional break-even move.
• Optional trailing stop.
• Strategy plots for entry, stop, and target.
• Validator test across at least three instruments.
• Optimizer test across fast/slow periods.

Completion check:

• The strategy compiles.
• It trades in simulation/backtest.
• Validator can run it without null reference errors.
• Results include the intended available commission model, and the slippage limitation is recorded.
• The chosen parameters work in more than one date range.