Services
We build document extraction, internal search and forecasting systems where a model is genuinely the right tool: unstructured input, too many rules to maintain by hand, or a ranking problem with no single correct answer. Before proposing a model, we check whether a database index, a form, or a set of rules would do the job for a tenth of the cost and with none of the drift.
This page converts on being straight with you about where the boundary sits. If your problem is deterministic, small and needs to be explainable to a regulator, we will tell you that, and we will still take the work — building the rule-based version properly, rather than wrapping it in a model to sound current.
When you need this
What we build
Our approach
For every candidate use case, we ask whether a lookup table, a set of rules, or an existing database field already answers it. This is not a stalling tactic — it's the fastest way to find the cases where the honest answer is 'you don't need us for this one', and it earns the trust to be believed on the cases where a model genuinely is the right tool.
Where a workflow affects an individual's access to a service, a benefit, or a financial outcome, we design a human decision point into the process rather than letting a model's output stand as the decision. Confidence scores and source citations are part of the interface, not hidden implementation detail.
A labelled test set and a scoring script exist before the first model call is written into the product. This means every subsequent change — a new prompt, a different model version, a retrained classifier — is measured against the same yardstick, and a regression is caught in CI rather than by a customer.
Extraction and classification below an agreed confidence threshold route to a review queue rather than auto-publishing. The threshold is set from the evaluation data, not guessed, and it is revisited as the model and the document mix change over time.
Document formats, customer language and underlying data distributions change. We set up ongoing sampling and periodic re-evaluation against fresh labelled data, so a model that was accurate at launch and has quietly degraded is caught by a dashboard, not by a complaint.
Technology
Modelling and pipelines
Retrieval and storage
Model integration
Evaluation and ops
Applied by industry
Referral letter and clinical correspondence extraction into structured fields for EMIS Web or SystmOne, with a clinician review queue for anything below confidence threshold — no autonomous clinical decisions.
Meter reading and billing exception classification to route disputes to the right team, and demand forecasting evaluated against a seasonal-naive baseline before it replaces the existing spreadsheet model.
Booking and enquiry email triage across sites, and retrieval-augmented search over supplier contracts and operating procedures so staff get a cited answer instead of a call to head office.
Applicant and tenancy document extraction (references, right-to-rent checks) into structured records, with a human sign-off step retained for compliance rather than automated.
Retrieval-augmented search over matter files and precedent documents with citations, and time-entry classification against matter codes with a fee-earner review step for low-confidence entries.
Typical engagement
Questions
We start from the failure mode you can tolerate. If a wrong answer must never reach a customer or a regulator without explanation, we look for a deterministic rule, a lookup table or a database query first, because those are cheap, auditable and always give the same answer to the same input. A model earns its place when the input is unstructured (a scanned invoice, free-text correspondence), the rules would be too numerous to maintain by hand, or the task is genuinely probabilistic, such as ranking search results.
A client wanted a model to route support tickets to teams. The routing logic was, on inspection, fourteen if-statements based on a category field and a customer tier that were already in the database. We built the if-statements, added a database index on the fields being filtered, and the routing runs in single-digit milliseconds with zero training data, zero drift and a rule any support manager can read and change themselves. That took two days, not two months, and there is nothing to retrain when a rule changes.
For classification and extraction, yes, to a working degree: confidence scores, attention over the source document, and evaluation against a labelled test set showing where accuracy drops. For generative outputs (a drafted response, a summary) we do not claim the same certainty, and we say so. Where a decision affects an individual's rights, benefits, or credit — the kind of case Article 22 UK GDPR and FCA guidance both care about — we design a human decision point into the workflow rather than presenting a model output as the decision.
For retrieval-augmented search over your own documents, close to none — the value comes from indexing what you already have, not from training. For classification or extraction fine-tuned to your documents, a few hundred to a few thousand labelled examples is a realistic starting range; below that, a general-purpose model with good prompting and a strict extraction schema usually outperforms a custom model trained on too little data. We tell you which situation you're in before proposing an approach.
A held-out test set the model never sees during development, scored on precision and recall for extraction and classification tasks, or on a rubric scored by a domain reviewer for generative tasks. That evaluation harness runs on every model or prompt change, so a change that improves one case and quietly breaks another is caught before it reaches production, not reported by a user three weeks later.
Send the problem, not a brief. We will tell you whether it is a project we should be involved in.
Talk to us