A route preview, a conflict check and an acceptance decision may appear close together in the interface, but they have different jobs. Keeping those responsibilities clear is central to how we are building Aerlattice.
The interface lets someone draw, inspect and compare. The planning engine evaluates a route against the project’s constraints. The local repository retains the project and the results needed to revisit it.
Use the same rules throughout the workflow
An alternative should be checked by the same engine as the original request. Otherwise, a route could look promising in a preview and mean something different when it reaches the decision step.
We also need to know when the underlying project has changed. A route that was workable before an edit needs to be assessed against the information that will support its acceptance.
Make behaviour repeatable
Controlled exercises give us inputs we can repeat while changing one part of the workflow. That makes it easier to investigate whether a difference came from the calculation, the stored data or the way the result was presented.
These boundaries help us improve the application without making every interface change a change to the planning model. They also give us a clearer basis for explaining a result to someone using the software.
