FlightStudioFlightStudioOpen dashboard
The FlightStudio ecosystem

Three layers. One mission record.

The authority, the operator and the aircraft should not live in three separate systems. FlightStudio covers all three without putting a vendor cloud in the middle — one data model, one security boundary, one evidence trail. Two of the three layers are Preview. This page says which parts of them run today and which do not.

One operational record
MissionAuthorisationAircraft TelemetryEvidence

The same record, written once and read by every layer. No export step between planning and evidence, and no copy of it on infrastructure you do not run.

01

FlightStudio

Govern · Airspace & UTM core

The authority layer. Strategic deconfliction, authorisation, risk assessment, Remote ID, geozones and conformance monitoring — and the evidence trail that every other layer writes into.

Explore the platform Standards ledger
Running today
  • ASTM F3548-21 strategic deconfliction against a DSS.
  • ASTM F3411 Remote ID, network and broadcast intake.
  • ED-269 geozone authoring, lifecycle and breach evaluation.
  • JARUS SORA 2.5 risk assessment with the SAIL matrix.
  • Conformance monitoring against the granted authorisation.
  • Tenant-isolated audit evidence for every state change.
Where it stops
  • SORA 2.5 and ED-269 are Beta — the maturity ledger on /trust is the single source for every label on this site.
  • Non-cooperative traffic detection is Planned; the platform shows only what is choosing to broadcast, and says so on the traffic screen.
  • Certification is not claimed. The positioning is verified, not certified.
02

FlightDesk Preview

Operate · Operator & dispatch workspace

The operator layer. Plan a mission, assign the aircraft and the crew, run readiness, then supervise the flight against the authorisation it was granted — without re-keying any of it into a second system.

See the operations surfaces
Running today
  • Mission planning and the mission record, in the FlightStudio console.
  • Fleet and aircraft assignment.
  • Operator and crew records, with role-based access.
  • Live supervision on the operations board and the map.
  • Readiness checks bound to the mission, not to a spreadsheet.
Where it stops
  • FlightDesk Node is not built. The standalone field workstation — the one that keeps a crew working through a network outage and reconciles when the link returns — is designed and not yet released.
  • Everything above runs inside the FlightStudio console. FlightDesk is today a workspace within it, not a separate application.
  • There is no scheduler. Missions are planned and dispatched; they are not queued and executed automatically.
Enrolment
FlightDesk Node will use the same vendor-neutral Edge v1 certificate flow as DJI Studio Link — one enrolment path, not one per device family.
Offline
Store-and-forward against an intermittent link, delivered in order on reconnect. Proven today by the MAVLink edge gateway; not yet by a Node.
One security boundary

What "no vendor cloud in the middle" actually means.

  • One identity model. A person authenticates with a token; a controller authenticates with a certificate. Both resolve to the same tenant, and every write is scoped to it by the database itself, not by application code remembering to filter.
  • One evidence trail. A mission planned in FlightDesk, authorised in FlightStudio and flown by an aircraft on DJI Studio Link produces one audit record, not three that have to be reconciled afterwards.
  • Your infrastructure throughout. The CA, the broker, the database and the map tiles are all yours. There is no step in the flow where the record leaves your boundary and comes back.
  • Every claim on this page has a status. Two of the three layers are Preview, and the gaps are listed beside the capabilities rather than under them.
Explore the platform Read the maturity ledger