Common client boundary
Keep synthetic, IG demo, and any eventual live market connection behind the same explicit interface.
LOADING...
In developmentPaper firstHuman approved
ForgeCommand subsystem
Stock Trading Automation
A paper-first market-analysis and decision-support project that keeps human approval between generated signals and consequential actions.
The work is evolving as a Trading module inside ForgeCommand, bringing market context, risk controls, proposals, and reviewable decision records into one operational interface.
PythonPyQt6IG MarketsTechnical analysis
Simulation interface · synthetic data
The engineering question
How can market analysis be useful without allowing uncertainty or automation to bypass control?
Trading systems combine noisy data, changing conditions, execution assumptions, and strong emotional incentives. A plausible-looking signal is not evidence that a strategy works, and a generated recommendation should never be treated as authority.
This project treats analysis, risk policy, approval, execution, and audit as separate responsibilities. The working rule is mock and demo first: observe, measure, and understand the system before considering any real-money boundary.
Architecture change
From isolated script to governed subsystem
The original standalone plan is now part of ForgeCommand, providing a wider control surface for status, configuration, approvals, audit history, and AI-assisted explanation.
// proposed decision boundary
Market data + account state
↓ analysis + explainable signal
Trade proposal
↓ deterministic risk policy + human approval
Simulated action + audit record
Current direction
Build the boundaries before expanding the automation
Explainable signals
Record the inputs, indicator state, and reasoning behind each proposal so a result can be reviewed later.
Approval before action
Separate generated analysis from the deterministic controls that authorise, reject, or suspend an action.
Measurable performance
Track P&L, drawdown, hit rate, expectancy, slippage, latency, and missed fills instead of relying on anecdotes.
Current build
A working interface foundation, not a trading claim
The screenshot documents an early mock surface for positions, working orders, risk metrics, market hours, watchlists, AI-assisted interpretation, and manual controls. It shows interface and workflow direction rather than validated performance.
Implemented foundation
PyQt interface, modular tabs, client abstractions, mock states, and development scaffolding.
Still unproven
Historical backtesting, operational validation, signal expectancy, and any basis for live automated execution.
Every balance, position, order, and P&L figure shown in the interface is synthetic. No result displayed on this page represents real performance.
Risk and controls
Safety conditions before scope
- ▸Paper or practice funds while strategies and controls are evaluated.
- ▸Per-strategy loss limits, daily loss limits, and drawdown halts.
- ▸One-click suspension and automatic circuit breakers on policy breach.
- ▸Audit records linking signals, proposals, approvals, simulated fills, and outcomes.
- ▸Pinned code and data versions for repeatable backtests.
Technical foundation
Current module stack
- ▸Python and PyQt6 for the ForgeCommand desktop interface.
- ▸An IG Markets client boundary with explicit mock, demo, and configured live modes.
- ▸Technical-analysis and signal-generation modules with configurable profiles.
- ▸Optional AI context for teaching-oriented analysis and explanations.
- ▸Local configuration and decision records inside the ForgeCommand workspace.
Validation
Evidence the project still needs to produce
Expectancy
Net outcome per trade and per day, including the full win/loss distribution.
Drawdown
Maximum drawdown measured against the risk envelope and suspension thresholds.
Execution realism
Fees, slippage, latency, partial fills, and missed fills in simulation.
Regime stability
Walk-forward performance across changing volatility and market conditions.
Roadmap
Progressive proof, not a rush to execution
Data foundation
Build the candle pipeline, local store, and deterministic backtest harness.
Baseline strategies
Implement simple momentum and mean-reversion references with comparable metrics.
Paper operations
Run scheduled simulations, reports, alerts, and failure handling.
Control validation
Exercise limits, approvals, suspension behaviour, and audit reconstruction.
Evidence review
Consider a tightly bounded live-cap experiment only after sustained paper evidence.
Current status: simulation and architecture work
The interface and module boundaries are being developed. Backtesting, paper-operation evidence, control validation, and any case for a live-cap experiment remain future gates.