AI for Business Processes

Not every problem needs a large language model. A great many business processes are better served by a small, purpose-built model that does one thing reliably, runs on a laptop or an embedded device, costs nothing per inference, and can be explained to an auditor. Much of my doctoral research depended on exactly that kind of AI: computer vision, SLAM, trained classifiers and probabilistic filters, working together inside a single processing pipeline.

I help organisations work out which category their problem falls into — and then build it, whether that means a fine-tuned generative model, a 200 kB TensorFlow classifier, or a rule engine that turned out to beat both.

Picking the right kind of AI

A Sphero Mini robot on a floor marked with coloured tape, used as ground truth for computer vision tracking — Computer vision tracking of a Sphero Mini against a marked floor, used to evaluate sensor fusion against ground truth. From the Sphero dead reckoning and CV tracking dataset.

Generative AI is genuinely transformative for open-ended language and image work: drafting, summarising, extracting structure from messy documents, answering questions over a corpus. It is also expensive, hard to make deterministic, and awkward when the answer needs to be defensible.

A large share of real business problems are narrow and repetitive — classify this image, detect this event in a sensor stream, predict this number, decide which of six actions applies. Those are exactly the problems where a small trained model or an explicit rule system wins: it is faster, cheaper, runs offline, does not leak your data to a third party, and produces the same answer twice.

The honest first question is therefore not "which model?" but "does this need a model at all?". Sometimes the answer is a well-designed data model and a query.

What I do

Small, purpose-built models

Compact models trained for one task and deployed where the data already is — in the browser, on a phone, or on an embedded device.

TensorFlow and TensorFlow.js models, including in-browser inference
Classification, regression and anomaly detection on sensor and process data
Quantisation and pruning to fit constrained hardware
Honest evaluation: baselines first, then a model only if it beats them

Computer vision & SLAM

Extracting position, motion and structure from cameras — the backbone of robotics, AR and automated inspection.

Visual SLAM for mapping and self-localisation in unknown spaces
Object and marker detection, tracking and pose estimation
OpenCV pipelines for pre-processing and calibration
Ground-truth capture and dataset construction for evaluation

Sensor fusion & estimation

Classical probabilistic methods that remain the right answer for noisy, real-time signals — and are often mistaken for something more exotic.

Kalman and particle filters for multi-source state estimation
kNN and probabilistic matching for fingerprint-based inference
Dead reckoning and drift correction
Fusing model output with deterministic constraints

Rule engines & symbolic AI

When the domain knowledge already exists in people's heads or in regulation, encoding it beats trying to learn it from scarce data.

Business rule engines (Drools/KIE) for decision automation
Reasoning over knowledge graphs and ontologies
SHACL constraints as machine-checkable business rules
Hybrid setups where a model proposes and rules dispose

LLMs, applied narrowly

Generative models used where they genuinely fit, with the retrieval and guardrails that make output trustworthy rather than merely fluent.

Retrieval-augmented generation over your own documents
Structured extraction from unstructured text into RDF or JSON
Tool-using agents bounded by explicit permissions
Evaluation harnesses, so a prompt change is a measurable change

Data foundations

Most failed AI projects are data projects that were never done. This is usually where the work actually starts.

Dataset design, collection protocols and labelling strategy
Publishing reproducible datasets (FAIR, versioned, documented)
Feature pipelines built on well-described data
Drift monitoring once a model is in production

AI inside OpenHPS

OpenHPS is a working example of this mixed approach. Because every technique is a node in a processing graph, a trained model, a SLAM backend and a hand-written filter can sit side by side in one pipeline, each doing the part it is best at. The modules below are all open source:

It starts with the data

Every one of the techniques above is only as good as what it was trained or tuned on. A large part of my research output is therefore not models but datasets — collected under a documented protocol, with ground truth, and published openly so results can actually be reproduced. That discipline transfers directly to commercial work: before promising an accuracy figure, you need a dataset that can prove it.