SAR AI is the decision layer inside the SAR ground station. It runs across every phase of a mission — pre-flight health review, in-flight relay optimisation, and (soon) post-flight debrief — in both single-drone SAR and multi-drone fleet patrol modes. One pipeline, one Safety Gate, one audit trail. Local by default, cloud-refined when connectivity exists, air-gapped when it doesn’t.

Where it runs

Pre-flight. Above every Launch button, the Pre-Flight Health Panel shows eight live health checks per drone: battery percentage, cell balance, GPS fix, compass health, failsafe configuration, geofence, telemetry heartbeat age, and Remote ID broadcast status. Each row is green, yellow, red, or waiting on a manual tick from the paper checklist. SAR AI reads all of those plus the current wind and the 1-hour forecast gust, and produces a natural-language recommendation:

  • “Green light, proceed — all checks passing.”
  • “Proceed with caution — wind 7.2 m/s, conservative mission envelope.”
  • “Hold launch — drone-2: battery 22% (swap before launch); forecast gust 11.3 m/s within 1 h (abort risk).”

The Launch button is disabled while the recommendation is red. Operators can type OVERRIDE to bypass — and that override is audit-logged with the failing check names, operator ID, and timestamp. The gate is designed to be bypassable (there are real situations where operators need to fly despite a yellow or red check), but never bypassable silently.

In-flight, fleet patrol. Every 30 seconds during a patrol, SAR AI reads fleet telemetry (battery levels, positions, weather, detection density, coverage state) and produces optimised relay parameters: swap threshold, relay overlap, transit speed multiplier, cruise speed, preferred standby drone for the next handoff. The orchestrator applies them on the next tick. If conditions deteriorate dramatically — wind spike, multiple drones below critical battery — the AI can recommend an immediate mission abort with a natural-language reason; the Safety Gate enforces the abort regardless of which layer proposed it.

In-flight, sector patrol. Sectors inherit the fleet-patrol behaviour today (one advisor decision applies across all sectors). Per-sector advisor tuning — each sector getting its own parameter set based on local conditions — is on the backlog.

Post-flight. Mission debrief is the next expansion point. Take the flight log, run it through the advisor with the benefit of knowing how the mission ended, produce a natural-language after-action review. Currently on the roadmap; not live.

The pipeline

Every decision — pre-flight, in-flight, anywhere — flows through the same three-stage pipeline:

  1. Local decision engine. Physics-based, offline, instant. Models battery discharge curves, wind drag penalties (+10% drain per m/s above 3), transit power consumption, charge times, detection density. Produces the baseline recommendation from live telemetry. Never needs network. Always runs first.
  2. Optional cloud refinement. When internet is available and API keys are configured: Anthropic Claude first (structured tool output), OpenAI GPT as first fallback, Google Gemini as second fallback. First successful response wins. The cloud layer receives the fleet telemetry and the local engine’s recommendation, and either confirms or improves it — adding contextual reasoning the local physics engine can’t do alone (weather-forecast integration, pattern recognition across missions, natural-language explanations for the operator log).
  3. Safety Gate. Always runs last. Validates every decision against inviolable constraints: swap threshold never below critical + 5%, transit speed multiplier never above 2.0, patrol speed always 2–8 m/s, wind-abort at 10 m/s no matter what the advisor says. No parameter that violates a hard safety bound ever reaches the mission.

Cloud providers are strictly optional. A deployment with zero API keys configured runs 100% on the local engine and the Safety Gate — same decision logic, same audit trail, just without the cloud layer’s refinement. This is the normal mode for field deployments where reliable internet isn’t guaranteed, and it’s the required mode for air-gapped deployments.

The UI tells you where every decision came from. A badge on every recommendation reads LOCAL, CLAUDE, GPT, or GEMINI — no ambiguity about which engine made a given call.

Why pre-flight is a good place for an AI’s first responsibility

There’s a design judgement behind starting with pre-flight health review rather than in-flight control. Pre-flight is a low-stakes environment for an AI recommendation. The drone is on the ground. The operator has time to read the reasoning, look at the checks, decide whether to proceed.

If SAR AI says “recommend delaying 1 h — gust forecast 11 m/s in 25 min”, the operator can agree, disagree, or override. Nothing bad happens during the disagreement. The operator builds trust (or distrust) with the AI’s recommendations before the AI is ever asked to do something in the air.

That’s deliberate. The sequence we follow for expanding AI responsibility across the product is: pre-flight first (low stakes, long thinking time), post-flight debrief next (zero stakes, high value for training pipelines), then in-flight advisory with the operator in the loop, then eventually in-flight automation — cautiously, only after operators and procurement reviewers have watched the advisor enough to trust it. For fleet-patrol relay tuning we’re already at step three; for SAR in-flight advisory we’re at step one. We won’t skip the intermediate steps.

What it means for operators

Single-drone SAR: the Pre-Flight Health Panel appears above every Launch button. Eight checks per drone, aggregated status, weather strip, and an SAR AI recommendation. Green means go, yellow means proceed with awareness of the caveats, red means stop / fix / explicit override with a documented reason.

Fleet patrol: the runtime advisor tunes swap thresholds and transit speeds every 30 seconds during the mission. The pre-flight panel also runs before the first drone takes off. The AI source badge on every recommendation shows LOCAL or the active cloud provider.

Air-gapped deployments: SAR AI runs on the local physics engine only. No external calls, same recommendation logic, same Safety Gate, same audit trail. The AIR-GAPPED badge in the top bar tells the operator they’re in offline mode; decisions are sourced LOCAL.

Evaluating SAR: the AI layer is on by default in the simulator. Try both modes — the pre-flight panel in single-drone SAR planning, the runtime advisor during the simulated 24 h fleet patrol — and you see the same engine across both.

What’s next

Two priority expansion points on the backlog:

Per-sector advisor decisions. With sectors shipping, the advisor needs to become sector-aware — today one decision applies across the whole fleet. Individual sectors may have different local conditions (local wind, detection density, battery state of their sub-fleet) that deserve tuning independently.

Post-flight debrief. Take the full mission log and run the advisor over it with the benefit of knowing how the mission ended. Output: a natural-language after-action review covering battery performance, relay timing, weather handling, detection events, and any anomalies. Useful for debriefs, for operator training, and for documenting missions to stakeholders and regulators.

One pipeline, one Safety Gate, one audit trail — running everywhere a decision needs making.