Waiting more than four minutes to allocate resources in a fast-moving emergency can put the commander at meaningful risk of choosing incorrectly. Consider a civil emergency with three situations developing at once. Situation A has the greatest number of casualties and needs immediate assistance. Situation B is worsening faster and will need substantially more resources in 20 minutes unless addressed now. Situation C has remained stable for an hour but could carry severe consequences if it escalates. Staffing is sufficient for only two situations. The decision depends on incomplete information, prior experience, and uncertain estimates of how quickly each situation will change. In exercises, we have seen the incident commander spend enough time analyzing this allocation problem for conditions to continue shifting before the choice is made.
The multi-incident triage bottleneck
Procedures and command structures are well established for single-incident response. The ICS, or Incident Command System, offers a workable hierarchy, and experienced commanders train extensively against single-incident scenarios. These procedures work because the problem's shape corresponds to the command organization's structure.
Multiple incidents disrupt that alignment. Teams must divide resources among separate situations with different rates of change, demands, and possibly command jurisdictions. In the UK, the JESIP, or Joint Emergency Services Interoperability Programme, guides coordination between agencies, but it does not answer the central triage question: how should resources be prioritized across situations developing at the same time when each information stream is incomplete and action cannot wait?
The bottleneck is the commander's time: assess every situation, forecast its resource needs, and produce an allocation recommendation. Two situations can be manageable. Five, combined with partial communications as discussed in our earlier piece on the coordination gap, are genuinely hard to assess well under pressure.
How commanders handle triage across situations
Exercises and post-incident debriefs with experienced commanders show several ways they adapt to multi-situation triage. One is ranking by incident type instead of present conditions, giving certain categories an inherent priority even when their immediate needs are lower. Another is delegation, with section commanders running their own situations and escalating only when defined triggers occur. A third is pattern recognition: commanders identify developments resembling earlier incidents and use quicker allocation heuristics.
These approaches often work and reflect real expertise. Problems arise when a situation is unfamiliar, changes faster than historical patterns indicate, or resources are so limited that sections cannot absorb the allocation challenge themselves. When these factors coincide, the incident commander must make novel, high-consequence choices in real time, with incomplete information and without the shortcuts that usually make allocation faster.
AI's contribution to triage support
AI decision support should not take over the allocation choice. Its contribution is to shorten the path to a credible initial assessment and document the development-rate estimates informing the commander.
In the example above, a system using current situation reports, deployment status, and historical development rates for comparable incident types could rank the three situations within seconds. It might place Situation B first because of its current rate of change and projected resource needs in 20 minutes, Situation A second because of casualties and available units, and Situation C on a monitoring list with a defined escalation trigger. This is not the decision. It is an organized starting point. The commander then considers what the system cannot know, including local geography, active inter-agency arrangements, and the reliability of reports from each sector, before allocating resources with less initial analysis.
Making development estimates visible is especially useful. Commanders often hold them as informal judgments. A support system can expose the assumption for review: "the system is assuming a 15-minute escalation window for Situation B based on historical patterns, but I know the wind direction has changed in the last 10 minutes and that assumption may be too conservative." That is the appropriate exchange. The system shows its reasoning, while the commander questions or overrides it.
Where algorithmic triage stops
AI triage support should not be expected to consistently beat experienced commanders. In our emergency response evaluations, its rankings matched commander assessments in roughly 80 to 85% of scenarios. In the remaining 15 to 20%, commanders held context the system lacked, and their rankings were better. The differences were concentrated in unfamiliar incident combinations, local environmental conditions, and inter-agency resource limits absent from the input data.
In practice, triage support is best used to accelerate assessment and provide a structured check on the commander's thinking, not to act as a separate authority. Reaching the same allocation sooner is a benefit. Choosing differently because the commander knows more is also the intended use of judgment the system cannot reproduce. Either result can be correct.
Design becomes unsafe when override is obstructed, certainty is overstated, or the recommendation's assumptions remain hidden. "PRIORITY: Situation B" offers little help. A clearer alternative is "Situation B ranked first based on estimated 18-minute escalation window: confirm or adjust."
Principles for useful triage support
Our exercises and deployments point to several practical design principles. First, keep the ranking separate from its reasoning. Commanders need the result immediately and should be able to inspect the basis, but a busy command post is not suited to reading long explanations while events develop.
Second, show confidence explicitly. A report that is 12 minutes old, paired with a highly variable development rate, deserves less confidence than a current update showing a stable pattern. This helps commanders adjust how heavily they rely on the recommendation.
Third, align update frequency with each situation's development rate. Updating every 60 seconds for an event unfolding over hours creates noise. Updating every 60 seconds for one changing over minutes can be genuinely valuable. The cadence should follow the operational tempo of what the system is tracking.
The accountability question
Emergency commands make life-safety decisions, and the accountability arrangement is clear: the incident commander remains responsible for resource allocation. An AI triage system does not alter that. It supplies information and a suggested ranking; the commander chooses. The system is a command tool, not an autonomous allocator.
This clarity affects more than regulation or liability. It shapes how commanders use the system. Someone who sees the recommendation as input will challenge it and apply it carefully. Someone who believes the system has assumed the allocation role may disengage from assessment, which is precisely what must be avoided. Commanders should keep reasoning through the triage problem rather than defer to an algorithm. The system can make decisions faster and better grounded, but it cannot replace the deliberation that gives them accountability. Good support sharpens command judgment without taking ownership of the choice.