The deciding feature may be the record you can recover after something goes wrong.
Autopilot comparisons often become contests of supported vehicles and features. Those lists matter, but procurement and operations need a second view: how the system explains itself. Can a team reproduce a configuration, simulate the behavior, inspect state transitions, export logs, test failsafes, and maintain a known version over time?
Build an evidence matrix around the mission. Compare configuration control, log depth and tooling, simulation path, ground-control compatibility, payload interface, developer documentation, release practice, security response, and support community. Then apply minimum gates for the evidence the operation cannot function without.
Editorial infographic: Configure → Simulate → Log → Support. The diagram is a planning aid, not a certification or regulatory determination.
A four-part decision lens
- Define mission-critical evidence. Make the condition visible in the same record used for the decision.
- Test configuration export and restore. Assign an owner and state what evidence will count as completion.
- Replay representative logs. Keep assumptions separate from observed or approved facts.
- Exercise simulation and failsafes. Test the exception path, not only the preferred operating case.
- Assess release and support lifecycle. Review whether the control changed the next real decision.
What this looks like in the field
Two stacks both fly the target route. One lets the team reproduce parameters, replay the event, trace mode changes, and validate a fix in simulation. The other satisfies the demonstration but leaves the operator dependent on a supplier summary. The technical feature gap is small; the assurance gap is large.
The management value lies in the boundary between one state and the next. A team must be able to see why an item moved from observation to action, from action to restriction, or from restriction to closure. If the transition has no named authority and no retained basis, the label is only decoration.
Governance before automation
Do not declare a universal winner. The evidence matrix depends on vehicle type, team skill, mission consequence, certification path, integration ownership, and support model. Record the version and date of every comparison because open-source projects evolve.
Begin automation with an exception map rather than a feature list. Identify what may proceed normally, what requires review, what must stop, and which person can release it. Software can then surface deadlines and missing evidence without pretending to make the consequential judgment.
The practical test
Select a closed case and remove the people who remember it from the review. Ask a new reader to reproduce the sequence and identify the closure evidence. Any answer that begins with “I think” identifies a field, timestamp, or approval trail that the process failed to preserve.
Put it to work this week
Choose the most recent exception in this topic. Write its starting condition, decision clock, owner, evidence requirement, and closure rule on one page. Test the page with a second person and change the one line that creates the longest argument.
For this topic, use “Define mission-critical evidence” as the opening prompt and “Assess release and support lifecycle” as the closure check. Keep both the original and revised record so the team can see whether the intervention reduced ambiguity rather than merely changing vocabulary.
Autopilot selection is a lifecycle decision about what the organization will be able to know, not only what the aircraft can do today.
For the wider workflow, see the related Flight Stack field note and the UAM KoreaTech books and workbooks.
Source and scope note
This column adapts a decision framework from the Dronology series and Mission Companion release notes. It is educational and vendor-neutral. It does not replace site-specific safety assessment, procurement law, aviation authorization, technical instructions, or professional advice. Useful primary starting points include:
