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.

Pre-release boundary

HyperionX 1.1.10 is being prepared for public release. 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 1.1.10 import time-zone selector is not applied by 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. Record that ordinary Validator and Optimizer do not provide configurable slippage.
6. Test another date range and keep selection data separate from out-of-sample data.
7. Run Playback with an explicitly selected LocalPaper account. The current release-candidate guard rejects external-account order mutations during Playback, but it does not 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 active candidate source and installer manifest contain the intended default-module fix, but the exact clean, signed installer has not completed installation, discovery, and workflow smoke validation. Do not count a source-tree-only test as proof that the public installer works. Treat Validator and Optimizer as unavailable on a fresh public installation until validation passes. 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.