What you will learn
- What incident command structure requires from a dashboard
- How unit assignments, objectives, and safety information are displayed
- What the command log records, and why it matters afterwards
- How the dashboard works at a large incident versus a small one
- What field updates need to reach command without delay
What the project is
Incident command organises an incident into functions: operations, planning, logistics, and safety, under one incident commander. The dashboard supports that structure by showing the incident's status, the units assigned to each task or sector, the objectives for the current operational period, safety hazards and accountability, and a log of decisions and changes. The commander reads the dashboard to decide what to do next, and the dashboard records the decision, so the reasoning survives the incident.
The dashboard must scale. A small incident may have three units and one objective; a large incident may have dozens of units across sectors, with staging, rehabilitation, and mutual aid. A dashboard designed only for large incidents will overwhelm a small one, and one designed only for small incidents will collapse at a large one. The working versions show the same structure at both scales, with detail expanding as the incident grows.
Core features
Accountability display is the feature. A commander who cannot see, at a glance, where every unit is and what it is doing does not have command of the incident.
- Incident status view: type, location, scale, and current phase, with the commander's objectives for the period.
- Unit assignment board: units grouped by sector or task, with status and assignment time, updated from the field.
- Personnel accountability: who is on scene, in which sector, with entry and exit tracking for hazardous areas.
- Safety flags: hazards identified, exclusion zones, and safety messages, visible to all command staff.
- Command log: decisions, orders, and changes, timestamped, forming the record for review afterwards.
- Resource requests: staging, mutual aid, and logistics needs, tracked from request to arrival.
- Operational period planning: objectives, assignments, and handover notes for the next commander.
How it is built
Build with incident commanders, in exercises, not from the command structure chart alone. A dashboard that commanders do not use during an exercise will not be used during an incident.
- Command study: observe exercises and real incidents, and learn what information commanders actually ask for, and when.
- Core build: status, assignments, accountability, and log, tested in tabletop exercises first.
- Scale testing: run the dashboard in a large multi-sector exercise, and fix the overload points it reveals.
- Field integration: unit status updates from dispatch and field tools, so the board updates without a scribe retyping radio traffic.
- Handover and review: operational period handover tools, and after-action reporting from the command log.
Tech considerations
The technical priorities are real-time updates, simple interfaces for stressed users, and a log that cannot be rewritten afterwards.
- Real-time updates with low latency, because a command board that lags the incident misleads the commander.
- Simple, large-format displays usable at a command post, on a tablet, and in a vehicle.
- Offline tolerance for field updates, with sync when connectivity returns.
- Immutable command log, so decisions and their timestamps survive review.
- Role-based access for command staff, sector officers, and reviewers, with audit trails.
Challenges to plan for
Command dashboards fail on update lag and on information overload. A board that is out of date, or that buries the decision in data, will be ignored in favour of the radio.
- Update lag: a board updated by a scribe from radio traffic is always behind, and commanders learn to distrust it.
- Overload: a large incident generates more information than any screen can show, and the dashboard must prioritise, not just display.
- Accountability gaps: personnel who enter a hazardous area without being logged create a safety risk the dashboard cannot show.
- Handover loss: a commander change without a structured handover loses the incident's context, and the next commander starts blind.
Who it is for, and honest limits
This fits fire departments, emergency services, and agencies that run incident command at multi-unit incidents. It fits less well for a single-unit response, where a radio and a notebook carry the command function adequately.
It does not command the incident. It supports the commander with a current picture and a record. Command authority, judgement, and accountability remain with the officer in charge, and the dashboard should make their decisions visible, not make them itself.
Frequently asked questions
What is incident command?
A standard structure for managing incidents, with one incident commander and functions for operations, planning, logistics, and safety. It scales from a single unit to a multi-agency response, and the dashboard mirrors that structure.
How does personnel accountability work?
Personnel are logged into sectors on arrival and out on exit, so the commander can see who is where, especially in hazardous areas. Accountability is a safety function first and a record second.
Can the dashboard handle mutual aid?
Yes, mutual aid units are assigned like any other unit, with their home agency recorded. Their status updates should flow through the same board, or the commander loses sight of them.
What happens at a commander handover?
The incoming commander receives the current status, objectives, assignments, and log, through a structured handover view. The handover itself is logged, so the record shows who commanded when.
Is the command log used afterwards?
Yes, for after-action review, training, and, where needed, legal review. That is why the log must be immutable: a log that can be rewritten afterwards cannot support an honest review.