AI & Data
Models that hold
when the data moves
Gradient-boosted trees still beat deep learning on most tabular business problems, and they retrain in minutes. We build forecasting, classification, ranking and anomaly detection systems, and we choose the boring model whenever the boring model wins.
Overview
Forecasting, ranking and detection models that keep working after the data shifts.
Machine learning in an enterprise is mostly a data engineering problem wearing a statistics costume. Feature availability at inference time, label leakage, and the gap between backtest and live performance account for more failed projects than model architecture ever has. We plan for those three before anything else.
Typical work: demand forecasting at SKU and location level, credit and fraud scoring, predictive maintenance on sensor streams, churn and propensity models, and search or recommendation ranking. Each gets a feature store, a backtest that respects time ordering, and a monitoring job that compares live predictions against outcomes as they arrive.
We are explicit about what accuracy is worth. A model that improves forecast error by two percentage points is only useful if the planning process can act on it; we work that arithmetic out with your operations team before training begins, and occasionally it tells us not to bother, which is a cheaper answer than a model nobody uses.
- 17.3%
- Reduction in weekly forecast MAPE at Brightmoor Foods
- 8.2 days
- Median warning lead time on bearing failures, Kestrel Industrial
- 1,900/s
- Sustained scoring throughput at 45ms p99 per request
Capabilities
What this covers
Six areas we staff properly. If your problem sits outside them, the honest note at the foot of this page says so.
Forecasting at scale
Hierarchical forecasts reconciled across SKU, site and region, with intermittent-demand handling and prediction intervals rather than point estimates. Backtests use rolling-origin evaluation, never random splits.
Classification and scoring
Credit, fraud, churn and propensity models calibrated so the score means what it says. We tune the decision threshold against the cost of a false positive in your process, rather than against an F1 score.
Anomaly detection on streams
Detection across sensor and transaction streams with seasonality-aware baselines and alert budgets. An alert your operators ignore is worse than none, so we tune for the volume a shift can actually action.
Feature stores and training pipelines
Point-in-time correct feature retrieval so training data cannot see the future, with the same code path serving features online. It removes the commonest cause of a model that backtests well and fails live.
Model monitoring and retraining
Population stability, feature drift and prediction-versus-outcome tracking, with retraining triggered by measured degradation rather than a calendar. Runs are reproducible from a pinned dataset version.
Interpretability and model risk
SHAP attributions, reason codes for individual decisions and stability testing across customer segments, documented to the standard a model risk function accepts, because in banking they will ask for it.
Deliverables
What you get
- Feature store with point-in-time correct offline and online retrieval
- Reproducible training pipeline pinned to versioned datasets and code
- Backtest report with rolling-origin evaluation and business cost analysis
- Deployed scoring service with latency and throughput benchmarks
- Drift and outcome monitoring with documented retraining triggers
- Model documentation pack including reason codes and segment stability tests
Stack
What we build it with
- scikit-learn
- XGBoost
- LightGBM
- PyTorch
- Feast
- MLflow
- Apache Spark
- Optuna
- Evidently AI
- Databricks
- Kubeflow
- Prophet
Process
How the engagement runs
Two-week increments against a written definition of done. You can stop at any increment boundary and keep everything built so far.
Decision mapping
We trace where the prediction lands: who acts on it, within what window, and what a wrong answer costs in currency. No model is scoped before that is written down.
Data audit and leakage hunt
We rebuild the dataset as it would have existed at prediction time. Leakage found at this stage is cheap; leakage found after go-live is a retraction.
Baseline then model
Last value, seasonal naive or a simple rule sets the floor. Anything we train has to beat it by a margin worth the operational cost of running it.
Deployment and shadow run
The model scores live traffic without acting on it for two to six weeks, so you compare predictions against outcomes before anything changes downstream.
Monitoring and retraining
Drift thresholds, outcome tracking and a retraining pipeline your team can run alone. We document the conditions under which the model should be switched off.
When this is the wrong engagement
If the relationship you want to model has changed structurally in the last quarter — new pricing, a new plant, a merged customer base — historical training data will mislead you, and rules should carry the process until enough new data exists.
FAQ
Questions we get asked
- How much data do we need before this is worth doing?
For tabular classification, a few thousand labelled examples per class is often enough to beat a rule. For forecasting, two to three full seasonal cycles matters more than row count. The binding constraint is usually label quality, and we check that in the first fortnight.
- Do you use deep learning?
Where it earns its place: sequence models on sensor streams, embeddings for text and images. For tabular data, gradient-boosted trees usually match or beat neural networks while training in minutes and staying far easier for your team to maintain, so that is where we start.
- How do we know the model still works six months from now?
You measure predictions against outcomes as they land, not accuracy on the original test set. We ship dashboards for population stability and per-segment error, with thresholds that page someone. Retraining is triggered by that signal rather than by a monthly cron job.
- Can you work with our existing data warehouse?
Yes, and we prefer it. Training reads from Snowflake, BigQuery or Databricks through the same tables your analysts use, so a number in the model matches the number in the report. Where the warehouse lacks event timestamps we add them rather than working around the gap.
Related