Flight Dispatch Decision System

A dispatch request arrives with five top-level blocks - weather, aircraft, manifest, crew, and flight - and every safety gate downstream reads directly from fields like weather.windSpeed, aircraft.fuelReserves, and manifest.cargoWeight.

Before any gate runs, this step derives the load figures: totalPassengers counts manifest.passengers, passengerWeight applies a flat 85 per head, and estimatedTakeoffWeight adds aircraft.emptyWeight, totalCargo, and passengerWeight together. Using a standard mass of 85 instead of weighing individuals mirrors the standard-passenger-mass method airlines use in load planning, and the resulting figure feeds the weight gate directly.

One comparison settles the load check: when estimatedTakeoffWeight exceeds aircraft.maxTakeoffWeight the flag goes false with 'Aircraft exceeds maximum takeoff weight', otherwise the flight passes with 'Weight within acceptable limits'. Comparing against certified maximum takeoff weight is exactly how load control signs off a departure, since exceeding it invalidates the performance and certification basis of the aircraft.

Legality of the crew resolves in order: crew.restCompliant equal to false trips 'Crew rest requirements not met', a computed len(crew.members) below 2 trips 'Insufficient crew members', and otherwise the table returns 'Crew requirements satisfied'.

Rest is checked first because flight and duty time limitation schemes such as FAA Part 117 make an unrested crew member ineligible no matter how many people are rostered. The floor of 2 reflects the two-pilot flight deck required on transport-category aircraft; a production system would also count required cabin crew against seat count, so this is a deliberately minimal staffing check.

Airworthiness comes down to two gates evaluated with first hit ordering: aircraft.maintenanceRequired set to true fails immediately with 'Aircraft requires maintenance', then aircraft.fuelReserves below 1 fails with 'Insufficient fuel reserves', and the final row confirms 'Aircraft is operational'.

Checking open maintenance before fuel matches line-maintenance practice, where a reported defect must be cleared or deferred under the minimum equipment list before the aircraft can be released. Requiring reserves of at least 1 echoes the final-reserve idea in fuel planning, but the exact threshold is a simplified stand-in for the fuller fuel policy an operator would actually file.

Wind and visibility are screened together under a first hit policy, ordered from the worst combination down. A weather.windSpeed above 45 with weather.visibility under 10000 fails as 'Extreme wind and low visibility', wind above 45 alone fails because 'Winds exceed aircraft limitations', wind above 35 paired with visibility below 5000 fails as 'High winds with low visibility', and visibility below 1000 fails on its own. Only when no restrictive row matches does the catch-all set dispatch.weather.flag to true with 'Weather conditions acceptable'.

Layered wind and visibility gates mirror how dispatchers apply operating minima: strong winds alone can exceed a type's demonstrated crosswind capability, while marginal winds only become disqualifying once visibility also degrades. A hard visibility floor reflects the takeoff-minima concept from instrument procedures, though the specific 45/35 and 10000/5000/1000 breakpoints here are conservative business choices rather than values from any particular regulation.

The verdict is assembled by folding the four gates together: isDispatchable holds only when all(values(dispatch), #.flag) is true, dispatchReasons and failedCriteria collect the sections whose flag is false, and dispatchSummary renders either 'Flight is cleared for dispatch' or 'Flight dispatch denied'. Surfacing which criteria failed, not just a boolean, is what lets a dispatcher act on the result instead of re-checking every input by hand.