Product Roadmap

This is the product direction for HyperionX. It is intentionally placed near the end of the documentation because most readers should first learn the platform workflow, Code Lab, reference APIs, AI tools, research workflows, and operating rules.

For learning how to use and build inside HyperionX, start with Code Lab Learning Path. For API contracts, use Platform APIs and HyperionX API Spec.

HyperionX should be built around the complete lifecycle of a trading idea:

1. Connect to data.
2. Read the chart.
3. Build indicators and strategies.
4. Validate the idea.
5. Optimize without curve fitting.
6. Simulate execution.
7. Trade manually or with controlled automation.
8. Review results.
9. Save the workspace.
10. Let AI help with context, coding, testing, and operations.

This roadmap is not a bug list. It is the product direction that keeps the platform coherent.

Product Principles

Principle	Meaning
HyperionX first	Public docs, templates, and APIs must use HyperionX names, namespaces, and lifecycle methods.
Full workflow	Charting, coding, validation, optimization, execution, and review should feel connected.
Simulation first	New trading actions should work in simulation before live trading is exposed.
Observable state	Orders, positions, strategies, data series, and AI actions should be inspectable and auditable.
Modular scripts	Strategies should be structured so entries, filters, exits, risk, and visuals can evolve independently.
Stable APIs	Code Lab, local APIs, and AI tools should depend on versioned contracts, not private UI objects.

Phase 1: Platform Foundation

Goal: make HyperionX dependable as a daily charting and manual trading platform.

Core deliverables:

• Fast chart loading for historical and live candles.
• Stable chart scroll, zoom, time axis, and price axis behavior.
• Multi-chart layout support.
• Instrument lists and watchlists.
• Workspace save, load, rename, duplicate, and restore.
• Theme-consistent dialogs, menus, popups, property grids, and error messages.
• Historical data manager with provider, market, symbol, and timeframe grouping.
• Provider abstraction for live, simulation, playback, and testnet connections.

Definition of done:

• A trader can open a workspace, connect, load charts, add indicators, trade in simulation, close the app, and restore the same layout.

Phase 2: Chart Trader And Manual Execution

Goal: make manual trading clear, fast, and controlled.

Core deliverables:

• Market, limit, stop market, and stop limit order entry.
• Base quantity and quote quantity sizing.
• Quick size buttons and editable quantity controls.
• Time-in-force support where providers support it.
• Reduce-only and post-only support where providers support it.
• Working order banners on chart with price, quantity, side, type, and cancel action.
• Position banner with side, quantity, entry, PnL, and close action.
• Drag-to-modify working order price.
• Flatten, close, reverse, cancel selected, and cancel all actions.
• OCO and bracket presets.
• Per-chart account and instrument context.

Definition of done:

• Every visible trading button either submits a confirmed action or explains why it cannot.
• The chart, orders grid, positions grid, and account state agree after every action.

Phase 3: Code Lab And Script Runtime

Goal: make HyperionX programmable without requiring users or AI agents to guess the API.

Core deliverables:

• Script templates for indicators, strategies, bar types, optimizers, optimization fitness modules, commissions, money management, and addons.
• Generated helper methods for compiled indicators and strategies.
• Compile diagnostics with file, line, column, and message.
• Hot reload for custom scripts after successful compile.
• Clear generated-code rules so users do not paste unsupported external generated regions.
• Example library covering indicator, strategy, rendering, and order management patterns.

Script areas:

• Indicators.
• Strategies.
• Bar types.
• Chart styles.
• Optimizers.
• Optimization fitness modules.
• Commissions.
• Money management modules.
• Addons.

Definition of done:

• A user can create a script from a template, compile it, add it to a chart, change parameters, and see generated helper methods update.

Phase 4: Strategy System Templates

Goal: provide strong strategy patterns users can reuse.

Core strategy model:

Entry -> Filter -> Exit -> Risk -> Visualization

Built-in examples should include:

• Market entry.
• Limit entry with timeout.
• Stop market entry.
• Stop limit entry.
• Bracket entry.
• Fixed stop and target exits.
• OCO bracket exits.
• Break-even stop.
• Trailing stop.
• Time exit.
• Opposite-signal exit.
• Scale in.
• Scale out.
• Multi-timeframe filter.
• Strategy plots.
• Real-time tick management.

Definition of done:

• Users can start from a clean strategy template and add features without turning one method into a fragile monolith.

Phase 5: Research, Backtesting, Optimizer, And Validator

Goal: make research evidence based instead of peak-result based.

Core deliverables:

• Backtest runner with clear assumptions.
• Performance window with summary, analysis, trades, orders, and equity curve.
• Optimizer with in-sample, out-of-sample, and total views.
• Period constructor with repeatable date splits.
• Brute-force optimizer for final validation.
• Genetic optimizer for exploration only.
• Custom optimization fitness modules.
• Saved optimizer database.
• Import and export of saved optimization results.
• Validator for one strategy across many instruments.
• Aggregate portfolio result and per-instrument drilldown.
• Commission, fee, slippage, and spread modeling.

Validation rules to teach in product:

• Do not choose only max net profit.
• Require out-of-sample performance.
• Require enough trades to be meaningful.
• Test parameter stability around the winner.
• Include commissions and slippage.
• Test market regimes and related instruments.
• Treat genetic optimization as exploration, not final proof.

Definition of done:

• A user can move from one strategy idea to a saved optimizer/validator report that explains why it is or is not suitable for simulation.

Phase 6: Advanced Chart And Market Structure Tools

Goal: support deeper analysis without forcing everything into standard line indicators.

Core deliverables:

• Custom rendering API.
• Visible-range rendering helpers.
• Volume profile and visible-range profile examples.
• Session range tools.
• Bookmap-style depth and liquidity visualization.
• Order-flow indicators.
• Market depth display.
• Multi-pane indicators.
• Bar coloring and background coloring.
• Custom bar types.
• Custom chart styles.
• Chart mouse and keyboard interaction for scripts.
• Script-created chart buttons and controls.

Definition of done:

• Advanced visuals redraw correctly during scroll, zoom, resize, and live updates without corrupting chart state.

Phase 7: Rion AI And Local Agent Platform

Goal: make AI useful because it can inspect real platform state and operate through permissioned tools.

Core deliverables:

• Read-only chart context.
• Indicator and strategy metadata.
• Chart Trader state.
• Code Lab file and compile diagnostics.
• Historical and visible candle access.
• Local memory database for chart snapshots, strategy runs, and user notes.
• Simulation-only action tools.
• Validator and optimizer tools.
• Risk and connection monitoring tools.
• Explicit permission toggles for every action class.
• Audit log for AI tool calls and results.

Permission stages:

Stage	Capability
Read	Inspect chart, candles, indicators, strategies, account labels, and chart trader state.
Code	Create templates, edit scripts, compile scripts, and report diagnostics.
Research	Run validator, optimizer, backtests, and saved-result queries.
Simulation	Place, cancel, modify, and flatten sim orders only.
Live read	Inspect live account, orders, positions, fills, and connection state.
Live trade	Disabled until explicit permissions, confirmations, risk limits, and audit logging are complete.

Definition of done:

• AI cannot claim an action happened unless a HyperionX tool returned a confirmed result.

Phase 8: Provider, Operations, And Compliance

Goal: prepare HyperionX for real customers and broker/exchange requirements.

Core deliverables:

• Provider-specific connection documentation.
• Attribution and logo requirements where required.
• Connection health monitoring.
• Order and execution audit logs.
• Data feed loss detection.
• Strategy malfunction detection.
• Emergency flatten/cancel workflows.
• Credentials never exposed to AI or public logs.
• Per-provider capability matrix.
• Testnet, simulation, and live separation.

Definition of done:

• Operators can answer what the platform is connected to, what permissions are enabled, what actions were taken, and why.

Product Completion Checklist

Before a major release, HyperionX should answer these questions:

• Can a new user learn the chart, Code Lab, and simulation workflow from the docs?
• Can a developer find the correct script API without reading source code?
• Can AI inspect chart and strategy context without screen scraping?
• Can AI compile scripts without guessing commands?
• Can research results be saved, reopened, and explained?
• Can every order action be traced from UI or AI request to order state?
• Can the platform recover from connection loss, provider errors, and strategy failures?
• Can live trading be kept disabled unless the user deliberately enables it?