A map can show a proposed route, a simulated aircraft or a position received from an external source. Those things may look similar on screen, but they tell the user different things.
Aerlattice is built around planning and review. Its main output is a request that has been checked and considered by a person. It does not send flight commands to an aircraft or grant clearance to fly.
A plan describes an intention
A planned route sets out where an aircraft is expected to be and when. Checking it means comparing that intention with the information available in the workspace, including other requests and restrictions.
An accepted plan is still a plan. During an exercise, observed or simulated positions may depart from it. Keeping that distinction visible helps a reviewer understand whether they are examining the intention, the observations or a proposed change.
What the monitoring features do
Aerlattice can run exercises and replay recordings on a shared timeline. It can show alerts for route deviations, feed loss and projected collisions. A suggested replacement route stays a draft until it is reviewed.
The optional MAVLink connection receives simulator telemetry. It is receive-only. The optional ADS-B layer displays external aircraft when an internet connection is available. Neither feature turns the application into an aircraft controller.
These details matter because the presence of moving aircraft on a map can otherwise suggest more authority than the software has.
How to read the demonstrator
When looking at a scenario, start by identifying the source of the positions and the purpose of the view. Is it showing a plan, a simulation or received observations? What does accepting a request do within that workflow?
For Aerlattice, the answer remains planning, simulation and human review. Operational validation is work ahead, and the demonstrator should be evaluated within that scope.
