Detection Is Not Resolution: A Red KPI Shows Where a Process Ends, Not Where It Breaks

In June 2026, in the Alaskan wilderness, a team of engineers from Palmer Luckey’s Anduril proved that a wildfire can be detected inside ten minutes of ignition. The setting was the final round of XPRIZE Wildfire, an eleven-million-dollar competition to build fully autonomous systems that detect and extinguish fires before they spread. Sensors covered a thousand square kilometres, software separated the real fire from decoys, and drones were airborne before a human could have finished a phone call. When XPRIZE announced the results on September 23, Anduril took first place in the autonomous response track. Every finalist detected. None fully suppressed. The three-and-a-half-million-dollar grand prize for extinguishing the fire went unclaimed.

That result is not a failure. It is the most useful thing the competition produced, because it separates two capabilities that most organizations treat as one. Detection is knowing something is wrong. Resolution is knowing why, and acting where the why lives. The first is a sensing problem. The second is a systems problem. They require different instruments, different people, and different budgets, and the gap between them is where most corporate money is wasted.

Every dashboard is built on the same principle as the warning light in a car. A threshold is set, a metric crosses it, a colour changes. The light does not say what is wrong. It says something is wrong, and it says so at the point where the failure became measurable, which is almost never the point where it began.

The sales number turns red. Sales is the last stop on nearly every value chain, so it is where every upstream problem eventually surfaces. A pricing error, a production delay, a customs hold, a credit policy that quietly tightened, a fulfilment partner that changed carriers: all of these arrive at the same place and wear the same colour. The alarm lands on the function with the least ability to fix it.

What happens next is predictable. A sales recovery program is launched within the week. A discount is approved. A new campaign is funded. The response is fast, visible, and often wrong, because it treats the location of the symptom as the location of the cause. Discounting to fix a fulfilment delay does not shorten the delay. It teaches customers to wait for the next discount.

Anduril’s team was fast. Ten minutes from ignition to detection is extraordinary. Speed of detection is a solved problem in most businesses too. What is not solved is the second step, and the danger is that speed in the first step gets mistaken for competence in the second. Acting fast on the visible layer feels like leadership. It produces a decision, a budget, and a meeting where someone can say the problem is being handled. It also consumes the capital that a real fix would have needed, and it delays the diagnosis by making the symptom temporarily quieter.

The instinct when a metric turns red is to ask which department is responsible. That question is almost always the wrong one, and it does damage before it produces anything useful. Departments are how a company is organized. Processes are how work actually moves. A single order can be touched by procurement, two production sites in different countries, a freight forwarder, a customs broker, a warehouse, and a billing system before it becomes revenue. No department owns that path. The head of sales owns the sales number and the head of production owns the production number, and nobody owns order-to-cash from end to end.

This is why the dashboard misleads. Metrics are owned by departments. Causes are owned by processes. Processes have no owner, so they have no metric, so the failure that runs across three functions and two jurisdictions is invisible until it reaches the one function that reports it.

I spent years converting financial institutions from one core system to another. The pattern never changed. The error appeared in the general ledger. The cause was in a data mapping three systems upstream, written by a team that had been disbanded, for a business rule nobody could still explain. The ledger was where the process ended. It was never where the process broke.

There is a practical discipline for closing the gap between detection and resolution, and it does not require new software. Follow the process backward from the red metric until the explanation crosses a boundary. A boundary can be a department, a system, a supplier, a jurisdiction, or a time zone. If the explanation for a sales decline never leaves the sales function, the tracing is not finished. If the explanation for a cost overrun never leaves the cost centre that reported it, the tracing is not finished. Keep going until the cause sits in a different place than the alarm. That is the point at which a fix has a chance of working, because it is the point at which the fix is aimed at the mechanism rather than the measurement.

Here is the honest counterargument. Sometimes the symptom must be treated first. When cash is running out, when a customer is about to leave, when the cost of delay clearly exceeds the cost of a wrong guess, triage is correct and diagnosis can wait. Firefighters knock down flames while the investigator looks for the ignition source. Both roles are legitimate. The distinction is sequence and intent: treatment of the symptom should buy time for the diagnosis, not substitute for it. The failure is not acting on the alarm. The failure is declaring the fire out because the alarm stopped.

Sometimes the cause is external as well. A supplier fails, a regulation changes, a currency moves. No process inside the company caused it. But the process determines how quickly the external shock becomes visible and how much damage it does before anyone acts. The cause may be outside your control. The exposure is not.

Detection needs sensors and thresholds, and most companies have invested heavily in both. Resolution needs a model of how the business actually works: someone who can say that a five-day slip at the second production site shows up as a sales miss in the third week, and can say it before the sales miss occurs. That is a causal map, not a dashboard, and almost nobody has built one.

This is also the honest limit of the current enthusiasm for artificial intelligence in operations. AI accelerates detection enormously. It reads more signals, faster, with fewer false positives. It does very little for resolution unless the causal model already exists, because a system cannot trace a process it has never been shown. Buying better alarms for a building with no floor plan produces louder alarms.

Before funding any fix, map the process that the red metric sits at the end of. Name the boundaries it crosses. Find the point where it breaks, and confirm that the intervention lands there rather than where the process reports. If the fix is aimed at the same place the alarm went off, you have bought a faster smoke detector. The fire is still burning upstream.