run_idstring uuid required
batch_idstring uuid nullable required
world_slugstring required
paddockstring nullable required
autonomy_host'bench' | 'jetson'
simulator_hoststring nullable
runner_launch_mode'worker' | 'command'
mission_configobject nullable
mission_plan_idstring uuid nullable
mission_plan_revisioninteger nullable
claim_tokenstring uuid nullable
lease_expires_atstring date-time nullable
dispatch'launch' | 'headless' required
How a simulated run reaches an aircraft, and therefore who authorises it.
LAUNCH is the ordinary path and the only one that flies anything: the run
schedules a mission request exactly as the customer app does, a pilot signs
the JSA and presses LAUNCH, and the dock delivers. FleetOps adds nothing to
that sequence and skips nothing in it.
HEADLESS never asks a dock for anything. The bench composes the same
mission config from the same farm and runs it against a stub dock, so there
is no clearance to grant, no aircraft to arm and nothing to authorise --
which is why there is no JSA on it. A sweep of two hundred seeds is this
one; a run you want a flight record for is the other.
state'pending' | 'requested' | 'claimed' | 'running' | 'succeeded' | 'failed' | 'cancelled' required
Where one cell of a sweep has got to.
PENDING through FINISHED is the bench's own progress. REQUESTED is where a
LAUNCH run waits: its mission request exists and the pilot's queue owns it
from there, so FleetOps deliberately stops describing it -- the request's
own state is the answer, and a copy here would be a second one.
mission_request_idstring uuid nullable required
simulation_run_idstring uuid nullable required
claimed_bystring nullable required
claimed_atstring date-time nullable required
started_atstring date-time nullable required
finished_atstring date-time nullable required
outcomeobject nullable required
failurestring nullable required
created_bystring required
created_atstring date-time required