Case Study
An end-to-end trading estate that separates ML research from execution, governs model promotion through shared contracts, and keeps production trading infrastructure observable in real time.
This platform is a full-stack algorithmic trading ecosystem spanning three interconnected repositories: tf_1 for machine learning, Trading-Win for Windows-side orchestration and broker connectivity, and Trading-WSL for execution inside the Linux runtime where live processes can run predictably. That repo split is intentional. It keeps experimentation, contract governance, and execution concerns separate so the production layer only consumes approved artifacts.
The ML engine trains four distinct model families. Each family is optimized for a different trading horizon and data shape, ranging from hourly macro regime classification down to multi-task learning over level-two order book dynamics. That allows the estate to blend slower contextual signals with short-horizon microstructure signals rather than forcing one model to solve every market regime.
Promotion is gated through a JSON-Logic pipeline backed by a shared ml-contracts schema repository. Models are not simply copied into production after training. They must satisfy contract validation, metadata requirements, and promotion rules before the execution layer is allowed to consume anything tagged production.alias.
On the infrastructure side, the system manages headless IBKR Gateway sessions in both paper and live modes, persists market data in append-only Parquet manifests, and pushes operational notifications through a shared FastAPI microservice. The result is a trading platform that treats ML, governance, and execution as one integrated production system rather than isolated scripts.
tf_1 (ML research + training) | | trains experiments, logs W&B runs, packages validated artifacts v ml-contracts (git submodule) | | shared JSON schemas + JSON-Logic promotion gates | validates model metadata, manifest shape, and release eligibility v Trading-Win (Windows broker/control plane) | | manages IBKR Gateway sessions, ports, paper/live environment control | syncs approved artifacts and manifests to runtime v Trading-WSL (execution runtime) | | loads only production.alias models | appends Databento + IBKR data to Parquet manifests | executes trading logic and emits runtime events v FastAPI TelegramNotifications microservice | +--> alerts, promotion notices, and operational telemetry
Predicts five directional classes from STRONG_SELL through STRONG_BUY so the execution layer can shift posture based on a broader macro backdrop.
Inputs include hourly price structure, rolling market context, momentum state, and higher-level trend features that define the prevailing regime.
Predicts near-term signal quality from seconds-level bars using a 30-minute lookback window, giving the system high-frequency tactical entries without discarding broader context.
Features center on micro-trend shifts, short-window volatility, bar-by-bar momentum decay, and compressed intraday state changes.
Predicts three outcomes in one network: immediate direction, bid-ask spread transitions, and market impact regression from order book behavior.
Inputs are built from Databento level-two snapshots, order book imbalance, queue dynamics, spread state, and short-horizon depth changes that matter for microstructure-aware execution.
Scores the probability of an intraday move for pre-market gap names so the system can prioritize which symbols deserve capital and monitoring attention at the open.
Inputs include float, short ratio, relative volume, and news sentiment signals that separate noisy movers from higher-conviction gap opportunities.
The broker layer manages headless IBKR Gateway sessions in both paper and live modes, including smart port probing and startup hygiene so connectivity is reliable before any trading process begins.
Historical bars and L2 data are written into Parquet manifests, giving the platform reproducible training inputs, auditable data lineage, and a consistent handoff between research and runtime.
Nineteen W&B campaigns capture model lineage, hyperparameters, evaluation runs, and comparative performance over the 2025–2026 training window.
JSON-Logic rules and shared schemas enforce promotion criteria so only models with valid metadata, compatible contracts, and approved release status can move into execution.
A shared FastAPI TelegramNotifications microservice provides the operational nerve system for the trading estate. It decouples alert delivery from both training and execution code, which keeps runtime services lean while still making every important event visible.
In practice, this covers promotion notices, execution status, environment changes, and runtime anomalies. Because the same microservice is shared across the estate, alerts remain consistent whether they originate from model training, broker control, or live execution workloads.