AirOS MissionOS

AirOS Mission Intelligence combines terrain, weather, infrastructure and imagery in one evidence first map, using bounded AI to support faster, transparent and human reviewed mission planning.

Comment

I’ve unified the naming as AirOS Mission Intelligence, with MissionOS as the product/workspace name. This keeps both names from your draft without confusing judges.

Inspiration

Working in aviation and supporting helicopter emergency medical services and aerial firefighting, I have seen how urgently crews need to turn fragmented information into operational understanding.

Terrain, weather, obstacles, power infrastructure, airspace, satellite imagery and incident data often sit across separate systems. Bringing those sources together manually consumes valuable time sometimes during the critical minutes before the rotors start turning.

We built AirOS Mission Intelligence to explore a better approach: one evidence-first workspace where planning teams can bring relevant geospatial data together, run a defined mission analysis and understand both the result and its limitations.

What it does

AirOS MissionOS our MissionOS workspace turns a location and an operational objective into an interactive, reviewable map analysis.

An operator can select a location, activate relevant data layers and run mission-specific workflows such as helicopter landing-site screening, aerial firefighting support, agricultural field intelligence and solar-farm assessment.

For a helicopter landing mission, MissionOS can:

  • analyse terrain and gradient across the selected area;
  • identify mapped buildings, obstacles and power infrastructure;
  • incorporate forecast wind and weather conditions;
  • generate and rank potential candidate areas;
  • display the supporting evidence directly on the map; and
  • produce a reviewable report containing scores, sources, confidence levels and limitations.

OpenAI models add a bounded intelligence layer. A planning agent can translate a natural-language objective into an authorised set of data functions, while a separate review agent checks the returned evidence and produces a limitation-first plan. An optional vision workflow examines satellite imagery for contextual features such as visible tree cover, water, roads and open ground.

The system is deliberately designed as planning support not as operational clearance or a replacement for formal aviation assessment. Model observations cannot override deterministic exclusions, and every output remains subject to human review.

How we built it

We built MissionOS as a plugin-first geospatial platform so new missions can reuse the same mapping, analysis and evidence infrastructure.

The frontend uses React, TypeScript and Mapbox to provide a full-screen operational map, mission controls, animated wind visualisation, selectable overlays and evidence-linked reports.

A FastAPI backend manages mission plugins, structured inputs, asynchronous mission jobs and provider integrations. Shared capabilities retrieve and normalise data from sources including Open-Meteo, OpenStreetMap, NASA FIRMS, Copernicus Sentinel-2, PVGIS and optional commercial imagery providers.

Deterministic spatial analysis handles terrain sampling, gradient calculation, infrastructure checks, exclusion rules and candidate scoring. OpenAI’s Responses API is used for constrained mission composition, evidence review and optional satellite-image interpretation. Each AI role uses structured outputs, explicit schemas and authorised tools rather than unrestricted access to the application.

Every result carries its provenance, retrieval time, method, confidence and known limitations. Provider credentials and imagery access remain on the server, while the browser receives only normalised results and proxied map layers.

Codex helped us accelerate the build across the plugin architecture, FastAPI contracts, React/Mapbox interface, provider adapters, testing and evidence-first safety guardrails.

Challenges we ran into

The greatest challenge was not displaying more information it was making information from very different sources understandable and reviewable in one place.

Each provider has different spatial resolutions, update intervals, coverage and failure modes. We had to avoid creating a visually impressive map that implied more certainty than its underlying data could support. Missing information needed to appear as missing, rather than being silently replaced or inferred.

We also had to establish a clear boundary between deterministic analysis and generative AI. In a high-consequence context, a model-generated observation must never be mistaken for verified ground truth. We therefore separated scoring and hard exclusions from AI interpretation, constrained model access to typed functions and labelled vision findings as advisory context.

Maintaining a responsive map while retrieving live data, running analysis and rendering multiple GeoJSON and raster overlays was another major challenge. We addressed this through asynchronous mission jobs, progressive status updates and independently controllable result layers.

Accomplishments that we're proud of

We are proud to have built a working end-to-end mission workflow rather than a standalone chatbot or static mapping demonstration.

MissionOS can take a location from initial query through provider-backed analysis, candidate generation, interactive evidence inspection and report export. Users can see not only what the system found, but also which source and rule produced each finding.

We are particularly proud of the platform’s evidence-first architecture. OpenAI outputs are structured, traceable and unable to override deterministic safety constraints. Unavailable providers are reported clearly, credentials remain server-side and every mission result exposes its assumptions and limitations.

The plugin architecture is another important achievement. The same shared capabilities already support multiple mission types, showing how the platform can expand without rebuilding its data infrastructure for every new use case.

What we learned

We learned that trustworthy AI products need strong boundaries as much as they need capable models.

OpenAI models were most valuable when used to interpret intent, coordinate authorised tools and organise evidence not when asked to invent an answer from incomplete context. Separating the planner, deterministic analysis and evidence-review responsibilities made the workflow easier to test and explain.

We also learned that provenance and uncertainty must be part of the core product experience. A confidence label hidden in a report is not enough: users need to inspect the supporting geometry, source, timestamp, method and limitation alongside the result.

Finally, we learned that a plugin-first architecture is especially effective for geospatial intelligence. Terrain, weather, infrastructure and imagery are reusable capabilities; the mission plugin supplies the operational question, constraints and scoring policy.

What's next for AirOS MissionOS

Our next step is to move from the current hackathon architecture toward a secure, persistent and collaborative operational-planning platform.

We plan to:

  • connect mission runs, evidence and audit records to PostGIS-backed persistence;
  • introduce durable background workers for larger spatial analyses;
  • add authentication, team workspaces and role-based review;
  • integrate higher-resolution and authoritative aviation datasets;
  • improve time-aware weather, airspace and incident-data analysis;
  • validate scoring policies with aviation and emergency-service specialists;
  • expand the mission-plugin library for winching, water pickup and delivery, wildfire intelligence and infrastructure assessment; and
  • build evaluation suites that continuously test model outputs, evidence citations and safety boundaries.

The long-term vision is not to automate the expert out of the decision. It is to give that expert a faster, auditable way to bring fragmented information together, ask the right questions and understand the limits of every answer.

Built With

Share this project:

Updates