It’s easy to say that a person remains involved when software is doing more of the work. The practical details matter: what can that person see, what can they change, and what happens before they have made a decision?
In Aerlattice, we make the review step explicit. The application checks requests and offers alternatives. A person reviews the result and records a decision.
Give suggestions a visible basis
A proposed change needs to be connected to the problem it is meant to address. Moving a departure time, for example, should be considered alongside the conflict, the mission window and the assessment of the revised request.
Aerlattice reports findings in space and time and checks saved drafts before review. This lets the reviewer examine the suggestion in the context of the plan.
A review note then records the reason for accepting, rejecting or pre-empting a request. The useful record includes the decision and the information it concerned.
Preserve the decision point
An accepted revision stays fixed until an explicit replacement decision. During an exercise, suggested replacement routes remain drafts.
This distinction matters because a suggestion can otherwise appear to become the plan simply by appearing on screen. Keeping it as a draft gives the person reviewing it a clear choice and leaves the accepted version identifiable.
The application also keeps decisions with the rest of the local project record, so that choice can be revisited later.
Describe what the software actually does
Terms such as “human in the loop” and “human on the loop” can leave room for different interpretations. For this product, the useful explanation is the workflow itself: software checks and suggests; a person reviews and decides.
That decision belongs to the demonstrator’s planning process. Aerlattice does not grant flight clearance or send commands to aircraft. Its current role is to help people examine plans and their alternatives.
