Aerlattice is a working desktop demonstrator. It can hold flight requests, check them against the information in an exercise, compare alternatives and record decisions. Those are useful things to show, but they leave an important question open: how well would the application support a team doing this work for real?
We don’t have an operational validation claim to make today. Getting there requires examining the application beyond the scenarios we supply with it.
Test the assumptions behind the workflow
An exercise begins with a set of known inputs. A real evaluation would need to look at incomplete information, changing plans and the different ways people interpret a finding.
Some questions are about the calculations. Others are about the person using them. Can a reviewer tell which inputs a check used? Do they understand what remains uncertain? Can they distinguish an accepted plan from a proposed replacement?
A feature working as designed is only part of the answer. The design itself needs scrutiny.
Check how the application handles problems
Reliability includes what happens when something goes wrong. A lost feed, an interrupted session or an unfamiliar import should leave the user able to understand the state of their work.
Aerlattice already keeps local project records, decisions and recordings, with complete workspace backups. Those capabilities provide a starting point for evaluating recovery and repeatability. They don’t, by themselves, establish readiness for every environment.
Let the evidence set the next step
Representative user studies and operational validation remain work ahead. We’ll need to learn from those results before making broader claims about suitability.
For now, the project page describes the demonstrator as it exists. It’s a place to inspect the workflow and understand its limits, including that Aerlattice does not command aircraft or grant flight clearance.
