Context
Most ML frameworks I’ve encountered were built to be comprehensive. The framework I’m building needed to optimize for something different: getting out of the way.
This is the manifesto behind a private MLOps framework I’ve been building — a distillation of what I’ve learned shipping ML systems, some of which worked, and some of which didn’t. It’s not a decision record. It’s the set of principles every decision record that follows will be judged against.
The problem with comprehensive frameworks
There’s a familiar instinct when you set out to build an ML platform: design for every possible future use case. Wire up a feature store, a model registry, experiment tracking, drift monitoring — all before a single model has gone anywhere near production. It feels responsible. It feels like foresight.
In my experience, it’s usually a trap.
The framework becomes the project. Weeks disappear into abstractions for problems you haven’t actually encountered. Meanwhile the actual ML problem — the one that was supposed to justify all this infrastructure — sits untouched, waiting for the platform to be “ready.” By the time it’s ready, its architecture reflects guesses rather than the problem itself, and the first real use case spends its early life fighting the very framework that was supposed to accelerate it.
This is a trap I’ve fallen into myself. The urge to generalize early rarely comes from the use case in front of you — it comes from the fear of rework, the belief that if you don’t design for everything up front, you’ll pay for it later. What that belief misses is that you pay for premature generalization now, in complexity you didn’t need, and you can still end up paying for rework later anyway, because reality rarely matches the hypothetical you designed around.
What a catalyst actually means
In chemistry, a catalyst speeds up a reaction without becoming part of the product. It lowers the energy required to get from A to B, and then it’s gone — it doesn’t show up in the output, and it doesn’t dictate what the output has to be.
That’s the mental model I want for this framework. Its job is to reduce the friction between identifying a problem and shipping a solution. Reduce the boilerplate, remove the repeated decisions, absorb the operational complexity that has nothing to do with the actual modelling problem. What it should never do is dictate how the problem itself gets framed.
The moment a framework starts insisting that every problem be shaped to fit its abstractions — that every model must go through the same feature pipeline, the same training orchestration, the same serving pattern, regardless of whether the problem calls for it — it’s stopped being a catalyst. It’s become a constraint wearing the language of infrastructure.
This distinction matters because the two failure modes look identical from the outside. A comprehensive framework and a genuinely useful one can both have impressive architecture diagrams. The difference only shows up when a real use case arrives and you find out whether the framework bends toward the problem, or the problem gets bent toward the framework.
A framework should earn every abstraction
One principle has consistently emerged while building this system: abstractions should be the result of repeated experience, not anticipation.
Every abstraction represents a hypothesis about the future. Some survive contact with real-world use cases. Many don’t. When an abstraction is introduced before the underlying problem is fully understood, it often becomes the very constraint it was meant to eliminate.
In this framework, abstractions are expected to justify their existence. They are introduced reluctantly, challenged continuously, and removed when they no longer serve the engineering problem they were created to solve.
Where this leads
The entries that follow become increasingly concrete: where over-engineering creeps in, when a feature store solves the wrong problem, what prebuilt serving containers don’t tell you, and what changes when training moves from a notebook to a distributed system.