Architecture

UDAI separates who the platform serves from how it is deployed. The operating model is three layers. The runtime is a single public API host, a telemetry worker, and institutional data stores.

A product overview of the three layers is on the UDAI site .

Three-layer operating model

Layer 1: OEM and partners

Ground control systems, fleet registry, partner API keys, and the surfaces partners use to extend UDAI. Typical partner-built programmes include fleet tools, project orchestration, and insurance workflows that consume verified registry and flight records.

Layer 2: Core platform

The public HTTP API, identity and access control, the unified data store, the Constraint Engine, and platform administration. All REST routes and both WebSocket surfaces are served from this host.

Layer 3: Government-facing

Airspace Zone management, airspace operations, and airspace monitoring. Authorised government programmes evaluate compliance against the same zones and awareness feeds as Layer 1 clients.

Platform components

UDAI API. One HTTP host for REST and WebSockets. Partner API keys and user JWTs are validated at the auth edge inside the API. Tenant scope is set with X-Organisation-ID.

Registry and operations store. PostgreSQL with PostGIS holds users, organisations, assets, missions, flight plans, permissions, Airspace Zones, and related memberships.

Constraint Engine. Geospatial store for mission envelopes, flight-plan envelopes, zones, and other spatial records. Intersection queries support deconfliction and awareness.

Telemetry Engine. A worker that ingests flight-session telemetry (MQTT into the processing path, WebSocket on the API host for live sessions) and writes frames to a TimescaleDB hypertable for live and historical query.

Operational lifecycle

Environments

See Environments for access policy and API Overview for the HTTP surface. Operators use Deploy topology for the runtime map.