The Override Problem: What Happens After Your System Makes a Recommendation

I shipped a feature last week I hadn't planned to build. Not because I suddenly had a great idea. Because someone asked me a question I couldn't answer. I was in a conversation with a founder who builds AI sales agents, the kind of product that captures CRM signals and fires automated outreach based on what the data says. He'd been looking at MDU Engine, a decision-support tool I've been building for performance marketers, and he asked what I thought was a simple question: "Does the system know what happened after it made a recommendation?" I paused. It didn't. And the more I sat with that, the more I realised it was the most important gap in the product, not a nice-to-have, not a future roadmap item, but a fundamental blind spot in how the system understood itself. Why this matters more than you'd think MDU Engine evaluates whether campaign data is statistically ready to act on before a budget decision is made. Upload your daily Meta or Google export, and the system runs five thousand simulations to assess data sufficiency, signal stability, consistency over time, and downside exposure. It returns a recommendation: Scale, Hold, Reduce, or Block with a confidence score and a quantified downside risk in actual currency. That part works. I'd built it, tested it, deployed it, written about it. What I hadn't built was any mechanism for asking the obvious follow-up: did the user follow the recommendation? And if they overrode it, which users absolutely will, because humans always do what happened next? Did things get better or worse? Without that data, the system had no way to know whether it was well-calibrated. It was issuing recommendations into a void. The recommendations might have been systematically wrong for a particular decision type, and the system would never find out. What "override" actually means in a decision system In any human-in-the-loop system which is how MDU Engine is designed, explicitly users will sometimes disagree with the output and act against the recommendation. This is fine. It's the point. The system provides guidance; the human makes the call. But if the system doesn't log the override, and doesn't track the outcome, it can't do two things it needs to do: First, it can't assess its own calibration. If a particular decision class say, HOLD recommendations when confidence is between 0.40 and 0.60 gets overridden more than 50% of the time, that's a signal the system is miscalibrated for that situation. The threshold might be wrong. The inputs might be weighted incorrectly. Something isn't right. Second, it can't give the user any signal about whether their overrides are working. If someone consistently overrides HOLD and scales anyway, and their outcomes consistently worsen, that's information worth surfacing. Not to punish them, to help them understand whether their instincts are better or worse than the system at specific decision types. Neither of these things is possible without tracking the override. What I built The feature has three components. The first is an override log that creates a pending record every time a recommendation is issued, capturing the user, the recommendation, the confidence score, the downside risk, and the timestamp. The second is a 48-hour follow-up prompt. Two days after a recommendation, the system asks: did you follow it? Did you override it? What happened, did outcomes improve, worsen, or stay the same? The third is a calibration dashboard that aggregates this data over time. It shows follow rate, override rate broken down by decision class, outcome correlation between followed and overridden decisions, and a miscalibration flag that activates when any decision class shows an override rate above 50% across three or more decisions. The miscalibration flag is the most interesting part. When it fires, it doesn't say "you're wrong." It says: "this decision type is being overridden at a rate that suggests the system's reasoning for it may not match reality. Investigate before relying on it." That's a different kind of output than a recommendation. It's the system commenting on its own reliability. And I think that's actually more valuable than the recommendation itself. The broader point Every system that advises humans has an override problem. The system makes a call. The human decides whether to follow it. And then... usually nothing. The feedback loop closes, if it closes at all, only inside the human's head. This is why so many decision tools degrade over time even when the underlying logic is sound. They're not learning anything from the gap between what they recommended and what actually happened. They're optimising for recommendation quality without any signal about recommendation usefulness. The override isn't a failure of the system. It's data. Treated as data, it makes the system better. Ignored, it stays static while the world moves. I built this feature in about a week, faster than anything else I've shipped on MDU Engine. Partly because the scope was clear. But mostly because the question that prompted it was so precise that the answer almost wrote itself. The best product improvements I've made haven't come from user surveys or analytics dashboards. They've come from one conversation with someone who understood the problem well enough to ask the question I hadn't thought to ask myself. MDU Engine is a public decision-support platform for performance marketing budget decisions. Try it free at app.mduengine.com.