Designing with Uncertainty #HCIExplained S2.E5

Welcome back to the Deep Dive. Today, we are going to break something. Or, more accurately, we're going to break a mental model that I think most of us have been carrying around since, I don't know, elementary school. It's a really comfortable model, though. Oh, it is. It's a model that makes the world feel safe and orderly and predictable. It's the architectural blueprint of our trust and technology. Yeah. And honestly, it's terrifyingly outdated. Exactly. We're talking about the myth of the perfect machine. And to get us started, I want to take you back to a simpler time. Picture a device we all grew up with, the pocket calculator. Oh, yeah. Maybe it was a Texas Instruments, maybe a Casio with that little solar panel strip on top. A classic. Those rubbery buttons, the gray casing. It was a beacon of truth. A beacon of truth. I love that. Now, think about how you interact with it. When you type in two plus two into that calculator, what do you get? You get four. Every single time, without hesitation. No, four, you don't get four is you don't get probably four, but you know, maybe three if it's raining outside, you get four. It's binary. It's deterministic. It's always correct. And because of that simple interaction repeated thousands and thousands of times in our childhoods, we have culturally trained ourselves to view all computers as these rigid, logic gates. Mm-hmm. Input A must lead to output B. It's the old covenant of computing, you could say. We built our entire foundation of trust on this idea that machines are objective, they're algebraic and they're infallible. If the machine says it, it must be the result of a perfect flawless calculation. But here is the hook for today's deep dive and it's a massive one based on the stack of research we've got here. We aren't living in that world anymore, that world is gone. It is. It really is. We've undergone this, this tectonic shift in technology. We've moved from what we might call the statistical era or the deterministic era of the calculator into what the research is calling the resilience era. And the machines we use now, I mean, generative AI, the internet of things, deep learning systems, the algorithm that's deciding your credit score or driving your car, they don't work like calculators. Not at all. Not even close. They're probabilistic, not deterministic. They don't know the answer in the way a calculator knows arithmetic. They guess. They guess. Yeah, they guess. They look at these massive, massive amounts of data they spot patterns within it and they make a prediction based on probability. It's a sophisticated guess, but it's still a guess. It's like having a super smart friend who is right about 99% of the time, but every now and then just completely hallucinate something yet speaks with absolute 100% unshakable confidence regardless of whether they're right or completely off the wall. That is the perfect analogy. And the danger and this is the core tension we need to unpack today is that while we are building these systems that are inherently uncertain, we are designing them to look certain. We're dressing a probabilistic guesses as hard facts. And that leads us to what the research calls the trust trap. Because when a system is good enough when it's highly reliable, but not perfect, we humans, we just stop paying attention. We check out. We check out. We assume the machine has it handled. And that's exactly where the danger lies. You see, uncertainty isn't a bug. It's a feature of the real world. The failure isn't that the machine is uncertain. The failure is that we and the machine itself pretend that it isn't. So here's our mission for this deep dive. We're going to unpack why uncertainty is unavoidable in modern tech. We aren't just going to say AI makes mistakes. We're going to look at the white box paradox. We'll find out why something called ghost data is haunting the internet of things. And why a cone of uncertainty might actually be more dangerous than the storm it's trying to predict. Exactly. And then crucially, we're going to talk about how to fix it. How to design for something called graceful failure. Yeah, how to build systems that know how to doubt themselves. Let's dive in. First, I think we need to get our definition straight. The sources break this down into a taxonomy of the unknown. If we're saying machines are uncertain, what does that actually mean? Because it's not all just glitches. Right. That's a great place to start. If you look at the literature on human computer interaction and uncertainty, they generally categorize it into two main buckets. You have allotoric uncertainty and then you have epistemic uncertainty. Okay, let's unpack those allotoric. That sounds complicated. Greek. It is. It comes from the Latin alia, which refers to a die as enrolling dice. So allotoric uncertainty is the role of the dice. It represents irreducible randomness. So this is just the noise of the physical world, the stuff you can't control. Exactly. It's the inherent chaos of reality. It's sensor noise. It's atmospheric turbulence. It's a sudden downpour of rain. If you're designing an autonomous vehicle, alia, toric uncertainty is the fact that it's raining and the road is slippery, or that the sun is hitting the camera lens at a weird angle and creating a flare. Okay. You can't fix this with more data. No matter how many terabytes of data you feed the computer, the road is still slippery. It's just the inherent randomness of the physical environment. It's the friction of reality. You can't code away the rain. Perfectly put. It's the friction. It's the static on the radio. It's always there and you have to account for it, but you can't eliminate it. Okay. So that's the dice roll. What about the second one? Epistemic. Epistemic uncertainty is different. This one comes from the Greek word "ephystein" for knowledge. So this is the gap in knowledge. This is the classic unknown unknowns. This happens when the model lacks the knowledge to handle a situation because it simply hasn't seen it before in its training. So this is the AI encountering something it wasn't trained on. Precisely. In data science, they call this out of distribution data. For example, if you train an image recognition AI only on pictures of dogs, thousands and thousands of dogs, every breed imaginable, and then you show it a cat. It freaks out. It has no idea what that is. It experiences high epistemic uncertainty. It literally doesn't know what it's looking at. In my guess, it's a weird looking dog. It might just fail. Now, unlike the dice roll, this could theoretically be fixed with more data. If you show it a million pictures of cats, that specific uncertainty goes away. But the world is full of infinite variations, so you can never truly eliminate it entirely. There's always a new cat that hasn't seen. I like the coin flip analogy here to keep these straight. So, alliatoric uncertainty, the first kind, the dice roll, that's like trying to predict the coin flip. It's 50/50. You can't know the outcome until it lands. That's just physics. That's the world being the world. Right. You can model the probability, but you can't predict the specific instance. But epistemic uncertainty, that's like trying to predict a coin flip when you don't realize the coin is weighted. Yes, that's a great way to put it. You're missing a key piece of information, the fact that the coin is weighted. If you knew that, your prediction would improve dramatically. The knowledge exists. The system just doesn't have it yet. So, why does this distinction matter for the tech we use every day? Why should the listener care if an error is alliatoric or epistemic? Because we are increasingly trying to map this chaotic, messy physical world onto a neat, clean, digital grid. And that map is never, ever perfect. This is especially true when we start talking about the Internet of Things, or IoT. Smart building, smart cities, all those connected sensors. Exactly. We have this image of these systems as being all-seeing, all-knowing, but they're not. And the sources mentioned this concept of ghost data in IoT. That sounds spooky. It's less spooky and more just, frustratingly messy. In a smart building, you might have thousands of sensors measuring temperature, occupancy, error quality, you name it. But sensors fail. Batteries die. Packets of data get lost in transmission over the network. Calibration drifts over time. So the system has holes in its vision. It's looking at the world through Swiss cheese. Exactly. It's working with incomplete data. That's the ghost data. But here's the kicker. And this is really counterintuitive for a lot of people. We tend to think that having more information always reduces uncertainty. That feels right. Information eliminates doubt. That's the classic information theory view. But in the era of big data and IoT, where we are generating something like 2.5 trillion bytes of data a day, we hit a wall. Information overload. It's actually entropy. Too much noise increases in determinacy. If you have a thousand sensors screaming at you and 500 of them are slightly out of calibration because of that alien torque noise we talked about, you don't have clarity. You have confusion. You can't verify what is true. It's like being in a crowded room where everyone is shouting a slightly different version of the time. You actually know less than if you just had one reliable clock. Precisely. We are drowning in data but starving for certainty. So we have this fundamental mismatch. We have a chaotic physical world full of alien torque noise rain wind dirt on a camera lens. And then we have these digital models full of epistemic gaps things. They just haven't learned yet. And yet when I look at my smart thermostat or my GPS, it gives me a single number. It is 72 degrees. You will arrive at 5.04 pm. And that brings us to the core problem. The machine hides the mess. It presents a facade of certainty. And when we believe that facade, well, really bad things can happen. Okay, so this is where we get into the consequences. And the research points to a really powerful psychological phenomenon called automation bias. Automation bias is huge. And it stems from a simple fact about us humans. We are frankly cognitive misers. We're lazy thinkers. Is that a polite way of saying it? I might say efficient, but yeah. We want to save mental energy. Thinking is metabolically expensive. Our brains are designed to conserve calories. So if a computer offers a solution, our brains says, great problem solved. And we just take it. We tend to favor automated suggestions even when they contradict what our own eyes are telling us. And the sources break this down into two specific types of errors that result from this. Errors of commission and errors of a mission. Let's break those down. Right. An error of commission is doing what the machine says, even when it's clearly obviously wrong. Yeah. This is the classic death by GPS scenario. Following the GPS into a lake, we've all heard those stories. Exactly. You are driving. Yeah. You are looking at the lake. Your eyes see the water. Your brain knows the cars don't drive on water. But the little glowing screen says, turn left. So you turn left. You commit the error because of the automation. You trust the screen more than your own retina. It's incredible how powerful that glowing screen is. It can override millions of years of survival instinct. It's like a magic spell. It overrides common sense because we have assigned the machine the role of truth teller going all the way back to that calculator. Okay. So that's commission. What about errors of a mission? That's the flip side. It's failing to notice a problem because the machine didn't alert you. This is also called the vigilance decrement. If you have a system that catches 99% of errors, you just stop looking for the 1%. You get complacent. You assume silence means safety. It's the security guard following a sleep because the alarm system is so good he figures he doesn't need to watch the monitor. Exactly. And when the alarm inevitably fails that one time, the guard is a sleep. The omission of the alarm leads to the guard's omission of his duty. Let's apply this to a real world tragedy because the source is going to some pretty forensic detail on the 2018 Uber autonomous vehicle crash in Tempe, Arizona. This isn't just a news story. It's a perfect case study in what happens when epistemic uncertainty meets a system designed for certainty. It is a heartbreaking case. But from a technical standpoint, it is incredibly revealing. So you had a self-driving car moving down a dark road. A woman, Elaine Hersberg, was crossing the street, pushing a bicycle. Now let's be really clear here. The car's sensors saw her. It wasn't that the sensors failed to detect an object, right? This wasn't a blindness issue. Correct. That's a critical point. The light R&D systems saw an object in the road. The sensors did their job. The failure was epistemic. It was a knowledge gap. The AI couldn't classify what it was seeing. It fell into a gap in its training data. Exactly. It had never seen a person walking next to a bicycle in that specific way at that angle in those lighting conditions. It was an out of distribution of it. The logs show that the system was just frantically toggling its classification. It went from vehicle to other to bicycle. It was oscillating, just guessing. It was confused. It was deeply confused. And crucially, it only settled on the classification bicycle about 2.5 seconds before impact. But here is the fatal flaw. The thing that makes this a design failure and not just a tragic accident. The system's internal logic for bicycle assumed that bicycles move with traffic in the bike lane. It didn't have a model for a bicycle moving across the road perpendicular to traffic. Correct. So it applied the wrong rule set. Yeah. It applied a set of rules based on a confident but completely wrong classification. Yeah. And because the system was designed to be decisive to act with certainty, it didn't have a mode for eye and confused. It didn't have a slowdown and be careful mode. There was no, I should probably break just in case protocol. No. It just kept guessing. It was too late. It had a binary failure model. It thought, I must classify this object in order to act. Instead of, I cannot classify this object. Therefore, I must stop. That is just, it's terrifying. It's that I must be right mode. It prioritized making a decision. Any decision over recognizing its own ignorance. And this isn't just about autonomous cars. We see this performance paradox in aviation too. You look at Air France flight 447. That was the crash in the Atlantic Ocean right a few years back. Yes. In that case, the autopilot disengaged because the external sensors iced over that's alien torque uncertainty, the weather messing with the pitotubes. But then the humans, the pilots took over. And what the research shows is that when humans intervene in these incredibly complex algorithmic systems, whether it's flying a modern airbus or quantitative trading on Wall Street, they often make it worse. Why? Because they don't understand the system state. They don't know why the computer gave up. It doesn't explain itself. Exactly. The computer just hands back control at the worst possible moment, usually when the situation is already chaotic and spiraling. It's like a friend is driving your car and suddenly screams, I don't know and covers their eyes while you're doing 80 on the highway. Good luck. The pilots on Air France 447 were just bombarded with contradictory warnings and alarms. They couldn't build a clear mental model of what the plane was actually doing. So the machine handles all the easy boring stuff for hours, walling the human into complacency, and then it dumped the impossible stuff on the human with zero context in five seconds to react. We call it the moral crumple zone. We'll get to that later. But it's this idea that the human is just there to absorb the blame when the machine gets confused. Wow. I want to look at one more example of hidden uncertainty. One that affects people's lives in a really different but equally profound way. The compass algorithm used in US court system. Yes. This is a critical example of what you could call black box uncertainty. Compass is a tool that's used to predict recidivism. So the likelihood that a criminal defendant will reoffend in the future. And judges use this to help them decide on things like bail and sentencing. They do. And the system spits out a score. It's usually simple label. High risk, medium risk, low risk. But what does that score really? Right. It's presented as a fact but it's a probabilistic guess. It's based on historical data. And that historical data is filled with all the biases of the justice system, historical racial inequalities, bias policing patterns, you name it. So if the data itself is biased, the uncertainty and the prediction is also biased. Exactly. But the system hides all of that nuance. It hides the uncertainty. It doesn't say there is a 60% chance this person reoffends with a margin of error of plus or minus 20% because our data on this demographic is noisy and potentially biased. Yeah. It just says high risk. It looks like a fact. It's stamped on their file. And that creates a black box where a defendant cannot challenge the probability can't cross examine a proprietary algorithm. If a judge sees high risk, that automation bias we talked about kicks right in. They assume the computers calculated something objective and scientific. When really it's just a statistical guess wearing a suit and die. Precisely. It is uncertainty masquerading as certainty. So okay, the natural reaction to all of this to the uber crash to the biased algorithms is to say, okay, fine, the computer should just explain itself. If the AI tells us why it made a decision, then we'll be able to trust at the right amount. That seems logical. That is the intuition. It's the whole field of explainable AI or X AI. But here is where it gets really, really interesting. And frankly, a bit weird. Research suggests that showing your work can actually backfire. This is the white box paradox. Yes. The white box paradox. You would think that if you open the black box, make it a white box, make it transparent. People would be more critical. They'd scrutinize it more. But studies show that explanations can actually increase automation bias. Wait, wait. So you're saying if the computer explains itself, I trust it more blindly. That feels completely counterintuitive. It is. But think about human psychology. It's because the explanation looks authoritative. If the AI says, I recommend this medical treatment because the patient's biomarkers A and B are elevated, which correlates with the condition C in the literature. You think, wow, it's done at homework. It has thought this through. It must be right. You stop checking the math because the narrative sounds so compelling. Exactly. An explanation is not a proof of correctness. It is just a narrative of the machine's potentially flawed logic. And if the machine's logic is flawed like the uber car thinking a bicycle always moves like a car, then the explanation will just be a very detailed, very convincing description of a bad idea. It's like when someone tells you a lie, but they add so much specific detail that you end up believing them. I couldn't call you because my phone died and then I couldn't find a charger and the cafe down the street was closed for a gas leak. That's it. Exactly. The detailed limitations and the risks and the uncertainties are often glossed over by the sheer narrative force of the explanation. We get seduced by the story. We confuse plausibility with truth. This reminds me so much of the cone of uncertainty in hurricane forecasting. We've all seen this map on the news. The storm is coming and there's this big white cone expanding out from the center. The cone of death, as some people call it. And this is a classic classic visualization failure. The cone technically represents a 66% confidence interval. What that means is that historically the center of the storm stays inside that cone about two thirds of the time, which means, and this is the important part, one out of three times 33% of the time the storm center goes outside the cone. Right, but that is absolutely not how people read it. They fall into what's called the binary trap. They look at the line on the map. If their house is inside the line, they think danger. If they're one inch outside the line, they think safe. They don't see the gradient of risk. They just see a wall, a boundary. They see a wall. And people also misinterpret the size of the cone. They see the cone getting wider as it goes out in time, and they think it means the storm itself is getting bigger. When actually it just means the forecast is getting more uncertain. The further out in time you go, the less we know. Exactly. The uncertainty is growing, not the storm. But these visual cues are so powerful. We are wired to interpret clean lines as boundaries of truth. I mean, there's research that shows that 31.5% of researchers actual scientists even misinterpret standard error bars in their own fields. So if a third of scientists can't even get it right, we can't possibly expect the general public to intuitively grasp confidence intervals during a stressful event like a hurricane. It's a profound design challenge. We are visual creatures who love boundaries and certainty, and we are trying to map a [BLANK_AUDIO] the probabilistic reality onto a 2D screen. Okay, so we've covered the gloom and doom. We've seen how hiding uncertainty can lead to disaster, but surely there has to be a better way. The outline mentions a success story involving ice cream. And honestly, I could go for some ice cream right now to deal with all this anxiety. Yes, the ice cream seller experiment. This was a fantastic little study run by the UK Met Office, their National Weather Service. We wanted to see if normal people, not scientists, not data analysts, just regular folks, could actually handle and benefit from probabilistic information. Because the longstanding assumption has always been, keep it simple, stupid. Don't confuse the public with percentages and probabilities. Just tell them what to do. Right, just tell me if I need an umbrella. So they set up this game. Participants played the role of an ice cream seller. And they had to make daily decisions about how much stock to buy and whether to even open their stand, all based on the weather forecasts they were given. High stakes ice cream arbitrage. I love it. It was. Now they divided the participants into groups. Group A got a deterministic forecast. The weather man just said it will rain or it will be sunny. A simple binary prediction. The old way, the illusion of certainty. Exactly. Group B on the other hand got a probabilistic forecast. So they were told there is a 30% chance of rain today. Okay. And who made more money selling ice cream? Group B. Yes, significant margin. The people who were given the uncertainty information made significantly more profit over the course of the experiment. Why? What did they do differently? Because they could hedge their bets. Think about it. If you tell me it will rain, my only logical move is to shut down the stand. Zero profit, but also zero loss. But if you tell me there's a 30% chance of rain, I might say, okay, the risk is pretty low, but it's not zero. I'll open, but maybe I'll buy a little less stock so I don't waste as much money if it does pour. They were able to optimize their decision making based on the level of risk. So people can handle the truth. We don't need to be coddled. They absolutely can. Yeah. In fact, other research shows they crave it. There's this concept called decoding pretended knowledge. It turns out that when a forecaster gives a binary answer, it will rain. Users actually sort of decode it. They assume the forecaster is covering their backside and being overly cautious. Right. Like if the weatherman says it's definitely going to rain, I assume he just doesn't want me to yell at him if I get wet. So he's exaggerating the risk. Exactly. You assume he's crying wolf. But if he says there's a 30% chance, it signals honesty. It signals a scientific approach. It tells the user, I'm not treating you like a child. Here's the data as we understand it. And that builds trust in the long run. It builds long term trust. Even if it does rain on that 30% day, you don't feel betrayed. You think, well, I got unlucky. I hit the 30%. But if he said it will be sunny and it rains, trust is destroyed instantly. So treating your users like intelligent adults is actually a good business strategy. Who knew? Transparency is a trust multiplier, not a trust killer. So if that's the case, how do we actually design for this? If we want to move away from the perfect machine myth and start embracing uncertainty, what does the interface on my phone or in my car actually look like? Because I don't want my car to give me a three-page dissertation on Bayesian probability while I'm trying to merge onto the highway. Right, it has to be intuitive. And this is the whole emerging fields of designing for doubt. And there are some really practical interesting strategies coming out of it. The first big principle is, signal, don't hide. OK, give me an example. What does that look like? What are the simplest ways is a traffic light system? Instead of giving a raw probability like 0.73 confidence, which feels kind of fake, precise to most people, you use categories. Green means reliable, proceed. No means review needed, use with caution. Red means low confidence. Human input required. That makes immediate sense. It's a visual metaphor we all understand. We already know how to stop at a red light. Another one is using visual cues. There's some fascinating research into using sketchy outlines or muted washed out colors for uncertain data. So if that chart is based on shaky data, you literally make the lines on the graph look like a hand drawn pencil sketch. Oh, I love that. It visually suggests this is a draft, this is a guess, don't take this as gospel. Exactly. It breaks that implicit bias we have where clean lines on a computer screen equal truth. If it looks like a sketch, your brain intuitively treats it as a sketch and invites you to question it. What about language? We're seeing this so much with large language models like chat GPT. They can sound so incredibly authoritative, so confident, even when they're just completely making things up. Linguistic uncertainty is a huge frontier. Global LMs are very sensitive to how we talk to them and how they talk back. There's a phenomenon that researchers have identified called sick of fancy. Sick of fancy as in being a suck up. Yes, exactly. If a user sounds certain in their prompt, if you type, "I am sure that this historical fact is true," please explain why. The AI will often just agree with you, even if you're completely wrong. It's programmed to be helpful and it interprets helpful as agreeable. So it just reinforces my own biases. It's an echo chamber powered by a supercomputer. Precisely. It mirrors your own express confidence. The proposed fix is for the AI to use humble language. It should be trained to use linguistic markers of uncertainty like, "I'm not an expert on this, but," or, "Here's my best guess, based on the available data," or sources differ on this point. And the sources mention a study that's just staggering. Chat GPT made errors in 153 out of 200 quotes it was asked to verify, but it only expressed uncertainty in seven of those cases. It was confidently wrong. And that is the single most dangerous state for any automated system. We need to train these models to identify their own epistemic gaps and to communicate them clearly. We actually need to reward the model for saying, "I don't know." The outline also mentions these things called the shape of AI patterns, things like tuners and governors. What are those? These are UI patterns that are all about giving control and agency back to the human. A tuner, for example, lets you adjust the model's parameters. You've seen this in some image generators. Maybe you want high creativity, which you know implies high uncertainty and weirdness, or maybe you want high precision in realism. You get to act like a DJ mixing the output to your needs. OK, that's a tuner and a governor. A governor is a human in the loop feature. It's a circuit breaker. It forces a pause. If the system's uncertainty is above a certain threshold, it shouldn't just act on its own. It should stop and say, "Human, I need you to sign off on this. I'm not sure." It prevents that Uber situation where the car just makes a life or death decision 2.5 seconds before impact. Exactly. It forces what some researchers call strategy-graded reliance. That means we need to teach users to rely on AI for the things it's good at, like massive pattern matching where it's 99% accurate. But to rely on themselves for ethical reasoning or for handling those bizarre out of distribution events, it's about knowing which tool to use for which job. This all seems to lead us to the underlying engineering philosophy behind all of this. We keep saying we're moving from the statistical era to the resilience era. And there's a concept here that I find absolutely fascinating, graceful failure. Graceful failure is the holy grail of resilience engineering. Right now as we've discussed, most AI has a binary failure model. High confidence, respond. Low confidence. Retry or crash. It's all or nothing. It works perfectly or it falls off a cliff. But biological systems like us, we don't work that way. When you may get tired or confused or a little drunk, we don't just instantly shut down and fall over. We degrade. We slow down. We start to double check things. We ask for help. We hold onto the hand rail and we go down the stairs. Right. We transition between states. Graceful degradation means designing a system with multiple levels of operation. Level 1. Normal operation. Everything's fine. Level 2. The strained operation, maybe the drone fly slower, where the chatbot gives shorter, more conscious answers. Level 3. Minimal safe operation. The car pulls itself over to the shoulder of the road. And finally, level 4. Shut down. So degradation is a designed state transition, not a bug. That is a beautiful way to put it. It is a choice. The system chooses to do less in order to preserve safety. The Uber car didn't have a constrained operation mode for I don't know what the strange object is. You just had drive and crash. And this connects to this other idea that shift from UQ to UC, uncertainty quantification versus uncertainty control. This is the deep engineering shift that's happening right now. The old school method from reliability engineering was UQ uncertainty quantification. Try to measure the probability of failure. There's a 1 in a million chance the wing falls off this airplane. That works pretty well for physical hardware. But software is different. It's not just about metal fatigue. Right, software and especially AI are dominated by epistemic uncertainty. By those unknown unknowns, you cannot predict every failure mode in a complex piece of software. You can't quantify all the weird things the world will throw at it. So instead of trying to measure the risk, which is UQ, you design the system to control the uncertainty. That's UC. How does that look in practice? What does it mean to control uncertainty? Let's take EV teals. Those electric flying taxes that companies are developing. The urban air environment is incredibly chaotic. You've got wind tunnels between buildings, flocks of birds, other drones, rogue plastic bags. You can't possibly quantify every single risk. So you design the system to actively manage its boundaries. If it gets confused by a sudden gust of wind, its protocol isn't just to calculate the odds of crashing. Its protocol is to actively move to a safer, more stable pocket of air or to safely handover control to a human pilot on the ground. It actively mitigates the unknown, rather than just calculating the odds of it. It's playing defense against the unknown, not just often. It is assuming the model will be wrong at some point and planning for that moment. Yeah. Rather than assuming the model's right and just crossing your fingers. I want to touch on the human element one last time before we wrap up. The sources have a section on the clinical perspective. We talked about doctors and medical AI earlier. What do they actually want from an AI assistant? Because if anyone needs certainty, you'd think it's a surgeon. This was a really surprising finding in the sources. You would think that doctors would want the AI to explain itself in plain English, right? The narrative explanation. I think this is cancer because of X, Y, and Z. The plausible story we talked about earlier. They liked that. Sure. It was interesting. But they didn't trust it. What they trusted and what they found much more useful was a feature called similar patient retrieval. What is that? It's purely evidence-based. Instead of a story, the AI says, "I think this patient might have conditioned X." Here are the charts of three other anonymous patients from the hospital's database who had similar symptoms and libresults, and they were all eventually diagnosed with conditioned X. Ah, so it's not giving an opinion. It's showing the raw data. It's showing its sources. It's showing the precedent. And the clinicians in the study preferred the verifiable evidence over the smooth confidence summary. The summary is just the machine talking. The similar patient feature is the machine showing its work. Not its internal math, but its external verifiable data. Don't tell me. Show me. Exactly. And that is such a key lesson for building trust in any of these systems. Don't just generate a story. Retrieve the truth. Let the human make the final connection. So let's bring all this home. We've gone all the way from the pocket calculator to the flying taxi. We've talked about ghost data, the trust trap, and the danger of binary black and white thinking. What does this all mean for us, the users of this technology every day? It means we need to fundamentally recalibrate our trust. We are living in the resilience era now. The goal is not to eliminate uncertainty. That is impossible. It's a fool's errand. The goal is to acknowledge it, to manage it, and to design for it. We need to start treating these machines like infallible calculators and start treating them like eager but very fallible assistants. Yes. Assistance who are brilliant at pattern matching but have absolutely no common sense and no real concept of truth. And if we don't, if we keep building systems that pretend to be perfect. Then we run headlong into the moral crumple zone. Blame that one more time. It's such a powerful visceral image. A crumple zone in a car is designed to be destroyed in a crash to absorb the impact and save the driver. But in these complex AI systems, the moral crumple zone is the human operator. When we hide uncertainty in the machine, when the Uber car pretends to know what is doing until the last second or the autopilot stays silent and then just gives up, the machine eventually fails. And who gets the blame? The driver, the pilot, the doctor. The nearest human. We take the moral impact for the machine's hidden uncertainty and its flawed design. So acknowledging uncertainty isn't just a technical fix or design choice. It is an ethical imperative to protect the humans we put in the loop. That is a heavy thought to end on, but a really necessary one. So to everyone listening, the next time your GPS or your chatbot or your smart analytics tool tells you something with 100% confidence. Pause. Just take a second and ask yourself, what is it not telling me? Exactly. Look for the ghost data. Click the cone of uncertainty and don't be afraid of a little doubt it might just save you. Thanks for diving deep with us. Stay curious.