Services · AI and data
The score is the easy part. The defensible answer is the work.
We build classification and detection systems for places where somebody has to act on the output and then justify the action — to a regulator, to a compliance committee, to a customer whose message was blocked. In those places "the model said so" is not an answer, and a system that cannot do better than that is a liability with a good validation score.
Two of the four cases on this site are built this way: a detection engine for SMS traffic, and a compliance system that compiles financial regulation into executable rules. The method below is what they have in common.
Non-negotiable
Four things we insist on before building anything
- Provenance to the source, not to the training set. An output has to point at the evidence that produced it — the characters of the regulation it came from, the features that moved the score, the messages that formed the campaign. "Explainability" as a dashboard panel is decoration; a trace somebody can follow back to a document is a deliverable.
- A person whose decisions become the next model. Analyst judgements — this is fraud, this is a false positive, this template is legitimate marketing — have to flow back as labelled data. Build this in from the start or the system peaks on its delivery day.
- The data stays inside your perimeter. Content, model state and decision log on your side; a defined set of aggregates out. In regulated industries this is a precondition rather than a preference.
- An anomaly is not a confirmed anything. That sentence belongs in the product's own language, not in a disclaimer underneath it. A system that calls a deviation "fraud" teaches its users to stop reading, and the day it matters they will not read.
The shape of the system
A loop, inside your perimeter
Every system of this kind we have built has the same four stations and the same boundary around them. The fourth station is the one projects skip, and skipping it is why so many detection systems are quietly switched off in their second year.
The question everyone asks second
Where a language model belongs, and where it does not
Language models are extraordinarily good at reading text that was written for humans and turning it into something structured. That is a real capability and we use it. They are not a substrate for a decision that has to be reconstructed later, and treating them as one is the most common expensive mistake in this category right now.
In the compliance system on this site, the division is explicit. A language model helps convert legal text — in its own national language, not translated into English first — into a typed representation that keeps character-level spans back to the source. The reasoning that actually produces an alert runs on a solver, using sCASP and Event Calculus, so every alert carries a justification tree that points at the exact words of the norm it came from.
Building the reasoning layer out of a language model would have been faster and would have demonstrated better. It would also have produced a system that cannot answer the only question that matters in a regulatory conversation: which rule, and where does it say that.
One measured number
Published with the method, because otherwise it is decoration
Most of the numbers that would flatter us belong to our clients and are covered by their agreements. This one is ours, from our own bench, and it is here with enough method attached that you could disagree with it.
Measuring a Bayesian online change-point posterior update over a batch of 10,000 rows — the component that models what normal behaviour looks like for a given sender, and the probability that current behaviour has departed from it:
- R64: CPU median 16.7281 ms against GPU 3.8999 ms — a factor of 4.29.
- R256: CPU median 68.0209 ms against GPU 16.4431 ms — a factor of 4.14.
- Conditions: Apple M5, PyTorch 2.14, float32, single-threaded CPU, GPU synchronised, measured 15 September 2026.
What that number is not
It excludes protocol decoding, tail-risk scoring, campaign correlation and any action taken on a network. It is a local numerical test on a laptop-class machine, not an NVIDIA rig and not an end-to-end throughput figure, and it cannot be compared with the transactions-per-second claims of inline firewall vendors.
Which is the point of publishing it this way. A speed-up factor with no method underneath it is a marketing asset; the same factor with its boundaries written down is evidence.
Where we have done this
Two systems, with their real status attached
Regulation compiled into executable rules
For an international financial holding operating in more than twenty countries: national-language regulation converted into a typed ontology with character-level spans, then into rules a solver can run against a transaction flow, producing alerts with justification trees. Status: in implementation — the compilation pipeline, the rule environment and both interfaces work; jurisdictional coverage is in progress. Read the case
Detection on SMS traffic
Content classification, language detection, text normalisation that survives deliberate obfuscation, campaign linking, an analytical API, and the labelling pipeline that turns analyst decisions into the next model. The Bayesian sender-profile work above is research on top of it and is marked as such rather than sold as delivered. Read the case
Adjacent questions
Four cases where we are the wrong supplier
You want a chatbot over your documents
A retrieval assistant on an internal corpus is a reasonable thing to want and a well-served market. It is not what this page describes, and the suppliers who do it all day will do it better and cheaper than we would.
There is no labelled history and nobody to label
Then the first project is not a model. It is instrumenting the decision so that six months from now there is something to learn from. We will say so, and it is a cheaper disappointment in month one than in month nine.
The number needs to go up and the reason does not matter
Sometimes that is a perfectly rational commercial position — a recommendation engine, an ad ranker. Our whole method is overhead in that world, and you should buy from somebody whose method is not.
It has to run in a vendor's cloud
If your content must leave your perimeter for the system to work, we are not the supplier — not because we cannot build it, but because we would spend the project arguing against the architecture we were hired to build.
Questions
The ones that decide whether this is worth starting
Do you need our data before you can say anything useful?
We need to look at it, not to take it. The first conversation is about what decision the model is supposed to support, who makes that decision today and what they look at while making it. That conversation is usually more informative than the dataset, because it reveals whether the thing you want predicted is actually recorded anywhere. A surprising number of projects end there, and end cheaply.
Can the system run entirely inside our infrastructure?
Yes, and in regulated environments it is the only architecture we propose. Message content, model state and the decision log stay inside your perimeter; what leaves is an agreed set of aggregates — installation identifier, version, health, volume for billing. This is not a feature, it is a condition of being deployable: an architecture that ships content to a vendor cloud does not pass the first data-protection questionnaire in most procurement processes.
What accuracy can you promise?
None, before we have seen your data, and we would be suspicious of anyone who does. What we will commit to is a measurement protocol agreed in advance: which metric, on which held-out data, against which baseline — including the baseline of what your people achieve today. A model that beats nothing in particular is a number, not a result.
Do you use large language models?
Where they are the right instrument, which is reading and structuring natural-language text — and not as the thing that produces a decision somebody has to defend. In the compliance system on this page an LLM helps turn legal text in its own language into a structured representation, and the reasoning that produces an alert runs on a solver, so the output can be traced back to the exact characters of the source. Using a language model as the reasoning layer would have been faster to build and impossible to audit.
Who owns the models?
You do, along with the training pipeline, the labelled data and the evaluation harness. Models trained on your data are yours, they stay in your repository, and the pipeline that produced them is documented well enough for another team to retrain without us. The handover standard here is the same as for any other build we do.
What happens after delivery, when the data shifts?
It is designed for, not discovered. A system like this is at its best on the day it ships and worse every month afterwards unless analyst decisions keep flowing back into it as labelled data. That loop is part of the build rather than a later phase — without it you have bought a snapshot of last year's fraud, or last year's regulation.
Next step
Describe the decision, not the dataset
Who makes the call today, what they look at while making it, and what happens when they get it wrong. Those three answers decide whether a model helps here at all.
Start with the decision
A reply from someone who will tell you if the thing you want predicted is not recorded anywhere — which is the usual finding.
EvidenceRead the two cases
Both systems, with what was delivered, what is still in implementation, and the figures we are not allowed to publish.