A map can show a proposed route, a simulated aircraft or a recorded observation. 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. Flight commands and clearance stay with the operator and their systems.
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.
These details matter because moving aircraft on a map should be read for what they are: positions to plan around.
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 is planning, simulation and human review, and the demonstrator should be judged within that scope.
