7 years building systems, 6+ years building models.

01

Flagging demand the drivers do not explain

Rolling Bayesian linear regression, Normal-Inverse-Gamma prior, posterior predictive p-values

• A fixed threshold, like mean plus or minus three standard deviations, does not move with the drivers, so it flags every promotion week. This model sets the expectation from the drivers. Say a promotion week should bring 120 units, give or take 10. If 160 arrive, only the gap the drivers do not explain is flagged.
• Demand = drivers (promotion, price, seasonality, weather) · weights + Gaussian noise. A zero-centred Gaussian prior on the weights (ridge regression in Bayesian form) plus an inverse-gamma prior on the noise variance is the Normal-Inverse-Gamma prior. It is conjugate, so each rolling-window fit gives the posterior and the posterior predictive, a Student-t, in closed form with no sampling. A two-sided posterior predictive p-value flags drops and spikes.
• I chose Bayesian regression because its flag comes with a reason. ARIMA, Isolation Forest and deep models can all flag a point, but ARIMA ignores the external drivers and the other two do not say why. Here the posterior weights carry credible intervals, so weight times driver value at the flagged point shows what moved demand. Driver attribution builds on this model.

deployed as a serviceon GCP Cloud Run, in Avathon's demand planning platform

Python, Normal-Inverse-Gamma updating, scikit-learn BayesianRidge, PyMC, FastAPI, Docker, GCP Cloud Run

02

Finding train faults the rules missed

Unsupervised anomaly detection with autoencoders on odometry and ATC signals

• A rule-based monitor fires only on faults someone already wrote a rule for. Say a rule trips when a signal crosses a fixed limit. A fault that looks odd inside that limit never trips it. I built unsupervised detection on train odometry and ATC (automatic train control) subsystem signals. It reached over 99% recall and surfaced failures the rules missed. I also packaged a statistical fault detection model as a standalone executable for the production fleet management system, where it improved maintenance efficiency by 30%.
• The models are autoencoders. An autoencoder squeezes a window of signal through a narrow middle layer and then rebuilds it. Trained on normal running, it learns to rebuild normal behaviour well. A window it rebuilds badly is unlike what it trained on, and that reconstruction error is the anomaly score. No failure labels are needed.
• I chose to learn normal behaviour because railway failures are few and far between. A classifier needs labelled faults, and there are too few to train one. Normal running fills the logs, so learning normal and flagging departures fits the data we have.

Basis Measured by the Alstom team, 2020 to 2023.

in productionon a fleet management system

Python, PyTorch, TensorFlow, autoencoders

Show the working

03

Naming the driver behind a flagged anomaly

Drop-one-driver Bayesian refits ranked by ΔBIC and Bayes factors, inside a multi-agent planning co-pilot

• A flag says demand is off, not why. When several drivers move in the same week, seeing which one changed does not settle it. So I drop each candidate in turn (promotion, price, weather, competitor stockout), refit on the anomaly window and rank drivers by how much worse the fit gets. The test demand I generated had a weather shock in only some states.
• The model is the Bayesian linear regression behind the anomaly detector. Dropping driver j and refitting changes BIC = k ln n - 2 ln L̂. A large rise, ΔBIC, says the window needs that driver, and exp(ΔBIC / 2) approximates the Bayes factor. The posterior coefficient and its credible interval size the effect; weight times driver value gives its contribution at the flag.
• I attribute with the same Bayesian regression that raises the flag, so one model gives both the detection and the explanation. In a planning co-pilot, a root agent passes a planner's request to anomaly, causal and forecasting agents through structured tool calls under an Observe Orient Decide Act loop, and GPT-4o returns the recommendation with its explanation.

presented internallythe attribution method, at an Avathon monthly all-hands

Python, scikit-learn BayesianRidge, ΔBIC, Bayes factors, LangChain, GPT-4o, structured tool calls

04

Ranking the causes of transit failures

Causal discovery and Causal Bayesian Networks with interventional and counterfactual queries

• Correlation-based monitoring can say which signals move with a failure, not which one caused it. Say two alarms appear together before most service failures. Correlation ranks them equally, so an engineer checks both. I built a root cause system that ranks causes by probability, so the engineer starts with the most likely one. It went into production on an urban transit fleet, and troubleshooting time fell 86%.
• Causal discovery learns, from the time-series data logs, a directed graph of which component states influence which. A Causal Bayesian Network gives each node a probability conditioned on its parents. That supports interventional queries, P(failure | do(fault)), which set a component's state and cut the arrows into it. It also supports counterfactual queries: given this failure, would it have happened without that fault?
• I chose a Causal Bayesian Network because it reaches all three rungs of Pearl's causal hierarchy: association, intervention and counterfactual. Correlation stops at the first, and naming a root cause needs the third. We developed this method as research work, and it became a UAI 2024 paper I co-authored on time-dependent counterfactual root cause analysis. We found no earlier use of the hierarchy for root cause analysis in an industrial setting.

Basis Measured by the Alstom team, 2023 to 2025.

in productionon an urban transit fleet

Python, causal discovery, Causal Bayesian Networks, do-calculus, counterfactual queries

Show the workingRead the paper

05

Choosing each series' model on the holdout, not at fit time

WAPE-primary model selection with an event-window gate and a 1.5x degradation cap

• The pipeline picked each series' model by its in-sample pinball loss at fit time. A score on weeks the model has already seen rewards fitting those weeks, not forecasting new ones. On 69 of 76 series (90.8%), the fit-time winner was not the holdout winner: the in-sample criterion was uncorrelated with holdout accuracy. I retired it and now select on the holdout.
• WAPE, the primary score, is total absolute error over total demand across the holdout weeks, sum |y - ŷ| / sum y, so big weeks count more. A model must also pass a gate: where a series has at least 3 active event weeks, its event-window WAPE must be at or below 1.2 times its overall WAPE. A 1.5x per-series degradation cap guards against regressions.
• I also dropped pinball loss at the 85th percentile as the selection score. The forecast feeds a P50 waterfall, so a criterion built for a high quantile was judging the wrong number. Across three pipeline reruns, median holdout WAPE went from 0.574 to 0.529 to 0.451. The cap resolved all 5 major regressions, and all 9 series whose selection changed improved.

Basis Median across 76 weekly retail series, holdout window, single split.

in productionfor a global consumer-devices manufacturer

Python, LightGBM, XGBoost quantile objective, statsmodels ETS and SARIMAX, pandas, parquet

Show the working

06

Forecasting new products from the ones they replace

Predecessor-successor transition features in gradient-boosted demand forecasters

• A new PC model starts with almost no order history, but the model it replaces often has a longer one. I mapped each product family to its predecessors, including many-to-many transitions, so a new model can borrow that signal. A family with a single record and no predecessor had nothing to learn from and nothing to borrow, so I marked it not forecastable from history.
• The forecasters are tree ensembles (XGBoost, LightGBM, CatBoost and Random Forest) with lag features and two lifecycle features: product age and days left in the lifecycle. The one-level predecessor from the transition map is a feature too, so a series with little history carries signal from the product before it. Forecasts run recursively: each month's prediction becomes the next month's lag.
• I chose to borrow from the predecessor, or from similar product lines, because planners do the same for any new launch. With no history, you make a calculated guess from similar products, yours or the market's. That is analogue forecasting. The same launch problem showed up in a weekly retail forecast at a global consumer-devices manufacturer. One launch overshot about 12 times over (WAPE 11.76), and pre-release clipping zeroed another. I concluded that capped and launch series should be scored by cap correctness and launch-ramp shape, not WAPE.

Basis PC forecast of 80 SKUs over 5 regions; launch series from weekly retail forecasts, holdout window, single split.

deliveredto a global PC manufacturer

Python, pandas, XGBoost, LightGBM, SARIMAX, Prophet, PyTorch LSTM

07

Routing 40,447 spare parts by their demand pattern

Syntetos-Boylan classification feeding a statsforecast model menu

• Say one part is used a few units every week and another 40 at a time once a year; they need different models. The first design split materials by plant mix. I moved model selection onto each material's own demand pattern and kept plant mix for splitting forecasts. Across 40,447 maintenance and spares materials, quantity share came out smooth 34%, lumpy 22%, intermittent 21% and erratic 18%.
• Syntetos-Boylan classes use two numbers: ADI, the average gap between periods with demand, and CV², the squared coefficient of variation of the non-zero demand sizes. The standard cut points, ADI 1.32 and CV² 0.49, give four classes. I flagged the 2,888 of 40,447 (7.1%) sitting on a cut point as unstable. Each class routes to a statsforecast menu, with AutoETS, Croston-SBA and TSB among them.
• A class narrows the menu, but each fit still gets checked. Flat forecasts on seasonal parts showed AutoETS collapsing to a level model. I added a forced seasonal AutoETS entry (ZZA) to the menu. It took one material from MASE 0.77 to 0.51 and another from 1.65 to 1.31. MASE scales error by a naive forecast's error, so below 1 beats naive.

Basis Per-material panel at one site, holdout MASE per series, single split.

shipped to customera mining and industrial operator, where production model selection reads it

Python, statsforecast with AutoETS including forced seasonal ZZA, AutoTheta, Croston-SBA and TSB, conformal prediction intervals, LightGBM, Plotly

08

Judging a forecast by the fill rate it produces

Lognormal lead-time demand, (s,S) policy sweeps and a nested backtest

• A forecast can look fine on error and still set a reorder point that runs the shelf empty. On one material, a Naive model frozen inside a composite collapsed the forecast band at the second cutoff. The reorder point fell from 3,618 to 489, and fill rate dropped about 54 percentage points. A pre-deployment guardrail caught it before rollout.
• The forecast gives a P10, P50 and P90 band. I fit a lognormal to it: σ = (ln P90 - ln P50) / 1.2816 from the upper span, because that tail sets the reorder point, and μ = ln P50. A bootstrap over past reservations gives the burst shape inside the lead time. An (s,S) sweep sets s from a service-level grid and S - s from min(EOQ, cap).
• I selected policies per segment, with per-material overrides only past a 10% margin, because per-material validation fill rate predicted test fill rate at Spearman ρ = 0.06 across 41 keys. The verdict: deploy on 9 smooth series, where test fill rate was 97.7% against the incumbent policy's 74.5% at lower inventory cost, and keep the incumbent on intermittent and lumpy series.

Basis Series at one site; nested split: train to 2024-12, validate on 2025, test on 2026-H1.

decision deliveredto a mining and industrial operator

Python, statsforecast, LightGBM, NumPy and SciPy lognormal fitting, pytest

Show the working

09

Planning production and freight in one program

A demand forecast feeding a mixed integer linear program for the Master Production Schedule, pack-out and freight mode

• On average, capacity looked fine: demand averaged 13,033 units a week against 14,409 units a week of pre-build capacity (90.5%). But 23 of 91 weeks ran over the cap, peaking at 80,059 units in the Presidents Day week. Building to each week's demand cannot meet those peaks, so the decision is when to build ahead and how to ship what was built.
• A demand forecast by SKU, channel, geography and week feeds a mixed integer linear program. It plans the Master Production Schedule and the pack-out together. A yes-or-no one-colour-per-week production constraint is what makes it integer. Weeks-of-supply targets are 12 for channels 1 and 2 and 13 for channel 3. Each week it picks air, fast boat or ocean under a 7-week ocean lead time.
• To test the planner and not a forecast, I replayed 52 weeks of actual demand through it. On channel 3, about 95% of sales, in one region, the plan cost $508K in freight against $1.53M all air and $763K all fast boat. That equals all ocean: with the pre-build scheduled, ocean could carry the year.

Basis 52-week backcast replay of actual demand, channel 3 (about 95% of sales) in one region; capacity check over 91 weeks of demand.

proof of conceptbackcast replay for a global consumer-devices manufacturer

Python, PuLP, CBC, pandas, XGBoost, SARIMAX

10

Finding and retracting a leak in my own benchmark

Gain-based feature attribution on a global LightGBM, then a leak-free recompute

• A covariate summed over a window that includes the holdout lets the model see the answer. Mine did: the backtest computed total_qty over a window that included the holdout. A feature importance export gave it 68.8% of model gain against lag_1 at 0.08%. The model was estimating each series' scale, not modelling demand dynamics. I now compute covariates only from data before each forecast origin.
• LightGBM gain importance is each feature's share of the loss reduction from all splits on it. When one aggregate takes most of it and the latest lag gets almost none, the model is reading level, not change. The leak hurt most where lags carry no signal. Rerunning with pre-origin covariates measured it at 9.9 WMAPE points on intermittent demand and 6.2 on lumpy.
• I retracted the published claim in writing instead of revising it quietly. That claim had LightGBM winning by 23 points. Leak-free, it scored 51.9 WMAPE on intermittent and 69.0 on lumpy, against Croston-Optimized at 62.6 and 70.7. I recomputed all 16 sweep configurations without the leak, and the ranking held. The lesson I wrote down: feature importance is step zero.

Basis Intermittent and lumpy series at one site, holdout backtest.

shipped to customercorrected findings reissued

Python, LightGBM, feature attribution, pandas