The Discipline of Action in Machine Learning Model Management

Forty-seven machine learning models were rotting in production when the analytics team finally looked honestly at what they had built.

Not growing. Not serving. Rotting. Each one had once represented a decision someone was unwilling to make — a boundary someone was unwilling to hold. And so instead of a decision, they built another model.

This is not a story about technical debt. It is a story about what happens when people in motion confuse movement with action.

The Weight of Accumulated Complexity

Eighty-seven percent of data science projects never reach production. The ones that do often drag behind them everything that should have been cut before deployment — models built for stakeholders who no longer work there, variants spawned from quarterly panics, algorithms that answered questions nobody is asking anymore.

The team's 47 models had arrived this way: one business question at a time, one seasonal adjustment at a time, one politely-worded request at a time. Each felt necessary in the moment. Together, they formed a system that consumed its own maintenance and produced increasingly stale predictions.

There is a passage from the Meditations — Book IV, 3 — where Aurelius reminds himself to examine what is actually before him, stripped of the story he has added to it. The team had added many stories. This model is still useful. We might need that variant again. The stakeholder who requested this will notice if we remove it. None of these stories held under examination. The model sprawl existed not because 47 models were needed, but because the discipline of saying no had been deferred, repeatedly, until the cost of saying yes had become invisible.

The average gap between recognising a problem and taking meaningful action in data organisations stretches to 14 months. This team knew. They had known for two quarters. They had discussed it in retrospectives, flagged it in planning meetings, noted it in documentation. Knowing is not the act. Naming is not the act. The act is the act.

What Marcus Aurelius Sees in This

Book III, 11 of the Meditations contains one of the harder instructions Aurelius gave himself: "Do not indulge in fancy, but do what needs doing." Not "consider what needs doing." Not "schedule time to discuss what needs doing." Do it.

The Stoic distinction at work here is the dichotomy of control — but most people apply it incorrectly, and that misapplication is exactly what produced 47 models instead of 3.

The dichotomy of control, properly understood, does not mean "focus on your attitude and release the rest." That is the self-soothing version, useful for frustration, ruinous for leadership. What it actually means is this: identify what lies within your power to act on, and then act on it fully, without reserve, without delay. The second half is not optional. It is the entire weight of the principle.

This reveals the harder truth: most model sprawl is not a technical problem. It is a governance problem that technical complexity has been used to avoid. Every time a team builds a new model instead of improving an existing one, refusing a marginal request, or retiring something that stopped earning its place — they are exercising the part of the dichotomy that releases control, while telling themselves they are being productive. They are busy. They are not acting.

The Stoic examination — what Aurelius called the hegemonikon, the ruling faculty, the capacity to judge clearly — asks a simple question of any action: does this serve a clear purpose, or does it serve my discomfort with a difficult conversation? Building the 41st customer segmentation variant nearly always serves the second.

This means that for someone in your position today — managing a model registry, inheriting a production environment, facing a quarterly review of infrastructure costs — the work is not primarily technical. It is the examined life applied to engineering decisions. What is this model actually doing? Who would notice if it disappeared? What decision are we avoiding by keeping it?

What most people miss here is that simplification feels like loss. It presents itself as risk. Removing a model someone requested, even a model nobody uses, triggers the same avoidance response as any confrontation. The Stoic commander — and Aurelius was, above all, a commander who had to make irreversible decisions about scarce resources — knew that this feeling is not a signal to stop. It is confirmation that the decision is real.

Flourishing, in Stoic terms, is not comfort. It is function. A system of three models that predict accurately, are understood completely, and are maintained with attention — that system is flourishing. Forty-seven models in various states of neglect is the opposite, regardless of how it reads in a capabilities deck.

Three Models, Clearer Purpose

The team's reduction was not elegant at first. It was uncomfortable in exactly the ways that mattered.

They categorised all 47 models by three criteria: actual business impact in the last two quarters, usage frequency measured by API calls rather than stakeholder claims, and predictive performance against a held-out baseline. Most models failed on two of three. Several failed on all three. One model that a senior director had personally championed had been called zero times in four months.

The consolidation left three models standing: customer lifecycle prediction, demand forecasting, and risk assessment. Each served a distinct, named decision. Each had an owner who could explain, without slides, what question the model answered and what would break if it were wrong.

Maintenance load fell. Monitoring became legible. The team's attention — which had been scattered across a maintenance surface too wide to hold clearly in mind — concentrated. Within one quarter, prediction accuracy on the core models improved by 23%. Not because they had better data. Because they had better attention.

If your team is managing data infrastructure costs under scrutiny, the Stop Paying for Data Infrastructure Your Analysts Never Actually Use course examines exactly this kind of consolidation decision with the rigour it deserves.

For the governance structures that make these decisions repeatable rather than heroic, the Build Your First Data Governance Framework prompt is a direct starting point.

What to Do This Week

Before you close this tab, open your model registry — or whatever you call the document or dashboard where production models are listed — and count them.

Then do this, without deferring it to a planning session:

Day one. List every model. Next to each, write one sentence describing the decision it supports. If you cannot write the sentence without opening a document to find out, that is your first answer.

Day two. Pull actual usage data for the last 90 days. Not stakeholder attestations. Logs. API calls. Query counts. Mark every model with fewer than ten meaningful calls in that window.

Day three. Bring the list to your team lead or your own honest judgment and ask: if we retired the bottom half of this list this quarter, what would actually break? Name specific downstream decisions, not general categories of risk.

Day four. Draft the retirement proposal. Not the "we should discuss retiring" email. The actual proposal, with dates.

Day five. Send it.

The discipline of action in the Stoic sense is not a mindset. It is a sequence of irreversible steps. Each step is small. The irreversibility is what makes it action rather than intention.

If your organisation is making decisions about BI infrastructure alongside model management, the BI Tool Categories Overview: Decision Framework for Leaders offers a structured way to align those choices.

And if your inner life as a technical leader involves carrying the weight of decisions your executives do not yet understand, Turn Raw Data Into Decisions Your Leadership Team Actually Trusts addresses the translation problem directly.

Explore Further

• Stop Paying for Data Infrastructure Your Analysts Never Actually Use — A direct course for teams facing the consolidation decision, with frameworks for what to cut and how to justify it.
• Scalable Enterprise Data Workflows with AI | Reduce Processing Time by 70% — If simplification reveals workflow gaps, this concept covers rebuilding with more durable architecture.
• Build Your First Data Governance Framework — The governance layer that makes model discipline sustainable rather than dependent on individual courage.
• Cut Your Cloud Analytics Bill Without Killing Your Data Science Team — For leaders whose model consolidation exists inside a larger infrastructure cost conversation.

Aurelius wrote the Meditations for himself. Not for publication. Not for an audience. They were instructions from a man who commanded an empire to the part of himself most likely to avoid what was necessary.

You do not need 47 models. You need the decision that 47 models were built to defer.

Make it this week.