Early phases focus on clear alerts, stored audit records, and outcome tracking — so you can verify setups before anything automates further.
Product Roadmap
Where Crypto Signal AI is headed and what is built today — implementation status, phased rollout, long-term vision, and success metrics. Directional planning, not a release schedule.
Why Phased Rollout
The platform is intentionally risk-first. Each phase adds capability only after the previous layer is stable enough to trust. Signals come from inspectable rules, AI explains rather than decides, risk checks have final authority, and live trading stays off until paper results prove the system earns it.
Backtests, paper trading, and performance analytics come before machine-learning filters or portfolio allocation — evidence over optimism.
Execution on real markets is a gated, opt-in final phase — never the default path for the product.
Implementation Status
A component-by-component view of what is built today versus what is still planned. This reflects the current codebase — not a release schedule. For how each implemented layer works, see Platform Architecture on the Overview.
| Area | Status | Notes |
|---|---|---|
| Market data (OHLCV) | Implemented | CCXT; geo-restriction hints for US exchanges |
| Indicators + regime | Implemented | Full indicator set; rich analyze_regime() context |
| Strategy engine | Implemented | 3 strategies; registry; deduplication |
| AI evaluation | Implemented | OpenAI or rule-based fallback |
| Cross-strategy conflicts | Implemented | Peer signals + opposing-side flags |
| Risk management | Implemented | Daily cap, AI reject, min R:R, stop distance, sizing |
| PostgreSQL persistence | Implemented | signals and signal_outcomes tables |
| Alembic migrations | Implemented | Baseline + outcomes migration |
| Alerts (Telegram/Discord) | Implemented | Approved and rejected signals |
| Backtesting | Implemented | In-memory runs; metrics to stdout; not persisted |
| Outcome tracking | Implemented | Manual or watch-triggered; no MFE/MAE yet |
| Watch / recurring scans | Partial | App-level loop; not packaged as systemd/cron |
| Test coverage | Partial | 27 unit tests; some environment-sensitive failures |
| Scheduler service | Planned | Phase 2 — external cron or worker packaging |
| Backtest persistence | Planned | Phase 2 — backtest_runs table |
| Performance analytics | Planned | Phase 2 — by strategy/regime/symbol |
| Dashboard | Planned | Phase 2 |
| Paper trading | Planned | Phase 2 |
| ML filter | Planned | Phase 3 |
| REST API | Planned | Phase 3 |
| Portfolio research | Planned | Phase 4 |
| Live execution | Gated | Phase 5 — explicitly gated and opt-in |
Phase Timeline
Five phases build on each other. Phase 1 is in place today, including watch mode for basic recurring automation. Later phases add analytics, dashboards, ML filtering, and optional live execution.
| Phase | Focus | Status |
|---|---|---|
| 1. Signal Intelligence | Transparent alerts, risk checks, and outcome tracking | Available now |
| 2. Validation + Automation | Analytics, persistence, dashboard, and paper trading | Next |
| 3. ML + API | ML quality filter, richer AI context, and API access | Planned |
| 4. Portfolio Research | Multi-strategy allocation and walk-forward validation | Planned |
| 5. Optional Live Trading | Gated, opt-in execution with safety controls | Gated |
Phase 1 — Signal Intelligence Foundation
Available nowThe core product you use today. Markets are scanned, strategies detect setups, AI or rule-based scoring explains them, risk approves or rejects each signal, and results are stored and optionally alerted.
- Live exchange OHLCV data for configured symbols and timeframes
- Three rule-based strategies: EMA RSI Breakout, Mean Reversion, and Volatility Breakout
- Rich market regime analysis with indicator snapshots on every signal
- AI explanations when configured, with a deterministic fallback scorer
- Cross-strategy conflict notes when multiple strategies fire on the same market
- Risk manager with daily caps, minimum reward-to-risk, and stop-distance limits
- Position size suggestions based on account equity and risk settings
- Telegram and Discord alerts for approved and rejected signals
- Signal deduplication — skips setups already stored for the same candle
- PostgreSQL signal history and outcome records with Alembic migrations
- Backtesting with expanded metrics (Sharpe, Sortino, Calmar, profit factor, and more)
- Outcome tracking for take profit, stop loss, expiry, and pending states
- Watch mode for recurring scans and periodic outcome updates
- CLI for scan, watch, backtest, database, and outcome commands
- Stabilize unit tests across Python/pandas versions
- CLI integration test coverage
- More exchange-specific configuration guidance (US geo-restrictions, Binance US)
Phase 2 — Validation and Automation
NextPhase 2 adds research tooling and production packaging on top of the Phase 1 pipeline. Basic recurring automation already exists via watch mode; the next work focuses on persisted analytics, dashboards, and paper trading.
- Watch mode — app-level recurring scans with periodic outcome updates
- Manual one-shot scans, backtests, and outcome updates from Phase 1
- Production scheduler packaging (cron/systemd units and deployment docs)
- Saved backtest runs with comparable performance history
- Strategy and regime performance summaries by symbol and timeframe
- Dashboard to review signal history and results
- Paper-trading ledger to simulate fills without real money
- Additional strategy coverage beyond the initial three
- Daily summary reports of scan and outcome activity
Phase 3 — Intelligence Upgrade
PlannedHistorical outcomes and backtest data feed a machine-learning quality filter and richer AI context. ML ranks signal quality — it does not place trades or override risk controls.
- Feature store built from stored signals and market data
- ML model to score trade quality using historical outcomes
- Enhanced AI prompts with strategy performance context
- REST API for integrations and external dashboards
- Triple-barrier labeling for research-grade outcome analysis
Phase 4 — Portfolio Research Platform
PlannedMove from single-signal review to portfolio-level research: how strategies combine, how allocation shifts by regime, and whether results hold up under rigorous validation.
- Normalized signals comparable across strategies and symbols
- Strategy allocation weights and regime-based routing
- Volatility-targeted position sizing at the portfolio level
- Multi-strategy portfolio backtests
- Walk-forward validation and overfitting controls
Phase 5 — Optional Live Trading
GatedLive order execution is explicitly optional and disabled by default. It becomes available only after extended paper trading, positive research metrics, and strict operational safeguards.
- Trade-only exchange API keys with manual kill switch
- Drawdown circuit breaker and consecutive-loss halt
- Exchange and counterparty exposure limits
- Full audit trail linking every live order to the originating signal
Long-Term Vision
Crypto Signal AI should evolve from a signal generator into a measurable trading research platform. The goal is not to replace traders — it is to help them make better decisions through structured data, rigorous validation, risk controls, and transparent explanations.
- 1. Generate Signals
Rule-based strategies detect setups across configured markets.
- 2. Track Outcomes
Approved signals are followed to record how they resolved.
- 3. Analyze Performance
Strategy and regime analytics reveal what works over time.
- 4. Train ML Models
Historical data feeds quality filters (planned Phase 3).
- 5. Improve Filtering
Better scoring reduces false positives without bypassing risk.
- 6. Backtest and Validate
Walk-forward and overfitting controls stress-test results.
- 7. Regime and Portfolio Routing
Allocation shifts by market conditions (planned Phase 4).
Traders and analysts review signals, use alerts and reports, and feed judgment back into the loop — the platform supports decisions; it does not make them automatically.
The four design principles on the Overview explain how this loop is built into the product today.
Success Metrics
How the platform measures whether it is working — operationally, as a research tool, and eventually as an ML-assisted filter. These are targets and evaluation criteria, not guarantees of performance.
Technical Metrics
Operational reliability targets for the signal pipeline itself.
- Reliable scan execution
- Alert latency under 30 seconds
- 100% persisted signal audit records
- Migration-managed schema changes
- Outcome tracking coverage for approved signals
Trading Research Metrics
How the platform judges whether strategies are worth trusting over time.
- Positive expectancy after realistic costs
- Controlled max drawdown
- Profit factor above baseline
- Strategy performance by regime
- Paper-trading consistency
ML and Research Metrics
Targets for later phases when ML filtering and walk-forward validation are in place.
- ML precision improvement over rule baseline
- Reduced false positives
- Stable walk-forward performance
- Low evidence of backtest overfitting
What This Means for You
Today you get a research-grade signal pipeline: rule-based strategies, AI explanations, risk filtering, alerts, backtesting, watch mode for recurring scans, and basic outcome tracking. You should treat every alert as decision support — review levels and context yourself before acting.
- Now (Phase 1) — Configure markets, run scan or watch, receive transparent alerts, backtest strategies, and track how approved signals resolve. See Configuration, Signal Workflow, Risk Management, and Outcome Tracking for how the current product works.
- Soon (Phase 2) — Persisted backtest history, performance summaries, dashboard, and paper trading. Watch mode already covers basic recurring scans and outcome updates; Phase 2 adds analytics and production packaging.
- Later (Phases 3–4) — Smarter filtering from historical outcomes, API access, and portfolio-level research tools — still without automatic live execution.
- Optional (Phase 5) — Live trading only after extended paper validation, positive metrics, and explicit opt-in with safety controls. It will never be enabled by default.
