A logistics company running a Living Model in production for eighteen months had achieved operational trust. The model recommended weekly capacity adjustments across nine distribution centers, and the executive team acted on its recommendations consistently. For eighteen months, the projections tracked actual outcomes closely enough to sustain confidence. Then, for three weeks, the pattern broke. Weekly fulfillment ran about four percent below the model's projection—not catastrophically, but systematically. The drift detector fired intermittent alerts. Three weeks is long enough to be a signal, not noise. The team had to diagnose the problem. Their options divided into three categories: update parameters in the existing diagram to absorb new information; examine whether the diagram itself had become wrong, with new mechanisms emerging or old ones weakening; or do nothing, treating the gap as statistical noise the model would correct on its own. Each choice was correct in some circumstances. Each had costs. This diagnostic moment—choosing the right maintenance discipline—separates organizations that build sustainable models from those that build models once and hope they hold.

A Living Model degrades because it is built as a description of a world that keeps changing. The causal diagram represents the mechanism by which variables influence each other in a specific organizational and market context. That context evolves. The mechanisms change with it. A model that does not account for this change becomes, over time, a confident description of a world that no longer exists. Without the maintenance disciplines that form the subject of this chapter, the defensible recommendation produced in month one produces an indefensible recommendation in month nineteen. This is not a failure of the original expert elicitation or the original algorithms. It is structural. The price of treating models as operational infrastructure—as systems that run, monitor, and learn indefinitely—is the cost of the machinery that keeps them operational. The organizations that extract durable competitive advantage from Living Models are those that treat this maintenance not as optional but as foundational. Every prior chapter in the architectural arc is undermined without it.

The maintenance architecture must handle three distinct modes of decay because each requires a different response. Parametric drift occurs when the weights on the edges of the causal diagram shift but the diagram itself remains correct. The mechanism is still the right one; the coefficients are different now than they were before. This is the domain of Bayesian updating. Structural drift is fundamentally different. It occurs when the causal mechanism itself changes. A new edge becomes active in the system—a variable that was previously inert now drives outcomes. Or an edge that was previously dominant has weakened or vanished. The diagram itself has become incomplete or wrong. Updating the parameters in a structurally wrong diagram will produce a model that is wrong in a worse way than it was before. Mechanism failure is the third mode. It occurs when the foundational causal story—the reasoning that justified the entire model—has been invalidated by a change in the world. Each requires a different response. Mistaking one for another is costly.

Bayesian updating of edge parameters is how production systems handle parametric drift. The model begins with priors on the coefficients derived from expert elicitation and historical data. As production data accumulates, that data is used to update the posterior on each parameter. This is not retraining the entire model. It is treating the edge coefficients as uncertain quantities and refining those uncertainties in light of new information. The mechanism requires data quality. If the production data is contaminated or biased, the posterior will move in the wrong direction. It also requires that uncertainty propagate properly into the recommendation. A coefficient that has become more uncertain should make the model more cautious about its output, not more confident. This is where many production systems fail. They update parameters but do not propagate the increasing uncertainty into the decision logic. The discipline of Bayesian updating assumes the diagram is still correct and only the quantitative relationships between variables have drifted. If the structural assumption breaks, the whole system becomes unreliable.

Structural change detection is operationally distinct from parameter updating. It operates at the moment when systematic deviations from the model's predictions suggest that the mechanism the model is describing has changed. A structural change flag means: stop assuming the diagram is correct and begin diagnosing whether the diagram itself has become wrong. This is expensive. It requires convening the expert who built the model. It requires examining the data to detect whether a new causal mechanism has become active or whether an old one has weakened. It requires, potentially, eliciting new expert judgment about the new mechanism. It is the escalation step in the maintenance hierarchy. The operational response to a structural change flag is not automatic. It is a moment of human review. A drift detector can fire continuously; a structural change detector should fire rarely, and when it does, it must trigger a diagnostic. The logistics company on Thursday was at precisely this moment. The team needed a diagnostic that would tell them whether they faced parametric drift or structural drift or simply noise.

Mechanism failure occurs when the foundational causal story of the model has been invalidated. The logistics model assumes that demand is determined by inventory and capacity availability—that if stock is high, demand can be met reliably, and if stock is low, demand spills over. That story held for years. But if the supply chain becomes severely disrupted and inventory becomes nearly impossible to obtain regardless of how capacity is allocated, the model's foundational story is no longer true. The causal story is not wrong about the past; it is wrong about the present. The world has changed so fundamentally that the mechanism the model describes no longer operates. Mechanism failure is rare but critical to recognize because it is the one mode of decay that parameter updates and structural drift detection cannot fix. The model cannot be kept alive if the world it was built to describe no longer exists. The organizational response is different. Rather than updating the model, the organization must recognize that the model is operating in a context where its assumptions no longer hold and retire it or replace it. Confusing mechanism failure with parametric drift leads to wasted resources in maintaining something that cannot be maintained.

The maintenance framework for a Living Model is not MLOps. MLOps is the operational discipline built for static learning problems—problems where you assume the data-generating process is stable, where you optimize for model accuracy, where the code and trained parameters are the primary artifacts that get versioned and deployed. Living Models operate under different assumptions. The mechanism changes over time. The data-generating process is not stable. The objective is not accuracy on a test set but decision quality in the world. The primary artifact is not code or parameters but the causal graph—the diagram that represents your understanding of the mechanism. DecisionOps is the operational discipline appropriate to this. DecisionOps integrates human review at critical moments: when parametric updates are being made, and always when structural changes are being detected or diagnosed. It treats the graph as version-controlled and auditable. It asks what has changed not just statistically but mechanically. It requires discipline around continuous parametric update, structural change detection, human diagnostic escalation, and ultimately the decision to retire or replace the model when the mechanism has changed too fundamentally to maintain.

The minimum viable feedback loop has four stages. The model produces a recommendation. The organization makes a decision on the basis of that recommendation, though not necessarily in accordance with it—executives retain discretion. An outcome occurs in the world. That outcome is measured and recorded. Finally, that measurement of the outcome is fed back to the model to update its understanding. This loop closes the orchestration circle introduced in Chapter Thirteen. Without this loop, the model operates blind. Without the decision stage, the model has no way to know whether its recommendations were acted upon. Without the outcome measurement, it cannot know whether the actions produced the expected results. Without the feedback stage, it has no way to update its parameters or detect structural changes. Many organizations build the first three stages and fail at the fourth. They generate recommendations, they act on them, the world produces outcomes—but the outcome data never gets connected back to the model. This is not a feedback loop. It is a prediction followed by outcomes that are never connected. The discipline that makes this loop work is the discipline that keeps the model alive.

Diagnosing a Living Model that is producing degraded recommendations requires a structured escalation. First, distinguish drift from noise. A continuous drift detector that monitors systematic deviations from prediction should fire before the gap becomes large. If the detector fires, you have a signal, not noise. Second, test whether parametric update resolves the gap. Apply Bayesian updates to the parameters affected by the recent data. If the gap persists after update, the problem is structural, not parametric. Third, convene the expert who understands the causal mechanism and begin examining whether the diagram itself has changed. Has a new mechanism become active? Has an old mechanism weakened or vanished? This is human diagnostic work, guided by data but not automated. Fourth, examine whether the foundational story is still true. Has the causal story that justified the model become false? If the world has changed so fundamentally that the mechanism no longer applies, the model cannot be kept alive; it must be retired or replaced. If the mechanism is still valid but the diagram is incomplete, update the diagram and re-parameterize. This diagnostic sequence prevents the organization from updating parameters when the structure is wrong, restructuring the diagram when the gap is just noise, or continuing to operate a model whose foundational story has become false.

The maintenance of a Living Model in production requires continuous discipline across four stages. Parametric updating must be continuous and automated, but the uncertainty that results from updating must propagate into the decision logic. Structural change detection must be ongoing, but human review must be triggered before any structural change to the diagram is enacted. The feedback loop must close completely: recommendation, decision, outcome, feedback. And the diagnostic framework must be applied whenever the model's performance begins to degrade. These are not optional refinements. They are foundational to the architecture. The organizations that build Living Models and then fail to implement these maintenance disciplines find that their investment depreciates rapidly. The model that was valuable in month one is indefensible by month nineteen. The organizations that treat the model as operational infrastructure—that continuously monitor it, update it, diagnose its failures, and refresh it when the mechanism changes—extract durable value from the architecture. The difference between success and failure is not the sophistication of the algorithm or the cleverness of the expert elicitation. It is the discipline of the maintenance system. A Living Model without maintenance disciplines is not a system; it is a project with an expiration date.

The thesis that threads through this chapter is this: the maintenance disciplines are not ancillary to the architecture of a Living Model. They are the architecture itself. The expert elicitation, the causal graph, the algorithms, the recommendation system, the executive report—all of these produce a defensible answer to a specific question at a specific moment in time. But that answer becomes indefensible as the world changes. The systems that keep the model alive—the parametric updating, the structural change detection, the human diagnostic escalation, the feedback loop that closes—are the systems that extend the life of that defensible answer from a moment into a sustained operational capability. The organizations that will extract durable competitive advantage from Living Models are the ones that recognize this. They will not treat the maintenance system as an afterthought. They will build the model and the system that keeps it alive together, as parts of a single operational infrastructure. They will invest in the discipline of DecisionOps as seriously as they invested in the discipline of expert elicitation. They will recognize that the graph is not an artifact to be handed off to engineers. It is an operational asset that must be continuously monitored, tested, and updated. The durable advantage comes not from the intelligence of the initial model but from the discipline of the system that keeps the model intelligent indefinitely.