Skip to main content

HX109 Performance Database And Reporting

HX109 teaches how HyperionX saves, finds, inspects, and exports strategy results. The current results database is a useful archive, but it is not a complete experiment-reproducibility system.

This lesson applies when the originating research workflow is available in the installed package. See Performance Database for the current storage schema and Backtesting for the clean-installer release limitation.

Lesson 1: Performance Windows

HyperionX performance views can show more than a single net-profit number.

Teach users to inspect:

  • Summary.
  • Trades.
  • Orders when the originating result provides them.
  • Analysis and drawdown views when available.
  • Pain level/risk views when available.
  • Portfolio views where applicable.
  • Long/short splits.
  • Tooltips for trades and drawdown points.

The goal is to understand how a strategy made or lost money, not only whether the final number is green.

When a standalone saved result is reconstructed from stored trades, Chart, Orders, and RiskLevels views are not restored.

Lesson 2: Saved Performance Results

Saved performance records can include:

  • Result name, type, and status.
  • Strategy identifiers, name, and version where available.
  • Instrument, connection/account identifiers, and data-series information.
  • Date range.
  • Headline performance metrics.
  • Stored trade artifacts and a storage path.

The current store does not consistently preserve full strategy parameters, optimizer ranges, optimizer/fitness choices, commission configuration, starting capital, application/build version, or complete order/chart/risk views.

Keep those inputs in a separate research record with the strategy source or source-control revision. A saved result can be valuable for review without being sufficient to rebuild the run exactly.

Lesson 3: Optimizer Database

The optimizer database is for finding and comparing saved work.

Teach:

  • Save the optimizer test name.
  • Keep period definitions in the external research record.
  • Record in-sample, out-of-sample, and optional simulation periods.
  • Record optimizer parameter ranges.
  • Record the fitness metric and optimizer type.
  • Reopen saved results before changing the strategy.
  • Compare stable parameter regions, not only one best row.

Do not overwrite historical research records without a reason.

Lesson 4: Portfolio Review

Portfolio-level results can hide weak components.

Review:

  • Aggregate equity curve.
  • Instrument-by-instrument contribution.
  • Long and short contribution.
  • Max drawdown by component.
  • Trade count by component.
  • Commission by component.
  • Whether one symbol explains most of the profit.

Portfolio views are useful only when users drill down into the parts.

Lesson 5: Exports

Export is part of support and research workflow.

Useful exports include:

  • Validator summary CSV.
  • Optimizer PDF.
  • Stored trade CSV and JSON.
  • Logs.
  • Chart datasets where supported.
  • Research Lab CSV and JSON.

Available exports depend on the originating workflow. Exports can contain account labels, strategy details, market data, local paths, or proprietary research. Inspect each file before sharing it; automatic log redaction does not apply to every research export.

Lesson 6: Result Review Checklist

Before trusting a result:

  1. Confirm the data range.
  2. Confirm the provider/instrument metadata.
  3. Confirm commission and the historical fill model.
  4. Confirm quantity and leverage.
  5. Confirm trade count.
  6. Confirm drawdown and pain level.
  7. Confirm long and short behavior.
  8. Confirm out-of-sample behavior.
  9. Save the result.
  10. Compare the reopened result with the external research record.

Ordinary Validator and Optimizer runs do not expose a configurable slippage model in the current release. Record that limitation as part of the review.

Completion check:

  • User can explain which views and artifacts are available for the selected result type.
  • User keeps the missing reproducibility inputs outside the current results database.
  • User can compare portfolio components instead of trusting the aggregate alone.
  • User can export research/support artifacts without leaking secrets.

See Performance Database for the current persistence boundaries.