OK, that makes sense. And understood on route vs position. But wouldn't your design still require additional complexity in the system? It would need to keep track of all bad flight plans, and also keep a database of the status of those plans. The controllers would need to update the status to tell the system that they had phoned and cancelled the bad plan. That (small) additional complexity would cost money and add risk.

It sounds to me like the engineers made a design decision between "add handling mechanisms for valid-but-unexpected flight plans" and "ensure we can handle absolutely every valid flight plan"? If so, this is a rare case where I sympathise with the engineering team behind a major IT failure.

Yes, absolutely. And that is the tricky issue. Because the plan was filed with the Eurocontrol’s IFPS system which handed it over to the UK's system.

Flight crew and dispatchers report that flight plans are regularly rejected, and then they need to file a new one. But it sounds like this rejection happens in a layer before the one which failed in this case.

So this is basically a system which is not meant to be able to reject a flight plan, since the plans it receives were already checked and validated.

"We won't need to reject a flight plan as the data we receive will always be perfect!" sounds like an approach to error handling that will lead to these sort of situations.

The issue should have been caught in one of the higher systems, and then the error should have also been handled in a more appropriate way.

Thank you for this. It all makes a lot more sense now.

> The system in question received the flight plan 4 hours before departure time.

This is not true. The plan is transferred 4 hours before it is due to enter UK airspace. Big difference. Flights can already be in the air when the plan is transferred.

> The plan is transferred 4 hours before it is due to enter UK airspace.

You are correct.