AI Lab

The methods behind the systems we ship

Applied research in perception, sequence modelling, language, audio and on-device optimisation, done to put a model on a customer's hardware and keep it honest there, not to publish a chart. This page is the glossary of what we actually build with.

Bring us a problem Browse the disciplines

RuntimeC++ · CUDA · TensorRT · ONNX Runtime
TargetsJetson-class edge · workstation · air-cooled rack
DisciplineHeld-out eval before every promotion
OwnershipWeights, code and evals stay with the customer

FLAGSHIP PROGRAMME

On-premise industrial AI, from silicon to answer

The lab's lead programme is a privacy-first diagnostics stack that runs entirely inside the customer's building: local models, verified training worlds, deterministic control and an edge acceleration line, developed measurement-first.

Deterministic runtime control

Research into what deterministic control can and cannot do for small AI agents: bounded steps, closed vocabularies where honest abstention is a correct answer, and claims that need witnesses.

Local-model inference stack

Open-weight models, quantized and served on commodity hardware, fine-tuned for industrial root-cause analysis so the plant's telemetry never leaves the plant.

Training worlds with verified ground truth

A data engine that turns real fault-labelled wind and solar telemetry archives and physics-grounded synthetic plants into training and evaluation worlds whose answers are checkable.

Edge acceleration programme

An edge co-processor line for high-throughput vector retrieval and real-time drift and anomaly monitoring, designed to sit beside a standard industrial PC.

Every capability claim passes a pre-registered evaluation with frozen gates before it ships, and the streaming-monitoring mathematics has been validated against real quantum-hardware measurement data. A research paper on the control work is in preparation: the results will be published openly as a preprint and submitted for peer review, negative findings included.

The diagnostics stack in the portfolio

Six disciplines, one bench

Each section below is a working vocabulary: the methods we reach for, what they are for, and where they are running today. Nothing here is a claim about accuracy. Every number lives in the customer's evaluation suite, not on a marketing page.

01Depth, geometry and what a camera can be trusted to knowComputer vision & 3D perception
02Time series, recurrence and the models that replaced the ones we grew up onSequence models & forecasting
03Language models put to work on documents that never leave the buildingNatural language & retrieval
04Speech and sound as signals first, then as languageAudio & signal processing
05Multi-object tracking where the frame budget is the specificationReal-time tracking in C++
06Making a model fit the box it has to live inEdge AI & embedded deployment

Computer vision & 3D perception

Depth, geometry and what a camera can be trusted to know

The work is turning pixels into metric structure, from a single lens or a calibrated rig, and then deciding how much of that structure to believe.

Monocular metric depth: Dense per-pixel depth from one camera, fine-tuned on scene-specific captures and scale-anchored against known geometry so the output is in metres rather than in relative units.
Stereo & multi-view geometry: Rectification, semi-global matching and learned cost-volume stereo for calibrated rigs; bundle adjustment and structure-from-motion when the rig is a moving camera.
Point-cloud processing: Voxel downsampling, ground-plane fitting with RANSAC, Euclidean clustering and sparse-convolution backbones for LiDAR and depth-sensor returns, including ground-truthing against simulated scenes.
Bird's-eye-view fusion: Lifting camera features into a top-down grid and fusing them with range sensors, so occupancy, free space and lane-level structure all come from one representation.
Uncertainty & calibration: Per-pixel confidence heads, temperature scaling and conformal thresholds, so a downstream rule can refuse to act on depth the model itself does not trust.

Sequence models & forecasting

Time series, recurrence and the models that replaced the ones we grew up on

Sensor streams, sales histories and event logs are sequences first. We choose the architecture by the shape of the data and the budget of the device, not by what is fashionable.

xLSTM (sLSTM / mLSTM): Extended LSTM cells with exponential gating and a matrix memory: recurrent models that recover the long-context performance of transformers at linear cost, which matters when the model has to run for months on an edge box.
State-space models: Selective state-space layers (the Mamba family) for very long sensor sequences where attention's quadratic memory is the constraint and a fixed-latency recurrent scan is the requirement.
Temporal convolution: Dilated causal convolutions with residual blocks for high-rate signals, a stable, interpretable baseline that we keep in every bake-off so a fancier model has to beat it.
Probabilistic forecasting: Quantile heads, conformal prediction intervals and skill scores against seasonal-naive baselines, so a forecast ships with the width of its own uncertainty and a reason to trust it over last week.
Anomaly detection on streams: Reconstruction-error and density models over windows of telemetry, with event-clustered evaluation so one long fault is counted once and false alarms are reported per machine-month.

Natural language & retrieval

Language models put to work on documents that never leave the building

The interesting problems are not the model but everything around it: retrieval that cites, generation that is bounded, and evaluation that catches drift before a user does.

Retrieval-augmented generation: Hybrid dense-plus-sparse retrieval (embedding similarity and BM25) with a cross-encoder reranker, chunked so every answer carries the passage it came from and a citation the reader can open.
Embeddings & vector indexes: Fine-tuned embedding models for a customer's own vocabulary, indexed with HNSW or IVF-PQ on local hardware, with recall measured against a labelled query set.
Structured extraction: Constrained decoding against typed schemas: contracts, invoices and forms become validated records, and the model's abstentions are counted as a feature.
Bounded agent harnesses: Tool-using agents with an allow-list of actions, a budget, a trace of every call and a human approval gate before anything consequential. The harness is the product, the model is a component.
Evaluation & drift: Golden question sets, faithfulness and citation-precision scoring, and regression gates that run on every model or index change, so a quiet degradation shows up as a failed check.

Audio & signal processing

Speech and sound as signals first, then as language

Voice on a phone line and vibration on a bearing are the same discipline: front-end signal processing that decides what the model gets to see.

Streaming speech recognition: Chunked, low-latency transcription with voice-activity detection and end-pointing tuned for telephone bandwidth. It runs on local hardware, so audio never crosses the network boundary.
Speaker & event detection: Diarisation for who-said-what, plus acoustic event classification (a dropped tray, an alarm, a machine changing pitch) from log-mel and constant-Q representations.
Order tracking & spectral features: Resampling vibration to the shaft's rotation so bearing and gear signatures land at fixed orders; envelope spectra and kurtograms for the faults a plain FFT hides.
Self-supervised audio pre-training: Contrastive and masked-prediction pre-training on unlabelled recordings from the customer's own site, so the downstream classifier learns from hours of context rather than a handful of labels.
Text-to-speech & dialogue latency: Streamed synthesis with sub-second turn-taking, measured end to end from the caller's last word to the first audible reply, on the same hardware that hosts the call.

Real-time tracking in C++

Multi-object tracking where the frame budget is the specification

Detection is the easy half. Keeping identities across occlusion, across cameras and across a night of footage, inside a fixed millisecond budget, is where the engineering lives.

Tracking-by-detection: Kalman-filtered motion models with Hungarian assignment on IoU and appearance cost, ByteTrack-style low-score recovery, and track lifecycle rules tuned per camera rather than globally.
Re-identification & appearance embeddings: Compact embedding networks for matching the same object across gaps and cameras, with an explicit policy for when a match is not confident enough to merge.
Sensor fusion: Camera, LiDAR and radar fused at the track level with a shared state and time alignment, so a target lost by one sensor is carried by another instead of being re-born.
Zero-copy pipelines: GStreamer and DeepStream graphs with GPU-resident frames from decode to inference to overlay, with no host round-trips and per-stream latency accounted for in the design.
Deterministic C++ runtimes: Pre-allocated buffers, lock-free queues and pinned memory; profiled with Nsight and sanitised builds, because a tracker that stalls once an hour is not a tracker.

Edge AI & embedded deployment

Making a model fit the box it has to live in

A model is not finished when it trains; it is finished when it runs within the thermal, memory and latency envelope of the device, unattended, for years.

Jetson-class deployment: TensorRT engines built per device and per precision, DLA offload where it pays, and power-mode and clock profiles chosen against a measured thermal budget.
Hardware-aware architecture search: Choosing backbones and input resolutions by measured latency on the target, not FLOPs on paper, with a latency lookup table built from the actual silicon.
Sealed appliances: Read-only root filesystems, signed images, watchdogs and offline-capable operation, so the customer owns a device that keeps working when the network does not.
Field telemetry & drift monitors: Input-distribution and confidence histograms shipped as summaries, never as raw frames, so we can see a camera drift out of calibration without seeing the camera.
Secure updates: Staged rollouts with A/B partitions and automatic rollback on a failed health check. A model update is a deployment, and it gets the discipline of one.

The optimisation bench

Every model we ship crosses the same five stations. The order matters: nothing is quantised before it is profiled, and nothing is promoted before a held-out evaluation says the compressed model still does the job.

Profile

Layer-level latency and memory on the actual target, under the actual input distribution, with the thermal state logged alongside.

Nsight
per-layer latency
thermal envelope

Prune & distil

Structured pruning of channels and heads, then knowledge distillation from the full model into the smaller one, so capacity is removed where the profile says it is idle.

structured pruning
distillation
LoRA merge

Quantise

Post-training quantisation with representative calibration data first; quantisation-aware training only where INT8 or FP8 costs accuracy the evaluation will not forgive.

INT8 / FP8
PTQ → QAT
calibration sets

Compile

Graph fusion, operator selection and engine build per device and precision: ONNX to TensorRT, or a compiled runtime where the target has no GPU at all.

TensorRT
ONNX Runtime
kernel fusion

Verify

The compressed model re-runs the full held-out evaluation, event-clustered and base-rate-adjusted; a regression anywhere sends it back a station.

held-out eval
regression gate
signed artefact

We publish methods. The numbers live in your evaluation suite, on your hardware, where you can rerun them.

How the lab works

Baselines before novelty

Every experiment includes the boring baseline: seasonal-naive, a linear model, last year's architecture. A new method ships only when it beats the baseline on held-out data across seeds, reported as a mean with its spread.

Pre-registered evaluation

Thresholds, metrics and the definition of a pass are written down before the run. A result that needs the rules changed afterwards is a finding about the rules, not a success.

Synthetic where reality is expensive

Simulated scenes, rendered sensors and generated edge cases fill the gaps real data cannot, and every synthetic result is confirmed against a real capture before it counts.

Customer-owned artefacts

Weights, training code, evaluation harnesses and traces are delivered into the customer's repositories and hardware. We keep the method; you keep everything it produced.

Questions the lab gets asked

Do you publish papers or benchmarks?

We publish methods and the occasional write-up when a customer agrees. We do not publish accuracy numbers on this site: they depend on data we do not own, and a number without its evaluation protocol is marketing.

Can you work with our existing models and data?

Usually yes. The first step is an evaluation harness around what you already have (a baseline we can both trust) and only then a proposal for what to change.

What hardware do you target?

Whatever the system has to live on: Jetson-class edge devices, workstation GPUs, air-cooled racks and, where there is no GPU, compiled CPU runtimes. The optimisation bench exists so the same model can be made to fit each of them honestly.

Last reviewed: August 29, 2026

Dark hollow metal cylinders forming an abstract pattern

Bring the lab a problem

Describe the signal, the device and the decision it has to support. We will tell you which of these methods apply, what a baseline would look like, and what we would want to measure first.

Talk to the lab