Expect the Unexpected (And Build for It)
May 16, 2026
THE ASSUMPTION PROBLEM
Every system is built around what we expect. The typical user, the usual transaction, the scenario most likely to occur. These are the known knowns — and designing for them is just the most practical. Most systems also account, to some degree, for the known unknowns — the gaps and risks already identified, the edge cases flagged during planning, the what-ifs that made it onto someone's list.
What systems struggle with, almost universally, is the third category: the unknown unknowns. The inputs nobody anticipated, the combinations nobody thought to test, the scenarios that fell completely outside the frame. These arrive without warning and without precedent. And how a system responds to them says a lot about it too.
IN DATA AND BI
Anyone who has worked in data long enough has a story like this. An automated sales report runs every morning without issue until a new market is onboarded and their source data uses a different date format. For weeks, a portion of transactions are silently dropped. The dashboard shows that market underperforming. Leadership pulls back investment. Eventually a manual reconciliation surfaces the truth. A date format. A regional exception. A business decision made on broken ground.
It happens in subtler ways too. A cost centre stops populating a field due to a quiet upstream change, and nulls flow in where numbers should be. The system treats null as zero and a product suddenly looks far more profitable than it actually is. Or duplicate records enter from a CRM migration, splitting one customer into two, making churn look higher and revenue per customer look lower than reality. In each case the pipeline did not break. It simply processed confidently and incorrectly, because nobody had engineered for the exception.
Rolling out a BI system involves rigorous testing. And what that process teaches you over time is not how to eliminate exceptions but how to recognise them, handle them cleanly, and build with enough experience to know where the edges tend to be. Every scenario caught early is one less surprise waiting down the road. Finding exceptions early in testing is actually a good sign — it means the system is being genuinely stress tested and that the team knows what to look for. At Cubot BI, that experience has been earned across implementations and refinements over years, and it shows in how we design. We know which patterns hold, where systems tend to be fragile, and how to build in ways that make exceptions manageable. A good BI system is not one that never encounters issues. It is one where issues are surfaced quickly, resolved cleanly, and added to a body of knowledge that makes the next implementation sharper than the last.
WHEN DECISIONS GET AUTOMATED
The stakes rise significantly when decisions stop being reviewed and start being automated. A human analyst looking at a dashboard might pause at an anomaly, question it, and dig in before acting. Automated systems do not have that instinct. Pricing engines, inventory replenishment, credit scoring and customer segmentation are all increasingly driven by agents that process inputs and produce outputs at a speed and scale no human team can match. That speed is the point — but it is also the risk.
When those inputs contain an exception the system was not designed for, the decision does not wait for anyone to notice. It executes immediately, across thousands of transactions or customers, before a single person has had the chance to question it. What might have been a data quality flag in a manual process becomes a business action that has already happened at scale. Automating decisions is powerful. But without the ability to recognise and handle exceptions, it is not efficiency — it is the fastest possible way to compound an error.
IN AI
Large language models perform impressively within the boundaries of what they know. Common questions, well-represented problems, familiar contexts — these they handle with confidence and fluency. But move toward the edge of that knowledge, into unusual contexts or domain-specific nuance, and something worth paying attention to happens. The confidence does not drop. The answer still arrives, fluently and authoritatively. It is simply confidently wrong.
This is what hallucination actually is — not a dramatic failure but a quiet one. The model encountered something outside its reliable range and processed it anyway, without any signal that it had crossed a line. It is not unlike a null being treated as zero in a data pipeline. The system did not break. It just produced a confidently incorrect output. As AI agents become more embedded in how organisations operate — summarising reports, generating recommendations, informing decisions — this problem does not diminish. It becomes faster and harder to trace. Without rigourous AI testing resources and capability, an organization cannot really trust its results for its context as well.
WHEN THE COST IS CATASTROPHIC
The Boeing 737 MAX crashes offer one of the most studied examples of what happens when an exception is not engineered for. The MCAS system was designed around the assumption that its sensor inputs would be reliable. When a single faulty sensor behaved outside that assumption, the system had no adequate way to handle it, and the consequences were catastrophic. This exception had existed as a possibility from the beginning but it was simply never fully anticipated. By the way, aircraft safety tests are also one of the most rigorous testing processes to exist - so these incidents lie at the extreme edge case as well.
The 2008 financial crisis followed a similar logic. The models that priced risk across the global financial system were built on the assumption that US housing prices could not fall simultaneously and nationally. It had not happened before, so the possibility was treated as remote enough to ignore. When it did happen, the models had no framework for it. They continued producing outputs as though everything was within the expected range, and because the entire system was built on the same assumption, every decision pointed in the wrong direction at the same time.
In both cases the exception was not unimaginable but it was simply inconvenient to imagine. The assumption held, the system was built around it, and when reality moved outside those boundaries the consequences compounded quickly. Assuming something is unlikely is not the same as being prepared for it. A single catastrophic result can make one re-think the entire system.
BEYOND THE AVERAGE
Outside of systems and technology, exceptions have a different quality entirely. They are not problems to be managed — they are where everything interesting lives. The athlete who should not have made it by conventional measure but did. The company that had no right to exist in a crowded market but was exceptional enough to survive and matter. The scientist whose idea was too unconventional for the mainstream until it wasn't. Every field that matters is shaped not by its averages but by its outliers.
The bell curve produces the mean. It may not always produce the remarkable. Institutions and systems that optimise relentlessly for the expected tend to produce reliable, predictable, and possibly average outcomes. That has its place. But growth rarely comes just from the middle path. In business, the most interesting opportunities often sit at the edge of what is considered normal — the unconventional product, the underserved market, the approach that breaks with how things have always been done. Creativity by its nature operates outside the expected. So does meaningful growth. Unconventional decisions are also harder to engineer but they can also produce good results.
DESIGNING A GOOD SYSTEM
Every system begins with engineering known knowns — the scenarios planned for, the inputs anticipated, the paths carefully designed. That foundation is necessary. But it is the unknown unknowns that ultimately define a system's quality. They arrive without warning, outside every assumption the system was built on, and they do not announce themselves in advance. The question was never whether they would come. It was always whether the system was ready when they did.
So as you build automation — whether it is a BI implementation, an automated decision pipeline, or an AI layer — it is worth asking honestly how much of that design accounts for the expected, and how prepared are you for the unknown unknowns. If you are able to see major exceptions early, you fare better. If you are able to gather resources and capability to flag these unknowns over a period of time, you’re on your way to ensuring better quality results in the long run as well. If you create a process to continuously watch out for the unknowns - you also might be better prepared for whatever they are.
How good is your system and the processes around it to allow for flagging, handling and monitoring exceptions?
