# Fact Cards — Mode B Addendum (2026-05-08)

> Mode B Solution Assessment of `_docs/01_solution/solution_draft01.md`. New facts gathered for findings F1–F20; Mode A facts #1–#101 remain canonical and are not duplicated.
>
> Index: [`00_summary.md`](00_summary.md). Mode B sources: [`../01_source_registry/MODEB_addendum.md`](../01_source_registry/MODEB_addendum.md). Mode B fit-matrix revisions: [`../06_component_fit_matrix/MODEB_revisions.md`](../06_component_fit_matrix/MODEB_revisions.md). Mode B output: [`../../01_solution/solution_draft02.md`](../../01_solution/solution_draft02.md).
>
> Confidence labels and schema match `00_summary.md` legend.

---

## Documentary-audit findings (no new web evidence required)

### Fact #102 — solution_draft01 C1 candidate table mis-licenses VINS-Mono as "BSD permissive clean"; the underlying Mode A C1 Fact #28 correctly classifies it as GPL-3.0 (deliverable-formatting error)
- **Statement**: `solution_draft01.md` § "Component: C1" lists VINS-Mono with the cell "Security: BSD permissive clean" and "Selected (mandatory simple-baseline) — fallback if OKVIS2 fails Jetson MVE". The Mode A C1 fact card #28 (`02_fact_cards/C1_vio.md`) explicitly states VINS-Mono is "GPL-3.0 (copyleft viral) — distribution of the onboard binary requires source disclosure for the entire linked binary and triggers GPL-3 anti-tivoization clauses for embedded firmware" — and the cross-component-gates D-C1-1 license-track decision exists precisely because VINS-Mono / VINS-Fusion / OpenVINS are on the GPL-3.0 axis. Source #122 (raw VINS-Mono LICENCE on github.com) confirms canonical GPL-3.0. The discrepancy is inside Mode A Step 8 (Deliverable Formatting); the Mode A evidence layer is correct.
- **Source**: Mode A C1 Fact #28; Source #122 (canonical LICENCE)
- **Phase**: Mode B documentary audit
- **Confidence**: ✅ High
- **Sub-Question Binding**: SQ3+SQ4 / C1
- **Implication**: solution_draft02 must (a) correct the C1 candidate table cell to "GPL-3.0 contingent on D-C1-1 = (a) or (c) license track", (b) demote VINS-Mono from "Selected (mandatory simple-baseline)" status because under D-C1-1 = (b) BSD/permissive-only track it would be **Rejected** by license, (c) elevate KLT+RANSAC homemade fallback to **the** mandatory simple-baseline (matches Mode A C1 Fact #35), and (d) name the actual BSD/permissive-track lead as OKVIS2 (matches C1 Fact #31). No change to the cross-component decision graph — D-C1-1 already exists as the gate that resolves this.

### Fact #103 — solution_draft01 latency math (~140-420 ms p95 at K=3 + adaptive LightGlue depth) crosses AC-4.1's 400 ms p95 budget at the upper end with no documented slack for FC-side IMU pre-integration, MAVLink/MSP serialization, OS scheduling jitter, or thermal-throttle backoff
- **Statement**: solution_draft01 § "Component-interaction diagram (pre-flight + runtime)" labels the runtime stack: "C1 OKVIS2 VIO ~30-50 ms + C2 MixVPR query ~25 ms + C3 DISK+LightGlue × K pairs ~90-180 ms FP16 + C4 OpenCV solvePnPRansac ~5-15 ms + GTSAM Marginals ~30-90 ms + C5 GTSAM iSAM2 ~2-5 ms per update at D-C5-5 = (c) + C8 per-FC pymavlink GPS_INPUT / MSP2_SENSOR_GPS 5 Hz periodic", and says total is "~140-420 ms p95 at K=3 + adaptive LightGlue depth". The upper end **420 ms exceeds AC-4.1's 400 ms p95** at the documented Jetson Orin Nano Super extrapolation. There is no reserved slack for: (i) MAVLink/MSP serialization + UART/USB transmission to FC (~5-20 ms typical), (ii) OS scheduling jitter under shared-CPU+GPU contention (~10-30 ms typical at 90th-99th percentile per Source #97 Postgres-on-Jetson observations), (iii) thermal-throttle backoff at +50 °C ambient per AC-NEW-5 (Jetson backs off from 25 W to 15 W, collapsing throughput by ~40%), (iv) FC-side IMU pre-integration interpolation latency for the timestamp the GPS_INPUT/MSP2_SENSOR_GPS frame is targeted at, (v) FAISS HNSW index search variance at p99 (~1-3 ms typical → up to ~10-15 ms at p99 per Source #115). A defensible AC-4.1 latency partition would carve a project-side worst-case ≤300 ms p95 budget with explicit per-stage deadlines + slack reservation; current draft01 budgets up to 420 ms with implicit assumption-of-best-case stack behavior.
- **Source**: solution_draft01.md self-citation; AC-4.1; Mode A Sources #97 + #115; AC-NEW-5
- **Phase**: Mode B documentary audit
- **Confidence**: ✅ High (math is internal to draft01)
- **Sub-Question Binding**: SQ3+SQ4 / C1+C2+C3+C4+C5+C7+C8 cross-cutting NFR
- **Implication**: solution_draft02 must add a NEW Plan-phase decision **D-CROSS-LATENCY-1: AC-4.1 latency budget partition strategy** with options (a) tighten K=3 to K=2 to recover ~30-60 ms of headroom, (b) drop GTSAM `Marginals` covariance recovery from RUNTIME path and use adaptive Jacobian-based covariance per D-C4-2 = (a) to recover ~20-60 ms, (c) accept the budget overrun and validate at Jetson MVE that p95 lands under 400 ms in steady-state (i.e. trust the math is conservative and adaptive-LightGlue-depth in practice will land closer to 140 ms than 420 ms), (d) hybrid: K=3 default + auto-degrade to K=2 + Jacobian-covariance under thermal throttle. Recommendation: **(d) hybrid** — preserves AC-4.1 satisfaction across the operating envelope without permanently sacrificing accuracy. **NEW cross-component gate: requires Jetson MVE measurement of full p95+p99 distribution under hot-soak NFT-3 conditions before lock.**

### Fact #104 — Camera intrinsics + camera-to-body calibration are PROJECT-LEVEL OPEN ITEMS per `_docs/00_problem/problem.md` last sentence and `flight_derkachi/README.md`; solution_draft01 does NOT inventory this as a Plan-phase decision
- **Statement**: `_docs/00_problem/problem.md` last sentence: "Camera intrinsics, lens distortion, raw camera feed parameters, and exact camera-to-body calibration are still pending, so final production accuracy claims remain gated on calibration data or a separately surveyed representative dataset." `_docs/00_problem/input_data/flight_derkachi/README.md`: "Camera intrinsics, lens distortion, raw camera resolution, and exact camera-to-body calibration are still unknown, so this fixture is not sufficient by itself for final production camera calibration or satellite-anchor accuracy claims." `_docs/00_problem/input_data/expected_results/results_report.md` § Known Gaps: "Final production acceptance requires camera calibration and representative datasets with synchronized camera/IMU plus ground-truth trajectory." solution_draft01 cites Sources #82+#83 (OpenCV solvePnPRansac signature requires `K` intrinsic matrix + `dist` distortion coefficients) but does not flag that **K and dist are not yet known** for the deployed ADTi 20MP 20L V1 nav camera. Without intrinsics + camera-to-body extrinsic calibration, the entire C4 pose-estimation pipeline cannot run on real production frames; the Jetson MVE results will be calibration-acquisition-dependent.
- **Source**: `_docs/00_problem/problem.md` line 1; `_docs/00_problem/input_data/flight_derkachi/README.md` line 12; `_docs/00_problem/input_data/expected_results/results_report.md` § Known Gaps; OpenCV Sources #82+#83
- **Phase**: Mode B documentary audit
- **Confidence**: ✅ High
- **Sub-Question Binding**: PCM (Project Constraint Matrix) input availability dimension
- **Implication**: solution_draft02 must add a NEW project-level decision **D-PROJ-1: Camera calibration acquisition strategy** with options (a) checkerboard calibration on a pre-deployment ADTi 20MP 20L V1 nav-camera unit (canonical OpenCV calibration workflow ~1-2 days engineering + lab access), (b) photogrammetric self-calibration from the first ~50 deployment frames over known landmarks (~2-3 days plus runtime support code; produces production-correct calibration but degrades first-mission accuracy), (c) request manufacturer's factory-calibration data sheet from ADTi (low cost if available; risk: vendor may not publish per-unit calibration), (d) hybrid: factory data sheet + ground-truth checkerboard refinement on each deployed unit. Recommendation: **(d) hybrid**. **CRITICAL Plan-phase gate**: this is a hard prerequisite for AC-1.1/1.2 frame-center-accuracy validation; Test Spec (greenfield Step 5) cannot lock end-to-end accuracy fixtures without it.

### Fact #105 — AC-NEW-7 cache-poisoning safety budget explicitly depends on a Suite Sat Service-side voting layer that solution_draft01 does NOT audit for existence, contract, or build status
- **Statement**: `_docs/00_problem/acceptance_criteria.md` § AC-NEW-7 External-dependency note: "The Suite Satellite Service is expected to operate a multi-flight ingest-side voting layer that gates onboard-tile promotion to 'trusted basemap' until multiple independent flights agree on geo-alignment. Voting algorithm is the Service's concern; onboard's job (AC-8.4) is to publish per-tile quality metadata sufficient for that layer. End-to-end AC-NEW-7 evidence depends on this Service contract." solution_draft01 § Architecture lists C6 + C10 as covering the onboard half (publish per-tile quality metadata, content-hash gate at takeoff, atomic-write descriptor cache) but does NOT verify that the Suite Service voting layer (a) has a documented contract, (b) has been implemented, (c) is on the parent-suite roadmap, or (d) has a fallback if not yet built. Without the Service-side voting, a single bad onboard pose with optimistic covariance writes a misaligned tile that becomes the next flight's anchor — cross-flight error compounding that NFT-5 (in solution_draft01) explicitly tries to test but cannot validate end-to-end without the Service contract.
- **Source**: AC-NEW-7 verbatim; solution_draft01 § Architecture C6+C10; solution_draft01 § Testing Strategy NFT-5
- **Phase**: Mode B documentary audit
- **Confidence**: ✅ High
- **Sub-Question Binding**: PCM cross-component external-dependency dimension; SQ8 (security)
- **Implication**: solution_draft02 must add a NEW project-level decision **D-PROJ-2: Suite Sat Service voting-layer contract verification** with options (a) verify Suite Service voting layer is documented + scheduled for the deployment timeframe; (b) draft the contract from the onboard side and propose to the Suite Service team; (c) build a project-internal multi-flight aggregator as a stop-gap until Suite Service ships the layer (~2-3 weeks engineering, but cross-flight aggregator means onboard now owns suite-component scope creep); (d) accept that AC-NEW-7 Service-side validation is best-effort and document the gap explicitly. Recommendation: **(a) verify + (b) draft** in parallel — the contract definition is small (per-tile quality metadata schema + voting threshold spec) and propagating it back to the Suite Service team de-risks the entire AC-NEW-7 obligation. **CRITICAL cross-suite gate**: requires coordination with the parent-suite Satellite Service team before AC-NEW-7 NFT-5 can pass with end-to-end evidence.

### Fact #106 — Mode A Phase 1 BLOCKING gate (`00_ac_assessment.md`) was not produced as a standalone artifact in the Mode A run per solution_draft01's own self-disclosure
- **Statement**: solution_draft01 § Note on AC assessment (lines 17-18): "Mode A Phase 1 (`00_ac_assessment.md` BLOCKING gate per the research SKILL.md) was not executed as a standalone artifact in this run. Per-AC binding evidence is instead distributed across the per-component fact cards and the Restrictions × Candidate-Modes sub-matrix sections in `06_component_fit_matrix/Cx_*.md`. This is acknowledged as a process deviation and is recoverable by extracting an `00_ac_assessment.md` summary file from the existing per-AC binding evidence on demand. No AC has been silently dropped or unverified." Per `_docs/00_research/00_question_decomposition.md` line 4 the Phase 1 skip was a **prior user decision** after a cleanup pass that stripped implementation details from `acceptance_criteria.md` and `restrictions.md`; "AC/restrictions are treated as fixed inputs". Mode B can either (a) extract the standalone artifact retroactively from the distributed evidence, (b) confirm the deviation as accepted by the user, or (c) leave it as-is for Plan-phase to either resolve or carry forward. The risk is small (per-AC binding IS in the per-component fact cards) but the canonical research methodology says a BLOCKING gate cannot simply be skipped.
- **Source**: solution_draft01.md "Note on AC assessment"; `_docs/00_research/00_question_decomposition.md` line 4; research SKILL.md Mode A Phase 1 BLOCKING-gate spec
- **Phase**: Mode B documentary audit
- **Confidence**: ✅ High
- **Sub-Question Binding**: Process compliance with research SKILL.md
- **Implication**: solution_draft02 acknowledges the deviation and recommends extraction of `00_ac_assessment.md` IF user wants the canonical artifact; otherwise the deviation is treated as accepted (per `00_question_decomposition.md` line 4 prior-user decision) and recorded explicitly in `_docs/_process_leftovers/`.

### Fact #107 — AC-4.5 (system may refine prior estimates and emit corrections) FC-consumption pathway is unspecified; neither MAVLink `GPS_INPUT` nor MSP2 `MSP2_SENSOR_GPS` support "correct prior frame N+ago" semantics; GTSAM iSAM2's NATIVE look-back refinement is therefore internal-only and does not reach the FC
- **Statement**: AC-4.5 ("System may refine prior estimates and emit corrections") is satisfied by GTSAM iSAM2's incremental smoothing per Mode A Fact #89 — the estimator can revise past keyframe poses when new measurements arrive. solution_draft01 § Component C5 + § Testing Strategy IT-10 cite this as a key benefit of D-C5-5 = (c) GTSAM-shared-substrate. However: ArduPilot's `AP_GPS_MAV` (Source #4) and iNav's `mspGPSReceiveNewData()` (Source #110) both consume the **latest** received GPS frame as the current best estimate; neither supports retroactive correction of a frame N steps in the past. So GTSAM iSAM2's look-back refinement value is **internal-only** — it improves the current best pose estimate after smoothing the past, but the FC sees only the current frame after smoothing, not corrections to past frames. AC-4.5 is therefore satisfied as "internal estimator refines past + emits the corrected current estimate", not as "FC retroactively corrects past flight log". Draft01 does not make this scoping explicit; IT-10 in particular does not validate AC-4.5 — it validates per-FC unit conversion of covariance.
- **Source**: AC-4.5 verbatim; Mode A Fact #89 (GTSAM iSAM2); Mode A SQ6 Source #4 (`AP_GPS_MAV.cpp`); Mode A C8 Source #110 (`gps_ublox.c`)
- **Phase**: Mode B documentary audit
- **Confidence**: ✅ High
- **Sub-Question Binding**: SQ3+SQ4 / C5; SQ6 / C8
- **Implication**: solution_draft02 § Architecture C5 must clarify "AC-4.5 satisfied as internal smoothing + corrected current-frame emission; FC log is forward-time only". solution_draft02 § Testing Strategy must add a new **IT-11 — Smoothing-loop look-back accuracy** test that validates GTSAM iSAM2's smoothed past-keyframe poses against ground-truth at smoothing convergence (independent of FC-side consumption). FDR (AC-NEW-3) MUST log smoothed past-frame estimates so post-mission analysis can verify AC-4.5.

### Fact #108 — SQ2 architectural decisions promoted "AdHoP refinement loop" + "Top-N inlier-based re-rank" to explicit named sub-stages in the runtime pipeline (per `_docs/00_research/00_question_decomposition.md` lines 175-178), but solution_draft01 § Architecture has neither a candidate row nor a named sub-stage for either
- **Statement**: `_docs/00_research/00_question_decomposition.md` § "SQ2 — Architectural decisions" — Decision 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)." Decision 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." solution_draft01 § Architecture lists candidate tables for C1+C2+C3+C4+C5+C6+C7+C8+C10. The component-interaction diagram shows "C2 MixVPR query → top-K=3 satellite tile retrieval → C3 DISK+LightGlue × K pairs" — the K=3 retrieval IS the top-K from C2, but the **re-rank by inlier count** sub-stage promised by SQ2 Decision 3 is not represented. Similarly, no AdHoP-conditional refinement candidate appears in the C3 row, despite SQ2 Decision 2 carving its latency budget.
- **Source**: `_docs/00_research/00_question_decomposition.md` lines 175-178; solution_draft01 § Architecture C1-C10; solution_draft01 § Component-interaction diagram
- **Phase**: Mode B documentary audit
- **Confidence**: ✅ High
- **Sub-Question Binding**: SQ2 closure
- **Implication**: solution_draft02 must either (a) populate the architecture with new candidate rows for "Top-N re-rank by inlier count" (likely a thin wrapper around the C3 matcher's RANSAC inlier counter) and "AdHoP-conditional refinement" (per Source #40 OrthoLoC AdHoP method-agnostic preconditioning); or (b) explicitly close SQ2 Decisions 2+3 as "implicit inside C3" — but in that case the "promote to explicit named sub-stage" wording from question_decomposition must be revisited and the user notified that the architecture deviated. Recommendation: **(a) populate** — both are well-scoped sub-components with cited Sources (#22+#25 in the original SQ2 closure) and the latency budgets are already carved. solution_draft02 § Architecture adds a "Re-rank" sub-stage between C2 and C3 plus an "AdHoP-conditional" sub-stage between C3 and C4.

---

## Web-research findings (2026-05-08)

### Fact #109 — MAVLink protocol lacks cryptographic authentication by default (CVE-2026-1579, CVSS 9.8 CRITICAL); ArduPilot supports MAVLink 2.0 message signing as the canonical mitigation; iNav has only partial MAVLink support and does NOT implement message signing — cross-FC asymmetry on the GCS / telemetry link is material for AC-NEW-7 + AC-NEW-2
- **Statement**: Per Source #126 (NVD CVE-2026-1579, CVSS 9.8 CRITICAL): "The MAVLink communication protocol lacks cryptographic authentication by default. Unauthenticated parties with MAVLink interface access can send arbitrary messages including SERIAL_CONTROL commands for interactive shell access." Affected named: PX4 Autopilot v1.16.0_SITL_latest_stable. **Mitigation: enable MAVLink 2.0 message signing.** Per Source #128 (ArduPilot Plane MAVLink2 Signing docs): ArduPilot supports MAVLink2 signing via Mission Planner SETUP > Advanced > "Mavlink Signing"; non-USB serial ports can be configured to only respond to MAVLink commands carrying the correct passkey; a 13-byte signature includes link ID (8 bits), timestamp (48 bits in 10-microsecond units since 2015-01-01), and 48-bit SHA-256 hash signature based on packet + timestamp + secret key (Source #128 + canonical mavlink.io/en/guide/message_signing.html). Issue #28736 + PR #29546 (March 2025) add channel-specific signing for separate MAVLink ports — direct relevance to companion-computer wired connections per Source #128. Per Source #129 (iNav MAVLink wiki, frogmane edited 2025-12-11): "iNav has partial MAVLink support and does not implement message signing. It lacks parameter API support and has limited command compatibility." Companion-FC inbound on iNav is MSP2 (not MAVLink) so the signing-gap is on the OUTBOUND MAVLink telemetry side from iNav to the GCS, not on the inbound external-positioning path — but cross-FC asymmetry is still material because the GCS link itself carries `STATUSTEXT` and operator commands per AC-6.1 + AC-6.2.
- **Source**: Source #126 (CVE-2026-1579), Source #128 (ArduPilot Plane MAVLink2 Signing docs + PR #29546), Source #129 (iNav MAVLink wiki), canonical mavlink.io/en/guide/message_signing.html (Source #128 cross-cite)
- **Phase**: Mode B web research
- **Confidence**: ✅ High (NVD official + ArduPilot official + iNav official wiki)
- **Sub-Question Binding**: SQ6 (FC adapter security posture) + SQ8 (AC-NEW-7 + AC-NEW-2 security)
- **Implication**: solution_draft02 must add a NEW Plan-phase decision **D-C8-9: MAVLink 2.0 message signing posture per FC** with options (a) require MAVLink 2.0 signing on ALL MAVLink channels (companion ↔ ArduPilot, FC ↔ GCS, companion ↔ GCS); (b) require signing only on the companion ↔ ArduPilot wired channel (the inbound external-positioning path on AP); (c) accept the unsigned-by-default posture and document it as an external-attack-surface risk; (d) hybrid: signing on companion ↔ AP wired channel + key rotation on every flight. iNav has no signing option per Source #129 — explicit cross-FC asymmetry must be documented. Recommendation: **(d) hybrid for AP**. Cross-FC asymmetry: iNav GCS link is unsigned by design — document explicitly under AC-NEW-7 and propose iNav firmware feature-request as Plan-phase carryforward. **NEW NFT-8 — MAVLink message-signing verification**: SBOM dump confirms passkey configuration for AP signing channel; iNav side documents the unsignable-link as accepted residual risk.

### Fact #110 — MegaLoc (Berton & Masone, CVPR 2025) and UltraVPR (RAL 2025 / ICRA 2026) are MIT-licensed aerial-validated VPR candidates that materially change the D-C2-11 deferred-evaluation recommendation; UltraVPR specifically targets UAV with documented 44 Hz throughput on Jetson Orin NX (Orin-Nano-Super-class)
- **Statement**: Per Source #123 (MegaLoc): MIT-licensed; February 2025 release; SOTA on multiple VPR benchmarks (indoor + outdoor); validated on aerial datasets via the AirZoo benchmark (Source #125) which "demonstrates that fine-tuning MegaLoc on aerial data yields substantial performance gains for aerial image retrieval and cross-view matching tasks". Distributed via torch.hub for easy installation. Per Source #124 (UltraVPR): MIT-licensed; RAL 2025 + ICRA 2026; "unsupervised lightweight rotation-invariant aerial VPR system designed for UAV applications"; **ONNX model runs at approximately 44 Hz on Jetson Orin NX** (Orin Nano Super is in the same Ampere family; expected to land in the same throughput band ±20%); validated on VPAir + UAV-VisLoc datasets — directly relevant to the project's pinned aerial UAV operating context. solution_draft01 § "Open decisions for Plan-phase" line 322 explicitly defers D-C2-11 (MegaLoc successor evaluation) to "post-research session" because Mode A had not gathered sufficient evidence on MegaLoc's aerial applicability or Jetson runtime. Mode B research closes both gaps: MegaLoc is aerial-validated (AirZoo); UltraVPR is aerial-pretrained + Jetson-throughput-documented. The D-C2-11 recommendation should be revised from "(c) skip and rely on closed mandatory pre-screen" to "(a) treat both MegaLoc AND UltraVPR as new Documentary Lead candidates on the BSD/permissive C2 axis at next session, with mandatory Jetson MVE under D-C1-2 / D-C2-4".
- **Source**: Source #123 (MegaLoc), Source #124 (UltraVPR), Source #125 (AirZoo aerial validation)
- **Phase**: Mode B web research
- **Confidence**: ✅ High (peer-reviewed publications + official repos with pretrained weights)
- **Sub-Question Binding**: SQ3+SQ4 / C2 D-C2-11
- **Implication**: solution_draft02 § Architecture C2 must add MegaLoc + UltraVPR as Documentary Lead candidates on the BSD/permissive C2 axis. UltraVPR is potentially the strongest candidate by the project's specific operating-context scoring: rotation-invariant (multi-heading aerial flights), unsupervised (no aerial-retrain cost — closes D-C2-1), Jetson-Orin-NX-runtime-documented at 44 Hz (substantially exceeds 3 Hz nav-camera rate with massive headroom), and MIT-licensed (BSD/permissive track clean). MegaLoc is the broader-applicability primary if SOTA across non-aerial datasets is also wanted (e.g., for cross-domain generalization). **D-C2-11 revised**: (a) elevate UltraVPR to Documentary Lead PRIMARY recommendation on BSD/permissive C2 axis, with MixVPR / EigenPlaces / SelaVPR as siblings; (b) add MegaLoc as Documentary Lead SECONDARY with broader-applicability tag; (c) preserve the closed pre-screen (5/5: MixVPR + SALAD + SelaVPR + NetVLAD + EigenPlaces) as fallback. Mandatory Jetson MVE per D-C1-2 / D-C2-4 expanded scope to cover both UltraVPR + MegaLoc + the existing five.

### Fact #111 — D-C8-2 = (b) companion-driven `MAV_CMD_SET_EKF_SOURCE_SET` switch pattern is supported by ArduPilot at firmware level since August 2021 (PR #18345 → SITL-tested) but no production-deployed GCS or companion implementation is publicly documented; the project will be establishing the canonical pattern itself
- **Statement**: Per Source #130 (ArduPilot common-ekf-sources.rst + PR #18345): ArduPilot supports `MAV_CMD_SET_EKF_SOURCE_SET` (MAVLink command id 42007) since merge in August 2021; the command accepts source set values in 1-3 range; tested in SITL. Source #130 explicitly states: "no GCSs are currently known to implement this" and "The results do not provide specific information about Auterion, NGPS, or production deployment status." This re-confirms Mode A SQ6 Fact #3 from a fresh search at access time 2026-05-08. solution_draft01 § Open decisions D-C8-2 = (b) "companion publishes to source-set 2 + auto-switches FC to set 2 on first valid fix + switches back to set 1 when companion is unavailable (RECOMMENDED ~mirrors NGPS/Auterion pattern)" cites NGPS/Auterion deployment pattern but Mode A SQ1 Sources #25–#37 do not provide direct evidence of either NGPS or Auterion using the companion-driven switch — they document the existence of those deployed systems but not their internal source-set switching mechanism. This is a gap: the project is committing to a pattern that is **architecturally supported but not production-deployed**.
- **Source**: Source #130 (ArduPilot common-ekf-sources.rst + PR #18345 verified 2026-05-08); Mode A SQ6 Fact #3
- **Phase**: Mode B web research (verification re-run)
- **Confidence**: ✅ High (ArduPilot official documentation)
- **Sub-Question Binding**: SQ6 / C8 D-C8-2
- **Implication**: solution_draft02 must downgrade D-C8-2 fit status from `Selected` to **`Selected with runtime gate`** per Step 7.5.3 carve-out wording, with the runtime gate being "validated end-to-end on ArduPilot Plane SITL by IT-3 (Spoofing-promotion latency) before lock". Add NEW Plan-phase decision **D-C8-2-FALLBACK: companion-driven switch fallback strategy if SITL validation fails** with options (a) switch to operator-manual source-set flip via RC aux switch option 90 per draft01's existing D-C8-2 = (c), accepting AC-NEW-2 ≤3s latency would now require operator response time; (b) implement operator-warning STATUSTEXT instead of automated switch, deferring authority to operator; (c) escalate to ArduPilot dev community to characterize firmware-side switch latency before lock. Recommendation: **defer to Test Spec greenfield Step 5** which owns SITL fixture acquisition.

### Fact #112 — OpenCV 4.x must be pinned to ≥4.12.0 per CVE-2025-53644 (CVSS 9.8 CRITICAL heap buffer write via crafted JPEG); affects 4.10.0 / 4.11.0; OpenCV is C4's primary `solvePnPRansac` runtime + KLT fallback in C1 + ortho warp in C4
- **Statement**: Per Source #127 (NVD CVE-2025-53644, CVSS 9.8 CRITICAL): "Uninitialized pointer variable on stack when reading crafted JPEG images. Affects versions 4.10.0 and 4.11.0. Fixed in version 4.12.0." Related weakness: CWE-457 (Use of Uninitialized Variable). solution_draft01 § Component C4 cites "OpenCV 4.x calib3d module"; § Component C1 KLT fallback uses "OpenCV pure-Python"; FDR thumbnail re-load + tile cache import paths potentially feed crafted JPEG bytes into OpenCV's `imread` / `imdecode`. The exposure is small (most JPEG inputs are trusted internal nav-camera stream) but FDR thumbnail re-load AND ortho-tile imports from the Suite Sat Service path could be hostile-input vectors per AC-NEW-7. Pinning OpenCV to ≥4.12.0 is a single-line change with no API-break exposure (4.12 is a minor release on the 4.x line).
- **Source**: Source #127 (NVD CVE-2025-53644)
- **Phase**: Mode B web research
- **Confidence**: ✅ High (NVD official)
- **Sub-Question Binding**: SQ8 (security) + SQ3+SQ4 / C1+C4 dependency pinning
- **Implication**: solution_draft02 must pin OpenCV to **≥4.12.0** in all C1+C4 candidate rows; add NEW Plan-phase decision **D-CROSS-CVE-1: dependency security pinning posture** with options (a) lock to specific patched versions of all CVE-affected dependencies (OpenCV ≥4.12.0; FAISS Apache-2.0 throughout — no CVEs; GTSAM clean — no CVEs; TensorRT 10.3 in JetPack 6.2 — no CVE-applicable since not using TRT-LLM 0.x); (b) maintain a project SBOM with monthly CVE re-scan; (c) automate pinning via dependabot or equivalent. Recommendation: **(a) + (b)** — minimal cost, maximum AC-NEW-7 audit-trail coverage.

### Fact #113 — XoFTR (cross-modal) achieves SOTA cross-modal matching but a 2026 SAR-optical benchmark (24-matcher comparison) found foundation-model features (DINOv2) provide modality invariance even WITHOUT explicit cross-modal training — reinforces SelaVPR (DINOv2-L) preference over MixVPR (CNN-only) when cross-domain UAV→satellite registration is the binding stress test
- **Statement**: Per Source #131 (XoFTR + 2026 SAR-optical benchmark): XoFTR achieved the lowest reported mean error at 3.0 pixels on SpaceNet9 cross-modal training scenes among 24 pretrained matcher families. **Critical finding**: "matchers without explicit cross-modal training sometimes performed comparably, suggesting that foundation-model features (like DINOv2) may provide modality invariance." This is direct contrarian evidence on the project's "DISK+LightGlue retrain on aerial-domain corpus closes cross-domain UAV→satellite gap" architectural bet (D-C3-1 = (a) RECOMMENDED-PRIMARY-MITIGATION). The contrarian implication: a DINOv2-backboned VPR (SelaVPR per Mode A C2 fact card) AND a DINOv2-backboned matcher (a hypothetical DINOv2-backed feature extractor + LightGlue) might close the cross-domain gap WITHOUT needing the D-C2-1 ~1-2-week aerial retrain that draft01 baselines. This does not invalidate the existing D-C3-1 = (a) recommendation but it strengthens the case for keeping SelaVPR (DINOv2-L) as a serious candidate alongside MixVPR (CNN) in the BSD/permissive C2 axis, and it suggests MegaLoc (which also uses foundation-model features per Source #123) is similarly attractive without retrain cost.
- **Source**: Source #131 (XoFTR + 2026 SAR-optical benchmark, two-source confirmation per Critical-novelty rule)
- **Phase**: Mode B web research
- **Confidence**: ⚠️ Medium (the "comparable performance without cross-modal training" finding is from one benchmark on SAR-optical, not UAV→satellite — extrapolation to project's exact operating context is plausible but unverified)
- **Sub-Question Binding**: SQ3+SQ4 / C2+C3
- **Implication**: solution_draft02 § Architecture C2 keeps SelaVPR (DINOv2-L two-stage) as **strong secondary** alongside UltraVPR primary on the BSD/permissive C2 axis (per Fact #110 promotion). solution_draft02 § Open decisions adds **D-C2-12: DINOv2-backbone feature-extractor evaluation for cross-domain matching** as carryforward research item — could potentially close D-C3-1 retrain cost via DINOv2-feature-based matcher (e.g., DINOv2 + LightGlue or DINOv2 + paired matcher) without requiring D-C2-1 aerial retrain. Defer to Plan-phase Jetson MVE.