Skip to content

Mutual-Aid Dispatch Board

Coordination tool — instantiates Central Reserve Redeployment

A shared board where every front posts its need and every unit its lendable capacity, matching the two on one live map while locking each committed resource so it can't be promised to two fronts at once.

The reserve is worthless if nobody can see it, and dangerous if two fronts each think it's theirs. Mutual-Aid Dispatch Board is the shared tool that fixes both: one live map on which every front posts what it needs and every unit posts what it can lend, so the pooled and lendable capacity becomes visible and matchable — and, the instant a resource is matched, it is shown as committed so it cannot be handed to a second front demanding it at the same moment. Its defining idea is visible, contention-safe matching across peers: it turns the archetype's slow, fragmented lateral coordination into a fast, transparent exchange, and it guards the one failure a shared pool invites — the same unit promised twice.

Example

A hurricane knocks out power across a region, and a utility mutual-aid network puts its shared line crews on one board. Every affected utility posts its outage state (the fronts); every utility with spare crews posts what it can send (the reserve). Two hard-hit utilities request the same twenty crews within the same few minutes.

Because the board locks a resource the instant it is matched, the first request claims those crews and they immediately show as committed to everyone; the second request is routed to the next available crews rather than double-promised the same ones. The board matches crews to the systems where restoration matters most, keeps every commitment visible so no dispatcher works off a stale assumption, and never lets two fronts leave believing they hold the same twenty trucks.

How it works

What distinguishes the board from a phone tree is that supply, demand, and contention all live in one place:

  • One shared map of needs and offers — every front's request and every unit's lendable capacity on a single live view, so no one has to ring around to discover where slack is.
  • Match requests to capacity — pair a front's need with an available resource explicitly, rather than hoping the right two parties find each other.
  • Lock on commitment — the moment a resource is matched it shows as committed to all, so it is removed from the pool everyone else is drawing on.
  • Throttle simultaneous demand — when several fronts converge on the same scarce capacity at once, the guardrail serializes and caps claims so the pool isn't over-promised in the scramble.

Tuning parameters

  • Membership and reciprocity terms — who is on the board and on what lending terms. A broader pool surges harder but needs more coordination and invites free-riding.
  • Commitment locking — how firmly a match holds a resource, from a soft hold to a hard lock. Firmer prevents double-commit; looser keeps room to re-optimize.
  • Visibility scope — how much of each other's state units can see. More transparency coordinates better but raises privacy and competitive concerns.
  • Match automation — manual claim versus automatic matching. Auto is faster; manual keeps human judgment on the awkward cases.
  • Guardrail strictness — how conservatively simultaneous demand is capped and buffered. Stricter avoids over-commitment but can leave usable capacity parked.

When it helps, and when it misleads

Its strength is making a shared reserve both visible and contention-safe. It replaces the slow, fragmented peer coordination the archetype flags with a fast transparent exchange, and it forecloses the specific accident a common pool invites — the same crew, cache, or team committed to two fronts who each planned around it.[1]

Its failure modes are the commons kind. If every front leans on the board and keeps no local reserve of its own, a correlated disaster that hits everyone at once finds the board empty exactly when it is needed most. Stale postings corrupt matches — a crew shown available that is already deployed sends a front chasing help that isn't there. And the classic misuse is gaming the board: posting inflated need to claim more than a fair share of the shared pool. The discipline is real-time locking, fresh postings, and reciprocity rules that keep the pool from being quietly drained by its heaviest users.

How it implements the components

Mutual-Aid Dispatch Board fills the visibility-and-contention side of the archetype — seeing the shared pool and keeping it from being over-promised:

  • multi_front_state_map — the board is the shared live map of every front's need and every unit's available or lendable capacity.
  • simultaneous_demand_guardrail — it locks committed resources visibly and serializes competing claims, so the same unit is never promised to two fronts converging at once.

It does not hold the authority to commit the reserve — that is Incident Command Structure; it does not own the authoritative operating record or coordinate the physical handoff — that is the Dispatch Center; and it does not set which front outranks which — that is the Logistics Routing Plan.

Notes

A mutual-aid board is a peer instrument: fronts both draw from and lend to the shared pool, and its authority is the transparency of commitments rather than a chain of command. That is what sets it apart from the Dispatch Center, which is a central hub that commands the reserve. The two compose well — the board surfaces where the slack and the need are; the center and its authority decide and execute the move.

References

[1] Real mutual-aid frameworks — the interstate Emergency Management Assistance Compact among U.S. states, or utility and fire-service mutual-aid agreements — pre-arrange the reciprocity and visibility that let members lend scarce capacity to whichever member is hardest hit. The board is the operational surface such a compact runs on. ↩