gps-denied-onboard/_docs/00_research/00_question_decomposition.md

Question Decomposition

Mode A Phase 2 (Initial Research — Problem & Solution Draft). Phase 1 (AC & Restrictions Assessment) was skipped per user decision after a cleanup pass that stripped implementation details from acceptance_criteria.md and restrictions.md (commit 12cc5a4); AC/restrictions are treated as fixed inputs.

Original Question

Design the GPS-denied onboard navigation system for a fixed-wing UAV operating in eastern/southern Ukraine, satisfying every AC in _docs/00_problem/acceptance_criteria.md under the constraints in _docs/00_problem/restrictions.md. Recommend a concrete component-by-component architecture and tech stack.

Research Output Class

Technical-component selection. All technical-component gates apply (per-mode API capability verification, Component Applicability Gate, Restrictions × Candidate-Mode sub-matrix, MVE evidence, mandatory context7 lookups for every lead library/SDK candidate).

Question Type

Decision Support (per Mode A Phase 2 default). Sub-flavour: multi-component decision support — weighing trade-offs across ~10 interlocking component areas under hard real-time + memory + safety budgets.

Project Context Summary (from _docs/00_problem/)

• What is being built: an onboard companion-PC system that replaces real GPS for a fixed-wing UAV when GPS is denied/spoofed, by combining nav-camera frames + FC IMU + a pre-cached satellite tile basemap, and emits standard MAVLink external-positioning messages to ArduPilot or iNav at frame rate.
• Operating area: eastern/southern Ukraine, active-conflict zones (war-zone scene change is a first-class concern, not an edge case).
• Mission profile: 8-hour fixed-wing flights, ~60 km/h cruise, ≤1 km AGL, ~400 km² operational area.
• Pinned external deps: ADTi 20MP 20L V1 nav camera (APS-C); Jetson Orin Nano Super 8 GB / 25 W; MAVLink protocol; ArduPilot + iNav as supported FCs; QGroundControl as GCS; Azaion Suite Satellite Service (offline cache interface ≥0.5 m/px).
• Hard runtime envelope: <400 ms p95 end-to-end latency (camera → MAVLink), <8 GB shared CPU+GPU RAM, 25 W TDP at +50 °C ambient for 8 h continuous, no in-flight network, 10 GB persistent tile cache + 64 GB per-flight FDR.
• Hard safety envelope: P(error >500 m) <0.1 % per flight, P(error >1 km) <0.01 % per flight; honest covariance reporting; explicit dead_reckoned failsafe under simultaneous GPS spoof + visual blackout; cache-poisoning probability bounds for tiles written back to the Service.

Project Constraint Matrix

Dimension	Binding constraint
Inputs available	Nav camera frames @ 3 fps (5472×3648, ~12 cm/px GSD @ 1 km AGL); FC IMU (high rate via MAVLink); FC attitude/airspeed/altitude; pre-cached satellite tiles ≥0.5 m/px (offline); operator re-loc hint via GCS (rare).
Outputs required	WGS84 position to FC via MAVLink external-positioning message(s) accepted by ArduPilot AND iNav; per-frame estimate carrying honest 95 % covariance, source label {satellite_anchored, visual_propagated, dead_reckoned}, and last_satellite_anchor_age_ms; mid-flight ortho-tiles written to local cache with quality metadata; 1–2 Hz GCS summary; FDR records per AC-NEW-3.
Hardware fixed	Jetson Orin Nano Super (67 TOPS sparse INT8, 8 GB shared LPDDR5, 25 W TDP, JetPack/CUDA/TensorRT).
Lifecycle	Real-time embedded; offline (no in-flight network); 8 h continuous; persistent tile cache across flights; FDR rollover.
Non-functional	<400 ms p95 latency; <8 GB shared RAM; ≤25 W power at +50 °C ambient; AC-1.1/1.2 accuracy; AC-2.1/2.2 registration & MRE; AC-3.x resilience; AC-NEW-1 cold-start <30 s; AC-NEW-2 spoof promotion <3 s; AC-NEW-4 false-position safety; AC-NEW-7 cache-poisoning safety; AC-NEW-8 blackout failsafe.
Hard disqualifiers	Anything requiring >8 GB RAM peak (CPU+GPU shared); anything not runnable under JetPack on Orin Nano Super; anything requiring in-flight cloud calls; anything that cannot honestly report covariance; anything that does not have a runnable example for monocular nadir UAV input over season-matched satellite tiles; anything whose license blocks military / dual-use deployment.

Research Subject Boundary

Dimension	Boundary
Population	Fixed-wing UAVs, downward-fixed monocular nav camera, Jetson-class edge HW, ArduPilot or iNav autopilot. Excludes: multirotors, gimbal-stabilised nav cams, server/cloud GPS-denied stacks, PX4 (out of scope), commercial sat-imagery direct integration (Service handles upstream).
Geography	Eastern/southern Ukraine — agricultural steppe, active-conflict scene change. Validation must include this geography or representative analogues (low-texture cropland, snow, war-zone destruction).
Timeframe	Production deployment 2026; tools / libraries / models considered must be currently maintained (commits/releases in last 18 months OR explicit long-term-stable status). Critical-novelty domain — see Step 0.5 timeliness assessment.
Operating context	Real-time embedded; offline in-flight; 8 h continuous duty; 25 W power envelope; 8 GB shared CPU+GPU memory; thermal envelope to +50 °C ambient.
Required interfaces	Inputs: ADTi 20MP nav cam, FC IMU (MAVLink), satellite tile cache. Outputs: MAVLink external-positioning to ArduPilot AND iNav; QGroundControl summary; FDR; tile write-back to Suite Service on landing.
Non-functional envelope	Per AC-1 to AC-8 plus AC-NEW-1 to AC-NEW-8. Hardest binding constraints: 400 ms p95 end-to-end; 8 GB shared RAM; AC-NEW-4 false-position probability bounds; AC-NEW-7 cache-poisoning probability bounds.

Sub-Questions

ID	Sub-question
SQ1	What existing/competitor GPS-denied UAV navigation systems exist (academic + open-source + commercial + military), and which of them have been validated on fixed-wing UAVs in active-conflict environments? What works, what fails?
SQ2	What is the canonical decomposition of "monocular nadir UAV ↔ pre-cached satellite basemap localization" into pipeline components? Is the decomposition below complete, or are there industry-standard components missing?
SQ3	For each component (VO/VIO, VPR, cross-domain registration, single-frame orthorectification, sensor-fusion estimator, tile cache + spatial index, on-Jetson inference runtime, MAVLink FC adapter, dataset/SITL validation infrastructure): what option families exist (simple baseline / production / open-source / commercial / SOTA / adjacent-domain / no-build), and what are the leading candidates as of 2026?
SQ4	For each lead candidate per component: what are the documented runtime/memory/latency/license/maintenance constraints, and how do they bind against the Project Constraint Matrix? Per-mode API capability verification with context7 for every library/SDK lead.
SQ5	What are the documented failure modes and real-world deployment lessons for each component family? In particular: VPR collapse under cropland repetition, DINOv2/foundation-model cost on Jetson at int8, RANSAC degeneracy at sharp turns / low texture, EKF over-confidence on cross-domain matches, ortho geometric error from unknown bank/pitch.
SQ6	How do ArduPilot Plane (current stable) and iNav (current stable) each accept external positioning input via MAVLink? What message types does each support? Where do their interfaces diverge, and what is the documented status of each interface (stable / experimental / known bugs)?
SQ7	What public datasets, benchmarks, and SITL/replay environments exist for cross-validating monocular nadir UAV navigation against satellite basemaps in season-matched + change-affected conditions? AerialVL, AerialExtreMatch, others?
SQ8	What are the security and safety considerations specific to the AC-NEW-4 (false-position) and AC-NEW-7 (cache-poisoning) safety budgets, including spoofing-detection signals from FC, ortho-tile geo-alignment quality estimation, and write-back cache-poisoning controls?
SQ9	What does the system look like end-to-end — wiring, scheduling, threading model, inference scheduling on shared CPU+GPU memory, cold-start sequencing, FDR rotation, and pre-flight cache provisioning workflow? (synthesis question, answered in Step 8)

Component Areas (search plan)

For each component below, the search plan covers all option families per Component Option Search Plan rules (research/steps/03_engine-investigation.md → "Component Option Breadth").

#	Component area	Required outputs	Key option families to enumerate
C1	Visual / Visual-Inertial Odometry (frame-to-frame motion when satellite anchor is unavailable)	Relative 6-DoF pose between consecutive frames or short windows; output frequency ≥3 Hz; metric scale (with IMU)	Classical (VINS-Mono / VINS-Fusion / OpenVINS), Kimera, ORB-SLAM3, OKVIS2, MSCKF-class, learning-based (DROID-SLAM, DPVO), pure VO baseline (KLT + RANSAC homography), no-build (skip and rely on pure satellite re-anchor every frame)
C2	Visual Place Recognition (VPR) — UAV nadir frame → top-K satellite chunks	Compact global descriptor per UAV frame and per cache chunk; cosine-rank top-K candidates	NetVLAD class, MixVPR, EigenPlaces, BoQ, AnyLoc (DINOv2 + VLAD), CricaVPR, foundation-model direct retrieval (DINOv2/DINOv3/SAM 2 / SuperGlobal)
C3	Cross-domain registration (UAV nadir ↔ ortho satellite tile, after VPR top-K)	Sub-pixel alignment + 6-DoF camera pose w.r.t. tile, with inlier ratio + covariance	Local-feature matching (SuperPoint+SuperGlue / LightGlue / DISK+LightGlue / ALIKED+LightGlue / XFeat), dense matchers (LoFTR / RoMa / DKM / MASt3R), classical (SIFT+RANSAC), specialized cross-domain (CMRNet+, CroCoMatch class), templating (mutual-information / ECC), no-build (skip cross-domain; rely on direct frame-to-tile homography from VPR retrieval)
C4	Single-frame orthorectification (nav frame → basemap-aligned tile, given current pose)	Ortho-rectified tile chunk with geo metadata + quality score	Single-frame perspective warp with flat-earth assumption; OpenCV homography; bundled-DEM-aware (rare for flat steppe — likely overkill); GDAL warp utilities; custom GPU shader on Jetson
C5	State estimator / sensor fusion (VO + IMU + sat anchors → fused estimate with covariance)	WGS84 position + 3D velocity + attitude + 6×6 covariance, frame-rate output, honest covariance, source label	EKF (manual), ESKF (manual or via library), MSCKF, factor-graph (GTSAM, iSAM2), particle filter, learned (out-of-scope for safety budget). Supporting: Mahalanobis outlier gates
C6	Tile cache + spatial index (storage + retrieval of basemap tiles + descriptors, with manifests, freshness, dedup, and write-back)	mmap-friendly storage; ANN over global descriptors; spatial query for geographic prior; manifest schema per AC	Storage: GeoTIFF + COG, MBTiles, custom flat layout. ANN: FAISS (IVF/PQ/HNSW), hnswlib, ScaNN, brute-force (small index). Spatial: R-tree / KD-tree / GeoPandas / SQLite+SpatiaLite. Manifest: SQLite, JSON-per-tile, Parquet sidecar
C7	On-Jetson inference runtime	INT8/FP16 inference of the chosen VPR + matcher models within latency + memory budget	TensorRT (native), Torch-TensorRT, ONNX Runtime + TRT EP, NVIDIA Triton (probably overkill), pure PyTorch fp16, NVIDIA DeepStream (for video), CUDA-Python custom kernels
C8	MAVLink FC adapter (per-FC external-positioning emission + spoofing-signal subscription, for ArduPilot AND iNav)	MAVLink frames consumed by ArduPilot Plane and iNav as external position; spoofing signals consumed from each FC	Libraries: pymavlink (per-message), MAVSDK (high-level), ArduPilot/iNav SITL for verification. Per-FC choice of message: GPS_INPUT vs ODOMETRY vs VISION_POSITION_ESTIMATE vs GLOBAL_POSITION_INT (documented capability per FC must be verified, not assumed)
C9	Datasets + SITL / replay — DROPPED from research scope per 2026-05-08 restructure (user choice A); deferred to Test Spec (greenfield Step 5). See "C9 / SQ7 Restructure" section below.	—	—
C10	Pre-flight cache provisioning + sector classification + freshness pipeline (RESEARCH SCOPE NARROWED 2026-05-08 to cross-coupling minimal — see "C10 Scope Restructure" section below)	(in research scope) confirmed orchestration mechanism for descriptor-cache rebuild (D-C6-3) + TensorRT engine build (D-C7-7) at pre-flight; on-disk artifact format(s); time/memory budget; failure-mode + retry behavior. (deferred to Plan-phase) operator CLI/desktop tool design, sector classification heuristics, freshness pipeline workflow.	(in research scope) FAISS Python API for write_index/read_index orchestration; TensorRT build orchestration trtexec CLI vs Python IBuilderConfig vs Polygraphy. (deferred) custom CLI/desktop, QGC plan files, MAVProxy, Mission Planner integration patterns.

Perspectives Chosen (≥3 mandatory)

1. Implementer / Engineer — Will the chosen stack actually compile, link, and run on the pinned Jetson within the latency + memory budget? Pitfalls of MAVLink GPS injection on each FC. Sub-pixel registration on UAV-nadir × ortho satellite. Inference-scheduler contention on shared CPU+GPU memory.
2. Practitioner / Field — What do UAV teams actually report from GPS-denied missions in real war-zone deployments? (Ukraine context if findable; otherwise analogous high-stakes deployments.) Real-world VPR collapse on agricultural cropland / snow / season change. Real-world FDR usefulness for post-mission forensics.
3. Domain expert / Academic — Recent (2024–2026) VPR + cross-domain matching benchmarks and their relative ranks under cross-season / cross-domain / cross-altitude conditions. Foundation-model-based VPR (AnyLoc, BoQ, MASt3R) — academic claims vs reproducibility. Recent factor-graph vs ESKF comparisons.
4. Contrarian / Devil's advocate — Why might foundation-model VPR fail on the Jetson budget? Where does cross-domain matching degrade silently? When does ortho-tile write-back amplify bad poses? When does honest covariance turn into "system never trusts itself" (over-cautious failure)?

Search Query Variants per Sub-Question

(Detailed query lists are appended below per sub-question; these will be executed in Step 2 and saved to the 01_source_registry/ folder, indexed by 01_source_registry/00_summary.md. The shape is shown here so the search plan is auditable; the full execution log will populate downstream files.)

SQ1 (existing systems / competitors): "GPS-denied UAV navigation 2025", "visual GPS denied fixed wing UAV", "satellite map matching UAV localization 2024 2025", "Ukraine UAV GPS spoofing countermeasures", "ARL ANT Project visual navigation", "vision-based GPS replacement UAV production", "UAV GPS spoofing real-world deployment 2025".

SQ2 (canonical pipeline): "visual aerial localization pipeline survey", "UAV satellite map matching architecture", "monocular UAV global localization pipeline 2024 2025".

SQ3 / SQ4 (per-component candidates + binding): per-component query templates (5+ variants each) — see Step 2 plan in 01_source_registry/00_summary.md once initialised. Each lead library/SDK candidate triggers the mandatory context7 per-mode capability verification per research/steps/03_engine-investigation.md.

SQ5 (failure modes): "VPR cropland failure", "DINOv2 Jetson Orin Nano latency", "SuperGlue LightGlue Jetson Orin", "ESKF cross-domain over-confidence", "RANSAC homography low-texture failure UAV", "ortho photo geometric error airframe tilt".

SQ6 (ArduPilot vs iNav external positioning): "ArduPilot Plane GPS_INPUT external", "ArduPilot ODOMETRY EKF3 source switching", "iNav external positioning MAVLink GPS_INPUT", "iNav MAVLink GPS substitute", "iNav GPS denied flight 2025", "ArduPilot vs iNav external nav comparison".

SQ7 (datasets): "AerialVL dataset", "AerialExtreMatch", "VPR-Bench cross-season aerial", "Mid-Air UAV dataset", "Mavic Mavik UAV public flight dataset", "satellite-aerial cross-view localization benchmark".

SQ8 (safety): "MAVLink GPS_RAW_INT spoofing detection", "EKF lane switch ArduPilot", "covariance under-reporting risk EKF", "geo-misalign detection ortho tile".

Completeness Audit

Probes (per references/comparison-frameworks.md → Decomposition Completeness Probes — applied here without re-reading the full file; will reconcile during Step 2):

Probe	Coverage
Functional decomposition complete?	C1–C10 cover all data flows from camera in to MAVLink out + back. ✓
Non-functional dimensions covered?	Latency, memory, accuracy, safety, freshness, security all in Project Constraint Matrix. ✓
Failure-mode dimension covered?	SQ5 explicitly. ✓
Cost / TCO dimension?	Hardware is pinned (Jetson Orin Nano Super); Service-side cost is out of scope; SW cost = mostly open-source candidates. Will revisit during Phase 3 (tech stack consolidation) if commercial options emerge. ✓
Maintenance / community-health dimension?	SQ4 binds it per candidate. ✓
Adjacent-domain dimension?	Robot SLAM, AGV warehouse navigation, aerial photogrammetry will be searched as analogues. ✓
Validation / dataset coverage?	Deferred to Test Spec (greenfield Step 5) per 2026-05-08 C9 / SQ7 restructure — fixture-class, not research-class. Dataset shortlist preserved for handoff.
Integration / boundary coverage?	SQ6 (FC adapters) + C8 + C10 (pre-flight provisioning). ✓
Operational/human-factors?	Pre-flight cache provisioning (C10) and operator re-loc hint (AC-3.4) covered. Mission-planning UX is out of scope. ✓
Security / threat model?	SQ8. Will deepen in Phase 4 (Security Deep Dive) if invoked. ✓

No major gap detected at decomposition time. If domain-discovery searches in Step 2 surface a missed dimension, a "gap-fill" entry will be appended here.

Notes on Output-Class Mode-Verification

Because this is Technical-component selection, every lead library/SDK candidate triggers:

• Pinned mode/configuration sentence in 02_fact_cards/Cx_*.md (per-component sub-files).
• context7 lookup with the three mandatory queries (mode enumeration; project's exact mode runnable example; disqualifier probe).
• MVE block per candidate.
• Per-numbered-Restriction and per-numbered-AC binding (Pass / Fail / Verify / N/A).
• Two modes of one library = two distinct candidates.

Step 0.5 — Novelty Sensitivity Assessment

Classification: Critical sensitivity.

Justification:

• Foundation-model VPR is moving fast: DINOv2 (Apr 2023), AnyLoc (Aug 2023), BoQ (CVPR 2024), MASt3R (May 2024), MASt3R-SfM / new VPR-leader candidates 2025; rankings on cross-season aerial benchmarks have shifted multiple times since 2023.
• ArduPilot Plane / iNav external-positioning interfaces have moved: ArduPilot EKF3 source-switching parameters and known double-fusion bugs between GPS_INPUT and ODOMETRY were a moving target through 2024–2025; iNav GPS-denied support has matured separately.
• TensorRT / JetPack stacks on Jetson Orin Nano Super have version-dependent INT8 quantisation behaviour and runtime tooling differences worth verifying against current releases.
• Public aerial-localization datasets (AerialVL, AerialExtreMatch, etc.) have had multiple revisions and added splits.

Source-time-window rules for this run:

• Lead-candidate selection / SOTA claims: prioritise sources from last 6 months; allow up to 18 months if no newer source covers the same claim and the older source is the official authority.
• Established baselines / classical algorithms (KLT, RANSAC, EKF, ORB, SIFT, GTSAM): no time window — canonical references are fine.
• Library/SDK API behaviour: must be verified against the currently shipped version at the time of search (context7 mandatory per lead candidate; release notes / changelog cross-checked).
• Cross-validation: every Critical-sensitivity claim that drives a candidate selection must have ≥2 independent sources or one official + one runnable MVE; single-source SOTA claims must be downgraded to Experimental only at Step 7.5 unless cross-validated.

SQ2 Closure — Pipeline-component coverage table (Mode A Phase 2, Step 3 result)

The C1–C10 decomposition was sanity-checked against five independent surveys/benchmarks (Skoltech aerial-VPR survey, U.Maine cross-view survey, OrthoLoC benchmark, AnyVisLoc benchmark, NUDT 2026 absolute-VL survey — all logged in 01_source_registry/SQ2_canonical_pipeline.md as Sources #38–#42). The canonical hierarchical framework retrieval → matching → pose-estimation is unanimously confirmed; project's split is canonical, not novel. Two augmentations are required.

Survey/benchmark canonical stage	Project component	Coverage status	Required action
Image retrieval (global VPR)	C2 — VPR	✅ covered	None
Re-ranking (top-N inlier-based)	(implicit, inside C2/C3)	⚠️ implicit	Promote to explicit sub-stage in solution_draft01
Local image matching (2D-2D, sparse or dense)	C3 — Cross-domain registration	✅ covered	Add Top-N inlier re-rank requirement
AdHoP-style perspective preconditioning	(not represented)	❌ missing	Add as optional sub-stage between C3 and C4, gated on Jetson latency budget
2D-3D lift via DSM	(not represented; current cache is 2D ortho only)	❌ architectural decision required	Decision required from user — see "Open architectural decisions" below
Pose estimation (PnP + RANSAC + LM)	C4 — Pose estimation	✅ covered	None
State estimator / fusion	C5 — Estimator / fusion	✅ covered	Augmented with covariance-honesty contract (already from AC-NEW-4)
IMU + VIO contract	C1 (VIO) + C6 (Tile cache) ⁂	✅ covered	Add yaw σ ≤ 5°, pitch σ ≤ 5° hard contract (Fact #24)
Tile cache + scheduler	C6 (Tile cache + spatial index)	✅ covered	Add 20% covisibility runtime invariant (Fact #27)
On-Jetson runtime	C7 — On-Jetson inference runtime	✅ covered	Pre-screen prunes non-viable candidates (Fact #26)
Anti-spoof / FC adapter	C8 — MAVLink FC adapter	✅ covered	Already addressed by SQ6
Datasets / SITL / replay	Deferred to Test Spec (greenfield Step 5) per 2026-05-08 C9 / SQ7 restructure	⚠️ moved out of research scope	Test Spec owns dataset-corpus selection, SITL framework choice (ArduPilot Plane SITL + iNav SITL/HITL), and replay framework choice
Pre-flight cache provisioning	C10 — Pre-flight cache + sector classification	✅ covered	None

⁂ The "IMU integration" concern lives in C1 (VIO) and partially flows from FC IMU; there is no separately numbered IMU component in the original C1–C10 split. SQ2 confirms this was correct — IMU is best owned by C1 (VIO) which already produces the yaw/pitch attitude. The σ ≤ 5° contract belongs on C1's output interface.

SQ2 — Architectural decisions (resolved by user, 2026-05-07)

#	Decision	Choice	Implication for SQ3+SQ4
1	DSM dependency on Suite Sat Service tile cache (Fact #23)	(a) 3-DoF acceptance — fix attitude from IMU/VIO, ignore DSM; current 2D-ortho cache contract preserved.	C6 (Tile cache) candidate matrix excludes DSM-dependent storage formats. C3 (matcher) candidates evaluated on 2D-2D output (homography) only. Yaw/pitch σ ≤ 5° (Fact #24) is noted as an empirical requirement on C1's output but NOT bound as a hard interface contract — emerges as an output of C1 candidate selection in SQ3+SQ4. AC-1.1.1 (≤80 m at 1 km AGL) likely satisfied per DSMAC-class lineage in Fact #17; if AC ever tightens, revisit option (b).
2	AdHoP refinement loop (Fact #22)	(b) Conditional — only invoked when initial reprojection error exceeds a threshold.	C3 (matcher) latency budget = base (single-pass) + AdHoP-conditional overhead (worst-case 2× when triggered). Per-frame Jetson MVE must measure both modes. The reprojection-error threshold becomes a SQ3+SQ4 hyperparameter.
3	Top-N re-rank promotion (Fact #25)	(a) Promote to an explicit named sub-stage between C2 and C3.	SQ3+SQ4 will hyperparameter-sweep N ∈ {5, 10, 15, 20}; C2 candidates evaluated jointly with re-rank cost. Top-N re-rank by inlier-count is now a hard pipeline component, not implicit.

SQ2 — Component-pruning carried into SQ3+SQ4 (Jetson-pre-screen result)

Per Fact #26 (RTX-3090-measured runtime → conservative Jetson-Orin-Nano translation):

• C2 candidates entering SQ3+SQ4 with mandatory Jetson MVE: MixVPR, SALAD, SelaVPR, EigenPlaces, NetVLAD.
• C2 candidates entering SQ3+SQ4 conditional on INT8 quantization path: AnyLoc, BoQ, DINOv2-VLAD.
• C2 candidates pruned outright: SuperGlue-as-reranker (latency).
• C3 candidates entering SQ3+SQ4 with mandatory Jetson MVE: LightGlue, XFeat, XFeat*, SP+LightGlue (NGPS template confirmed).
• C3 candidates pruned outright: RoMa, MASt3R, DKM (dense-matcher latency on Jetson).
• C3 candidates as "AerialExtreMatch reference points" only: GIM+DKM, GIM+LightGlue (per Source #40 — accuracy benchmark, not for production deployment).

C9 / SQ7 Restructure (2026-05-08, user choice A)

Decision: drop C9 (Datasets + SITL / replay) entirely from the research scope. Defer dataset-corpus selection, SITL framework choice (ArduPilot Plane SITL + iNav SITL/HITL), and replay framework choice (custom vs PX4-Avionics-Replay-style) to Test Spec (greenfield Step 5). Pull D-C7-1 (calibration-dataset-strategy) back inside C7 batch 1 and close it there.

Rationale: datasets are test fixtures, not architectural commitments. They feed into Test Spec → Decompose Tests → Implement Tests, not into the deployed pipeline on the Jetson. They don't bind against the AC-4.1 / AC-4.2 / R-NEW-2 / R-NEW-4 envelope. Choosing among AerialVL S03 vs AerialExtreMatch vs VPR-Bench vs MahalNotchVPR / Mid-Air UAV vs the project's own Mavic + Derkachi flight footage is a "what evidence proves the system meets AC-X" question, not a "what gets implemented on the Orin Nano" question. SITL and replay framework choice are test-infra commitments rather than runtime commitments; SITL framework is largely deterministic at this point (ArduPilot Plane SITL + iNav SITL/HITL are the canonical paths the locked C8 closure already implies).

Effective changes:

• Component Areas table: C9 removed; remaining components are C1–C8 + C10.
• Sub-Questions table: SQ7 is deferred to Test Spec (Step 5) — its query variants and dataset shortlist remain documented here for handoff but are not researched in this Mode A run.
• SQ2 closure table: "Datasets / SITL / replay" row → "Deferred to Test Spec".
• D-C7-1 (calibration-dataset-strategy): closed inside C7 batch 1. Strategy = prefer real UAV nadir flight footage at ~1 km AGL over season-matched satellite tiles as the calibration corpus distribution; specific fixture-file selection (AerialVL S03 vs project's Mavic + Derkachi clips vs other corpora) is fixture-class and delegated to Test Spec. Synthetic-tile augmentation via random homography is a documented low-data fallback, only invoked if real flight footage is insufficient for Recall@K-target calibration.
• Cross-component gates: D-C7-1 is no longer cross-coupled to C9; owner narrows to Plan-phase architect (closed at research time).
• Cross-row dependencies in C7 / C8 fact cards and fit-matrix files: every "C9 datasets / SITL / replay row when opened" reference becomes "Test Spec (Step 5) when opened".

Carryforward to Test Spec (Step 5) — preserved here so Test Spec's first invocation has the handoff payload ready:

• Dataset shortlist: AerialVL (VISTA / NTU), AerialExtreMatch, VPR-Bench, MahalNotchVPR / Mid-Air UAV, project's own Mavic + Derkachi flights.
• SITL frameworks: ArduPilot Plane SITL (canonical), iNav SITL/HITL (canonical); Gazebo / Webots noted-and-rejected as overkill for the spoof-promotion + visual-blackout failsafe scenarios that AC-NEW-2 and AC-NEW-8 actually exercise.
• Replay frameworks: PX4-Avionics-Replay-style canonical reference; custom Python harness as the lightweight default if PX4 replay's MAVLink-injection point doesn't cleanly match the C8 closure's per-FC injection cadence (5 Hz GPS_INPUT for AP / 5 Hz MSP2_SENSOR_GPS for iNav).
• SQ7 query variants (carried forward verbatim from above): "AerialVL dataset", "AerialExtreMatch", "VPR-Bench cross-season aerial", "Mid-Air UAV dataset", "Mavic Mavik UAV public flight dataset", "satellite-aerial cross-view localization benchmark".
• Test-coverage obligations Test Spec must answer:
  • Which corpora exercise which AC (AC-1.1 / AC-1.2 / AC-2.1 / AC-2.2 / AC-3.1 / AC-3.2 / AC-3.3 / AC-3.4 / AC-NEW-1 / AC-NEW-2 / AC-NEW-4 / AC-NEW-7 / AC-NEW-8).
  • SITL test-harness shape exercising AC-NEW-2 spoof-promotion <3 s end-to-end on both ArduPilot Plane SITL and iNav SITL/HITL (per locked C8 batch 1 closure cross-component decision D-C8-2).
  • Replay-fixture format compatible with both C8 injection paths (pymavlink GPS_INPUT for AP, YAMSPy MSP2_SENSOR_GPS for iNav).
  • INT8 calibration corpus pin (specific files satisfying the C7 batch 1 D-C7-1 strategy = real UAV nadir flight footage at ~1 km AGL over season-matched satellite tiles).

C10 Scope Restructure (2026-05-08, user choice C — cross-coupling minimal)

Decision: narrow C10 (Pre-flight cache provisioning + sector classification + freshness pipeline) research scope to the two cross-coupling confirmation sub-areas. Defer the operator-side CLI/desktop tool, sector classification heuristics, and tile age-stamping/freshness schema to Plan-phase as operator tooling design out-of-research-scope.

In-scope (C10 batch 1):

1. D-C6-3 confirmation — descriptor-cache rebuild trigger pipeline. Recommendation inherited from C6 batch 1 (Fact #92 + D-C6-3) = periodic rebuild during C10 pre-flight provisioning + faiss.write_index serialize + load-at-takeoff in <5 s. Confirmation work: pin the orchestration tool (FAISS Python API vs subprocess invocation), the trigger semantics (manifest hash change vs operator-manual vs new-tile-delivered), the on-disk file format, the rebuild time budget at pre-flight, and the failure-mode + retry behavior.
2. D-C7-7 confirmation — TensorRT engine-build pipeline. Recommendation inherited from C7 batch 1 (Fact #94 + D-C7-7) = primary build-on-deployed-Jetson during pre-flight + reference-Jetson-built engines as fallback. Confirmation work: pin the build-orchestration tool (trtexec CLI vs Python IBuilderConfig vs Polygraphy), the calibration-corpus shipping mechanism into the pre-flight build (per D-C7-1 closure: real UAV nadir flight footage at ~1 km AGL over season-matched satellite tiles), the per-model build-duration budget, the retry/fallback logic on build failure, and the on-disk engine cache layout.

Out-of-research-scope (deferred to Plan-phase):

• Operator-side CLI/desktop tool design (mission-prep tooling shape; CLI vs GUI; integration with QGC plan files / MAVProxy / Mission Planner equivalents).
• Sector classification (active-conflict vs stable rear) heuristics + interface — used to decide AC-8.2 freshness threshold (6 mo vs 12 mo).
• Tile age-stamping + freshness schema beyond what AC-8.2 + AC-NEW-6 already mandate.

Rationale for narrowing:

• The C6 and C7 closures already locked architectural recommendations (periodic rebuild during pre-flight and build-on-deployed-Jetson at pre-flight). What remains is mechanism confirmation, not candidate enumeration.
• The deferred items are fixture/operator-tooling-class concerns. Their cross-coupling with the runtime architecture is mediated entirely by the descriptor-cache file and the TensorRT engine cache file — both fixed by the in-scope confirmations. Operator tool design can iterate freely at Plan-phase without touching runtime contracts.
• Aligns with the C9-restructure precedent: keep research focused on architecture-binding decisions; push fixture/tooling decisions to the phases that own them.

Effective changes:

• Component Areas table: C10 row preserved with reduced scope. Per-FC details below.
• Required outputs for C10 in the table: narrows from Tooling (operator-side) to pull tiles from Suite Sat Service for an operational area, classify active-conflict vs stable rear, age-stamp, populate descriptor index to Confirmed orchestration mechanism for descriptor-cache rebuild + TensorRT engine build at pre-flight; on-disk artifact format(s); time/memory budget; failure-mode + retry behavior.
• Cross-component gates: D-C6-3 and D-C7-7 remain owned jointly with C10; new C10-internal decisions D-C10-x will be added at C10 batch 1 closure.
• SQ5 interleaving: limited C10 SQ5 facts (failure modes during pre-flight build/rebuild) collected during this batch.

Carryforward to Plan-phase — operator-tooling design issues preserved here so Plan-phase has a starting list:

• Tool shape: integrate as a sub-command of Mission Planner / QGC plan-file workflow vs standalone CLI vs lightweight desktop GUI.
• Sector-classification source: operator-marked geofence polygons vs Suite Sat Service metadata vs hybrid.
• Tile age-stamping: per-tile capture date in manifest (already mandated by restrictions.md) vs additional sector-class tag vs full audit trail per AC-NEW-7.
• Freshness pipeline: when to re-pull from Suite Sat Service (every flight, weekly, on operator demand, on sector-class change).

Next Step

SQ1 ✓ → SQ2 ✓ (with three architectural decisions resolved) → SQ3+SQ4 per component (C1→C8) ✓ → C10 batch 1 in progress (cross-coupling minimal scope, 2 sub-areas: D-C6-3 + D-C7-7 confirmation) → SQ5 interleaved → SQ8 → SQ9 synthesis at engine Step 8.

(SQ7 deferred to Test Spec per C9 restructure; C9 dropped; C10 operator-tooling-design deferred to Plan-phase per the C10 scope restructure above.)

Pipeline shape (final, post-C10-restructure): C1 (VIO) → C2 (VPR) → Top-N re-rank by inlier count → C3 (matcher) → AdHoP-conditional refinement → C4 (PnP+RANSAC+LM) → C5 (estimator) → C8 (FC adapter) with C6 (cache, 2D ortho) + C7 (Jetson runtime) + C10 (pre-flight orchestration: descriptor-cache rebuild + TensorRT engine build) cross-cutting.

First C1 (VIO) candidate batch: VINS-Mono / VINS-Fusion / OpenVINS / OKVIS2 / DROID-SLAM / DPVO / pure-VO baseline (RTAB-Map and ORB-SLAM3 already pruned by Fact #16). Per-mode context7 capability verification mandatory for every lead library/SDK candidate.