gps-denied-onboard/_docs/00_research/04_reasoning_chain.md

# Reasoning Chain

> Mode A Phase 2 — engine Step 6 (Fact-to-Conclusion Reasoning Chain). Walks each dimension from `03_comparison_framework.md` as `fact → mechanism comparison → conclusion`. Conclusions come from mechanism comparison, not "gut feelings" (per `references/quality-checklists.md`).
>
> Backing artifacts: source registry [`01_source_registry/00_summary.md`](01_source_registry/00_summary.md) (#1–#121); fact cards [`02_fact_cards/00_summary.md`](02_fact_cards/00_summary.md) (#1–#101); component fit matrix [`06_component_fit_matrix/00_summary.md`](06_component_fit_matrix/00_summary.md); cross-component gates [`06_component_fit_matrix/99_cross_component_gates.md`](06_component_fit_matrix/99_cross_component_gates.md).

---

## Dimension 1: Solution overview — pipeline shape

### Fact Confirmation

The canonical GPS-denied UAV navigation pipeline converges on **`retrieval → matching → pose-estimation → fusion`** with VIO/IMU as auxiliary, per multiple SQ2 surveys (Skoltech aerial VPR, U.Maine cross-view, OrthoLoC 2.5D geodata, AnyVisLoc low-altitude multi-view, NUDT 2026 sciopen survey — Sources #38–#42; Facts in `02_fact_cards/SQ2_canonical_pipeline.md`).

### Reference Comparison

End-to-end visual-localization (single-network direct lat/lon regression) was rejected per Source #38 evidence of poor cross-domain generalization + no native covariance output. Twist Robotics OSCAR (Ukrainian peer, deployed; Source #25), Auterion Artemis (Skynode N + Visual Navigation, Ukraine-tested; Source #31), and snktshrma/ngps_flight (NGPS GSoC 2024 — LightGlue+SuperPoint+UKF+VISION_POSITION_ESTIMATE; Source #33) all converge on the same hierarchical retrieval+matching+pose+EKF pipeline.

### Conclusion

The project's pipeline shape is **C2 (VPR retrieval) → C3 (cross-domain matcher) → C4 (PnP+RANSAC+LM pose) → C5 (state estimator fusion with C1 VIO + IMU) → C8 (per-FC adapter to deliver pose to flight controller)**, with C6 (tile cache + spatial index) feeding C2 retrieval and C7 (on-Jetson inference runtime) hosting all learned models, and C10 (pre-flight cache provisioning) building C6's descriptor cache + C7's TensorRT engines before takeoff. **No deviation from the canonical pipeline is justified by evidence**.

### Confidence

✅ High — five independent SQ2 surveys agree; three independent SQ1 deployed/peer systems agree; rejection of end-to-end alternatives is L1-evidence-backed.

---

## Dimension 2: Implementation cost & dependency footprint

### Fact Confirmation

Per-component implementation-cost cells in `03_comparison_framework.md` row 2 sum to a roughly **8-12 week** integration window for the recommended primary candidates (single engineer FTE, no parallelization), broken down: C1 OKVIS2 ~1-2 wk; C2 MixVPR base ~3-5 days + D-C2-1 retrain ~1-2 wk; C3 DISK+LightGlue ~1 wk + retrain ~1-2 wk; C4 OpenCV+GTSAM ~3-5 days; C5 Manual ESKF ~1-2 wk + GTSAM iSAM2 ~2-3 wk; C6 mirror-suite-pattern ~3-5 days; C7 TensorRT engine builds ~1 wk first model + ~1 day each subsequent; C8 pymavlink+MSP2 ~1 wk total; C10 orchestration wrapper ~1 wk. Plus the dedicated Jetson MVE bring-up phase (D-C1-2) ~1-2 weeks before any candidate can be locked.

### Reference Comparison

Selecting GPL-3.0-track candidates (D-C1-1 = (a)) costs roughly the same engineering time but adds license-track gating (forces SALAD over MixVPR for C2; forces VINS-Fusion or OpenVINS over OKVIS2/Kimera-VIO for C1). Selecting Cand 2 (PostGIS+pgvector) over Cand 1 (mirror-suite-pattern) for C6 adds ~1-2 weeks PostGIS+pgvector co-installation Jetson MVE work + cross-suite cascade decision (D-C6-7). UBX impersonation (Cand 3 for C8) adds ~1-2 weeks vs MSP2_SENSOR_GPS without measurable benefit.

### Conclusion

**Recommended implementation order**: C8 (FC adapter) + C7 (Jetson runtime) + C6 (cache) before C2/C3 (because the latter depend on the former for pre-flight build + runtime hosting), then C2/C3 (with parallel D-C2-1 retrain), then C1+C4+C5 in parallel (each consumes an independent input class), then C10 orchestration wrapper as the integration capstone. Gives a parallelizable critical path of ~6-8 weeks for two engineers + ~2-week Jetson MVE bring-up overlap.

### Confidence

⚠️ Medium — engineering estimates are L3 inferential (no L1 measured-time evidence), but per-component closure verdicts in `06_component_fit_matrix/Cx_*.md` cite the specific work items and their L1 supporting docs.

---

## Dimension 3: Maintenance cost & dependency stability

### Fact Confirmation

The recommended primary stack consists of dependencies whose maintenance posture is verified at access time (`02_fact_cards/Cx_*.md` per-fact "Date accessed" lines):
- OpenCV LTS 4.x — stable since 2018 (Source #82+#83); Apache-2.0
- GTSAM — daily-active, last-pushed 2026-05-08 = TODAY at access time (Source #86+#87+#90+#91); BSD-3-Clause
- TensorRT 10.3 — bundled with JetPack 6.2; Apache-2.0 in TRT 10.x (Source #99+#104+#105)
- LightGlue — active 2025-2026 (Source #69+#70+#71); Apache-2.0
- DISK — Apache-2.0 (Source #76+#77); paper 2020 + active maintenance
- pymavlink — LGPL-3.0 (Source #106); ArduPilot-canonical
- FAISS — MIT (Source #114); Facebook Research, daily-active

The most-stale recommended primary dependency is OpenGV (Source #84) with a last-pushed of 2023-06-07 — gated behind D-C4-3 (license clearance) + D-C4-4 (maintenance staleness mitigation) closures because it is recommended only as the modern-competitive-lead-richer-minimal-solver for C4, not as the primary path.

### Reference Comparison

The Jetson AI Lab community wheels (D-C7-3 + D-C7-4 + D-C7-5) are the highest dependency-pin risk in the stack — they're community-maintained and have a release cadence independent of upstream PyTorch/onnxruntime-gpu. Mitigation: D-C7-3 = (c) mirror to project-controlled artifact registry; D-C7-9 lock JetPack 6.2 + TRT 10.3 for first deployment.

### Conclusion

**Maintenance posture is BSD/permissive-clean across the recommended primary stack**, with two contained risks: (a) Jetson AI Lab community-wheel cadence (mitigated via D-C7-3 mirror), (b) OpenGV staleness (mitigated via D-C4-4 fork-and-patch). No recommended primary dependency is on a deprecated, abandoned, or reverse-license-shifted project.

### Confidence

✅ High — every dependency's maintenance signal verified via L1 source (GitHub last-pushed timestamp + license file + canonical doc index).

---

## Dimension 4: Risk assessment — license, hardware, cross-domain transfer

### Fact Confirmation

Three categories of risk, per the cross-component gates file `99_cross_component_gates.md`:

**License risk**: D-C1-1 user-decision split (BSD/permissive vs GPL-3.0 vs both) drives candidate eligibility per row. Hard disqualifiers: canonical SP+LightGlue (Magic Leap noncommercial — D-C3-1 forced mitigation); MASt3R (CC-BY-NC). Contingent: SALAD (GPL-3.0; D-C2-N gating); PostGIS (GPL-2.0-or-later; D-C6-7 gating); pymavlink (LGPL-3.0; D-C8-3 mitigation = bundle unmodified per LGPL §6).

**Hardware-target risk**: TensorRT engines are tied to (SM 87, JetPack 6.2, TRT 10.3, precision mode) per Source #105 — cannot be transferred between Jetson SKUs or across JetPack point releases. Mitigation: D-C7-7 = (c) primary build-on-target + reference-Jetson fallback; D-C10-7 self-describing filename schema; D-C10-8 reference Jetson at HQ + deployed-Jetson-copy-to-archive.

**Cross-domain transfer risk**: All C2 VPR candidates are street-view-pretrained (per Facts in `02_fact_cards/C2_vpr.md`); D-C2-1 retrain on aerial corpus is required to close the cross-domain gap. AnyVisLoc + AerialExtreMatch + OrthoLoC 2.5D surveys (Sources #34, #40, #41) all confirm street-view → aerial cross-domain transfer is the dominant accuracy-loss source.

### Reference Comparison

Rejected risk-mitigation alternatives:
- "Ship without retrain" — would violate AC-1.1/1.2 frame-center accuracy on cross-domain UAV-vs-satellite-tile inference.
- "Build TensorRT engines on x86 dev machine and copy to Jetson" — IMPOSSIBLE per Source #105 hardware-tied constraint.
- "Skip license posture and ship under permissive default" — would force project to either (a) accept GPL-3.0 contagion if user-chosen GPL-3.0 candidates are linked, or (b) silently exclude GPL-3.0 candidates without user awareness.

### Conclusion

**Risk is decomposable into three independent gates**: license-track (D-C1-1) for source eligibility, hardware-tied-engine (D-C7-7 + D-C10-5..D-C10-8) for runtime artifact provenance, cross-domain transfer (D-C2-1) for accuracy. Each gate has a closed mitigation pathway. No risk is open-ended.

### Confidence

✅ High — every cited risk has an L1-evidence-backed mitigation path documented in the cross-component gates file.

---

## Dimension 5: Expected benefit — quantified lift over mandatory baseline

### Fact Confirmation

Per-component documentary lift over each component's mandatory simple-baseline:
- **C1**: OKVIS2 vs VINS-Mono — modern-competitive lift on cross-domain tracking robustness (Fact #44 / Fact #47); not quantified at the per-pixel error level.
- **C2**: SALAD-full vs MixVPR-2048 = +5-7 R@1 on MSLS Challenge (Fact in `C2_vpr.md`); EigenPlaces vs MixVPR = -0.6 R@1 at 512-D variant (paper Tab 3, Fact #20).
- **C3**: DISK+LightGlue vs canonical SP+LightGlue = +7.99 absolute AUC@5° on IMC 2020 stereo (LightGlue paper Appendix A Table 6, Fact in `C3_matchers.md`); ALIKED vs SP = +1-3 absolute AUC@5° per ALIKED paper Table VII.
- **C4**: GTSAM `Marginals` vs OpenCV `solvePnPRansac` post-hoc Jacobian = NATIVE 6×6 covariance recovery vs ~3-5 day engineering cost for hand-rolled Jacobian + Schur complement (Fact #54 vs Fact #52).
- **C5**: GTSAM iSAM2 vs Manual ESKF = NATIVE AC-4.5 look-back refinement + smoother bias estimation across sliding window (Fact #89 vs Fact #88); pure ESKF has no look-back.
- **C6**: Cand 2 (PostGIS+pgvector) vs Cand 1 (mirror-suite-pattern) = native KNN + radius queries; but **5-10× slower geographic lookup** at the project's pinned 3 Hz spatial-grid query rate per Source #93 + Source #97 evidence — improvements MARGINAL-TO-NEGATIVE.
- **C7**: TensorRT INT8 vs FP16 = 2-3× speedup per Source #102 YOLO26n benchmark on Jetson Orin Nano Super.
- **C8**: All three FC candidates satisfy AC-4.3 by design; UBX impersonation (Cand 3) provides no measurable AC-4.3 lift over MSP2_SENSOR_GPS (Cand 2); mid-batch comparative-improvement verdict locked Cand 2 as primary for iNav.
- **C10**: Polygraphy `--data-loader-script` cleaner than hand-written `IInt8EntropyCalibrator2` (Source #117 + #118 vs Source #121); calibration-cache reuse keeps subsequent rebuilds <30 sec vs 10-30 minute first-build cost.

### Reference Comparison

The **only** dimension where a modern-competitive-lead candidate is being preferred over the mandatory simple-baseline AS THE PRIMARY PATH is C3 (DISK+LightGlue over canonical SP+LightGlue) — and that's forced by license disqualifier on canonical SP weights, not by lift alone. Every other component keeps the mandatory simple-baseline as the primary path (or as a co-primary alongside the modern-competitive-lead per the GTSAM-shared-substrate hybrid for C4+C5).

### Conclusion

**Expected benefit is asymmetric across components**: C3 has a forced-modern-lead path; C4+C5 have a recommended hybrid (simple-baseline at the algorithmic core + modern-competitive-lead for covariance recovery via shared GTSAM); all other components keep the simple-baseline as primary. This shape minimizes the radius of any single component swap and preserves AC-NEW-4 covariance honesty NATIVELY at the C4+C5 layer.

### Confidence

✅ High — per-component lift cells cite specific paper tables / benchmark numbers / API capability evidence.

---

## Dimension 6: Applicable scenarios — pinned mission-profile fit

### Fact Confirmation

The Project Constraint Matrix (`00_problem/restrictions.md` + `00_problem/acceptance_criteria.md`) pins the deployment context: fixed-wing UAVs, eastern/southern Ukraine, 8 h flights at ~60 km/h cruise, ≤1 km AGL, sector ≤150 km² + transit corridor ~50 km², predominantly sunny daytime with seasonal/visibility class coverage required, Jetson Orin Nano Super (8 GB shared, 25 W TDP), ArduPilot Plane + iNav as the supported FCs (PX4 explicitly out of scope).

Per-component applicability:
- **C1, C2, C3, C4, C5**: All recommended primary candidates apply to nadir-down ~1 km AGL flight; D-C2-1 retrain on aerial corpus closes the street-view-pretrained gap.
- **C6**: Cand 1 mirrors verified-existing parent-suite `satellite-provider` pattern (Source #92 filesystem read at `/Users/obezdienie001/dev/azaion/suite/satellite-provider/`).
- **C7**: TensorRT + Polygraphy + trtexec all run on Jetson Orin Nano Super SM 87 per Source #105.
- **C8**: pymavlink GPS_INPUT covers ArduPilot Plane (verified Source #4 + #106 + #107); MSP2_SENSOR_GPS covers iNav (verified Source #111 + #112 + #113); both within AC-4.3 contract.
- **C10**: All Source #114-#121 evidence on Jetson Orin Nano Super SM 87 + JetPack 6.2 + CUDA 12.6 + TRT 10.3 + cuDNN 9.3 stack.

### Reference Comparison

Auterion Artemis (Source #31) deploys the same canonical pipeline shape on similar Jetson-class hardware (Skynode N) in Ukrainian theater with reportedly 1000-mile range — but on a closed-source proprietary stack. NGPS (Source #33) deploys SP+LightGlue+UKF+VISION_POSITION_ESTIMATE on ArduPilot — confirms ArduPilot Plane + visual-localization companion pattern is operationally validated. The novelty in this project relative to existing systems is (a) iNav support (no other open-source GPS-denied companion targets iNav), (b) AC-NEW-7 cache-poisoning safety budget (no existing system enforces multi-flight Service-side ingest voting on tile geo-alignment).

### Conclusion

**Every recommended primary candidate is applicable to the pinned mission profile with no open scope mismatches**. The two project-novel elements (iNav adapter + cache-poisoning safety) are covered by C8 (MSP2_SENSOR_GPS path) and C10+C6 (D-C10-3 content-hash gate) respectively, both with selected candidates and mitigations in place.

### Confidence

✅ High — every applicability claim cites either a verified-existing pattern in the parent suite OR an L1 documentary source for the deployed hardware.

---

## Dimension 7: Team capability requirements

### Fact Confirmation

The recommended primary stack requires the following skill set: PyTorch + ONNX export literacy (C1/C2/C3), TensorRT INT8 calibration via Polygraphy CLI (C7+C10), GTSAM Python API + factor-graph design (C4 D-C4-2 = (b) + C5 D-C5-5 = (c)), MAVLink + iNav MSP V2 protocol literacy (C8), PostgreSQL + FAISS Python API (C6), bash/Python orchestration with crash-safe atomic file writes (C10). C++ + ROS comfort needed for OKVIS2 (C1 modern-competitive-lead) but OPTIONAL — KLT+RANSAC fallback (Fact #53) is pure-OpenCV Python.

### Reference Comparison

Alternate recommendations would shift skill demand: choosing OpenGV (Source #84) for C4 would add ~3-5 days engineering for OpenGV-internal Jacobian propagation through bearing-vector residuals (harder than OpenCV's pixel-Jacobian per Fact #53 closure); choosing UBX impersonation (Cand 3) for C8 would add UBX protocol literacy + AC-NEW-7 audit-trail design (D-C8-7); choosing Cand 2 (PostGIS+pgvector) for C6 would add PostGIS-on-aarch64 build literacy.

### Conclusion

**The recommended primary stack maps to a 2-engineer team with a junior+mid Python/C++ split**: senior engineer drives the GTSAM-shared-substrate hybrid (C4+C5) + the FC adapter integration (C8), junior+mid engineer drives the rest (C1 fallback + C2/C3 + C6 + C7 + C10 + Test Spec deliverables). No specialty (e.g., Cython, Rust, native-CUDA-kernel authoring, GPU-driver internals, FPGA programming) outside the standard CV/ML/robotics-engineering Python + C++ stack is required.

### Confidence

⚠️ Medium — team-capability mapping is L3 inferential; per-component skill demand is L1-evidence-backed.

---

## Dimension 8: Migration difficulty — swap cost across components

### Fact Confirmation

Per-component swap-cost cells in `03_comparison_framework.md` row 8 are bounded at ~2-3 weeks max for the most expensive swap (Manual ESKF → GTSAM iSAM2 = different state representation per `C5_state_estimator.md`). Most swaps are ~1 week (DISK+LightGlue → ALIKED+LightGlue; OKVIS2 → VINS-Mono; MixVPR → SALAD; TRT-native → ONNX Runtime+TRT EP; Cand 2 MSP2 → Cand 3 UBX impersonation). C7 hybrid orchestration tools (D-C10-5 = (d)) are interchangeable per the hybrid policy.

### Reference Comparison

Cross-component swap costs are smaller than within-component swaps because the C2/C3 boundary is well-defined (descriptor → matcher API) and the C4/C5 boundary is well-defined (anchor pose + 6×6 covariance → estimator factor). The exception is the C4+C5 GTSAM-shared-substrate hybrid (D-C5-5 = (c)) — swapping out GTSAM at C5 would force reverting D-C4-2 = (b) and re-engineering C4's covariance recovery via post-hoc Jacobian (D-C4-2 = (a)) at ~1 week additional cost.

### Conclusion

**Migration difficulty is bounded and per-component**. The largest swap radius is the GTSAM-shared-substrate hybrid (~3-4 weeks combined cost to revert both D-C4-2 + D-C5-5), but reverting it is a Plan-phase decision that doesn't surface at runtime. No component lock-in exceeds ~3 weeks of engineering, which is well within typical Plan-cycle revision budgets.

### Confidence

⚠️ Medium — engineering swap estimates are L3 inferential; per-component swap pathways are L1-evidence-backed.

---

## Dimension PROJECT-9: License-track posture (D-C1-1 split)

### Fact Confirmation

D-C1-1 user-decision splits the candidate landscape into BSD/permissive vs GPL-3.0 tracks. The BSD/permissive track is COMPLETE for C2 (4 mandatory candidates: MixVPR + SelaVPR + NetVLAD + EigenPlaces), C3 (4 candidates: DISK+LightGlue + ALIKED+LightGlue + XFeat + XFeat+LighterGlue, after canonical SP+LightGlue HARD DISQUALIFIER from Magic Leap noncommercial license), C4 (3 candidates: OpenCV + OpenGV pending D-C4-3 + GTSAM), C5 (Manual ESKF + GTSAM iSAM2), C6 (Cand 1 mirror-suite-pattern), C7 (TensorRT 10.x Apache-2.0 + ORT MIT + PyTorch BSD-3-Clause), C8 (MSP2 + UBX MIT/BSD-3; pymavlink LGPL-3.0 = bundle-unmodified compliant with LGPL §6 per D-C8-3), C10 (FAISS MIT + atomicwrites MIT + Polygraphy + TensorRT Apache-2.0).

### Reference Comparison

The GPL-3.0 track is partial: VINS-Fusion + OpenVINS for C1 (Fact in `C1_vio.md`); SALAD + (conditional AnyLoc/BoQ/DINOv2-VLAD) for C2; PostGIS contingent for C6; pymavlink LGPL-3.0 throughout for C8 (covers both tracks via bundle-unmodified pattern).

Hard disqualifiers (independent of D-C1-1 = (a) or (b)): canonical SP+LightGlue (Magic Leap noncommercial); MASt3R (CC-BY-NC).

### Conclusion

**The BSD/permissive track is COMPLETE**: every component has at least one BSD/permissive primary candidate available. The user can choose D-C1-1 = (b) (BSD/permissive only) and the project is unblocked. Choosing D-C1-1 = (a) (GPL-3.0 only) would unlock additional candidates in C1 (VINS-Fusion + OpenVINS) and C2 (SALAD + conditional pre-screen extensions) but would force a license posture decision on every downstream consumer of the project. The recommended default is D-C1-1 = (c) (both tracks open) which preserves the modular swap pathway documented in Dimension 8.

### Confidence

✅ High — license verification per candidate is L1-evidence-backed via repo LICENSE files + SPDX identifiers + GitHub API license metadata.

---

## Dimension PROJECT-10: AC-NEW-4 covariance-honesty fit

### Fact Confirmation

AC-NEW-4 requires `P(error >500 m) <0.1 %` and `P(error >1 km) <0.01 %` per flight, with covariance carried in the MAVLink message as the FC's only defense (per `00_problem/acceptance_criteria.md` line 81-83). Achieving this requires honest 6×6 posterior covariance from C5, propagated through C8's per-FC field conversion.

Native 6×6 covariance support per candidate:
- **C4 OpenCV `cv::solvePnPRansac`**: NO (returns `retval, rvec, tvec, inliers` only per Source #83 signature) — D-C4-2 mitigation REQUIRED (post-hoc Jacobian OR wrap in GTSAM Marginals).
- **C4 OpenGV `absolute_pose::optimize_nonlinear`**: NO (no covariance output API per Source #85) — D-C4-2 = (d) mitigation if OpenGV elevated to primary.
- **C4 GTSAM `Marginals(graph, result).marginalCovariance(pose_key)`**: YES, NATIVE per Source #87 (multiple snippets) — **only C4 candidate that satisfies AC-NEW-4 NATIVELY**.
- **C5 Manual ESKF**: NATIVE 6×6 via analytic Jacobian per Solà §6 canonical recipe (Fact #88).
- **C5 GTSAM iSAM2**: NATIVE 6×6 via `Marginals.marginalCovariance` (Fact #89) — same NATIVE AC-NEW-4 satisfaction pathway as C4 GTSAM.

### Reference Comparison

The C4+C5 GTSAM-shared-substrate hybrid (D-C5-5 = (c)) couples both layers via GTSAM's `Marginals.marginalCovariance` API: C4 wraps `solvePnPRansac` result in GTSAM `BetweenFactor<Pose3>` prior + per-inlier `GenericProjectionFactorCal3_S2` factors → `LevenbergMarquardtOptimizer` → `Marginals` (D-C4-2 = (b) per Fact #54), then C5 ingests that anchor + covariance as a `PriorFactorPose3` in iSAM2 (Fact #89). C8 D-C8-8 = (b) extracts the 2×2 horizontal sub-matrix from C5 `Marginals` 6×6, computes the 95% confidence ellipse semi-major axis `sqrt(2.0 * 5.991 * λ_max)`, and emits per-FC.

### Conclusion

**The GTSAM-shared-substrate hybrid is the architecturally cleanest path to AC-NEW-4 satisfaction**: covariance is recovered NATIVELY at C4, propagated NATIVELY through C5, and converted-then-emitted at C8 with no impedance mismatch. The Manual ESKF path (C5 simple-baseline) also satisfies AC-NEW-4 NATIVELY but requires C4's covariance to be recovered via D-C4-2 = (a) post-hoc Jacobian (~1 day engineering) since the ESKF can't ingest a non-covariance-bearing anchor. This is acceptable but loses the cross-layer NATIVE coupling.

### Confidence

✅ High — every covariance-API verification is L1-evidence-backed via official SDK docs + canonical paper equations.

---

## Dimension PROJECT-11: AC-4.1 + AC-4.2 fit on Jetson Orin Nano Super SM 87

### Fact Confirmation

AC-4.1 requires end-to-end latency <400 ms p95; AC-4.2 requires <8 GB shared memory. Per-component latency budgets on Jetson Orin Nano Super (extrapolated from L1 benchmarks on similar hardware where Jetson-direct evidence is unavailable):
- **C1**: OKVIS2 ~30-50 ms per frame; KLT ~5-10 ms.
- **C2**: MixVPR ~10-20 ms FP16 + ~5-10 ms INT8 per query.
- **C3**: DISK+LightGlue ~30-60 ms per pair FP16 — **TIGHT at K=10 retrieval pairs per UAV frame** (300-600 ms standard / 150-300 ms adaptive); D-C3-3 mitigation via reduced K (3-5) OR adaptive depth (1.86× speedup on easy pairs per LightGlue paper §5.4).
- **C4**: OpenCV ~5-15 ms per RANSAC iteration; GTSAM `Marginals` ~30-90 ms per pose recovery (Plan-phase Jetson MVE confirmation).
- **C5**: Manual ESKF ~5-15 ms per update; GTSAM iSAM2 ~5-100 ms per update depending on D-C5-5 factor density (RECOMMENDED D-C5-5 = (c) ~2-5 ms per update is fastest path).
- **C6**: Cand 1 ~6-54 ms per cache hit (Postgres btree + FAISS HNSW within AC-4.1).
- **C7**: TensorRT INT8+FP16 mixed per D-C7-6 per-family policy meets AC-4.1 across pipeline.
- **C8**: pymavlink + MSP2 send-side ~1-5 ms per message; rate 5 Hz per D-C8-5.
- **C10**: Pre-flight only; not in AC-4.1 budget. Takeoff load <5 s per D-C10-4 mmap path.

Memory: C7 ~700 MB-1.5 GB total across all loaded engines; C5 GTSAM iSAM2 ~50-200 MB factor graph; C6 ~430 MB FAISS HNSW at 2048-D halfvec × 100K tiles (per Source #115 formula). Total estimated ~1.5-2.5 GB peak runtime within AC-4.2 8 GB budget.

### Reference Comparison

The dominant latency consumer is **C3 matchers at K=10 retrieval pairs per UAV frame** (300-600 ms standard for DISK+LightGlue). D-C3-3 mitigation paths are documented and parameterizable. Source #102 YOLO26n benchmark on Jetson Orin Nano Super confirms TensorRT INT8 delivers ~2-3× speedup over FP16 for CNN-class models — giving budget headroom for C2 + C7 + per-frame VPR retrieval.

### Conclusion

**AC-4.1 satisfaction is feasible at K=3-5 retrieval pairs per frame with adaptive-depth LightGlue** (~150-300 ms for matchers, leaving ~100-250 ms headroom for C1+C4+C5+C8). AC-4.2 satisfaction has comfortable headroom (~5-6 GB free under recommended primary stack). **Strongest mitigation lever**: D-C3-3 K-pair budget choice; secondary lever: D-C7-6 per-family precision policy.

### Confidence

⚠️ Medium-High — most latency cells are L2 extrapolation from RTX-3080/3090 benchmarks scaled to Jetson; final confirmation requires Plan-phase Jetson MVE per D-C1-2.

---

## Dimension PROJECT-12: AC-NEW-7 cache-poisoning safety fit

### Fact Confirmation

AC-NEW-7 requires `P(geo-misalign >30 m) <1 %` and `P(>100 m) <0.1 %` per flight across all onboard tiles written. The end-to-end safety contract spans (a) onboard tile-write side (AC-8.4 mid-flight tile generation; per-tile quality metadata), (b) Suite Sat Service-side multi-flight ingest voting layer (out of onboard scope), and (c) **descriptor-cache + TensorRT engine integrity at takeoff load**.

The (c) part is what C6+C10 own. FAISS Source #114 explicit security warning: "No attempt is made to check the correctness of loaded data. A faulty or malicious file could lead to out-of-memory errors or code execution." — direct AC-NEW-7 risk if untreated. D-C10-3 mitigation: SHA-256 content-hash verification gate at takeoff load, reject + STATUSTEXT to FC + refuse takeoff on mismatch. D-C10-2 mitigation for the truncated-file class (separate from tampering): `python-atomicwrites` package (write-to-temp + fsync + atomic rename + parent-dir fsync per Source #116).

### Reference Comparison

Skipping content-hash verification (D-C10-3 = (a)) would leave the cache-poisoning failure mode open at the cost of ~50 ms one-time hash check at takeoff. Skipping atomic-write (D-C10-2 = (a)) would leave the truncated-file failure mode open — a power loss or process kill mid-`faiss.write_index` leaves a corrupt FAISS file that loads successfully and produces silently-wrong descriptor matches at takeoff (direct AC-NEW-7 violation + AC-3.3 re-localization stability violation).

### Conclusion

**AC-NEW-7 cache-poisoning safety on the descriptor-cache + TensorRT engine path is satisfied by the D-C10-2 atomic-write + D-C10-3 content-hash + D-C10-7 self-describing filename triad**. The Suite Sat Service-side multi-flight ingest voting (the dependent half of the contract per AC-NEW-7 external-dependency note) is out of onboard scope but is acknowledged in `00_problem/acceptance_criteria.md` line 98.

### Confidence

✅ High — D-C10-2 + D-C10-3 + D-C10-7 mitigations cite L1 evidence (Source #114 FAISS warning + Source #116 atomic-write pattern + Source #105 hardware-tied-engine constraint).

---

## Cross-cutting reasoning summary

| Reasoning lever | Conclusion | Confidence |
|---|---|---|
| Pipeline shape | Canonical retrieval+matching+pose+fusion; no end-to-end alternative | ✅ High |
| Implementation cost | ~6-8 weeks parallelizable critical path + ~2 wk Jetson MVE overlap | ⚠️ Medium |
| Maintenance posture | BSD/permissive-clean primary stack; OpenGV staleness contained | ✅ High |
| Risk decomposition | License + hardware-tied + cross-domain; all three have closed mitigations | ✅ High |
| Expected benefit asymmetry | C3 forced-modern-lead; C4+C5 hybrid; rest keep simple-baseline primary | ✅ High |
| Mission-profile fit | Every primary candidate applies; iNav + AC-NEW-7 are project-novel and covered | ✅ High |
| Team capability | 2-engineer Python+C++ split; no specialty stack required | ⚠️ Medium |
| Migration difficulty | ≤3 weeks per swap; GTSAM-shared-substrate is the largest radius | ⚠️ Medium |
| License-track posture | BSD/permissive track COMPLETE; recommend D-C1-1 = (c) both tracks open | ✅ High |
| AC-NEW-4 covariance honesty | GTSAM-shared-substrate hybrid satisfies NATIVELY across C4+C5+C8 | ✅ High |
| AC-4.1 + AC-4.2 fit | Feasible at K=3-5 LightGlue pairs + adaptive depth + D-C7-6 per-family precision | ⚠️ Medium-High (Plan-phase Jetson MVE confirms) |
| AC-NEW-7 cache-poisoning safety | D-C10-2 + D-C10-3 + D-C10-7 triad satisfies onboard side; Suite Service side out of scope | ✅ High |