Skip to content

Capacity-Aware Dispatch Optimizer

Tool — instantiates Central Reserve Redeployment

Recommends which reserve unit to commit to which competing front by scoring front priority, response windows, route time, compatibility, local-cover floors, and turnaround into a ranked deployment — while leaving the commit to a human.

When several fronts call for the reserve at once, the hard part is not seeing the situation but choosing — fast, and without stripping one front to save another. Capacity-Aware Dispatch Optimizer is the decision engine for that choice. It takes the competing requests and the reserve's current state and computes a ranked recommendation: which unit to which front, scored against front priority, each front's response window, route time, resource–front compatibility, the local-cover floor that must not be breached, and the turnaround that governs reuse. Its defining move is to fold the archetype's allocation rules — who has priority, what cover is untouchable, which windows are still reachable — into one comparable score, and then to recommend rather than decide: a human keeps the commit. It is the calculator of the trade-off, not the sensor that feeds it or the authority that signs it.

Example

A cloud platform keeps a small reserve of senior on-call engineers who can be pulled across regional teams. At 02:00 three incidents fire nearly at once: a Sev1 payments outage in the east region, a Sev2 elevated error rate in the west, and a Sev3 dashboard glitch. The optimizer scores the possible assignments. Payments outranks the rest on priority and carries the tightest response window (a ~15-minute SLA); the nearest-ready engineer with payments-system access is scored highest for it. Pulling the west region's only remaining on-call to help would breach that region's local-cover floor while its Sev2 is still open, so the optimizer rules that assignment out rather than merely penalizing it. It returns: send Engineer A to payments now, hold Engineer B to keep west covered, and flag that the Sev3 has no reserve to spare and should wait. The incident commander accepts A, but overrides the hold on B — she knows the west Sev2 is about to be handed to a vendor, context the model did not have. The optimizer made the trade-off explicit and fast; the human corrected it on information it lacked.

How it works

What distinguishes this tool from a generic scheduler is how it treats the archetype's rules:

  • Priority as objective, cover as constraint. Front priority drives the score to maximize, but the minimum local-cover floor is a hard constraint — the optimizer will decline to feed a front rather than pull another below its floor.
  • Window feasibility as a filter. Only assignments that actually meet the target front's response window are eligible; a fast-but-too-late unit is excluded, not just discounted.
  • Consume, don't compute, the physics. Route times come from the travel-time model and turnaround from the recall protocol; the optimizer treats them as inputs and reasons over them.
  • Recommend with an override. The output is a ranked, explained recommendation a human can accept or overturn — never an automatic commit.

Tuning parameters

  • Objective weights — how front value trades against arrival speed and cover margin. Weighting priority hard concentrates the reserve on the top front; weighting cover hard spreads protection but may under-serve the crisis.
  • Hard vs soft constraints — whether local-cover and window limits are absolute floors or penalized preferences. Hard floors protect fronts reliably but can leave the decisive front short; soft ones flex but can be quietly eroded.
  • Override friction — how easily an operator can overturn a recommendation. Low friction keeps humans genuinely in control but invites ignoring the tool; high friction leans on the model and courts automation bias.
  • Optimization horizon — myopic (best answer to this wave) versus look-ahead (holding reserve against a probable next front). Look-ahead hedges the future at the cost of the present.
  • Compatibility strictness — how exact the resource-to-front match must be before an assignment is eligible, trading availability against fit.

When it helps, and when it misleads

Its strength is speed and consistency under load: it makes the multi-front trade-off explicit, applies the same rules to every wave, and surfaces the case where honoring cover means a front simply cannot be served — a conflict humans under pressure tend to paper over.

Its failure modes cluster around misplaced trust. The sharpest is automation bias: operators rubber-stamp the recommendation and stop bringing the context the model cannot see, so a confident output quietly becomes an unaccountable decision.[^automationbias] Because the score is only as good as its inputs, bad route-times or miscoded priorities produce recommendations that are confidently wrong. The tool also optimizes whatever proxy it is given — "fastest arrival" can override "right unit for the job" — and, like any model, it is easily run backwards to justify a dispatch already made. The discipline is to keep the human override real and actually exercised, audit the inputs as carefully as the algorithm, and treat the output as an argued recommendation rather than a verdict.

How it implements the components

Capacity-Aware Dispatch Optimizer fills the decision-rule subset — the rules that turn a contested situation into a recommended commitment:

  • front_priority_rule — encodes which front prevails when demands collide; the objective the recommendation maximizes.
  • minimum_local_cover_rule — enforced as a hard floor: no assignment may pull a front below the cover it must retain.
  • response_timing_window — applied as a feasibility filter so only deployments that can actually arrive in time are eligible.

It consumes route times from the Travel-Time Matrix and turnaround/availability from the Recall and Reconstitution Protocol rather than producing them, and it does not display the situation (Multi-Front Dispatch Board), constitute the pool (Strategic Reserve), or hold the release authority (Reserve Release Playbook).

Notes

The archetype's core risk is decision delay eating the time saved by central position — which is exactly what this tool attacks. But the cure has its own edge: a fast recommendation that is reflexively accepted trades delay for automation bias. The optimizer earns its place only where the override is genuine; if humans never overturn it, it has quietly become the unaccountable decision-maker the "human-in-the-loop" design was meant to prevent.