How we build

Most AI consultancies will tell you what they build. This page is about how, because that is where projects succeed or die, usually months after the demo, when the model meets data nobody curated and questions nobody benchmarked.

Not everything we do is a model. A security audit, an LLM application or a readiness assessment each has its own shape, and pretending otherwise would be the kind of overclaim this page exists to avoid. What stays the same across all of them is how we measure, so that is where this starts.

How we measure

These hold for every deliverable, whatever kind of work it is and however short, from a four-week review to a two-year research project. They are the ordinary standard of scientific work, and none of them is our invention:

• A baseline before a claim. Every result is reported next to a simple reference point. A number with nothing to compare it to is not evidence of anything.
• Uncertainty on every number. We report intervals instead of point estimates, using conformal prediction where it applies and repeated runs where the process is stochastic.
• A methods section. Each report states what was run, on which data, how it was split and what was excluded. It is written so that someone who disagrees with us can find the place where they do.
• Reproducible by you. The harness, the probe suite or the notebook comes with the report. If the conclusion cannot be re-run after we leave, it has a short shelf life.
• Rates, not anecdotes. This matters most in security work, where a single successful attack proves much less than a success rate measured over many trials, and where regressions are tracked across retests.

That is the part that never changes. What follows is how it plays out in the most common kind of project we do.

When the work is a predictive model

Most of our modelling projects end up with the same shape, and it is worth describing because every step is a choice that could have gone another way. Treat it as our default. We start here and move off it when the data says to.

1. 1

   Foundation model

   Start from a model (vision, atomistic, language or signal) that has already learned the structure of data like yours.

2. 2

   Domain adaptation

   Frozen features, adapters, fine-tuning or self-supervised pretraining on your unlabelled data, chosen by how far your domain sits from the model's.

3. 3

   Fast model

   A small model makes the prediction itself. It retrains in minutes, serves in milliseconds and is explainable by construction.

4. 4

   Calibrate

   Conformal calibration wraps the prediction in an interval with a guaranteed error rate, which we check on held-out data.

5. 5

   Deploy and learn

   The model ships with drift monitoring, and its least certain cases go to your experts first, so every answer they give makes the next version better.

Start from a model that already knows the domain

The expensive insight of the deep learning era is not that big models predict well. It is that they represent well: a network trained on millions of micrographs, molecules or documents has learned what matters in that domain, and that knowledge transfers, even to the modest, precious datasets that real labs and production lines have.

So almost nothing we build starts from random weights. It starts from a model that has already seen a great deal of something like your data.

Domain adaptation: making it yours

A foundation model knows a great deal about the world in general and nothing about your particular furnace, assay or inspection line. Closing that gap is where most of the real work sits, and the options form a spectrum:

• Use it frozen. Run your data through the model and keep the representations it produces. This is by far the cheapest option. It needs no GPUs after the first pass and is often enough when your problem is close to what the model was trained on, which is why we start here.
• Adapt part of it. Retrain the last blocks, or attach small adapter layers and train only those. This middle path buys most of the benefit of full fine-tuning on a fraction of the data and compute.
• Fine-tune the whole thing. This is warranted when your domain is far from anything in the pretraining set and you have the labels to support it. Scientific imaging often is that far: a model raised on photographs has no idea what a grain boundary or a stained section is.
• Continue pretraining on your unlabelled data. This one is often underrated. Most labs sit on far more unlabelled data than labelled, and self-supervised training on it teaches the model your domain before a single label is spent.

Which of these a project needs depends on your data volume and on how far your domain sits from the model's. We answer that question by trying the cheap end first and measuring, so the expensive option has to earn the move.

A fast model on top

Whatever comes out of adaptation, the thing that makes the final prediction is deliberately small. On tabular and feature-based problems that is usually gradient-boosted trees, sometimes a linear model, sometimes a light head on the adapted network. The library matters much less than the three properties we insist on:

• Minutes to retrain, so improving the model becomes a routine task.
• Cheap to serve, so cost does not scale alarmingly with use.
• Explainable by construction, with attributions in terms of features that mean something in your domain.

Keeping the last stage small changes the economics of everything downstream. Retraining takes about as long as a lunch break, so the active-learning loop keeps turning, and serving costs stay flat as usage grows. When an auditor, a regulator or your own R&D lead challenges a prediction, there is a chain of attributable evidence to show them, where a large end-to-end model would leave you pointing at 300 million parameters.

End-to-end deep models have their place, and when a problem needs one (dense prediction, generation, or raw signals where no feature layer makes sense) we build and train one. What matters is that the choice is made for stated reasons, after the honest baseline has been run, and is never the default.

Uncertainty is not optional

A prediction without an error bar is a guess with good typography. In science that has always been obvious; in industry it becomes obvious the first time a confident model is wrong about something expensive.

Calibration is what makes uncertainty usable. When the system says 90%, it is right nine times out of ten, and we check this on your data as part of delivery. That single property is what lets a model be used as a measuring instrument:

• Automation thresholds you can defend. Auto-accept the certain cases, route the uncertain ones to a person, and set the boundary from a measured error rate.
• Active learning that pays. The model's least certain cases are the ones worth an expert's hour, so the labelling budget goes where it moves the model most.
• Failure that announces itself. Drift shows up as widening intervals and falling confidence long before someone downstream notices the numbers went strange.

The same discipline, everywhere

Most of this page describes tabular and feature-based work because that is the most common shape. The method itself is how we build everything: fair baselines, measured uncertainty, explanations by construction, and deployment that feeds the next version. That includes LLM applications and agents, where "measure the failure rate before you ship" turns out to be a security practice as much as an engineering one.

Where to go next