A reviewer needs to understand more than whether a flight request passes a check. They need to know which route was examined, what information the check used and how a proposed change would affect the plan.
That is why we are designing Aerlattice around the relationship between a request, its assessment and the decision made about it.
Keep the assessment tied to the route
A request includes waypoint positions, heights, timing and aircraft limits. Changing any of those can change the result. A useful workflow should make it clear when an assessment belongs to an earlier version and another check is needed.
Findings also need a place and a time. A reviewer should be able to locate the overlap that caused a warning and compare ways to resolve it, including a different route, departure or radio-channel assignment.
Preserve the accepted plan while considering a change
A proposed replacement should stay separate while it is examined. Otherwise, the person reviewing it may lose track of which route is already accepted and which is still a suggestion.
Our design keeps the choice explicit and retains the information behind it. The aim is a record that helps someone understand the decision when they return to the workspace.
