v1.0.0

Recovery Strategies

Configure which recovery strategies the solver evaluates.


Overview

The strategies field in SolverConfig determines which recovery approaches the solver explores. Each strategy runs as an independent optimisation pass, and the results are returned as separate options ranked by cost.

By default, all four strategies are enabled:

json
{
  "strategies": ["delay", "cancel", "swap", "cancel_tail"]
}

Available Strategies

delay

Propagate the delay through the schedule without any cancellations or aircraft swaps. Every flight remains on its original aircraft. This is the most conservative approach.

Constraints applied:

  • The disrupted flight is delayed by at least the specified min_delay_minutes
  • No flights may be cancelled
  • No aircraft swaps are permitted

cancel

Allow flight cancellations on the disrupted aircraft's line of flying. If the delay exceeds the reaccom_window, the disrupted flight itself is cancelled.

Constraints applied:

  • At least one cancellation on the disrupted tail's flight line
  • No aircraft swaps on the disrupted tail

swap

Allow aircraft swaps across compatible tails (same aircraft type) while delaying the disrupted flight. This enables the solver to shift aircraft assignments to minimise downstream impact.

Constraints applied:

  • The disrupted flight is delayed by the minimum delay
  • At least one aircraft swap must occur

cancel_tail

Cancel all remaining flights on the disrupted aircraft's tail from the disruption point onwards. Flights before the disruption are unaffected.

Constraints applied:

  • All flights on the disrupted tail at or after the disrupted flight's departure are cancelled
  • Pre-disruption flights remain on their original tail

Choosing Strategies

Including more strategies gives the solver a wider solution space and generally produces better results, at the cost of longer computation time. Each strategy runs independently.

Minimal configuration

If you only want to see delay and swap options:

json
{
  "strategies": ["delay", "swap"]
}

Must-cancel scenarios

When the delay exceeds the reaccom_window (default 12 hours), the delay and swap strategies are automatically skipped, and the solver focuses on cancellation-based approaches.