← Back to Blog

How We Built a Self-Improving Trading AI That Thinks Like a Quant Team

When I set out to build Traders Regiment, I had one rule: no shortcuts. Every component had to be built the way an institutional quant team would build it — with the right tool for the right job, with explicit contracts between layers, and with failure modes that were designed for rather than discovered in production.

This is the architecture of that system. Every layer, every decision, every reason.

The System at a Glance

Traders Regiment is a monorepo with six independently deployable services:

The Language Stack — The Right Tool for Every Task

No single language is best for everything. We chose each language for what it does best:

Task	Language / Stack	Why
Real-time signal orchestration	Node.js	Non-blocking async I/O — concurrent calls to 12 models at once
ML model inference	Python	scikit-learn, LightGBM, PyTorch — mature, best-in-class ML ecosystem
Sequence modeling	PyTorch Mamba	State-of-the-art long-range dependency modeling for market sequences
Regime detection	Python	HMM, fractal analysis, anomalous diffusion — statistical foundations
Frontend UI	React	Reactive component model — fast, declarative, easy to test
Data pipeline	Python (pandas, numpy)	Best for numerical, time-series, and financial computation
Telegram bridge	Node.js	Event-driven architecture matches Telegram's webhook model
Circuit breaking	Node.js	Built-in async error handling + promise race conditions for timeouts

The 5-Phase Recursive Consensus Engine

This is the core of Traders Regiment. Every trading decision passes through five phases:

The 12 Models

Each model is an independent analytical agent with its own specialty. They don't know about each other — they just produce their output. The ensemble aggregator collects all votes and converges on a consensus:

• DirectionModel — bull/bear/neutral classification with confidence scores
• MagnitudeModel — predicted size of move, not just direction
• RegimeModel_HMM — Hidden Markov Model for regime classification
• RegimeModel_FPFK — Fractal and power-law regime detection
• RegimeModel_Anomalous — Anomalous diffusion detection for crisis identification
• SessionModel — historical session probability distributions
• AlphaModel — non-obvious edge from cross-model disagreement
• OptionsModel — IV regime, gamma exposure, options flow analysis
• TechCandleModel — candle pattern recognition with wick noise filtering
• TechIBModel — trendline and horizontal structure analysis
• MambaSequenceModel — long-range sequence pattern recognition (PyTorch)
• ExitModel — stop-loss and target optimization per regime

Recursive Deliberation

Phase 2 doesn't end with a simple vote. The ensemble aggregator runs a multi-round deliberation:

1. Round 1: All 12 models vote. Ensemble aggregates.
2. Round 2: Models that were in the minority are asked to justify or revise. Regime conditions are injected as context.
3. Round 3: Final convergence. Confidence score is weighted by historical model accuracy in the current regime.

The result is not just a majority vote — it's a deliberated consensus that has been stress-tested against dissenting views.

The Deliberative Board Room

The Board Room is our governance layer. It exists to prevent bad trades, not just to confirm good ones. It has veto power — and it uses it.

Board Member	Specialty	Veto?
Tech_IB	Trendline + horizontal structure geometry	No
Tech_Candle	Candle patterns, wick noise filtering ("wick = noise, close = truth")	No
RegimeWatcher	CRISIS and CONTAGION regime detection	YES
OptionsDesk	Expiry day detection, LOW_IV regime	YES
RiskOfficer	Daily stop (2 losses), max positions (1 open)	YES — ALWAYS FINAL

Veto Conditions (Codified)

• regime == "CRISIS" or "CONTAGION" → RegimeWatcher vetoes
• is_expiry_day == True or iv_regime == "LOW" → OptionsDesk vetoes
• losses_today >= 2 or positions_open >= 1 → RiskOfficer vetoes
• dead_chop == True (ATR < ATR_avg × 0.5) → Tech_IB vetoes
• wick_alone == True (wick signal without close confirmation) → Tech_Candle vetoes

The Board Room cannot be overridden by any other component. RiskOfficer veto is absolute. No code, prompt, or agent may disable or bypass these conditions.

Watchtower — The Self-Correcting Guardian

Watchtower is our performance monitoring and self-correction layer. It runs continuously, not on-demand.

Watchtower monitors:

• Model Drift — every 15 minutes, Watchtower compares each model's recent accuracy against its 30-day baseline. If accuracy drops more than 5%, the model is flagged.
• Regime Stability — if the regime classifier changes state more than 3 times in one hour, a regime instability alert fires and strategy weights are tightened.
• Signal Outcome Tracking — every signal's outcome is logged. Watchtower compares predicted vs. actual across regime, session, and instrument.
• Performance Decay — if the overall ensemble win rate drops below the paper-trade threshold, Watchtower sends a regime-specific alert to the trader.

Watchtower is the reason Traders Regiment doesn't just work on day one. It works better on day 30, and even better on day 300. The system learns from its own performance.

Self-Correction Loop

Self-Improving AI — The Continual Learning Pipeline

Traders Regiment uses Elastic Weight Consolidation (EWC) — a technique that allows the AI to learn new market patterns without catastrophically forgetting the patterns it already knows. This is critical in trading, where old regimes return and old patterns resurface.

The continual learning pipeline:

• Paper Trade First — every model change or new strategy is paper traded for a minimum 1 trading week before any consideration for live deployment.
• Replay Buffer — significant historical events (regime transitions, crisis events, high-volatility sessions) are stored and replayed periodically to reinforce old learning.
• Bayesian Hyperparameter Optimization — Optuna-based tuning that adapts learning rates and regularization to current market conditions.
• MLflow Tracking — every training run is logged with parameters, metrics, model artifacts, and DVC commit hash. Full data lineage from candle to signal.

Security Architecture

Security is not a feature. It's architecture. Every layer has explicit security controls:

Security Measure	Layer	What It Prevents
No secrets in code	All layers	Credentials in git history
Parameterized SQL queries	ML Engine	SQL injection
Pydantic input validation	ML Engine	Malformed inputs
5s timeout + circuit breaker	BFF	Cascading ML failures
Rate limiting	BFF	API abuse / DoS
SSH key auth + fail2ban	VPS	Brute-force access
UFW firewall (SSH locked to known IPs)	VPS	Unauthorized network access
Zod validation on all BFF routes	BFF	Bad data entering the system

Data Infrastructure

• SQLite Candle Database — efficient, portable, ACID-compliant. Candle data, session aggregates, trade log. Loaded from NinjaTrader CSV exports.
• DVC (Data Version Control) — every dataset tracked alongside code. dvc repro recomputes the full pipeline. dvc push/pull syncs models and data to/from remote storage.
• MLflow — experiment tracking for every training run. Self-hosted via Docker. Parameters, metrics, SHAP values, and model artifacts logged automatically.
• MinIO (S3-compatible) — model artifact store. Production models promoted from Staging after paper trade review.

The Pipeline Ahead

The current architecture is the foundation. Here's what's being built on top of it:

• Watchtower Auto-Recalibration — Watchtower triggers EWC recalibration automatically when drift is detected, without human intervention.
• Redis Caching — adding Redis for sub-millisecond consensus caching. Regime cache TTL 300s. Consensus cache TTL 60s.
• Trading Calculator Hub — stateless API routes for every trading calculator, backed by Python numerical engines.
• Multi-Asset Data Pipeline — MCX, forex, crypto candle ingestion into the same DVC-tracked database.
• Institutional API — REST API with API key auth for white-labelling the consensus engine to prop firms.

The architecture was designed for growth. Every layer has explicit contracts. Every service is independently deployable. Adding a new model family takes one new subdirectory and one new BFF route — nothing else needs to change.