Zora Air flies autonomous drone missions in simulation

What Zora is

Zora is Bynn’s mission executive and autonomy engine for autonomous systems. It is the intelligence behind an autonomous system, not the vehicle. It connects a mission objective with perception, decisions, planning and execution, starting with aerial missions. The family has three branches: Zora Air, which flies missions in simulation today, and Zora Ground and Zora Robotics, which share the same engine and are planned.

How a mission is composed

Missions are built as graphs of nodes in Mission Control’s mission editor. The nodes are the steps of a flight: take off, check surroundings, look for, approach, fly through, navigate, land on, decide and check. A node names its target in plain words the camera model can recognize, such as “the purple octagonal gate opening”, and can carry a time limit, after which it leaves through timeout.

Every node leaves through one of four outputs: done, failed, timeout or unsure. An operator can wire each output to the next step or to a fallback, or leave it to the engine’s built-in recovery. Single-path missions fly today; branching execution, in which a Decide node lets DecisionNode choose the branch, is next.

How a mission is flown

Once a mission starts, it never pauses for the operator. The work is divided between three parts.

DecisionNode decides

Tactical questions about each camera frame go to DecisionNode: where is the target, is the path clear, have we passed the opening, how risky is the next move. The questions are asked two at a time and bound to the exact frame they concern. Answers that arrive late, out of order or from a model that is not approved are dropped. Risk lowers speed, and lower confidence selects more conservative behaviour. DecisionNode’s answers steer the mission; they never command the motors directly.

The mission executive coordinates

The mission executive runs the phases of the mission, its time budgets and its recovery. When confidence is low, a target is lost or an answer fails, it climbs a recovery ladder of its own: hold and re-observe, back off, climb, search wider, approach from another side, re-plan. A mission ends only on success, an operator Stop, its time budget, camera loss or an exhausted recovery ladder, and the engine flies the fallback itself.

The autonomy engine executes

Between answers, a fast local tracker follows the target on every frame and is re-anchored by each confirmed DecisionNode fix. Motion is planned as segments metres ahead and retargeted in flight as new answers arrive, with control at 20 Hz and jerk-limited velocity shaping, instead of stop-and-go steps. The vehicle adapter streams short-lease setpoints: if the stream stops for any reason, the vehicle receives zero input. Existing flight and robot controllers keep their stabilisation and hardware emergency duties. The model proposes; Zora, running locally, keeps mission and execution authority.

What the simulation demonstrates

Zora Air flies its missions in a third-party drone simulator. The demonstrated missions include take-off, observation, obstacle traversal and landing. In the obstacle course, for example, the mission is to take off, find a purple octagonal gate, fly through its opening, then find an orange H landing pad beyond it and land on the pad, with no operator input once the mission starts.

Every run is recorded: its trace, every camera frame, the questions asked, and a summary with the phases, recovery events, latency and motion continuity. That record is what makes a run inspectable after the fact, which matters as much as the flight itself.

What it means for an enterprise buyer

Most organizations will not buy an autonomy engine this year. Many are already putting enterprise AI into processes where a model’s output triggers an action, and the questions Zora is built around apply to them directly:

• Where does authority sit? In Zora, the model answers questions and the local engine decides what to execute. A model output should be an input to a checked action, not the action itself.
• What happens on low confidence? A defined recovery path, chosen in advance, is safer than a system that stops and waits, or one that proceeds regardless.
• What is recorded? If you cannot replay what the system saw, asked and did, you cannot audit it or improve it.

The same division of labour, a decision engine answering bounded questions inside a process that keeps control, is how DecisionNode is used in software workflows, from routing work to checking an AI agent’s proposed actions before they run.

Where Zora is heading

Search and rescue gives autonomous systems a clear purpose: helping people when reaching them is difficult. We are developing Zora for applications including search and rescue, firefighting and infrastructure inspection. These are development directions; the current demonstrations are in simulation and form part of our work toward systems that can carry out useful missions in the physical world.

Limits and caveats

• Simulation only. Physical vehicles and onboard computers are not yet implemented, and no field deployment is claimed.
• Zora is an experimental research platform, not a product on sale. Zora Ground and Zora Robotics are planned.
• Single-path missions fly today; branching execution is not yet available.
• Simulated conditions are simpler than the physical world. Results in simulation do not establish performance in the field.

Read more

The Zora page describes the engine and its status. DecisionNode, the decision model Zora consults, is described on the DecisionNode page, and our research results, each labelled by type of evidence, are on the research page. If your organization is putting AI into processes that act, see how we approach enterprise AI.