Knowledge base / Release 0.2
Trading system documentation
The evidence-linked guide to execution, strategy research, market data and operational controls.
01 / System boundary
Architecture and data flow
The platform separates data acquisition, research selection, strategy validation, profile promotion and execution. The portal is outside the runtime boundary.
Fallback → production JSON → research override → validated instrument profile.
Research produces evidence. Promotion changes profiles. Execution interacts with the broker.
02 / Runtime
Execution engine
The engine ↗ evaluates eligible instruments during the entry window, applies sizing and risk limits, manages orders and positions, checks stops and performs EOD processing.
- Trade mode: entries and open-risk management.
- EOD mode: end-of-day lifecycle separate from entry processing.
- Safety: paper mode, daily loss limit, position/exposure limits, lockdown and kill controls.
- State: logs, positions and profiles remain runtime-owned; host paths are excluded.
03 / Decision model
Signals and scoring
The checked-in profile selects breakout and SPY regime. Volume, VWAP, slope and gap fields remain but are conditional or disabled.
Breakout
30-bar reference high on five-minute bars.
SPY regime
Market context, relative strength and beta ceiling.
Volume / VWAP / gap
Only active when their gates or components are enabled.
trigger.min_signal_score=0.4 and entry.score_threshold=70 are separate scales and paths.
04 / Controls
Risk and exits
The current profile allocates $1,000 per stock, permits ten positions, caps exposure at 100%, and uses a -$500 daily loss threshold. Stops use intraday ATR(21) at 3× with a 2% fallback; checks run every 30 seconds and EOD liquidation is ten minutes before close.
trail_trigger_matches_atr_multiple=true. Computed execution behaviour is authoritative.05 / Evidence
Research pipeline
Stock selector
Filters the universe, enforces coverage, runs the frozen model and ranks robust survivors.
Realistic backtester
Models spread, commission, latency, next-bar execution, stops and explicit overrides.
Optimiser
Uses staged horizons, holdout, walk-forward, stress, concentration and neighbour stability.
Optimisation and tuning are research-only. Instrument promotion is a separate validate/promote/rollback workflow.
06 / Inputs
Market data
IB history and the ticker manager maintain the canonical store. Completeness, deterministic duplicate handling, quarantine, checkpoints, retries, timeouts and status reporting protect inputs. Pre-market bars are isolated to 04:00–09:29 ET and cannot overwrite the canonical store.
07 / Runbook boundary
Operations
- Hostinger deploys reviewed changes automatically from
main. - WordPress and the portal remain separate websites.
- Never commit broker credentials, account IDs, tokens, VPS credentials or absolute runtime paths.
- Future visibility starts with a narrow authenticated read-only API.
- Future controls require authorization, confirmation, idempotency, audit logs and kill/lockdown enforcement.
08 / Reconciliation
Known gaps and conflicts
- General backtester: 9,999-session time exit; selector frozen model: five sessions.
- Source documentation conflicts over whether a 3% VWAP ceiling is production parity or research-only.
- Friday/time-exit parity between live execution and backtesting needs focused verification.
- The trading-system README mixes current behaviour with implementation history.
These are open reconciliation items, not production guarantees.
Browse