🏗️Architecture

UDAI is designed as a modular, high-scale Digital Public Infrastructure (DPI). It separates identity, registry, and operational logic into distinct layers to ensure maximum interoperability and security.

System Overview

1. Core Data Models

UDAI operates on 12 Canonical Data Models that ensure a single source of truth for the entire ecosystem.

• Identity: Users, Pilot Credentials, Organisation, Organisation Membership.

• Hardware: Drone Model, Drone, Payload, Drone Ownership.

• Operational: Mission, Flight Plan, Flight Session, Flight Data, Airspace Restriction Zone.

2. API Architecture (The Five Pillars)

The API is exposed via five strictly isolated pillars, ensuring that failures in one domain (e.g., Telemetry) do not affect others (e.g., Authentication).

• Authentication: RBAC/CBAC management and identity verification.

• Fleet: Distributed registry of aerial assets.

• Mission: Orchestration of complex flight plans and approvals.

• Telemetry: High-throughput ingestion and fan-out of live flight data.

• Airspace: Real-time management of 3D geospatial constraints.

3. Server Environments

• Production (api.udai.live): High-availability cluster for live operations.

• Staging (staging-api.udai.live): Pre-production environment for integration testing.

• Local: Development environment for rapid iteration.

4. Gateway Layer

Auth Gateway

The first entry point for all requests. It enforces:

• Identity Proofing: Verifying partner-api-key and User JWT.

• Context Extraction: Identifying the X-Organization-ID to set the tenant scope.

• Rate Limiting: Preventing DDoS and API abuse at the edge.

API Gateway / Router

Handles the internal routing of requests to the appropriate pillar services. It coordinates cross-pillar calls (e.g., checking if a Pilot is authorized in the Auth pillar before allowing a Mission creation in the Mission pillar).