🪞🛡️ FLYsafe.live - v2 - Cloud Custodian, Autopilot Runner & dTwin Strategy

🎯 Solution Concept

Three components, one contract each. RTM Core is the cloud brain: flight binding, the fleet-wide picture, flight authorization, flight tracking, and all DAA reasoning. It publishes avoidance commands and proximity alerts once, and never talks to an aircraft directly. The Cloud Custodian is a per-aircraft supervisory layer: it maintains the dTwin in tenant.drones from telemetry the Runner forwards, and it independently verifies — from that same telemetry — that the Runner did what RTM Core said. The Autopilot Runner is the protocol-specific edge: it turns RTM Core's maneuver into native MAVLink or DJI commands, confirms execution from real telemetry (not just a command acknowledgment), and is the same component that streamed telemetry in in the first place.

1. System Architecture — Where & How Drone Data Comes In

This is the structural view carried forward unchanged from v1.13: where drone records originate, how they enter tenant.drones, and where identity propagates.

The Custodian maintains its drone's row in tenant.drones — that is its primary job. Telemetry enters via the Autopilot Runner (§3), gets normalized, and the Custodian writes state through the API. Keycloak.θ.Drone registers each drone as a user (<tenant>-<serial>) purely for authentication — no drone metadata lives there. AADMS resolves inbound ADS-B callsigns to (tenant, serial) for cross-tenant routing.

2. The Custodian's Four Obligations

An Cloud Custodian is the entity inside FLYsafe.live RTM responsible for representing one specific drone. There is exactly one Custodian per drone per tenant. In v1.13 it carried three obligations; v2.0 adds a fourth, sourced directly from the DAA strategy's parallel-AMQP-consumer redesign (§3.7).

3. The Autopilot Runner — Telemetry In, Avoidance Out

The data path into the Cloud Custodian is a Runner embedded inside the operator's GCS — not a separate edge container the operator has to install and manage. The same Runner also executes RTM Core's avoidance commands and confirms execution from real telemetry. Two Runner form factors cover the bulk of the fleet:

3.5 Centralized Configuration Management via Custodian APIs

The Cloud Custodian doesn't just maintain telemetry-derived state — it's also the system of record for how each aircraft connects. The protocol-specific configuration for every supported telemetry source (MAVLink autopilot, DJI FlightHub 2, DJI Cloud API, ADS-B) is stored in tenant.drones and exposed through the Custodian APIs.

3.6 Data Source Monitoring — The Vigilance Obligation

Every Custodian is responsible for knowing whether data is actually arriving from the aircraft, and at what rate and latency. A silent source is worse than a failed source, because a silent source looks the same as a healthy one until an operator notices the position hasn't moved.

3.7 DAA Verification — Parallel AMQP Consumers, Not a Relay

This mirrors TCAS-style monitoring rather than gating: the safety-critical path (RTM Core → Runner) has no extra hop that can add latency or become a silent single point of failure, and the Custodian becomes a true independent check rather than a relay that could itself fail to pass something along. See Fig. 2 above and §9 for the full DAA execution model this verification loop backs.

4. State Lives in tenant.drones

The dTwin is a row in tenant.drones. The Custodian maintains it. Everything that wants to know the current state of an aircraft — including its DAA verification status — reads through the API surface that sits on top of this table. This section is fully self-contained: every schema the Custodian reads or writes, including the v2.0 DAA-verification columns, is reproduced here in full rather than pointed at v1.13.

DLB Field Cross-Reference

The table below maps every field the FLYsafe.software DLB exposes for a drone to its role in the Cloud Custodian. Stored in dlb_drones fields are persisted verbatim in drones.dlb_drones and surfaced through the v_dtwin view — they are never copied into drones.drones. Seeds RTM default fields supply initial values the Import process seeds into drones.drones on first insert; operators may later override via Custodian APIs. FK link fields are written to drones.drones once to establish the foreign key relationship. This table is unchanged from v1.13 — the DLB import contract is orthogonal to the Custodian/Runner DAA redesign.

Schema: Raw DLB Import Table (drones.dlb_drones)

Stores every field from the DLB API with column names exactly as they arrive. This is the upsert target for the Import process (Steve Smith). No renaming — the schema matches the DLB source verbatim. Unchanged from v1.13.

-- drones.dlb_drones · /tenant/rtm-app-db/schema/dlb_drones.sql
-- Raw DLB import table. Column names match the DLB API verbatim.
-- Written by the Import process (Steve Smith). Never modified by RTM side.
CREATE TABLE IF NOT EXISTS drones.dlb_drones (

  -- DLB primary identity (exact field names from DLB API)
  guid                             TEXT        NOT NULL,        -- DLB drone UUID
  serial_number                    TEXT        NOT NULL,
  name                             TEXT,                        -- drone display name
  brand                            TEXT,
  model                            TEXT,
  drone_type                       TEXT,
  status                           TEXT,                        -- e.g. Airworthy, Grounded
  color                            TEXT,

  -- Regulatory / operational identifiers
  identification_number            TEXT,                        -- TC registration  (AS TC_Registration in v_dtwin)
  inventory_number                 TEXT,                        -- operator callsign (AS Callsign in v_dtwin)

  -- Hardware & firmware
  hardware_version                 TEXT,                        -- e.g. Pixhawk Cube
  firmware_version                 TEXT,                        -- e.g. 4.0.7
  flight_controller_serial_number  TEXT,
  controller_serial_number         TEXT,
  controller_serial_number2        TEXT,

  -- Performance specs (stored as TEXT to match DLB source; cast on use)
  max_horizontal_speed             TEXT,                        -- seeds horizontal_speed_ms in drones.drones
  max_vertical_speed               TEXT,                        -- seeds vertical_speed_ms in drones.drones
  max_flight_time                  TEXT,                        -- rated endurance (minutes)
  payload_capacity                 TEXT,                        -- kg
  weight                           TEXT,
  propulsion_type                  TEXT,                        -- ELECTRIC | ICE | HYBRID

  -- Ownership & financial
  company_guid                     TEXT,
  user_guid                        TEXT,
  insurable_value                  TEXT,
  purchase_date                    TEXT,                        -- ISO-8601 string from DLB; cast on use
  tech_number                      TEXT,
  notes                            TEXT,

  -- Import bookkeeping
  imported_at                      TIMESTAMPTZ NOT NULL DEFAULT now(),

  PRIMARY KEY (guid)
);

CREATE UNIQUE INDEX IF NOT EXISTS idx_dlb_drones_serial
  ON drones.dlb_drones (serial_number);

Schema: Custodian dTwin Table (drones.drones)

The canonical per-drone RTM state table maintained by the Cloud Custodian. Holds only RTM-specific data — configuration, live state, DAA verification state, and the link key (dlb_guid) back to drones.dlb_drones. All DLB identity fields live exclusively in dlb_drones and are accessed via the v_dtwin view. Everything through data_source_* is unchanged from v1.13; the DAA verification block is new in v2.0, backing the Custodian's fourth obligation (§2) and the parallel-AMQP-consumer model (§3.7).

-- /tenant/rtm-app-db/schema/drones.sql
-- One row per drone per tenant. Maintained by the Custodian. PK = (tenant, serial).
-- DLB identity data lives in drones.dlb_drones; join via dlb_guid. Use v_dtwin for the full dTwin record.
CREATE SCHEMA IF NOT EXISTS drones;

CREATE TABLE drones.drones (
  -- Core identity
  tenant_id                         text NOT NULL,
  serial_number                     text NOT NULL,
  dlb_guid                          text NOT NULL,            -- FK → drones.dlb_drones.guid

  -- Custodian configuration (RTM-managed; written via Custodian APIs)
  adapter_type                      text DEFAULT 'mavlink'::text NOT NULL,   -- mavlink | dji_fh2 | dronesense
  adapter_config                    jsonb DEFAULT '{}'::jsonb NOT NULL,
  publish_rate_hz                   int4 DEFAULT 4 NOT NULL,

  -- OI defaults & FLYplan automation (speeds seeded from dlb_drones on first insert)
  oi_automation_enabled             bool DEFAULT false NOT NULL,     -- pilot-granted authority; see §7
  horizontal_speed_ms               float8 DEFAULT 15.0 NOT NULL,   -- seeded from dlb_drones.max_horizontal_speed
  vertical_speed_ms                 float8 DEFAULT 6.0 NOT NULL,    -- seeded from dlb_drones.max_vertical_speed

  -- Flight Volume (FV) / Contingency Volume (CV) buffers — horizontal only; vertical separation
  -- from other traffic is handled by the NMAC/SWC crewed/uncrewed minima below, not by FV/CV.
  fv_buffer_m                       float8 DEFAULT 56.0 NOT NULL,    -- horizontal buffer around flight path
  cv_buffer_m                       float8 DEFAULT 150.0 NOT NULL,   -- additional horizontal buffer past FV edge

  -- OI geometry parameters (see §5A)
  oi_automation_square_m            float8 DEFAULT 700.0 NOT NULL,   -- OI square side (m); valid 350–1400
  oi_automation_radius_m            float8 DEFAULT 400.0 NOT NULL,   -- OI radius (m); valid 200–800
  oi_automation_amend_min_trigger_m float8 DEFAULT 100.0 NOT NULL,   -- OI amend min trigger (m); valid 50–200
  oi_automation_amend_max_alt_agl_m float8 DEFAULT 300.0 NOT NULL,   -- OI amend max altitude AGL (m)
  oi_automation_amend_enabled       bool DEFAULT false NOT NULL,

  -- Flight monitoring — radius within which a mission waypoint is considered reached.
  waypoint_buffer_m                 float8 DEFAULT 50.0 NOT NULL,    -- valid 5–500

  -- Default pilot binding — pre-filled pilot when a mission is created without explicit selection
  default_pilot_name                text NULL,
  default_pilot_fs_guid             text NULL,               -- FLYsafe.software pilot GUID

  -- Separation defaults — per-drone conflict-evaluation minima, metres, split crewed/uncrewed × horizontal/vertical.
  nmac_h_crewed_m                   float8 DEFAULT 150.0  NOT NULL,  -- NMAC horizontal, crewed traffic
  nmac_v_crewed_m                   float8 DEFAULT 30.0   NOT NULL,  -- NMAC vertical, crewed traffic
  nmac_h_uncrewed_m                 float8 DEFAULT 15.0   NOT NULL,  -- NMAC horizontal, uncrewed traffic
  nmac_v_uncrewed_m                 float8 DEFAULT 8.0    NOT NULL,  -- NMAC vertical, uncrewed traffic
  swc_h_crewed_m                    float8 DEFAULT 1500.0 NOT NULL,  -- SWC horizontal, crewed traffic
  swc_v_crewed_m                    float8 DEFAULT 150.0  NOT NULL,  -- SWC vertical, crewed traffic
  swc_h_uncrewed_m                  float8 DEFAULT 150.0  NOT NULL,  -- SWC horizontal, uncrewed traffic
  swc_v_uncrewed_m                  float8 DEFAULT 30.0   NOT NULL,  -- SWC vertical, uncrewed traffic
  eval_distance_m                   float8 DEFAULT 1852.0 NOT NULL,  -- Evaluation ring (~1 NM)

  -- ADS-B provisioning
  adsb_in_enabled                   bool DEFAULT false NOT NULL,
  adsb_out_enabled                  bool DEFAULT false NOT NULL,
  adsb_surrogate_enabled            bool DEFAULT false NOT NULL,
  tisb_rebroadcast_enabled          bool DEFAULT false NOT NULL,     -- enables rebroadcast of this aircraft’s own telemetry to TIS-B

  -- Conspicuity / ADS-B detail — provisioning detail behind the flags above.
  ec_adsb_hex                       text NULL,                       -- static ADS-B ICAO hex; set when adsb_hex_mode = 'static'
  adsb_out_device                   text NULL,                       -- transponder model, e.g. Ping978ec | Ping2020i | SkyEcho 2 | TISB | other
  adsb_hex_mode                     text DEFAULT 'dynamic'::text NOT NULL,   -- dynamic (ADDRt) | static (user-entered, see ec_adsb_hex)
  surveillance_mode                 text NULL,                       -- descriptive surveillance method, e.g. "MLAT + ADS-B", "ADS-B + Vision"
  daa_enabled                       bool DEFAULT false NOT NULL,     -- Detect-and-Avoid active for this drone (provisioning intent — see daa_status below for outcome)
  broadcast_binding                 text NULL,                       -- e.g. Bound | Unbound — binding status between this drone and its broadcast identity
  networkid_streaming_enabled       bool DEFAULT false NOT NULL,     -- gates NetworkID into RTM viz + DAA; independent of tisb_rebroadcast_enabled

  -- Observed ADS-B state (read-only) — from surveillance feeds, not the provisioning intent above
  adsb_observed_broadcasting            bool NULL,
  adsb_observed_last_icao_hex           text NULL,
  adsb_observed_last_seen_by_cifib_at   timestamptz NULL,             -- last seen by the CIFIB upstream gating pipeline

  -- DAA verification (v2.0) — the Custodian's fourth obligation; see §2, §3.7, §9
  daa_status                        text NULL,               -- FULL | DEGRADED | NO_QUALIFIED_SURVEILLANCE
  current_avoidance_maneuver_id     text NULL,               -- FK to the AMQP avoidance_maneuver message's alert_id, while active
  current_avoidance_state           text NULL,               -- NONE | COMMANDED | EXECUTING | CONFIRMED | MISMATCH | CLEARED
  last_daa_verification_at          timestamptz NULL,         -- last time the Custodian compared Runner telemetry against a published command

  -- Ownership flag (see §8)
  ownership_flag_enabled            bool DEFAULT false NOT NULL,

  -- Data source monitoring — the Custodian’s vigilance obligation; see §3.6
  data_source_mechanism             text NULL,               -- mavlink_runner | dji_runner | dji_cloud | adsb | multi
  data_source_rate_hz               float8 NULL,
  data_source_latency_ms_p50        float8 NULL,
  data_source_latency_ms_p95        float8 NULL,
  data_source_status                text NULL,               -- HEALTHY | DEGRADED | STALE | DISCONNECTED
  data_source_max_latency_ms        int4 DEFAULT 2000 NOT NULL,      -- expected envelope
  data_source_last_seen_at          timestamptz NULL,

  -- Current flight — the mission this drone is executing right now.
  -- Populated by FLYsafe.software on mission publish; progress fields updated by the Custodian from telemetry.
  current_mission_id                text NULL,
  current_flight_state              text NULL,               -- PLANNED | ACTIVE | COMPLETED | ABORTED
  current_flight_window_start       timestamptz NULL,
  current_flight_window_end         timestamptz NULL,
  current_waypoint_index            int4 NULL,
  current_waypoint_total            int4 NULL,
  current_progress_pct              int4 NULL,

  -- Current OI — the currently active Operational Intent for this drone.
  -- Written by the Flink OI Automation job on every generation/regeneration.
  current_oi_id                     text NULL,
  current_oi_state                  text NULL,               -- DRAFT | SUBMITTED | ACCEPTED | ACTIVE | COMPLETED | REJECTED
  current_oi_source                 text NULL,               -- AUTOMATED | MANUAL | MISSION_PUBLISH
  current_oi_window_start           timestamptz NULL,
  current_oi_window_end             timestamptz NULL,
  oi_last_regenerated_at            timestamptz NULL,
  oi_next_regeneration_at           timestamptz NULL,

  -- Live state (Custodian writes these from Autopilot Runner telemetry)
  position_lat                      float8 NULL,
  position_lon                      float8 NULL,
  position_alt                      float8 NULL,
  flight_mode                       text NULL,
  armed                              bool NULL,
  battery_remaining_pct             int4 NULL,
  link_rssi_dbm                     int4 NULL,
  adapter_connected                 bool DEFAULT false NOT NULL,
  last_telemetry_at                 timestamptz NULL,

  -- Cross-references
  aadms_id                          text NULL,               -- cross-tenant identity reference

  -- Timestamps
  created_at                        timestamptz DEFAULT now() NOT NULL,
  updated_at                        timestamptz DEFAULT now() NOT NULL,
  retired_at                        timestamptz NULL,

  CONSTRAINT drones_pkey PRIMARY KEY (tenant_id, serial_number),
  CONSTRAINT drones_dlb_guid_fk FOREIGN KEY (dlb_guid) REFERENCES drones.dlb_drones(guid),
  CONSTRAINT drones_dlb_guid_unique UNIQUE (dlb_guid)
);

CREATE INDEX idx_drones_serial   ON drones.drones USING btree (serial_number);
CREATE INDEX idx_drones_daa_status ON drones.drones USING btree (daa_status)   -- v2.0
  WHERE daa_status IS NOT NULL;

Schema: dTwin View (drones.v_dtwin)

Read-only view that joins drones.drones with drones.dlb_drones on the dlb_guid foreign key. This is the authoritative dTwin data record — the single consistent view consumers should use when they need both RTM state and DLB identity together. The Custodian APIs serve responses that reflect this aggregated record, now including the DAA verification block.

-- drones.v_dtwin · /tenant/rtm-app-db/schema/v_dtwin.sql
-- dTwin view: joins drones.drones (RTM state) with drones.dlb_drones (DLB identity).
CREATE OR REPLACE VIEW drones.v_dtwin AS
SELECT
  d.tenant_id, d.serial_number, d.dlb_guid,

  -- DLB identity (from dlb_drones; renamed for clarity)
  dlb.name AS drone_name, dlb.brand, dlb.model, dlb.drone_type, dlb.status, dlb.color,
  dlb.identification_number AS "TC_Registration",
  dlb.inventory_number      AS "Callsign",
  dlb.hardware_version, dlb.firmware_version, dlb.max_horizontal_speed, dlb.max_vertical_speed,
  dlb.max_flight_time, dlb.payload_capacity, dlb.weight, dlb.propulsion_type,

  -- Custodian configuration, OI defaults, pilot & separation defaults, ADS-B provisioning
  d.adapter_type, d.adapter_config, d.publish_rate_hz,
  d.oi_automation_enabled, d.horizontal_speed_ms, d.vertical_speed_ms,
  d.fv_buffer_m, d.cv_buffer_m, d.oi_automation_square_m, d.oi_automation_radius_m,
  d.oi_automation_amend_min_trigger_m, d.oi_automation_amend_max_alt_agl_m, d.oi_automation_amend_enabled,
  d.waypoint_buffer_m, d.default_pilot_name, d.default_pilot_fs_guid,
  d.nmac_h_crewed_m, d.nmac_v_crewed_m, d.nmac_h_uncrewed_m, d.nmac_v_uncrewed_m,
  d.swc_h_crewed_m, d.swc_v_crewed_m, d.swc_h_uncrewed_m, d.swc_v_uncrewed_m, d.eval_distance_m,
  d.adsb_in_enabled, d.adsb_out_enabled, d.adsb_surrogate_enabled, d.tisb_rebroadcast_enabled,
  d.ec_adsb_hex, d.adsb_out_device, d.adsb_hex_mode, d.surveillance_mode, d.daa_enabled,
  d.broadcast_binding, d.networkid_streaming_enabled,
  d.adsb_observed_broadcasting, d.adsb_observed_last_icao_hex, d.adsb_observed_last_seen_by_cifib_at,

  -- DAA verification (v2.0) — see §2, §3.7, §9
  d.daa_status,
  d.current_avoidance_maneuver_id,
  d.current_avoidance_state,
  d.last_daa_verification_at,

  d.ownership_flag_enabled,

  -- Data source monitoring — see §3.6
  d.data_source_mechanism, d.data_source_rate_hz, d.data_source_latency_ms_p50, d.data_source_latency_ms_p95,
  d.data_source_status, d.data_source_max_latency_ms, d.data_source_last_seen_at,

  -- Current flight & current OI
  d.current_mission_id, d.current_flight_state, d.current_flight_window_start, d.current_flight_window_end,
  d.current_waypoint_index, d.current_waypoint_total, d.current_progress_pct,
  d.current_oi_id, d.current_oi_state, d.current_oi_source, d.current_oi_window_start, d.current_oi_window_end,
  d.oi_last_regenerated_at, d.oi_next_regeneration_at,

  -- Live state
  d.position_lat, d.position_lon, d.position_alt, d.flight_mode, d.armed, d.battery_remaining_pct,
  d.link_rssi_dbm, d.adapter_connected, d.last_telemetry_at,

  -- Cross-references & timestamps
  d.aadms_id, d.created_at, d.updated_at, d.retired_at

FROM drones.drones d
JOIN drones.dlb_drones dlb ON dlb.guid = d.dlb_guid;

Schema: AADMS Materialized View (aadms.drones)

Cross-tenant drone lookup table used by the ADS-B routing pipeline. A materialized view that aggregates drones.drones (joined to dlb_drones for callsign) from every tenant schema into a single flat surface. ADS-B records arrive carrying only callsign; AADMS resolves callsign → (tenant_id, serial_number). Unchanged from v1.13.

-- aadms.drones · cross-tenant drone lookup
CREATE SCHEMA IF NOT EXISTS aadms;

CREATE MATERIALIZED VIEW aadms.drones AS
  SELECT d.tenant_id, d.serial_number, d.dlb_guid AS guid,
         dlb.inventory_number AS callsign, d.aadms_id AS id
  FROM tenant_airmarket.drones.drones d
  JOIN tenant_airmarket.drones.dlb_drones dlb ON dlb.guid = d.dlb_guid
  WHERE d.retired_at IS NULL
  UNION ALL
  SELECT d.tenant_id, d.serial_number, d.dlb_guid AS guid,
         dlb.inventory_number AS callsign, d.aadms_id AS id
  FROM tenant_sait.drones.drones d
  JOIN tenant_sait.drones.dlb_drones dlb ON dlb.guid = d.dlb_guid
  WHERE d.retired_at IS NULL
  -- ... repeat for each tenant ...
;

CREATE UNIQUE INDEX idx_aadms_drones_callsign ON aadms.drones (callsign);
CREATE INDEX        idx_aadms_drones_serial   ON aadms.drones (serial_number);

Schema: DAA Rules Store (drones.daa_rules)

One row per Detect-and-Avoid rule per drone — the ordered rule set the Conspicuity/DAA panel edits as daa_rules[]. Rules are evaluated in sort_order; each can be individually enabled/disabled without deleting it. Unchanged from v1.13.

-- drones.daa_rules · one row per DAA rule per drone
-- Read/written by the Custodian API's DAA endpoints; evaluated by the DAA service at runtime.
CREATE TABLE drones.daa_rules (
  tenant_id             text NOT NULL,
  serial_number         text NOT NULL,
  rule_id                text NOT NULL,                             -- e.g. R1, R2, R3

  condition_text        text NOT NULL,                              -- human-readable trigger condition, e.g. "Target within NMAC radius"
  action_text            text NOT NULL,                              -- action taken when triggered, e.g. "RTH — Immediate"
  priority                text NOT NULL,                              -- critical | high | medium | low
  enabled                 bool NOT NULL DEFAULT true,
  sort_order             int4 NOT NULL DEFAULT 0,                    -- evaluation / display order

  PRIMARY KEY (tenant_id, serial_number, rule_id),
  FOREIGN KEY (tenant_id, serial_number) REFERENCES drones.drones(tenant_id, serial_number)
);

How drones.dlb_drones and drones.drones work together

drones.dlb_drones is the primary store for all raw DLB API data, written by the Import process and never touched by RTM. drones.drones holds only RTM state — configuration, live telemetry, DAA verification, and the dlb_guid foreign key. Three distinct processes write to these tables at different times; each owns specific columns and must not write to columns owned by another.

The dTwin: what it actually is

The dTwin is the conceptual digital twin of one aircraft — the canonical answer to “what does FLYsafe.live believe is true about this drone right now?” It is the v_dtwin record for that drone. This is the complete GET /drones/{serial} response — every block, including the new daa block.

{
  "identity": {
    "serial_number":   "1581F5BBB1F2A",
    "tc_registration": "C-FAIRTL69",
    "callsign":        "AIRTL69",
    "tenant":          "airmarket",
    "adapter_type":    "mavlink"
  },
  "position":    { "lat": 53.5461, "lon": -113.4938, "alt_msl_m": 720.4 },
  "flight_mode": "AUTO",
  "armed":       true,
  "battery":     { "remaining_pct": 68 },
  "adsb": {
    "in_enabled": true, "out_enabled": true,
    "surrogate_enabled": false, "ownership_flagged": true
  },
  "pilot": { "default_name": "Jane Chen", "default_fs_guid": "pilot-8f3a2e19-4c1a-4e6b-9c17-2b9e5d3f7a0c" },
  "oi": {
    "automation_enabled": true, "default_distance_m": 300, "waypoint_buffer_m": 50.0
  },
  "volumes": { "flight_volume": { "buffer_m": 56.0 }, "contingency_volume": { "buffer_m": 150.0 } },
  "separation": {
    "nmac_crewed_m":   { "h": 150.0,  "v": 30.0 },
    "nmac_uncrewed_m": { "h": 15.0,   "v": 8.0 },
    "swc_crewed_m":    { "h": 1500.0, "v": 150.0 },
    "swc_uncrewed_m":  { "h": 150.0,  "v": 30.0 },
    "eval_distance_m": 1852.0
  },
  "data_source": {
    "mechanism": "mavlink_runner", "rate_hz": 4.0,
    "latency_ms_p50": 180, "latency_ms_p95": 420, "max_latency_ms": 2000,
    "status": "HEALTHY", "last_seen_at": "2026-09-05T14:22:18.315Z"
  },
  "current_flight": {
    "mission_id": "mission-airmarket-2026090514200", "state": "ACTIVE",
    "window": { "start": "2026-09-05T14:00:00Z", "end": "2026-09-05T14:45:00Z" },
    "waypoints": { "current_index": 5, "total": 12 }, "progress_pct": 42
  },
  "current_oi": {
    "oi_id": "oi-airmarket-2026090514201", "state": "ACTIVE", "source": "AUTOMATED",
    "last_regenerated_at": "2026-09-05T14:21:15Z", "next_regeneration_at": "2026-09-05T14:21:45Z",
    "geometry_ref": {
      "flight_volume":      "/api/v1/drones/1581F5BBB1F2A/oi/current/flight-volume",
      "contingency_volume": "/api/v1/drones/1581F5BBB1F2A/oi/current/contingency-volume",
      "submitted_volume":   "/api/v1/drones/1581F5BBB1F2A/oi/current"
    }
  },
  "daa": {                                       // v2.0 — the Custodian's verification obligation, §2/§3.7
    "enabled":        true,                    // drones.drones.daa_enabled
    "status":         "FULL",                    // FULL | DEGRADED | NO_QUALIFIED_SURVEILLANCE
    "active_maneuver": {
      "maneuver_id":   "alert-7f2a9c31-4e5b-4c8a-9d21-8b6f3e2a1c04",
      "state":         "CONFIRMED",          // NONE | COMMANDED | EXECUTING | CONFIRMED | MISMATCH | CLEARED
      "commanded_at":  "2026-09-05T14:22:03.100Z",
      "verified_at":   "2026-09-05T14:22:04.850Z"
    },
    "last_verification_at": "2026-09-05T14:22:04.850Z"
  },
  "adapter_health": { "connected": true, "last_publish_ago_ms": 247 },
  "timestamps": { "updated_at": "2026-09-05T14:22:18.523Z", "source_ts": "2026-09-05T14:22:18.491Z" }
}

↑ Returned by GET /drones/{serial}. There is no canonical “dTwin payload schema” separate from the API response — the response is the schema. Cheaper subset endpoints (/state, /current-flight, /current-oi, /data-source, /daa-status) exist for consumers that don’t want the full payload every time.

5. Cloud Custodian APIs

This is the complete catalog of API operations the Cloud Custodian exposes, categories A through K, fully specified. The same APIs are consumed by:

• The frontend (FSL RTM Map, JC) — for operator configuration changes and live state display.
• The Autopilot Runner — for posting telemetry and avoidance-execution reports, and for reading its own boot configuration.
• The MCP server — wrapping a curated subset as AI-callable tools so Aircraft AI, OCC AI, and Compliance AI agents can read and (where permission-scoped) write the same state.

All endpoints are tenant-scoped (the tenant is resolved from the JWT). The base path is /api/v1. Verbs use REST conventions: GET reads, POST creates/triggers, PUT updates, DELETE removes. Where a notification stream is useful, a WebSocket endpoint is offered as a parallel option to polling.

MCP exposure

The MCP server wraps a curated subset of the above as AI-callable tools. The principle is read freely, write narrowly: agents can read drone state, OI status, ownership state, identity, health, and DAA status without restriction; writes are scoped to operationally-safe toggles only.

Operations not on this list (retire, identity registration, mission binding writes, adapter-config changes) are deliberately not exposed via MCP. POST /drones/{serial}/avoidance/report is likewise excluded — it is a machine-to-machine Runner-to-Custodian channel, not an operator or agent action.

6. Identity Model — Four-Tier Layout

Unchanged from v1.13. FLYsafe.live carries a drone's identity across four systems; mixing them up breaks the binding pipeline.

7. FLYplan Workflow

Unchanged from v1.13 §7 — the automated creation and maintenance of Operational Intents. See that document for the full seven-step table (onboarding, pilot-granted OI Automation authority, mission publish, telemetry-driven state advance, OI regeneration, operator review, mission completion).

8. Surveillance & Ownership Tagging

Unchanged from v1.13 §8. Flight_Live consults each drone's ownership_flag_enabled (read from the Custodian API) to tag incoming surveillance records as own-aircraft or external. Records are tagged, not filtered, at ingest — each downstream consumer applies its own filtering policy. See that document for the full decision record.

9. DAA Execution Model — RTM Core, Maneuver Selection & Protocol Behavior

This section is folded in from FLYsafe Architecture — DAA, Custodian & Runner Strategy, grounded in the am-flyrtm-blender repository (a Flight Blender / InterUSS derivative). It is what RTM Core actually computes, and what the Autopilot Runner does with it.

How RTM Core chooses a maneuver — candidate generation & forward-simulated scoring

DefaultAvoidanceEngine.compute_maneuver() doesn't apply a fixed rule — it generates several candidate maneuvers and predicts the outcome of each before picking a winner. This is what makes it rich avoidance.

Three-tier hybrid avoidance — onboard, local injection & cloud

The Runner isn't only a translator for RTM Core's commands — it's also a local sensor-aggregation and injection layer that keeps functioning when RTM Core isn't reachable at all.

Autopilot avoidance paths — ADS-B injection vs. Guided Mode

On the MAVLink side, the Runner has two mechanisms available to cause an avoidance maneuver. Which one runs is an operator-configurable deployment setting — FLYsafe's default deployment uses Guided Mode.

MAVLink vs. DJI — automatic entry/exit

Both protocol implementations follow the same shape: automatic entry, automatic exit — no manual confirmation gate by default, matching the precedent already set by UAvionix Casia.

IP boundary — what's stock ArduPilot vs. what's FLYsafe's own

ArduPilot is the muscle — dumb and reactive, doing exactly what any operator's ArduPilot does. FLYsafe's differentiation is the orchestration layer above it: RTM Core's DAA reasoning, delivery-and-trust verification through the Custodian, and the Runner's translation-and-confirmation logic that turns a cloud-level “avoid this” into a reliable, provably-executed action on a stock autopilot — without modifying the autopilot itself.

Operator visibility layer

The Mission Planner Plugin (already built, Tim Tuxworth) injects STATUSTEXT-style DAA status directly into Mission Planner's messages panel. The planned FLYsafe.live RTM Chrome Extension (Maykon Ferrero) closes the equivalent gap for any browser-based GCS — augmenting the web page UI directly rather than integrating with a single vendor's API, so the same pattern extends to future web GCS platforms without rework.

10. Lifecycle & Operational Model

All v1.13 lifecycle events (drone added in DLB, Runner installed, Custodian boots, telemetry arrives, OI automation granted, source degrades, drone armed/airborne, OI accepted, mission completes, drone retired) carry forward unchanged — see v1.13 §9. Two DAA-specific events are new in v2.0:

11. Open Questions & Next Steps

Tracked across the wiki subpages under TECH-002/FSL RTTP. Carried forward from both source documents.

• AMQP fanout/topic exchange topology (§3.7). Custodian and Runner each need their own bound queue off a fanout or topic exchange — real infrastructure work for Maykon and Raman. Confirm exchange type and per-flight-declaration queue naming.
• Maneuver translation ownership. RTM Core's engine outputs a heading/rate command, not a position. Does RTM Core itself compute and publish a projected lat/lon, or does the Runner own that projection locally? Needs a decision before Runner-side execution work is built against a stable contract.
• GUIDED setpoint loop. Dead-code maneuver functions exist in the Runner codebase but are one-shot, not a streamed rate/setpoint loop, and none are called today. Needs a real heartbeat-maintained loop, telemetry-based confirmation, and an AMQP consumer for command_type == "avoidance_maneuver".
• Exclusion-zone fence upload. No MISSION_TYPE_FENCE protocol code exists yet; the reference airframe shows FENCE_TOTAL -103 — no fence points loaded.
• DJI DRC channel implementation. Build the descent-and-hold command over the DRC live-control channel; confirm DJI Dock's Resume Flight From Breakpoint behavior.
• Chrome extension scoping. Define DOM/API hook points on FlightHub 2 for the in-page DAA overlay; confirm distribution path.
• Telemetry POST rate & payload schema. What frequency does the Custodian accept from the Runner? What is the canonical body schema? (Maykon + Tim)
• DM-DI — ADS-B field split. v1 uses a single surrogate boolean; splitting into distinct in/out/runtime fields is anticipated but not yet scheduled.
• Sprint allocation. MAVLink Runner (Tim) · DJI Runner / Chrome GCS Plugin (Maykon) · Custodian server & APIs incl. category K (Maykon) · drones schema + import (Brayden + Steve Smith) · AMQP fanout topology (Raman) · RTM Map UI for daa-status (JC).

📐 Reference — Polygon Generation API Requirements (Owner: JC)

§4 established that three geometries — Flight Volume, Contingency Volume, and the Submitted Volume — are stored in flights_binding and exposed via the §5A endpoints. This section specifies the API that actually computes those three polygons from a predicted trajectory and the drone's FV/CV buffer defaults. It does not yet exist; JC is building it. Everything below is the requirements contract for that work — not a description of a shipped API. Unchanged from v1.13.

Request contract

{
  "tenant_id": "airmarket",
  "serial_number": "1581F5BBB1F2A",
  "trajectory": [                              // predicted path, ordered, ≥ 2 points
    { "lat": 53.5461, "lon": -113.4938, "alt_msl_m": 720.4, "t": "2026-09-05T14:22:00Z" },
    { "lat": 53.5480, "lon": -113.4901, "alt_msl_m": 725.1, "t": "2026-09-05T14:23:30Z" }
    // ...
  ],
  "fv_buffer_m": 56.0,                          // horizontal only
  "cv_buffer_m": 150.0
}

Response contract

{
  "flight_volume":      { "type": "Polygon", "coordinates": [ /* GeoJSON PolygonZ */ ] },
  "contingency_volume": { "type": "Polygon", "coordinates": [ /* GeoJSON PolygonZ */ ] },
  "submitted_volume":   { "type": "Polygon", "coordinates": [ /* GeoJSON PolygonZ — see open question below */ ] },
  "computed_at": "2026-09-05T14:22:18.600Z"
}

Functional requirements