From Artificial Intelligence to Augmented Intelligence
The question that shaped the last decade was how capable a machine can become on its own. The question that shapes the next one is how much of that capability can be delivered into human perception and judgment without displacing the person who remains accountable for the outcome.
Why this matters
Most model progress is measured in isolation: a benchmark, a dataset, a task with a known answer. Consequential work rarely arrives that way. It arrives partially observed, time-bounded, and with a person who has to justify what happens next.
When a system is evaluated only on its standalone output, the handoff to the human becomes an afterthought. The result is capability that exists on paper and evaporates in use, because the operator cannot see how the conclusion was formed, cannot correct it quickly, and cannot defend it afterward.
Augmented intelligence treats that handoff as the product. The relevant unit of performance is not the model's answer, it is the quality and speed of the decision a person can make with it.
The OODA perspective
OODA is engineering systems on the assumption that human authority is a design constraint, not a limitation to be removed. A system that produces a better answer no one can act on has produced nothing.
That framing changes where engineering effort goes. Instead of optimizing a single output, the work concentrates on perception, context, explanation, and the boundary where a person approves, adjusts, or refuses an action.
It also changes what counts as a failure. A confident, unattributable recommendation is a failure even when it happens to be right, because it cannot be trusted the next time the situation is unfamiliar.
Design & engineering implications
- Implication 01
Design the handoff before the model
The interface between machine output and human judgment should be specified first: what is asserted, what is uncertain, what evidence is attached, and what the person is being asked to do. Model selection follows from that specification rather than preceding it.
- Implication 02
Make provenance a first-class field
Every assertion surfaced to an operator should carry where it came from and when. Provenance is what allows a decision to be revisited, corrected, and explained later, and it is far harder to retrofit than to carry through from the start.
- Implication 03
Measure the loop, not the output
Evaluation should target the full cycle a person completes with the system, including time to understanding and rate of correction, rather than only isolated output accuracy.
- Implication 04
Keep approval boundaries explicit and reversible
Where a system can act, the boundary of that authority should be declared in the architecture, visible in the interface, and reversible in practice. Implicit autonomy is the most expensive kind to unwind.
Questions under active investigation
- How should uncertainty be presented so it changes behavior appropriately rather than being read as noise or as false precision?
- Which parts of understanding can be delegated to a system without eroding the operator's own situational model over time?
- What evaluation design distinguishes genuine augmentation from an operator who has simply learned to defer?
Where this goes next
This is a working position, developed further in the context of a specific program rather than in the abstract. The OAIA framework is where it becomes an architecture, and research and development is where the open questions are pursued.