# 09 — Open questions

Known unknowns, each with a proposed default so the project never blocks on an answer. These are the questions to settle with the domain teams early.

## 1 — Time synchronization across the swarm

**The single most critical open item.** Merging state and detections from multiple drones is only meaningful if their clocks agree. GPS time may be unavailable (GPS-denied operation is a design case).

*Proposal:* PTP over the mesh with one elected (or designated) grandmaster per mission, disciplined by GPS when available; record per-drone clock-offset estimates into `telemetry` so post-flight fusion can correct residual skew. Budget: peer clocks within ≤1 ms keeps 5 Hz pose fusion honest; IMU-grade fusion needs tighter, but that happens on-board within one clock domain.

## 2 — Frame of reference in GPS-denied flight

Visual-odometry positions are relative; different drones may hold different local frames.

*Proposal:* the `frame_ref` field in the state schema is mandatory from day one; frame alignment (co-registration) is a mission-logic concern, but the platform must carry the metadata — retrofitting it is painful.

## 3 — Conflict resolution after partitions

By construction there are no write conflicts in bulk sync (each drone writes only its own `drone=` subtree). But *derived swarm-level* products (shared maps, fused detections) may need merging.

*Proposal:* keep swarm-level fusion out of the storage layer entirely: every drone stores its own observations; fusion is computed, not stored, in flight — and recomputed from ground truth in the warehouse. If a persistent shared structure becomes unavoidable, use a CRDT type for it rather than inventing reconciliation.

## 4 — Degradation policy under sustained link loss

What does a drone do when it has seen no peer state for N seconds?

*Proposal:* the platform's job is to expose staleness honestly (per-peer last-seen in the state cache) and keep store-and-forward running. The behavioral response (loiter, climb, return) is mission logic — but the staleness contract must be a documented, tested number per message class.

## 5 — Data disposal on loss of a drone

A drone that does not return carries a full flight on NVMe.

*Proposal:* LUKS at rest ([05](05-network-security.md)) bounds exposure; key revocation removes the lost unit from the mesh. Open question for the domain owner: is remote crypto-erase over C2 required, and what evidence standard applies to disposal?

## 6 — Sensor priority order under resource pressure

The degradation ladder ([03](03-data-platform.md)) needs a domain-approved ordering: which high-rate sensors are sacrificed first when NVMe or CPU budgets are hit?

*Proposal:* default order — reduce optional high-rate environmental sensors first; never degrade `state`, `detections`, or IMU. To be reviewed per mission profile.

## 7 — Hardware-in-the-loop coverage

The virtual swarm covers logic and protocol; it does not cover radio behavior, GPU thermals, or NVMe write endurance under vibration.

*Proposal:* a small HIL rig at the bench — real compute module + radio, simulated sensor feeds — as stage 5.5 of the roadmap, exercised by the same seeded scenarios as CI.

## 8 — Video retention policy

Detections are events, but how much raw video context should be kept? Full stream on NVMe is possible but dominates the storage budget; keeping only detection-triggered clips aligns with event-driven sensing principles and privacy-proportionality, but reduces training data.

*Proposal:* configurable per mission: detection-triggered clips with pre/post-roll as the default profile; full-stream retention as an explicit opt-in for data-collection flights.

## 9 — Fleet identity and registry governance

Who owns the device registry (drone ids, key issuance, revocation) organizationally, and what is the audit process for provisioning?

*Proposal:* treat the peer registry as a versioned artifact in the release manifest ([11](11-cicd-delivery.md)) so every change is reviewed, signed, and rollback-able like code.

## 10 — Nano-platform profile

Sub-250 g class units cannot run the full stack (no GPU, minimal CPU/storage).

*Proposal:* define a minimal profile early — state publisher + UDP-multicast pose broadcast, no local Parquet store, no video — so the swarm protocol never assumes full-stack peers.
