Machine learning earns its place when a decision is being made hundreds or millions of times and the cost of getting it slightly more right adds up. We build the models behind those decisions and — more importantly — the systems that keep them honest when the world shifts underneath them.
The line between machine learning and applied AI is increasingly blurry. We use the term ML when the underlying problem is well-defined, the data is structured, and the goal is to optimise a measurable outcome. Generative AI work lives under its own discipline page; both practices share the same MLOps backbone.
What we build
Forecasting
Demand, supply, energy output, prices, throughput — anywhere a downstream decision (procurement, dispatch, staffing, hedging) depends on a credible projection. We pay attention to interval forecasts and calibration, not just point accuracy.
A forecast nobody acts on is overhead. The hard part is making the forecast operationally usable: integrating it into the planning workflow, sizing the team that interprets it, and instrumenting the downstream decisions so we can tell whether the model is actually moving the business.
Optimisation
Production scheduling, route planning, asset dispatch, feedstock and mix optimisation, energy balancing — combining classical operations research with ML where each fits best. We have built models that adjust process inputs in real time against both environmental factors and commodity benchmarks to maximise yield against current pricing.
Optimisation is where ML and OR meet, and choosing the right tool for the right sub-problem is most of the work. We have no allegiance to either tradition — we use mixed-integer solvers, dynamic programming, reinforcement learning or learned heuristics depending on the structure of the problem.
Classification and computer vision
Material identification, quality grading, defect detection and document classification — trained on real client data, deployed where they are used (cloud, on-prem or edge), and retrained on a schedule we maintain. Used at scale in industrial sorting and processing operations.
The interesting questions in classification are rarely about model architecture. They are about labelling guidelines, class taxonomy under disagreement, dataset coverage of rare-but-costly failure modes, and the retraining cadence that keeps the model in step with reality.
Anomaly detection
Fraud, fault, drift, emerging risk. We design for the rate of false positives the downstream team can actually triage, not the rate that looks good in a slide.
Anomaly systems live or die on the alerting pipeline. We work as much on alert prioritisation, suppression and feedback loops as we do on the underlying detector — because a sensitive detector wired into an unworkable inbox is worth less than a calibrated one wired into a clear runbook.
How we operate models in production
- Versioned models, prompts and datasets in a registry the team trusts.
- Continuous evaluation against held-out and live traffic with explicit acceptance criteria.
- Drift detection on inputs and outputs — alert thresholds set against business consequence, not statistical purity.
- Rollback paths and shadow deployments so a regression never breaks the user-visible service.
- Cost monitoring so inference does not silently turn into the largest line on the cloud bill.
- Real-time BI dashboards so the operators consuming the model can see what it is doing.
Most ML projects fail in operations, not in modelling. The boring parts of this list are what we spend most of our time on, and what makes the difference between a model that ships and a model that quietly stops being used.