Skip to content

Multi-Front Dispatch Board

Monitor — instantiates Central Reserve Redeployment

A live shared display of competing front requests, current reserve positions, route state, and arrival estimates — with unresolved allocation conflicts flagged — so the reserve is committed against one common picture rather than scattered reports.

A central reserve is only as good as the allocator's grasp of where it is needed and where it currently sits — and in a fast multi-front situation that grasp usually arrives as a dozen phone calls with incompatible information. Multi-Front Dispatch Board is the shared, live display that replaces those calls with one picture: every front's request and severity along one edge, the reserve's current positions and commitments along another, the health of the routes between them, and the arrival estimate for each candidate move. Its defining contribution is shared visibility of contention — it does not just show status, it flags where two fronts are reaching for the same reserve package and which conflicts are still unresolved. It is a window, not a decision: it makes the situation legible so a human (or the optimizer) can choose well, but it chooses nothing itself.

Example

A freight railroad runs its reserve of relief locomotive power and standby "recrew" pools from a network operations center. On a bad afternoon the board lights up with several fronts at once: two hump yards are short of crews and backing up, a third has a mechanical failure blocking a departure track, and a mainline subdivision has a derailment fouling both tracks. The board shows each trouble spot's severity and what it is asking for (the front state), where every reserve locomotive set and recrew pool currently is and what is already committed (the operating state), and which subdivisions are fluid, congested, or out of service (the route state) — plus the ETA of each reserve package to each front. It then flags the collision: the derailment site and one of the yards are both requesting the same recrew pool, and only one can have it. Seeing that conflict surfaced in one place — rather than as two dispatchers lobbying by phone with half the picture — the controller commits the pool to the derailment, which is throttling the whole corridor, and reroutes power to the yard the long way around. The board did not make that call; it made the call makeable.

How it works

What distinguishes this board from a generic status wall is that it is built as an allocation surface:

  • One integrated picture. Front requests, reserve positions, route health, and arrival estimates are fused into a single view, rather than living in separate systems the allocator has to reconcile in their head.
  • Contention made visible. The board's signature feature is highlighting conflicts — two fronts contending for one package, a commitment that would breach cover — instead of merely listing statuses.
  • Read-mostly and shared. It is a common operating picture many parties watch at once, not a private worksheet, so everyone argues from the same facts.[^cop]
  • Show, don't solve. It surfaces the arrival estimates and route states it is fed; it does not compute them or decide from them.

Tuning parameters

  • Refresh latency — how live the picture is. Real-time feeds support sharper decisions but cost more and can flood the board with noise; periodic snapshots are calmer but can be dangerously stale in a fast situation.
  • Aggregation level — one system-wide board versus per-region drill-downs. Aggregate views serve the allocator's concentration decision; detailed views serve the operators executing it.
  • Conflict-surfacing sensitivity — how aggressively contested packages and cover breaches are flagged. Too eager breeds alarm fatigue; too lax lets collisions slip through unseen.
  • Information scope — front and reserve state only, or also route health and ETAs. A richer picture is more decision-ready but risks clutter that buries the one fact that matters.
  • Shared access — whether only the central controller sees it or every front does. Shared visibility cuts phone lobbying but can tempt fronts to overstate need to move up the board.

When it helps, and when it misleads

Its strength is that a single shared picture beats a flurry of partial reports: it surfaces the contested-reserve conflict early, grounds the concentration decision in one version of the truth, and lets the allocator see at a glance which front is actually throttling the system.

Its failure modes follow from its being a display. A board is only as true as its feeds — a wrong reserve position or a stale route status yields a confident, wrong allocation — and a polished screen can manufacture an illusion of control, where a situation feels handled because it is rendered neatly, not because it is resolved. Rich dashboards also invite watching in place of deciding. The characteristic misuse is letting the board become status theater for onlookers rather than a working surface for the allocator. The discipline is to instrument the freshness of every feed, treat each unresolved-conflict flag as an action item with an owner rather than a decoration, and keep the board pointed at the decision rather than at the audience.

How it implements the components

Multi-Front Dispatch Board fills the shared-visibility subset — the live picture the allocation decision reads from:

  • multi_front_state_map — displays each front's condition and request, so competing needs are seen side by side.
  • multi_front_operating_state — shows where the reserve currently is and what is committed versus available across the fronts.
  • route_capacity_and_health_map — surfaces the state of the routes the reserve must travel — fluid, congested, or closed — that gates every move.

It displays but does not decide (Capacity-Aware Dispatch Optimizer), does not estimate the arrival times it shows (Travel-Time Matrix), and does not constitute the pool (Strategic Reserve); the conflicts it flags are resolved by the optimizer and the release authority, not on the board.

Notes

Among the archetype's several display-and-dispatch siblings, this board occupies a specific lane: it is the allocation decision surface for the central reserve — competing requests, reserve packages, and the conflicts between them — rather than a general utilization dashboard or the staffed room that acts on it. Keeping it read-mostly is deliberate: the moment a board also commits resources, its feed errors turn into dispatch errors with no human check between them.