I’ll have the Autonomy, Please.

Autonomy developers possess a crucial understanding that eludes many technical thought leaders: autonomy should be utilized as an adjective, not a noun. It's akin to desiring some "blue" without specifying what kind or how much. When we say we want autonomy, we must clarify in what aspect we seek autonomy. Do we want an autonomous drone? If so, what specific actions should it perform autonomously? Should it self-actuate, make decisions, detect inputs, or determine which inputs to ignore?

Several years ago, a scientist by the name of Bruce Clough at the Air Force Research Labs published a paper titled "Metrics, Schmetrics! How The Heck Do You Determine A UAV's Autonomy Anyway," which outlined a methodology for conceptualizing autonomy using the OODA loop (Observe, Orient, Decide, Act). Each component of the loop was assigned a score from 1 to 10, indicating the desired level of autonomy. To measure autonomy, one must simply determine which functions should observe inputs, orient themselves based on inputs, make decisions based on inputs, or take action based on decisions. Should autonomy follow pre-programmed rules, seek permission, adapt based on past outcomes, or collaborate with other systems like a team or tribe?

The new approach to expressing autonomy requests involves stating, for instance, "I want an autonomous solution that observes, orients, and provides landing site recommendations to my UAV. If the pilot fails to make a decision within 10 seconds, the recommended landing site will be executed." This clearly defines the desired autonomy and resembles a system specification requirement, as it should. Autonomy is an adjective that necessitates specification. How much autonomy is needed? Autonomy in which specific function? It is not possible to simply order autonomy along with a side of fries. Autonomy must be custom-ordered, a la carte.