🛰️ FLYplan - v1 - Automated Operational Intent Strategy

1. Governing principles

Three principles carry the whole design, and each one exists specifically to stop us from rebuilding something that already exists elsewhere in the stack.

2. What the live API data confirms

Rather than designing purely from DJI's public docs or the external chat the team shared, I pulled live schema from our actual FlightHub2 and FSS connections. That changed a few assumptions and confirmed others. The findings below are quoted directly from those live calls, cross-checked against the DJI-FLIGHT-HUB-RESEARCH.md already in this project.

3. End-to-end pipeline (DJI FlightHub 2, primary implementation)

This is the automated sequence the team described, updated to insert the FSS reconciliation step and to remove the standalone containment-monitoring logic in favor of consuming OpenUTM's existing conformance output.

OI lifecycle state machine

4. FSS reconciliation and FSL flight binding

This is the concrete answer to what was previously an open question in this project's earlier draft (how do we join a FlightHub Task to a FLYsafe flight, given mission_guid is empty in the live data). It's now a designed pipeline step rather than an assumption.

Near-term scope

The development focus right now is getting the left-hand branch of Fig. 3 right: querying FSS reliably (drone-serial↔GUID mapping has to be correct, and the time-window tolerance has to be tuned so it doesn't false-match two flights of the same drone close together), and building a clean, well-defined FSL-native flight-binding record when no FSS match exists. That record should carry everything downstream processing needs — the FlightHub task_uuid/wayline_uuid, dock/drone serials, the OI id, and explicit provenance fields (origin: "fsl_auto", fss_synced: false) so nothing downstream has to guess where the record came from.

Future scope — explicitly deferred

Eventually, FSL-originated flights should be pushed back into FSS: creating a matching flight record via the DLB Flight API's write endpoints, and uploading the telemetry RTTP already captured so FSS's own record isn't empty. Worth noting the FSS flight schema already has an automateFlight boolean — the vendor's own data model anticipated exactly this kind of automated-flight scenario, which is a good sign this sync is a supported pattern rather than something FSS would need to be reworked for. This is called out here specifically so it isn't quietly built early by accident — the team's direction is clear that this is a later phase (Section 10, Phase 5).

5. MQTT / OpenAPI / DLB call inventory

The concrete calls the DJI adapter and the FSS reconciliation step need, organized by pipeline phase. Endpoint shapes match DJI's published Cloud API structure and our own tool-confirmed schema; the exact base path should be confirmed live per tenant (ours currently resolves to es-flight-api-us.djigate.com).

6. FlightHub 2 GUI: annotations and pilot alerts

The annotation mechanism the team asked about is real and reachable today through our own tooling — list_element_groups/list_elements confirm FlightHub 2 organizes map content into named groups holding GeoJSON Point/Polygon features with a color property and what appears to be a per-element notify flag.

Recommended structure: one dedicated element group per FlightHub 2 project — "FLYsafe Operational Intents" — holding one Polygon per active/recent OI, named with the OI id and current state (e.g. OI-927155 · ACTIVE), colored by state (grey/pending → blue/accepted → green/active → amber/warning → red/critical → muted grey/closed). Every OI state transition in Section 3's state machine fires a corresponding annotation update, not just the initial creation. Keep the OV and CV visually distinct in weight — OV solid and saturated ("where I'm expected to be"), CV thin/dashed and optionally toggled off by default per-project — so the map doesn't get overloaded.

7. Conformance-driven OI modification

This section replaces what would otherwise have been a new "containment tracking service" with a much smaller design: RTTP as a consumer of conformance state that already exists, not a producer of it.

8. Notification model

One shared notification object across all of RTTP — sourced from OpenUTM's conformance events, task/OI lifecycle transitions, and FSS reconciliation outcomes alike — keeps severity handling from being reimplemented per source.

{
  "event": "OI_NON_CONFORMANT",
  "severity": "WARNING",
  "oi_id": "OI-927155",
  "source": "flyrtm_openutm",
  "platform": "dji_flighthub2",
  "dock_sn": "8UUXN6700A0AJF",
  "message": "OpenUTM reports aircraft non-conforming to active OI.",
  "location": { "lat": 53.7377, "lon": -113.0317, "alt_m": 621.4 }
}

9. Generalized adapter framework

To satisfy the eventual port to Auterion, ArduPilot, and PX4, everything above should sit behind a small adapter interface — with one important clarification this revision adds: conformance monitoring is not part of any per-platform adapter. OpenUTM operates on telemetry that's already normalized through the existing 3-topic MQTT architecture regardless of source platform, so it sits above the adapter layer entirely.

A worthwhile planning note: DJI — the platform being built first — is also the hardest one, since it has no native waypoint-index or mission-progress telemetry. ArduPilot and PX4 already flow through the existing Aircraft Agent / GCS Plugin into the standard MAVLink topic and natively expose MISSION_CURRENT/mode transitions, so their adapters are comparatively simple ports, not new integrations. Auterion sits in between and needs its own short research pass (mirroring the DJI research already done in this project) before implementation, since its cloud API surface and auth model haven't been verified against a live tenant.

10. Phased roadmap

11. Open questions

• What is the exact event/topic contract for OpenUTM's conformance determination that RTTP should subscribe to, and does it already include a predictive/advisory state or only binary conforming/non-conforming?
• Does DJI's Cloud API support task-lifecycle webhooks for our tenant (would eliminate the polling in step 1 of Section 3)?
• Is FlightHub 2 notification-push and Pilot 2 folder distribution actually enabled for our account tier?
• What are the DLB Flight API's rate limits and exact query parameters for matching a flight by drone + time window, and how should the time-window tolerance be tuned to avoid false matches between two close-together flights of the same drone?
• What regulatory sign-off is required before RTTP is allowed to auto-generate and auto-submit an amended OI with no human review step (Section 7, phase D)?
• What's the target timeline for the FSS bidirectional sync (Section 10, phase 5) — this document deliberately treats it as out of scope now, but it shouldn't be indefinitely deferred once the FSL-side objects are proven out.