AI
Two different tools
Prediction and optimisation are not the same job
A model that forecasts demand tells you what is likely to happen. It does not tell you how many vehicles to send, which staff to roster, or which orders to accept — and using a forecast to answer those questions usually means somebody applying rules of thumb to its output in a spreadsheet.
Optimisation answers the second kind of question directly, and can prove that no better answer exists inside the constraints you gave it. Most real problems need both: a forecast to say what is coming, and a solver to decide what to do about it.
We are equally comfortable telling you a problem needs neither.
What we build
Where this earns its keep
Scheduling and rostering
Crews, shifts, vehicles, theatre lists, maintenance windows. Constraints that contradict each other and a solution that has to hold when someone calls in sick.
Planning and allocation
Production plans, network flow, inventory placement, portfolio and capital allocation under limits that are policy rather than preference.
Forecasting and classification
Demand, risk, churn, failure. Built where enough honest history exists to learn from, and refused where it does not.
Documents and language
Extraction from contracts, claims and reports; routing and summarising, with a human in the loop wherever being wrong is expensive.
Tooling
CPLEX, Gurobi, and knowing when you need neither
We model in the commercial solvers — CPLEX and Gurobi — because on hard mixed-integer problems they remain substantially faster than the open alternatives, and speed is what decides whether a plan can be re-run after a disruption or only overnight.
Licences are expensive, so we also run models through NEOS, the free solver service hosted at the University of Wisconsin, which is a practical way to prove the value of a model before anyone signs a purchase order. For smaller problems we will happily use an open solver and tell you the licence is unnecessary.
Models are written to be read. You get the formulation, not just a binary that emits numbers nobody can question.
How it runs
From question to something in production
Frame the decision
What is actually being decided, by whom, how often, and what makes an answer unacceptable. Most failed models are answers to the wrong question.
Look at the data before promising anything
A short, paid look at what you hold. It sometimes ends with us saying the data will not support the model you wanted — which is cheaper to hear now.
Build the model and test it against reality
Measured against what your people currently decide, on historical cases, so the benefit is a number rather than a claim.
Put it where the decision is made
An API, a scheduled run, or a screen your team already uses. A model nobody can reach changes nothing.
Hand it over
Documented, re-trainable and owned by your team. We would rather be asked back than be needed.
Plainly
What we will tell you
If a rules engine and a well-built report would do the job, we will say so. If the data is too thin, too dirty or too new to learn from, we will say that too, before anyone has spent a quarter finding out.
Nothing here is judged on whether it is impressive. It is judged on whether the decision it touches gets measurably better.