ValkyrieOS

The command layer, built first

Platform-independent command-and-control and mission autonomy for heterogeneous uncrewed vehicles. A non-lethal, simulation-first demonstrator today, at TRL 3 to 4, verified and replayable.

What it is

ValkyrieOS is the command layer for the Valkyrie programme: a platform-independent command-and-control and mission-autonomy system for heterogeneous uncrewed vehicles. It exists today as a non-lethal, simulation-first demonstrator at TRL 3 to 4. One operator commands a fleet of simulated heterogeneous UAS; the system allocates tasks, absorbs a link loss, re-tasks, and records every decision in a log from which the whole mission replays. New vehicle types enter by capability descriptor only, and leaking platform behaviour into the core is treated as a defect.

What V0 demonstrates

One operator. A fleet of simulated heterogeneous UAS. Observation zones to cover. Cost-based task allocation across the fleet. A mid-mission link loss to one asset. Re-tasking that preserves coverage, or states its shortfall when it cannot. Permanent operator authority throughout: approve, override, pause, abort, nudge. A Safety Governor that blocks non-compliant actions rather than warning about them. And an append-only, hash-linked event log from which any mission replays deterministically. Those nine beats are the requirements spine, and the demonstrator is verified against them.

What V1 adds

V1 draws the boundary between the command layer and the vehicle, and proves it with real autopilot software in the loop.

• A versioned vehicle-descriptor contract, and a formal vehicle adapter boundary.
• A MAVLink adapter that has driven real autopilot software in the loop (ArduPilot SITL) with the same command layer.
• Mixed simulated and SITL fleets.
• A range-based comms model that distinguishes a lossy link from an absent one.
• A twenty-asset performance budget.
• An operator-session mode for structured feedback.
• Data shapes aligned to STANAG 4586 at the boundaries. Alignment, never compliance.
• A two-run After-Action comparison, and export signing.

Design principles

Non-lethal by construction

The demonstrator is non-lethal by construction, not by configuration. The Safety Governor blocks non-compliant actions rather than warning about them.

Determinism

Same log, same mission. Any run replays deterministically, and a replay that differs from its log is a defect.

The event log as the spine

The append-only, hash-linked event log is the system of record. The After-Action Review replays it rather than summarising it.

Operator authority

The operator's authority is permanent: approve, override, pause, abort, nudge. Autonomy proposes and carries out; it does not remove the operator from the loop.

Drone-agnostic by descriptor

New vehicle types enter by capability descriptor only. Leaking platform behaviour into the core is treated as a defect.

Simulation honesty

Degraded conditions are modelled, not physically real, and the software says so. What is simulated is labelled as simulated.

The evidence

Five screens from the demonstrator, and the signed log they replay from.

Mission composer

Zones, fleet and constraints, set before the run.

Command map

The fleet, the zones and the allocation, live.

Asset panel

Each asset's state, link and task.

Mission execution

The link loss, the re-tasking, and the operator's controls.

After-Action Review

The mission replayed from its log, decision by decision.

Any mission replays deterministically from its signed, hash-linked log.

Standing questions

The questions we most want validators to press on. They are open, not rhetorical.

• Comms-model fidelity: what does the link model need before an operator finds the degradation beat credible?
• Allocation: does the contract-net auction earn its keep at five assets, or does the exact solver do the real work?
• Shortfall computability: at what fleet and zone count does the coverage shortfall stop being computable in useful time?
• Descriptor survival: does the capability-descriptor pattern survive a genuinely different vehicle?
• Event taxonomy: what is the minimum event set an experimentation assessor expects to see replayed?
• Control set: is approve, override, pause, abort, nudge the right operator control set, or merely the easy one?

Press on it

If you assess autonomy for a living and one of these questions has an answer we will not like, we want to hear it.