A model is only as honest as the split it was tested on.
Most stalled machine-learning projects we are handed have a working model in them already. What they are missing is the path in front of it — ingestion, cleaning, entity resolution, features computed once so training and serving cannot drift apart — and the path behind it: a deployable artefact, an evaluation somebody can defend, a cost per prediction at real volume, and monitoring that notices before a customer does.
That is the work we do. Not a research lab, and most of the time you do not need one.
Anonymised mobile-location data turned into footfall and behaviour insight for a location-intelligence company — the privacy constraint shapes the model rather than filtering its output.
Acoustic, RF, electro-optical/infrared and radar fused into one validated track for airspace security — detection to handoff in four seconds.
There is no accuracy, precision or AUC figure anywhere on this page. A number without a dataset, a split and an operating point is decoration. Every chart here is schematic and says so.
30 minutes, working session. Bring the question you want answered and the data you actually hold; you leave with a one-page read either way. Nobody follows up more than once.
Six states a machine-learning project arrives in
We have been handed all six. Only one of them is about the model.
The notebook that cannot be deployed
It works, and it has a good score. It is also four hundred cells, three hard-coded paths, a manual step in the middle, and one person who knows the order to run it in.
The score was too good
Excellent on the validation set and useless in service. Somewhere a feature contained the answer, or the split was random on data that has time in it. This is found after launch, by a customer.
It works and nobody deployed it
Nearly ready for two quarters. The data science team does not own infrastructure, the platform team has no context, and the model sits between them as everybody’s second priority.
Training and serving disagree
The feature is computed one way in the pipeline and another way in the API. The difference is small, silent and everywhere, and it takes weeks to find because both sides look correct on their own.
It decays and nothing says so
Performance was measured once, at launch. Six months on the inputs have shifted, the model is quietly worse, and the only monitoring in place is on the API’s uptime.
The pipeline was written on a sample
The real dataset arrives, pandas allocates its way through the memory ceiling, and the job that took two minutes now takes nine hours — or nothing at all.
The same data, split two ways
One schematic dataset with time in it, and a feature that quietly carries the answer. Split it at random and the learning curves agree beautifully. Split it by time — train on the past, test on the future, the way the model will actually be used — and the truth arrives.
Training and validation move together to the end. On this evidence the model generalises, the project is finished, and somebody writes a number in a slide.
Rows from the same week are sitting on both sides of the split, so the model is being asked about days it has already seen. The feature carrying the answer — a running total computed after the event — is never tested.
This is the cheapest failure to prevent and the most expensive to discover. It is why the first thing we agree on is the metric and the split, before an experiment runs — so the answer at the end is checkable rather than negotiable.
Reconciling instruments that each lie differently
Acoustic, RF, electro-optical/infrared and radar, fused into a single validated track for airspace security — detection to handoff in four seconds. The hard part is confidence: naive fusion inherits the union of every sensor’s errors, so the work is deciding whose reading to believe, when, and how much. Sensor fusion case →
Four systems, and what was hard about each
Every one has a case page behind it. Where a figure appears below, it is the only figure that has been cleared — there are no others.
Python · SQL
Privacy-safe
Privacy-safe location intelligence at national scale
Anonymised mobile-location data turned into footfall and behaviour insight for a location-intelligence company. The hard part is that the privacy constraint designs the system: the insight has to survive without the individual, which is an aggregation and modelling problem rather than a filtering one. This is the clearest case we have of data engineering deciding what the model can even be. Location intelligence case →
Acoustic · RF
EO/IR · radar
One validated track out of four disagreeing instruments
Detection to handoff in four seconds, for airspace security. Each sensor is wrong in its own way — one in weather, one in clutter, one at range — so the model is a confidence reconciliation rather than a classifier, and the output has to be a track a human operator will act on. Sensor fusion case →
OpenCV · MediaPipe
TensorFlow
Perception where the constraint is a frame budget
Distance and head-angle tracking running live in a browser, beside speech and an animated character. We prototyped on OpenCV, then benchmarked OpenCV with TensorFlow against OpenCV with MediaPipe on accuracy, stability and speed, and shipped the winner behind a clean API. The binding constraint here is not a score — it is how much of the frame this is allowed to cost. Face-tracking case →
Decentralized
MVP
Making a model’s provenance and cost legible
An MVP connecting data suppliers, ML developers and compute into one ecosystem with micropayments. The hard part is that the three sides value completely different things, and the product has to make where a model came from and what it costs readable by someone who is never going to open the code. ML marketplace case →
Two more pieces of data-science work sit outside these, without case pages of their own. We have worked with PeakVentures, whose product is advertising and marketing intelligence built on live signals rather than lagging reports — real-time signal processing, cross-channel journey mapping and predictive audience modelling. And a precision-healthcare platform, which we are not naming, where the delivered piece was exactly one thing: the filtration of a dataframe. That is a small sentence for a real week of work, and it is the honest shape of this field.
What the data-science seat on this team covers
Beyond the four systems above, this is the range an estimate here is drawn from. Read it as depth on the seat rather than a list of delivered projects.
Natural-language work with spaCy, NLTK, Gensim and Transformers: extraction and structuring from documents that were never designed to be parsed, and the unglamorous evaluation that tells you whether the extraction is trustworthy on the next thousand.
Graph-theoretic analysis with NetworkX and Neo4j, where the value is in the relationships rather than the rows — entity resolution, network structure, and the patterns a table will not show you.
PyTorch and scikit-learn as the everyday tools; TensorFlow and Keras where that ecosystem is already in place, as it is on the digital employee. Pandas everywhere, and the discipline to know when a dataframe has outgrown one machine.
Deploying models into production environments rather than handing over a notebook: the artefact, its version, its evaluation harness, and the retraining path written down before anyone needs it.
Exploratory analysis sits under all of it — the days spent finding out what the data actually contains, which is where most of the honest surprises live and where a project is usually saved or lost.
A model is an asset with an owner and a bill
Once a model leaves the notebook it acquires the things software has: a version, a provenance, a cost per call, and someone accountable when it is wrong. Building that scaffolding is unglamorous and it is what separates a model that runs from a model that shipped. ML marketplace case →
The work, as we actually sell it
Timelines are indicative ranges and depend on scope. The first one is small enough that the answer is allowed to be no.
Is a model the right instrument?
2–3 WEEKSWhether the data supports the question, whether a deterministic rule would do it, what the baseline is, and what a model would have to beat to be worth running. You get the document, and the do-not-build recommendation if that is the answer.
Data pipeline before model
4–12 WEEKSIngestion, cleaning, entity resolution, feature computation and versioning — built once and used by both training and serving, so the two cannot quietly diverge.
Notebook to production
6–14 WEEKSA working experiment becomes a deployable, testable, versioned artefact with a defined retraining path. You get the service, the evaluation harness, and the model versioned separately from the code.
Evaluation you can defend
2–6 WEEKSThe metric chosen before the experiment, temporal splits where time matters, leakage checks, calibration, and a baseline that is honest about what a simple rule already achieves.
Inference cost and latency
3–8 WEEKSBatch against real-time, quantisation and distillation, hardware choice, and the cost per prediction modelled at your real volume rather than at demo scale.
Monitoring and drift
3–8 WEEKSInput-distribution monitoring, scheduled retraining with its own regression suite, and an alert that reaches a person before a customer writes in.
What you are probably thinking
Not ready to talk? Take the checklist.
One page, 15 questions to ask before your model goes to production — temporal splits and what makes one necessary, the leakage checks worth running first, training and serving computing the same feature the same way, the baseline a simple rule already achieves, how the model is versioned against the code, cost per prediction at real volume, what is monitored besides uptime, and who gets paged when the inputs move.
Bring the question, the data you hold, and the decision it would change.
A free 30-minute working session, not a sales call. We restate your question as a modelling problem, name the baseline it has to beat, and tell you whether a model is the right instrument at all. You keep a one-page read either way: the question restated, the baseline, the leakage risks we would check first, and whether a deterministic rule would do the job.
