Putting a model into a system that already runs.
A model, whether your own, a third party's, or one reached over an external API, has to go into production in a way that outlasts a runtime upgrade, a change of hardware and a change of the team maintaining it. The work here is fixing the interface, not modelling.
The problem it solves
A model running in the environment it was trained in is not yet a component. The surrounding code is usually tied to implicit details: the framework that produced the weights, the shape and dtype the input happens to have, the library versions that round a particular way. None of those dependencies is recorded anywhere, so replacing the model means rewriting the code around it. A separate problem is preprocessing at inference diverging from preprocessing at training: it raises no error and biases every prediction. The fix is to define the model as a component with an explicit interface, and to cover that interface with tests.
What it covers
- Review of the system the model has to live in
- Export to a runtime-independent format
- A written contract for input, output and preprocessing
- A runtime wrapper with minimal dependencies
- Reference input–output pairs recorded at build time
- An install check your team runs in one command
- Tests for the failures that stay silent
- Batch size and thread limits tuned to your hardware
- A documented path back to the previous version
You get
A model that can be replaced without touching the surrounding code, and a set of checks that confirm it works on your own hardware without us present.
Typically SaaS and e-commerce teams with a model already in hand that has to survive the next runtime upgrade, and buyers in regulated sectors who need the interface fixed in writing before anything reaches production.
Book an architecture review →