Refactor documentation for splittable artifacts and update references

Updated various documentation files to clarify the handling of splittable artifacts, allowing for folder equivalents of key markdown files when they exceed size limits. Adjusted references in multiple sections to reflect this new structure, ensuring consistency across the research methodology. Enhanced clarity on the saving actions and artifact organization, particularly for `01_source_registry.md`, `02_fact_cards.md`, and `06_component_fit_matrix.md`. This change aims to improve usability and maintainability of the research documentation.

_docs/00_research/00_question_decomposition.md

@@ -74,8 +74,8 @@ For each component below, the search plan covers all option families per `Compon
 | 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** | Reproducible validation against AC-1/2/3/4/NEW-4/NEW-7/NEW-8 budgets; fixtures for AerialVL S03, AerialExtreMatch, own Mavic flights, Derkachi flight footage | AerialVL (VISTA / NTU), AerialExtreMatch, VPR-Bench, MahalNotchVPR / Mid-Air UAV; SITL: ArduPilot Plane SITL, iNav SITL/HITL, Gazebo, Webots; replay: PX4-Avionics-Replay-style or custom |
-| C10 | **Pre-flight cache provisioning + sector classification + freshness pipeline** | 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 | Likely a custom CLI/desktop tool — research existing UAV mission-prep tools (QGC plan files, MAVProxy, ArduPilot Mission Planner equivalents on the operator side) |
+| ~~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)
 
@@ -86,13 +86,13 @@ For each component below, the search plan covers all option families per `Compon
 
 ## 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 `01_source_registry.md`. The shape is shown here so the search plan is auditable; the full execution log will populate downstream files.)
+(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.md` once initialised. Each lead library/SDK candidate triggers the mandatory `context7` per-mode capability verification per `research/steps/03_engine-investigation.md`.
+**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".
 
@@ -114,7 +114,7 @@ Probes (per `references/comparison-frameworks.md` → Decomposition Completeness
 | 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? | SQ7 + C9. ✓ |
+| 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. ✓ |
@@ -124,7 +124,7 @@ No major gap detected at decomposition time. If domain-discovery searches in Ste
 ## 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.md`.
+- 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`).
@@ -148,7 +148,7 @@ Source-time-window rules for this run:
 
 ## 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.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.
+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 |
 |---|---|---|---|
@@ -163,7 +163,7 @@ The C1–C10 decomposition was sanity-checked against five independent surveys/b
 | 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 | **C9 — Datasets + SITL / replay** | ✅ covered | None |
+| 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.
@@ -187,10 +187,67 @@ Per Fact #26 (RTX-3090-measured runtime → conservative Jetson-Orin-Nano transl
 - **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→C10)** → SQ5 interleaved → SQ7 → SQ8 → SQ9 synthesis at engine Step 8.
+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.
 
-Pipeline shape entering SQ3+SQ4: `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) + C9 (datasets) + C10 (provisioning) cross-cutting.
+(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.