The model is the small part

#The proportion

The observation that machine learning code is a small fraction of a real system is nearly a decade old and still describes what I see [1]. Around it sit configuration, data collection, feature extraction, verification, serving infrastructure, resource management, monitoring and process tooling.

Projects that plan for the model and improvise the rest end up with the improvised parts as the operational burden.

#The debt that is specific to machine learning

Ordinary software debt is bad code you can read. Machine learning debt is often invisible in the code.

Entanglement. Changing anything changes everything. Add a feature and every existing weight shifts, so there is no local change and no small review.

Undeclared consumers. A model's output is read by systems its authors do not know about. Changing the output distribution breaks something nobody connected to you.

Data dependencies. These have no compiler. An upstream table changes shape and the model degrades quietly, with no build failure and no exception.

Correction cascades. A model that corrects another model's output creates a dependency that cannot be untangled later.

#Validate data as strictly as code

Data lifecycle challenges dominate practical effort [3]. The practices that pay for themselves are unexciting: a schema for every input with types and ranges, distribution checks against a reference window, and failing the pipeline on violation rather than logging a warning.

That last one is the difference between catching a problem at ingestion and discovering it in production metrics three weeks later. Production platforms built around this idea make validation a pipeline stage rather than a script [4].

#Serving is where the correctness bugs live

Training and serving compute features in different places, and any difference between them is a bug that no test catches. A feature computed over a full history at training time and over a recent window at serving time is a different feature.

The reliable fix is one implementation used by both. Anything else relies on two implementations staying in agreement, which they will not.

#Monitoring the input, not only the output

Output quality metrics are lagging indicators, because they require ground truth that arrives late or never. Input distribution is a leading indicator and is available immediately.

Drift is guaranteed rather than possible, since the world the model describes keeps changing [5]. Monitoring for it is a standing requirement rather than a project phase.

#The organisational finding

The case study work on software engineering for machine learning identifies data management, model customisation and reuse, and the difficulty of modularising machine learning components as the recurring pain points across teams [2]. Those are process problems as much as technical ones, and a readiness rubric is a practical way to make them visible before deployment [6].