Services

The problem

A large estate produces far more telemetry than anyone can watch. Fixed thresholds either fire constantly and get muted, or stay quiet through the failure that mattered. Even when one fires correctly it arrives at the moment of failure and says only that something broke, not what has been degrading or why. The gap is rarely the algorithm. It is the distance between a method that works on a saved dataset and a service that runs every day against live data.

How I work on it

I start with the failures you actually care about and the data you actually have. That usually means a period of unglamorous work on the telemetry itself: what is recorded, how often, what is missing, and which signals move together. Those relationships are also what later let a detection point at a probable cause rather than just a timestamp. Detection design comes after that.

I choose the simplest method that can be defended, I say plainly what it will not catch, and I stay with it for as long as it holds. Multivariate analysis and careful feature work solve a large share of detection problems at a fraction of the cost of a trained model, and produce a result you can explain to the engineer who has to act on it. Heavier machine learning is a decision to argue for on the evidence, not a starting assumption, and I will tell you when the simpler approach has run out of room.

Detection on its own is reactive: it tells you that something has gone wrong. The systems worth building go further, locating where a fault originates rather than where it surfaces, and picking up slow degradations and periodic patterns before they become an outage. My published research covers that ground directly, including fault localisation and periodicity analysis. I have taken this route through to a service running against the telemetry of a supercomputing fleet of roughly 9,000 GPUs at a leading US national laboratory, while employed at Dell Technologies.

I test the system and write up the results, so your engineers can see how often it gets things wrong and carry on with it after handover. Where the compute budget is tight and the engine has to share machines that are already busy, it is written in Rust. Where the analysis is exploratory, Python.

• Detection engine, deployable and documented
• Fault localisation and early-warning signals, where the data supports them
• Validation harness and reproducible results
• Alert and triage design for the operations team
• Handover documentation and code walkthrough

The problem

Capacity decisions get made on a spreadsheet that one person understands and nobody trusts. The question underneath them is how close a system is to saturation, and nothing in the metrics reports that directly. Throughput, latency and queue depth are all observable. Headroom is not. Working it out means building a usable proxy for it out of the I/O behaviour you can measure, then being able to say what that proxy does when the workload changes in size, in mix, or in pattern. On a real estate, that measurement is patchy before you start.

How I work on it

I build a model of how the system responds to I/O rather than a trend line through past utilisation. A trend line can only extrapolate conditions the system has already met, and the capacity questions worth asking are about conditions it has not. The model gives you a proxy for the headroom you have now, and a way to ask what that becomes under a workload you have not yet run.

Before any of that there is usually a dataset to build. Fleet telemetry is rarely uniform: systems run different firmware, report different metrics, sample at different intervals, and go quiet for days at a time. Working out what is genuinely missing, what is an artefact of how the data was collected, and what can reasonably be reconstructed is a large part of the job, and getting it wrong quietly biases everything built on top. I do that work deliberately and write the decisions down, because a model is only as defensible as the dataset underneath it.

The result has to be something your own planners can drive and interrogate. If they cannot see why an answer changed, they will go back to the spreadsheet.

Most of the remaining risk sits in the testing rather than the model. The usual failures are a model that was accidentally shown information it would not have had at the time, a backtest arranged in a way that flatters it, and prediction ranges that are narrower than the errors they are supposed to cover. I check for all three before anyone is asked to plan against the output, and where a simple baseline passes those checks I will say so and stop there. I built a workload forecasting and what-if planning tool on these principles that was adopted by product teams at Dell Technologies.

• Dataset assembled from existing telemetry, with its gaps and assumptions documented
• Headroom model with its evaluation written up
• What-if planning tool for non-specialist users
• Backtest results and evidence that the prediction ranges hold
• Review of an existing model you already depend on

The problem

Logs, alerts and tickets are part English and part machine: IP addresses, hex codes, timestamps and vendor tokens. General-purpose language models have never seen the second part. If the job is routing an alert to the right team, the second part is usually where the answer is. Language models have made this look easy. They have also made it easy to ship something that demos well and fails quietly on your data.

How I work on it

A log line carries meaning at three levels: the words, the shape of the tokens that are not words, and the mix of characters inside each one. An IP address, a hex code and a timestamp are recognisable before you have seen that exact value. The architecture that reads all three was not mine. The evidence that it works on real operational text was. My published research took it to 0.98 accuracy, showed that it degrades gracefully on a system it has never seen, and showed that it can be adapted to a new system without starting from scratch.

The difference was made in the data, not the model. Build a corpus that contains your vocabulary. Mask the parts of a message that change every time, so near-duplicates collapse into templates. Label by rule where a rule holds and by hand where it does not. Then measure how much of the live vocabulary the model has actually seen, and pull each input out in turn to find out what it is really doing. That last step is how you learn that character-level features carry a model through an environment it was never trained on. It is also the step that gets skipped.

When a team is weighing a large language model against something smaller, I build the evaluation first, and cost, latency and failure modes go into the comparison alongside accuracy. The answer is often a lightweight model fed by a careful data pipeline, which can be retrained cheaply and deployed at scale. Sometimes it is the large model. The evaluation is what tells you which.

• Corpus, templates and labelled training set, with the labelling rules written down
• Classification or extraction pipeline, production-ready
• Evaluation designed around your data
• Model selection review, costs included
• Second opinion on a vendor claim or an internal build

I provide expert witness and litigation support in disputes involving artificial intelligence and machine learning systems. That means independent, evidence-based opinion on how a model was built, what it was evaluated against, whether a technical claim stands up, and what the records actually show. My opinion rests on ten years of building and operating production machine learning systems, including anomaly detection at national-laboratory scale, and on published research in model evaluation. I give the same answer whoever is asking. If you are a solicitor working on a matter of this kind, I would be glad to discuss it.

Fixed-scope delivery

A defined piece of work with an agreed outcome and an agreed price. Best when you know what you need built and want it finished.

Call-off advisory days

A block of days drawn down as you need them, for design review, method selection, or a standing second opinion on work your team is doing.

Technical due diligence

An independent read on a machine learning system or a technical claim, for investors, acquirers, or a board that has been told something works.

Work is delivered remotely from Brighton, with time on site where the problem needs it. Rates are quoted per engagement rather than published, because scope and duration change the figure. Ask and you will have a quote within two working days.