The demo lands. The room applauds. The model does exactly what it was built to do, maybe a little more. The team takes a bow, the slides go back into the deck, and everyone rolls off to the next thing.
You were in that room. You championed the project, you approved the go-live, and then you moved on to the next budget cycle like everyone else.
The applause is the problem, because everyone in the room reads it as the end.
When you designed this team and this delivery, what did “done” mean? If the answer was “shipped,” you built a project, not a capability.
That distinction is structural, not semantic. Projects have endpoints. A capability needs someone to own its performance after the builders leave. Most AI deployments are structured as the first while being expected to behave like the second, and the gap between the two is not a technology problem. It is an organizational design problem, and it accumulates where no one is looking.
The day-ninety problem
Permalink to “The day-ninety problem”On day one the model is pristine. By day 90 the world it was trained on has moved on without it. Customers behave differently, new product categories have appeared, supplier catalogs have changed. The model has not.
Performance drifts slowly, without ever tripping an alert. A few percentage points here, a few there. The system still runs, decisions still run on its output, and no one is watching closely enough to know whether those decisions are still any good.
A Harvard and MIT study of 32 datasets across four industries found that 91% of machine learning models degrade over time. Degradation itself is not the surprise. The surprise is how long it runs unnoticed, because it rarely announces itself and usually surfaces only when a business metric moves, weeks or months later. By day 90, in most organizations, no one is accountable for catching it, because no one was ever put in charge of catching it.
The drift has a source. The model ran exactly as built. What moved underneath it was the context: the supplier profiles, the customer patterns, what its inputs meant at training time. So the ownership gap is really two gaps. No one owned the model after launch, and no one owned the context it depended on either.
That accountability gap was designed in at the go-live celebration. Not on purpose. But the choice to treat deployment as a handoff rather than a transfer of ongoing ownership is a leadership choice, even when it is made by default.
Ownership Gap | Source: Context & Chaos
The three patterns, and the decision behind each
Permalink to “The three patterns, and the decision behind each”Organizations eventually notice the problem, and when they do, three patterns tend to emerge. What is worth examining is not just how each one looks, but which leadership decision produced it.
Ownership models | Source: Context & Chaos
Default inheritance by the platform team. The team that hosts the infrastructure inherits the model because someone has to keep it running. They keep the servers up and the endpoint responding. But platform teams are built for infrastructure, not business logic, so they can tell you the API is alive and not whether the predictions still hold in the business context. This is what you get when go-live planning includes no explicit owner for the deployed system. The platform team fills a vacuum nobody decided to leave, and accountability ends up sitting apart from the capability to act on it.
Residual ownership by the build team. The data science team that built the model stays nominally on call, but in practice they tend it while building the next one. It gets attention only when something breaks, and degradation rarely breaks anything loud enough to notice. This is what you get when data science is structured as project delivery: the moment the incentive is to ship the next model, the last one becomes maintenance debt. That is a decision about what the team is rewarded for, and it is yours to make or to leave unmade.
Business ownership on paper. A business leader is named as owner in a governance document, defines the outcome, and is accountable for it. On paper this is clean. In practice that owner can see the business result, or its absence, but cannot diagnose why or intervene. The governance document creates nominal ownership without creating the conditions for the real thing, because it separates accountability from capability at the moment of design.
Each of these is rational. Each holds a piece of the answer. And each falls short for the same reason: it treats ownership as something that accretes by default rather than something a leader designs on purpose.
The structural problem
Permalink to “The structural problem”So the real decision, the one that is easy to keep deferring, is this: do you keep organizing data science as project delivery, or do you redesign it around production ownership?
Those are genuinely different operating models. They hire against different criteria, they define “done” differently on a performance review, and they reward different things. In the project delivery model, a data scientist’s success is measured at deployment. In the production ownership model, it is measured by how the live system performs six months after the builder has moved on.
Think about what that changes. You stop rewarding shipped features for their own sake and start tracking live performance drift, decision accuracy over time, and the gap between expected and actual business outcomes. The job changes less in title than in contract: the person who built the model owns how it behaves in production. The experimental work is still part of the job. It is no longer the whole of it.
That is not a small adjustment. It is an organizational redesign, and if you do not make it deliberately, it defaults to one of the three patterns above, none of which survives past day 90.
The Day 90 Curve after Go Live | Source: Context & Chaos
What it costs to leave the call unmade
Permalink to “What it costs to leave the call unmade”Imagine a logistics company that deployed a routing optimization model. At launch it cut delivery times and fuel costs, the team celebrated, and they moved on to the next project. Six months later a new supplier joined the network with different shipping profiles, a regional warehouse changed its hours, and seasonal order patterns shifted. The model kept producing recommendations that looked reasonable but drifted further from optimal with each passing month: routes that added miles, schedules that missed windows.
No one had been assigned to watch. No one had been assigned to retrain. No one had been assigned to decide when the output was no longer good enough.
The system was still working. It just was not working well, and no one knew who to call, because that question had never been answered at the leadership level.
The failure is organizational, not technical. The model performed exactly as built while the ownership structure that should have kept it current was never put in place. And that gap was decided, or left undecided, in the meeting where go-live was approved.
What redesigning actually requires
Permalink to “What redesigning actually requires”If you decide to move toward production ownership, the work is mostly structural rather than technical. A few things have to change at once.
Deployment stops being the success milestone. A shipped model is not a model delivering value, and the incentives have to say so.
Live performance becomes something you measure and reward: not just uptime, but output distributions, decision accuracy, and the downstream business outcomes the model was supposed to move. Those become part of how the people who built the system are evaluated.
The accountability contract changes more than the job title does. The practitioner who builds the model owns its full life, from first exploration to live performance. The sandbox is part of the role, not its boundary.
You build the conditions that let someone own production without being swallowed by it: real investment in monitoring and retraining infrastructure, and the organizational trust to let the builder decide when a model needs retraining or retirement. That last point is underrated. A model that runs for years becomes infrastructure people depend on, and the person who built it needs the authority, not just the obligation, to call for its retirement when maintaining it costs more than rebuilding.
The invitation
Permalink to “The invitation”If you have already made this structural call, I want to hear how you did it.
Not how the practitioner changed their morning routine. How you changed the incentives. What did you tell the team “done” means now? How did you rewrite the performance review to reward production ownership over delivery velocity? Where did the research instincts of your data science team collide with the operational discipline the new model demands, and where was it worth pushing through anyway?
The question of who owns the live system is not settled. But the cost of leaving it open shows up everywhere: applause on day one, silence on day 90, and a system still making decisions with no one accountable for whether those decisions are any good.
Left unowned, that system becomes a liability waiting to mature. The decision about whether to let it is yours.
Note: Views expressed are those of the contributor. All submissions are vetted for quality and relevance. Context and Chaos is information-first: no promotions, paid or otherwise.
About Context & Chaos
Permalink to “About Context & Chaos”Context & Chaos isn’t just a newsletter. It’s shared community space where practitioners, builders, and thinkers come together to share stories, lessons, and ideas about what truly matters in the world of data and AI: context engineering, governance, architecture, discovery, and the human side of doing meaningful work.
Our goal is simple, to create a space that cuts through the noise and celebrates the people behind the amazing things that are happening in the data & AI domain.
Whether you’re solving messy problems, experimenting with AI, or figuring out how to make data more human, Context & Chaos is your place to learn, reflect, and connect.
Got something on your mind? We’d love to hear from you. Hit Reply!
Share this article