Model Risk Management
Deploying machine-learning models to make trading decisions carries a specific risk category beyond ordinary software bugs: a model can be internally consistent, pass every unit test, and still be systematically wrong about the world it was trained on (regime shift, distribution drift, a correlation structure that breaks). This page describes how that risk is governed -- borrowing the same discipline traditional finance requires of model-driven trading desks, scaled to this platform's size.
Validation before promotion
No model reaches live trading weight without passing through the calibration pipeline described in Risk Management: walk-forward validation, live A/B comparison against the incumbent configuration, and a reconciliation check against actual (not simulated) results before promotion. A model that looks good in backtest but fails live reconciliation does not get promoted -- this is an automated gate, not a judgment call made under deadline pressure.
Continuous drift monitoring
The training pipeline (training/, 16 modules) includes dedicated drift monitoring that runs independently of the trading loop -- its job is to notice when a model's live input distribution has moved away from its training distribution, which is the leading indicator of the model quietly becoming wrong before its output performance visibly degrades.
Ensemble as a risk control, not just a performance feature
Because 16 strategy modules vote through a consensus layer rather than any single model having unilateral authority (see ML Models & Strategy Layer), a single model drifting or failing does not directly translate into a bad trade -- it is down-weighted by the consensus mechanism (auto_evolve.py) before it can dominate a decision. This is the same rationale institutional risk committees use for requiring model diversification, not just model validation.
Kill-switch authority
The platform's risk gate (Iron Dome, see Risk Management) can halt new entries independent of any model's output when drawdown, volatility, or cascade-risk thresholds are breached. Model risk governance is not solely "trust the model was validated" -- it is backstopped by a rule-based circuit breaker that does not depend on any model being right in real time.
What this does not cover yet
This page describes the technical control structure. It does not yet describe a human model-risk review board or independent model-validation function separate from the engineering team that builds the models -- that separation-of-duties layer is standard at institutional scale and is a fair diligence question to raise; today, model validation and model development are not organizationally separated, because the organization is one engineer.