Skip to main content

HX106 Live Readiness

HX106 is a release-readiness checklist, not an approval to trade live. It helps you collect evidence that a specific build, provider, account, instrument, and workflow behave as expected before real capital is considered.

Release and certification boundary

The latest signed public release recorded by the project changelog is HyperionX 1.1.12.0. This documentation audit did not independently certify the downloadable MSI; verify its Windows signature and Help > About. A feature marked Current still requires certification with the exact provider, credentials, environment, entitlement set, and order types you intend to use. Preview, Beta, Internal, and Unavailable surfaces are not live-readiness evidence.

Lesson 1: Record The Test Identity​

Start a readiness record with:

  • HyperionX version from Help > About.
  • Installer source and signature check.
  • Provider and connection environment.
  • Exact account name and type: LocalPaper, Server Paper, or Broker.
  • Instrument, venue, contract, tick size, multiplier, and quantity step.
  • Strategy source revision and parameter preset when applicable.
  • Test dates and operator name.

Use Feature And Provider Status for the current capability boundary. Do not copy pricing or entitlement promises into the readiness record; verify the signed-in entitlement state in the app.

Lesson 2: Prove Data Readiness​

Check the data before checking a strategy:

  1. Load the intended historical range.
  2. Confirm live timestamps advance when a live connection is expected.
  3. Verify symbol mapping, asset type, tick size, multiplier, and session assumption.
  4. Compare imported timestamps and a sample of OHLCV with a trusted source.
  5. Record gaps, duplicates, out-of-order input, and provider interruptions.
  6. For Level II or standalone Time and Sales, prove that the view is not showing fallback/sample data.

The signed 1.1.12 snapshot and reviewed 1.1.14 development source both display an import time-zone selector without forwarding the selection to the local tick parser, so naive timestamps require extra verification. See Historical Data And Import.

Lesson 3: Prove Strategy Behavior In Layers​

Use this sequence:

  1. Build the full Code Lab project with no errors.
  2. Create a fresh strategy instance after the build.
  3. Review the strategy on historical data when the installed research modules are available.
  4. Record the selected historical fill model and commission model.
  5. For the signed public 1.1.12 contract, record that ordinary Validator and Optimizer do not provide documented configurable slippage. The project changelog classifies the 1.1.14 Validator setting as Unreleased, so it is not part of this release-readiness test.
  6. Test another date range and keep selection data separate from out-of-sample data.
  7. Run Playback with an explicitly selected LocalPaper account. Do not rely on a build-specific external-account guard to select or verify the account for you.
  8. Run current-data simulation on LocalPaper.
  9. Verify start, stop, disable, cancel, exit, and disconnect behavior.

The project changelog records product-owned research defaults in signed release 1.1.11 and later, plus the validated Python Research Runtime in the signed 1.1.12 MSI. This documentation audit did not independently test the distributed installer. Verify the exact artifact, installed version, first-launch discovery, and a small known workflow rather than treating a source checkout or release note as proof. Follow Backtesting, Validation, and Optimization.

Lesson 4: Preserve A Reproducible Record​

The Performance Database stores useful result identity, headline metrics, and artifacts, but not every parameter and runtime assumption. Keep a separate record of:

  • strategy source revision and parameters
  • optimizer ranges, optimizer type, and fitness metric
  • commission and fill model
  • starting capital, quantity, leverage, and margin assumptions
  • application version and provider data provenance
  • known slippage and liquidity limitations

Reopening a saved result is not proof that the experiment can be reproduced. See Performance Database.

Lesson 5: Certify Manual Order Operations​

On a non-live account, verify every manual workflow you expect to use:

  • Market, Limit, Stop, and Stop Limit behavior where the selected surface exposes them.
  • Change and cancel.
  • OCO target and stop creation after a fill.
  • Partial-close behavior supported by the route.
  • Cancel all, close, and flatten.
  • Provider reject messages.
  • Order, execution, and position reconciliation after reconnect.

Chart Trader and MegaDOM submit directly to the selected account and do not show a general order-confirmation dialog. Read Accounts And Trading Environments immediately before live-route testing.

Lesson 6: Rehearse A Disconnect​

Provider orders can remain live while the desktop is disconnected.

  1. Use a non-live account.
  2. Submit a working order.
  3. Interrupt and restore the connection under controlled conditions.
  4. Check the provider's authoritative order and position state.
  5. Verify whether HyperionX reconciles, rejects, or leaves the outcome unknown.
  6. Practice the provider-side cancel/flatten path.
  7. Export logs and note timestamps.

If an order submission has an unknown outcome, do not blindly resubmit. Follow Connection Recovery.

Lesson 7: Restore The Operating Environment​

Save a named workspace, restart HyperionX, and reopen it. Then recheck:

  • connections and account type
  • chart symbols, intervals, and latest data
  • indicators and strategy versions
  • Chart Trader and MegaDOM account selection
  • open research/tool windows
  • active provider orders and positions outside the workspace model

Workspaces restore supported layout/configuration, not live trading state or in-memory strategy execution. See Save And Restore Workspaces.

Release Gate​

Do not proceed to a Broker account unless all of these are true:

  • The required provider and feature are Current for the intended capability.
  • The exact account/environment has passed controlled provider certification.
  • Historical, Playback, and LocalPaper evidence is recorded with known model limits.
  • Direct-order, reject, reconnect, unknown-outcome, cancel, and flatten procedures were rehearsed.
  • Provider-side risk limits and monitoring are configured.
  • Preview/Beta tools are not being used as production safeguards.
  • A support package can be produced with Support And Diagnostics.