How we build

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

Our method fits in four sentences. Start from a model that already knows something about your kind of data. Adapt it to your problem using the data you actually have, rather than the data a paper had. Put a small, fast model on top, so the thing can be retrained over lunch instead of over a quarter. Calibrate all of it, so the system knows - and says - when it is out of its depth.

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 dataset that real labs and real production lines actually 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 it is a spectrum rather than a switch:

• Use it frozen. Run your data through the model and keep the representations it produces. Cheapest by far, needs no GPUs after the first pass, and often enough when your problem is close to what the model was trained on - which is why it is where we start.
• Adapt part of it. Retrain the last blocks, or attach small adapter layers and train only those. A middle path that buys most of the benefit of full fine-tuning on a fraction of the data and compute.
• Fine-tune the whole thing. Warranted when your domain is genuinely 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. The quietly underrated one. 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 is a question about your data volume and how far your domain sits from the model's, not a matter of taste. We answer it 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 is a normal working task rather than a project.
• 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.

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 for the actual prediction. Minutes to retrain, milliseconds to serve, explainable by construction.

4. 4

   Calibrate

   Conformal calibration wraps the prediction in an interval with a guaranteed error rate, checked on held-out data - not a hope.

5. 5

   Deploy and learn

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

Keeping the last stage small changes the economics of everything downstream. Retraining is a lunch break, not a GPU-week, so the active-learning loop actually turns. Serving costs stay flat as usage grows. And when a prediction is challenged - by an auditor, a regulator or your own R&D lead - there is a chain of attributable evidence, not a shrug pointing at 300 million parameters.

End-to-end deep models have their place, and when the problem genuinely needs one - dense prediction, generation, raw-signal problems where no feature layer makes sense - we build and train one. The point is that this is a decision with reasons attached, made after the honest baseline, not a 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 - checked, on your data, as part of delivery. That single property is what turns a model from an oracle into an 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 rather than a feeling.
• Active learning that pays. The model's least certain cases are the ones worth an expert's hour - so 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.

How we measure

Everything above is a set of engineering choices. What makes them checkable is a standard we hold every deliverable to, including the short ones - and it is the ordinary standard of scientific work rather than anything we invented:

• A baseline before a claim. Every result is reported next to a simple, honest reference. A number with nothing to compare it to is not evidence of anything.
• Uncertainty on every number. Intervals rather than point estimates, conformal where it applies, repeated runs where the process is stochastic.
• A methods section. What was run, on which data, how it was split, what was excluded. 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. Especially in security work, where a single successful attack proves much less than a measured success rate over many trials - and where regressions are tracked across retests.

This is the part that does not change between a four-week review and a two-year research project.

The same discipline, everywhere

This page describes tabular-and-features work because that is the most common shape. But the method - honest baselines, measured uncertainty, explanations by construction, deployment that feeds the next version - is how we build everything, including 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