AI where deterministic software stops working.
We apply AI where ordinary software reaches a practical limit, and then we select, adapt and integrate the model that clears it, running on infrastructure you own. Most of the work is not the model: it is the contract around it, the data feeding it, and the measurement that says whether it earned its place.
The problem it solves
Deploying a model requires it to fit the data formats you already produce, to interoperate with the components either side of it, and to run strictly inside your own security perimeter. It has to stay dependable through a runtime upgrade or a change of supplier. That is why what we deliver is not the model itself but the interface and the operating contract designed around it, which turn an algorithm into a system component that is reliable and transferable.
What it covers
- Feasibility review: whether a model is warranted at all
- Dataset design, labelling strategy and versioning
- Fine-tuning pretrained models on your domain
- Parameter-efficient adaptation where full training is not warranted
- Retrieval systems over your own documents
- Export, interface contracts and runtime wrappers
- Inference tuning for the hardware you actually have
- Deployment into your existing cluster
- Evaluation sets and accuracy reporting you can re-run
- Monitoring for drift after the model is live
You get
A model integrated as a component of your system, with a written interface, an evaluation set you can re-run yourself, and deployment on infrastructure you already operate.
Most often bought by teams in financial services and the public sector, where the model has to run inside a perimeter somebody audits, and by media and e-commerce operations working at a volume where checking everything by hand stopped being possible.
Book an architecture review →Evidence
The stack is organised by the architectural problem each part solves. We separate the areas with recorded operating metrics from the integration work around them, so the line between measured results and general engineering capability stays visible.
Text and knowledge
Making a model useful on documents and language that are specific to one company: contracts, tickets, policies, the vocabulary of one industry.
- NLPnatural language processing
- Classification, entity extraction and normalisation over your text. The work is teaching a general model your domain vocabulary, not inventing a new one.
- LLMlarge language models
- Open-weight models deployed inside your perimeter, or hosted APIs wired in with spend controls, chosen on the consequences rather than on preference.
- RAGretrieval-augmented generation
- Answers grounded in your own documents, with the source cited. Usually cheaper and more accurate than fine-tuning a model on the same material, because retrieval updates when the document does and can point at what it used. Two things we insist on. Permissions are enforced when the passage is retrieved, not when the answer is shown: a summary of a document you may not open is still a disclosure of it. And retrieval runs on ordinary compute while interactive generation does not, so we size those two separately.
- OCRoptical character recognition
- Invoices, contracts, forms and scans turned into structured fields, normally feeding an extraction step rather than ending at plain text.
Vision and sound
Models that read images, video and audio. This is the group with published figures on this site; the entity-resolution work below is one of its results.
- CVcomputer vision
- Classification, detection, matching and deduplication over images. The broad discipline the classifier below belongs to.
- CNNconvolutional neural networks
- The architecture behind most of it. We fine-tune a pretrained backbone on your data rather than starting from nothing, which is what makes the cost and the accuracy predictable.
- ASRautomatic speech recognition
- Transcription and speaker separation for calls and recordings. A common case for keeping the workload in-house, since recordings often may not leave.
- TTStext to speech
- Speech synthesis where a system has to answer out loud, with the latency budget that implies.
Adaptation and operation
How a model gets shaped to your data, and what keeps it working once it is in production. This is the half of the work that decides whether the first half survives.
- PEFT / LoRAparameter-efficient fine-tuning
- Adapting a large model by training a small fraction of it. It is what makes domain adaptation affordable — and it is still the step we reach for last, after prompting and retrieval have been measured and found short.
- MLOpsmachine learning operations
- The pipeline around the model: data collection and cleaning, versioned datasets, reproducible training, deployment into your cluster, and monitoring for the quality drift that no error log will report.
The model runs on infrastructure you already operate: your cloud account, your own hardware, or both. It sits inside the same perimeter we build for everything else: no listening port on the outside, verified by external scan; secrets held centrally and rotated; eBPF policy deciding what each workload is allowed to reach. Your data and the evaluation set stay where they already are.