# Component Fit Matrix — C6: Tile cache + spatial index

> Mode A Phase 2 — engine Step 7.5 (Component Applicability Gate, structured per-component candidate-selection table). Status vocabulary in [`00_summary.md`](00_summary.md). Backing fact cards: [`../02_fact_cards/C6_tile_cache_spatial_index.md`](../02_fact_cards/C6_tile_cache_spatial_index.md). Cross-cite: parent-suite `satellite-provider` existing pattern verified directly at `/Users/obezdienie001/dev/azaion/suite/satellite-provider/` per Source #92 (PostgreSQL + pure btree composite + filesystem tile storage; NO PostGIS, NO extensions).
>
> Index: [`00_summary.md`](00_summary.md). Sibling components: [C1 VIO](C1_vio.md), [C2 VPR](C2_vpr.md), [C3 Matchers](C3_matchers.md), [C4 Pose](C4_pose_estimation.md), [C5 State estimator](C5_state_estimator.md), [C7 Inference runtime](C7_inference_runtime.md), [C8 FC adapter](C8_fc_adapter.md), [C10 Pre-flight provisioning](C10_preflight_provisioning.md). C9 dropped per 2026-05-08 restructure. Cross-component gates: [`99_cross_component_gates.md`](99_cross_component_gates.md).

---

## C6 — Tile cache + spatial index

**Status**: **CLOSED at 2/N (batch 1 closed 2026-05-08)** at documentary level. **Cand 1 (mirror-suite-pattern) RECOMMENDED PRIMARY** per comparative analysis below. Cand 2 (PostGIS+pgvector) DEFERRED to defer-to-Plan or Jetson-MVE secondary — re-evaluate IF (a) project use case expands to require radius-meters-based queries, OR (b) Jetson MVE phase reveals Cand 1's app-side combined-query overhead is materially impacting AC-4.1 latency budget at the tail, OR (c) D-C1-1 license-posture choice (a) GPL-3.0 track is selected AND project elects to standardize on a single Postgres-extension stack for cross-suite consistency.

**Pinned mode** (per-frame tile-cache lookup + descriptor ANN contract for the project's C6 row):

- inputs: `{(query_lat, query_lon, query_alt_m) from C5 state estimator @ 3 Hz; (query_descriptor: numpy.ndarray of shape (d,) and dtype float32) from C2 VPR @ 3 Hz; (operator_reloc_hint_lat, hint_lon, hint_zoom) rare per AC-3.4; (mission corridor polygon + zoom level + cache budget) one-time at takeoff from C10 pre-flight provisioning}` on `Jetson Orin Nano Super (8 GB shared, JetPack 6 Ubuntu 22.04 base)` at flight time
- outputs: `{geographic-spatial-grid query: [(tile_id, tile_x, tile_y, file_path, descriptor), ...] returning K=9 (3x3) to K=25 (5x5) candidate tiles at tile_zoom = Z_target (typically Z=18 per project default); descriptor-ANN query: [(tile_id, file_path, l2_distance), ...] returning top-K=10 descriptor-similar tiles; combined query: app-side intersection (geographic-prefilter-then-descriptor-rerank canonical hierarchical retrieval pattern per Fact #21 SQ2 conclusion); cache-status diagnostics for FDR (cache_hit, cache_miss, tile_id_loaded, load_latency_ms, source_label)}`

**Locked-in research-time defaults** (carried forward from C1 + C2 + C3 + C4 + C5 — Fact #41 + user-pinned scope from session-start):
- D-C1-1 = (c) **keep both license tracks open** through Plan; final license decision deferred to post-Jetson-MVE.
- D-C1-2 = (b) **defer Jetson Orin Nano Super hardware MVE to a dedicated bring-up phase** between research and Plan; research closes with documentary ranking + per-candidate `Verify` gates.
- **C6-specific user-pinned scope** (from session-start `c6_scope` + `c6_postgres_locus = A` + follow-up clarification): Postgres on Jetson at runtime locked; satellite-provider pattern is NOT carved in stone (open to cascading changes IF research reveals MATERIAL improvement, NOT for marginal gain); simple disk tile storage following parent-suite satellite-provider pattern; spatial index uses Postgres-built-in mechanisms (btree composite OR PostGIS GiST per candidate evaluation).

**Interactions with prior C-row closures**:
- **Source #92 parent-suite satellite-provider pattern verified directly via filesystem read**: PostgreSQL + Dapper + .NET 8.0 microservice; pure btree composite indexes `idx_tiles_coordinates ON tiles(tile_zoom, tile_x, tile_y, version)` + `idx_tiles_composite ON tiles(latitude, longitude, tile_size_meters)`; filesystem tile storage at `./tiles/{zoom_level}/{x}/{y}.jpg` slippy-map hierarchy; **NO PostGIS, NO GiST, NO spatial extension** at suite level. This is the strongest project-pattern signal for C6 candidate selection.
- **C2 VPR descriptor dimension axis (D-C2-9 NetVLAD + D-C2-10 EigenPlaces + D-C2-6 SALAD descriptor-size choices)**: C6 cache footprint scales linearly with descriptor dimension. Cand 1 + Cand 2 both pass through C2 dimension choice without preference; D-C6-1 NEW (Cand-1) and D-C6-6 NEW (Cand-2) descriptor-storage-format choices both recommend halfvec / float16 for 2× cache savings at minimal Recall@K loss.
- **C2 VPR retrieval-pipeline architecture**: C6 owns the storage + index for global descriptors that C2 VPR queries at 3 Hz. The geographic-prefilter-then-descriptor-rerank canonical hierarchical retrieval pattern per Fact #21 SQ2 conclusion is satisfied by both candidates (Cand 1 via app-side round trip; Cand 2 via single combined SQL query).
- **C5 state-estimator output as cache-query input**: C5's WGS84 position estimate at min-3-Hz drives the (query_lat, query_lon) input to C6; C6 cache miss feeds back into C5's source-label state-machine demotion (`satellite_anchored → visual_propagated → dead_reckoned`) per AC-NEW-8 blackout failsafe escalation.
- **C8 MAVLink/MSP2 FC adapter (when opened)**: C6 cache hits provide the satellite-anchor pose that becomes the GPS_INPUT/MSP2_SENSOR_GPS message payload via C5; cache hit/miss timing is critical for AC-NEW-2 spoofing-promotion <3 s timing.
- **C10 pre-flight cache provisioning + sector classification (when opened)**: C10 owns the LOAD side of C6 (populating the cache from the suite satellite-provider before flight); C6 owns the QUERY side at flight time. C10 also owns the FAISS-index-rebuild + serialization mentioned in D-C6-3 NEW.

| # | Candidate | License | Per-mode verification | Status | Lead reason / disqualifier | Sub-matrix cite |
|---|---|---|---|---|---|---|
| 1 | **Manual mirror of existing parent-suite `satellite-provider` pattern** — PostgreSQL btree composite on slippy-map `(tile_zoom, tile_x, tile_y, version)` + bytea descriptor blobs + app-side FAISS HNSW loaded at takeoff + filesystem tile storage at `./tiles/{zoom}/{x}/{y}.{image_type}` (psycopg-binary or asyncpg Python driver + `faiss-cpu` Python package on Jetson) | **Clean throughout** — PostgreSQL (PostgreSQL License = BSD-style permissive) + FAISS (MIT) + psycopg2/asyncpg (LGPL-3.0 / MIT-Apache-2.0 dual); no Postgres extensions; eligible on every D-C1-1 license-posture choice with the simplest license-compliance story | ✅ Mode enumeration via Source #92 direct filesystem read of satellite-provider migrations 001/003/011 + Source #93 PostgreSQL 16 multicolumn-indexes docs WebFetch + Source #96 FAISS context7 IndexHNSWFlat / IndexFlatL2 / IndexIVFFlat enumeration + Source #97 March 2026 Postgres-on-Jetson empirical confirmation + Source #98 OSM slippy-map convention WebFetch — **all four query modes verified**: geographic-spatial-grid range query (`WHERE tile_zoom = ? AND tile_x BETWEEN ? AND ? AND tile_y BETWEEN ? AND ?`), descriptor-ANN (FAISS `index.search(query, k)`), combined geographic-+-descriptor (app-side intersection), operator re-loc hint (direct btree-indexed point query); ✅ runnable example via satellite-provider .NET service + canonical FAISS Python notebooks; ✅ **NATIVE 6-byte sub-millisecond btree lookup** on integer-coordinate columns for the dominant 3 Hz spatial-grid query; ✅ **Postgres-on-Jetson empirically confirmed** in Source #97 March 2026 article (OLTP throughput saturates at 10 concurrent connections — ARM CPU 6 cores, NOT memory, is limiting factor — well within project's 3 Hz single-query rate); ⚠️ **app-side combined geographic-+-descriptor query overhead** ~1-2 ms per round trip (mitigated at 3 Hz: ~3-6 ms/sec absolute time, negligible vs AC-4.1 400 ms p95 budget); ⚠️ **takeoff-time FAISS index build** ~5-30 sec (mitigated via D-C6-3 = (c) periodic rebuild during C10 pre-flight + serialize via `faiss.write_index` + reload at takeoff in <5 sec); ⚠️ **AC-8.3 cache budget TIGHT at 2048-D float32 descriptors** (mitigated via D-C6-1 = (b) halfvec at 4 KB/tile, OR via D-C2-10 = (b) 512-D EigenPlaces at 2 KB/tile); ⚠️ **no native KNN distance ordering for geographic queries** (mitigated via per-zoom k-tile-radius math: at zoom 18 ~150 m/tile k=2 covers ~750 m, at zoom 20 ~38 m/tile k=8 covers similar) | **Mandatory simple-baseline + RECOMMENDED PRIMARY** (engine Component Option Breadth rule role — structurally analogous to OpenCV `solvePnPRansac`'s role in C4 row + NetVLAD's role in C2 row + SuperGlue+SuperPoint's role in C3 row + Manual ESKF Solà 2017's role in C5 row); deployment-ready under every D-C1-1 license-posture choice; **EMPIRICALLY-CONFIRMED Postgres-on-Jetson viability** per Source #97 March 2026 evidence; **EXACT mirror of parent-suite satellite-provider pattern = ZERO new infrastructure to learn, debug, or maintain across the suite vs onboard split**; final ranking confirmed at Jetson MVE phase per D-C1-2 | **THREE CONVERGING POSITIVE structural advantages**: (i) **PROJECT-PATTERN ALIGNMENT** — exactly mirrors the parent-suite `satellite-provider` pattern verified directly via Source #92 filesystem read (PostgreSQL + Dapper + .NET 8.0 microservice; pure btree composite + filesystem `./tiles/{zoom}/{x}/{y}.jpg`); if a tile is requested in pre-flight provisioning by C10 from the suite Postgres, the same SQL query and same filesystem path work on the Jetson at flight time; per coderule.mdc "Before writing new infrastructure or workaround code, check how the existing codebase already handles the same concern. Follow established project patterns." Cand 1 is the ONLY C6 candidate that satisfies this rule fully; (ii) **TRIVIAL DEPENDENCY FOOTPRINT** — vanilla PostgreSQL 16 (already required if `c6_postgres_locus = A` Postgres-on-Jetson) + FAISS-CPU Python package + psycopg-binary; **NO Postgres extensions** (no PostGIS, no pgvector, no pg_trgm); **clean throughout** on every D-C1-1 license-posture choice (PostgreSQL License + MIT + LGPL/MIT-Apache dual); (iii) **EMPIRICALLY-CONFIRMED Postgres-on-Jetson viability** — Source #97 March 2026 Medium "Edge to Data Center: GPU-Accelerated Vector Search on a Jetson Orin Nano" confirms full Postgres + pgvector + Ollama + embedding-model GPU stack runs on Jetson Orin Nano Super; **CPU cores (6) are the limiting factor, NOT memory**, which means the 8 GB shared memory budget is plenty of headroom for Cand 1's modest 700 MB-1.5 GB total. **THREE NEGATIVE-BUT-MITIGABLE structural findings** all of which are well within the AC-4.1 + AC-4.2 + AC-8.3 budgets after mitigation: (iv) **app-side combined geographic-+-descriptor query overhead** ~1-2 ms per round trip (mitigated at 3 Hz: ~3-6 ms/sec absolute time, negligible vs 400 ms AC-4.1 budget); (v) **takeoff-time FAISS index build** ~5-30 sec one-time cost (mitigated via D-C6-3 = (c) periodic rebuild during C10 pre-flight + serialize via `faiss.write_index` + reload at takeoff in <5 sec); (vi) **AC-8.3 cache budget TIGHT at 2048-D float32 descriptors** (mitigated via D-C6-1 = (b) halfvec at 4 KB/tile + D-C2-10 = (b) 512-D EigenPlaces). **TWO MINOR CAVEATS**: (vii) no native KNN distance ordering for geographic queries (mitigated via per-zoom k-tile-radius math; project's pinned 3x3 grid lookup at fixed zoom doesn't exercise this capability); (viii) no native great-circle / geodesic distance (negligible at project's ≤200 km mission radius where Web Mercator distortion is <0.5%). **AC-NEW-4 covariance honesty handling**: N/A (cache is passive; covariance is C4/C5 responsibility). **AC-NEW-7 cache-poisoning safety**: PASS at storage layer via UNIQUE constraint + immutable on-disk JPEGs + content-hash verification; cache-poisoning DETECTION is C9/C10 responsibility | Fact #92 in [`../02_fact_cards/C6_tile_cache_spatial_index.md`](../02_fact_cards/C6_tile_cache_spatial_index.md) (per-mode entry + per-numbered-Restriction × per-numbered-AC sub-matrix block) |
| 2 | **PostgreSQL + PostGIS 3.4 GiST on `geography(POINT,4326)` + KNN distance ordering (`<->`) + pgvector 0.7+ HNSW for descriptor ANN + filesystem tile storage** (canonical `postgis/postgis` extension by PostGIS Project Steering Committee + canonical `pgvector/pgvector` extension by Andrew Kane; modern-competitive-lead-spatial-extension; **DIVERGENT from parent-suite satellite-provider pattern** — requires D-C6-7 NEW cross-component cascade decision) | **License complexity** — PostgreSQL (PostgreSQL License = BSD-style permissive) + PostGIS (**GPL-2.0-or-later** per canonical project license) + pgvector (PostgreSQL License = BSD-style permissive) + psycopg2/asyncpg (LGPL-3.0 / MIT-Apache-2.0 dual). **PostGIS GPL-2.0-or-later may conflict with D-C1-1 license-posture choice (b) BSD/permissive-only-track** — hard verification gate at D-C6-5/D-C1-1 final lock; eligible under D-C1-1 = (a) GPL-3.0 track or (c) keep-both-tracks-open; CONTINGENT REJECT under D-C1-1 = (b) | ✅ Mode enumeration via Source #94 PostGIS workshop KNN docs WebFetch + PostGIS context7 indexed at `/postgis/postgis` + Source #95 pgvector context7 indexed at `/pgvector/pgvector` — **all four query modes verified**: geographic-KNN (`ORDER BY position <-> ST_MakePoint($lon, $lat)::geography LIMIT K` with index-assisted EXPLAIN), geographic-radius (`WHERE ST_DWithin(position::geography, ST_MakePoint($lon, $lat)::geography, $radius_m)` native great-circle distance in meters), descriptor-ANN (pgvector HNSW `ORDER BY descriptor <-> $query_vec LIMIT K`), combined geographic-+-descriptor (single SQL statement combining `ST_DWithin` filter + `<->` descriptor distance ordering); ✅ runnable example via canonical PostGIS workshop nyc_streets dataset + pgvector README HNSW examples; ✅ **NATIVE great-circle distance for `geography` type** + **NATIVE KNN distance ordering** + **NATIVE radius queries in meters** + **NATIVE combined SQL query** — ALL FOUR are improvements over Cand 1's btree-only approach; ⚠️ **PostGIS+pgvector co-installation on Jetson Orin Nano Super NOT empirically verified** — Source #94 search results explicit limitation: "do not provide specific information about PostGIS 3.4's compatibility with ARM64 architecture on Jetson devices, nor do they document the installation footprint" (D-C6-5 NEW gate covers this); ⚠️ **pgvector HNSW dimension limit at 2,000-D for full-precision `vector` type** — for MixVPR canonical 2048-D descriptors per Fact #18 cluster, this JUST EXCEEDS the limit (mitigated via halfvec_l2_ops which supports up to 16,000 dim); ⚠️ **GiST geographic lookup ~5-10× slower than Cand 1's btree composite for the dominant 3 Hz spatial-grid query** — GiST ~1-5 ms vs Cand 1's btree ~0.1-0.5 ms (mitigated: at 3 Hz the absolute latency difference is negligible, but the relative slowdown is real); ⚠️ **PostGIS GPL-2.0-or-later license complexity** — D-C1-1 = (b) BSD/permissive-only-track makes Cand 2 a hard CONTINGENT REJECT | **Modern-competitive-lead-spatial-extension** (engine Component Option Breadth rule role; addresses the "Postgres-built-in spatial index" axis the user explicitly named in the session-start `c6_scope` clarification; **NATIVE KNN + radius + combined-SQL** capabilities improve over Cand 1 BUT the project's pinned use case does not exercise these capabilities); deployment-ready under D-C1-1 = (a) or (c) license-posture choices; CONTINGENT REJECT under D-C1-1 = (b); **DIVERGENT from parent-suite satellite-provider pattern** = forces D-C6-7 NEW cascade decision; final ranking deferred to Jetson MVE phase per D-C1-2 + D-C6-5 NEW | **FOUR CONVERGING POSITIVE structural advantages over Cand 1**: (i) **NATIVE KNN distance ordering for geographic queries** — `ORDER BY position <-> ST_MakePoint(...) LIMIT K` with index-assisted EXPLAIN per Source #94 evidence; **no app-side k-derivation OR distance-sort required** vs Cand 1's per-zoom k-tile-radius math; (ii) **NATIVE great-circle / geodesic distance for `geography` type** — `ST_DWithin(position::geography, ..., $radius_m)` returns true distance in meters across WGS84 ellipsoid; no Web-Mercator approximation; **material accuracy improvement near poles or at very high zoom but negligible for project's UAV at 1 km AGL covering ≤200 km mission radius (Web Mercator distortion <0.5%)**; (iii) **NATIVE combined geographic-+-descriptor query in a single SQL statement** — eliminates app-side round-trip overhead present in Cand 1 (~1-2 ms per query); enables Postgres query planner to choose the most selective filter first; (iv) **NATIVE `ST_DWithin(geography, geography, radius_m)` radius queries in meters** — directly answers "give me all tiles within R meters of the query point" without per-zoom k-derivation = **NEW capability vs Cand 1**. **FOUR NEGATIVE-BUT-MITIGABLE structural findings**: (v) **HEAVIER POSTGRES-EXTENSION DEPENDENCY** — PostGIS ~30-80 MB shared libraries + pgvector ~5-10 MB shared library; well within AC-4.2 8 GB budget but real cost is extra extensions to maintain, version-pin, and verify ARM64 compatibility for at C7 inference-runtime + Jetson MVE phase; (vi) **GiST geographic lookup 5-10× slower than Cand 1's btree composite for the dominant query** — at 3 Hz the absolute latency difference (~1-5 ms vs ~0.1-0.5 ms) is negligible, but the relative slowdown is real; (vii) **pgvector HNSW dimension limit at 2,000-D for full-precision** — `vector` type HNSW supports up to 2,000 dimensions per Source #95; for MixVPR 2048-D this JUST EXCEEDS the limit; mitigation = halfvec_l2_ops (half-precision, 2-byte storage, supports up to 16,000 dimensions, 50% cache footprint saving, ~0-2% Recall@K loss) per D-C6-6 NEW = (b); (viii) **NO empirically-verified Jetson Orin Nano Super deployment for PostGIS+pgvector combined stack** — Source #97 confirms Postgres+pgvector but not explicitly+PostGIS; D-C6-5 NEW Jetson MVE verification gate. **TWO HARD CAVEATS**: (ix) **PostGIS GPL-2.0-or-later license-complexity** — D-C1-1 = (b) BSD/permissive-only-track makes Cand 2 a hard CONTINGENT REJECT; (x) **DIVERGENT from parent-suite satellite-provider pattern** — forces D-C6-7 NEW cross-component cascade-changes-back-to-suite decision. **COMPARATIVE-IMPROVEMENT-VS-CAND-1 VERDICT** (per user's "significant-improvement-only" bar): **Cand 2's improvements (native KNN, native radius queries, single-SQL combined query) are real BUT the project's pinned 3 Hz spatial-grid query at fixed zoom does not exercise these capabilities**; Cand 2 is **5-10× slower for the dominant geographic query** AND **requires PostGIS+pgvector ARM64 Jetson MVE verification** AND **forces a cross-suite cascade decision (D-C6-7)** AND **may conflict with D-C1-1 license-posture choice (b)**. **The improvements are marginal-to-negative in the project's specific operating context** — no material justification to deviate from the existing satellite-provider pattern. **Cand 2 promotion criteria**: re-evaluate IF (a) project use case expands to require radius-meters-based queries, OR (b) Jetson MVE phase reveals Cand 1's app-side combined-query overhead is materially impacting AC-4.1 latency budget at the tail, OR (c) D-C1-1 license-posture choice (a) GPL-3.0 track is selected AND project elects to standardize on a single Postgres-extension stack | Fact #93 in [`../02_fact_cards/C6_tile_cache_spatial_index.md`](../02_fact_cards/C6_tile_cache_spatial_index.md) (per-mode entry + per-numbered-Restriction × per-numbered-AC sub-matrix block + comparative-improvement-vs-Cand-1 analysis) |

### C6 — Plan-phase deliverables raised by candidate closures

1. **D-C6-1 NEW (Cand-1 + applies to Cand 2 via D-C6-6 mirror) — descriptor-storage-format choice** (full-precision float32 in `bytea` column ~8 KB/tile-at-2048-D / **halfvec via app-side conversion + storage as 2-byte half-floats ~4 KB/tile-at-2048-D ~50% cache savings ~0-2% Recall@K loss RECOMMENDED** / INT8 quantized ~1 KB/tile-at-2048-D ~87.5% cache savings + per-vector scale parameter requires ~1 day engineering for quantization-aware loader). **Recommendation**: D-C6-1 = (b) halfvec for descriptor storage at ~2× cache-footprint-saving with ~0-2% Recall@K loss documented in pgvector ecosystem.

2. **D-C6-2 NEW (Cand-1-only) — FAISS index variant choice for app-side descriptor ANN** (`IndexFlatL2` brute-force exact-distance for small caches <10K tiles ~1-3 ms per query / **`IndexHNSWFlat(d, M=32)` graph-based approximate for primary path 100K-1M tiles ~1-3 ms per query w/ efSearch=64 RECOMMENDED** / `IndexIVFFlat` inverted-file approximate w/ training requirement / `IndexIVFPQ` for additional product-quantizer compression at ~10% Recall@K loss). **Recommendation**: D-C6-2 = (b) IndexHNSWFlat M=32 for primary path; IndexFlatL2 fallback for small caches per Source #96 contextual guidance.

3. **D-C6-3 NEW (Cand-1-only, CROSS-COMPONENT with C10) — descriptor-cache-rebuild-trigger strategy** (rebuild on every cache modification ~simplest but slow ~5-30 sec per rebuild blocks readiness / incremental add via `index.add()` ~faster but HNSW does not support delete cleanly per Source #96 / **periodic rebuild during pre-flight provisioning ~most robust requires C10 coordination + serialize via `faiss.write_index` + reload at takeoff in <5 sec RECOMMENDED**). **Recommendation**: D-C6-3 = (c) periodic rebuild during C10 pre-flight provisioning. Applies only if Cand 1 selected.

4. **D-C6-4 NEW (Cand-1-only) — geographic-spatial-grid radius `k` choice** (fixed-1 = 3x3 grid simplest / fixed-2 = 5x5 grid covers AC-3.x sharp turns more robustly / fixed-4 = 9x9 grid for very high-bank or low-zoom / **dynamic derived from zoom + ground-speed projected over next 5 sec RECOMMENDED**). **Recommendation**: D-C6-4 = dynamic.

5. **D-C6-5 NEW (Cand-2-only contingent) — Jetson PostGIS + pgvector co-installation Plan-phase verification choice** (**verify on Jetson MVE phase as part of D-C1-2 dedicated bring-up phase RECOMMENDED — already-required Jetson hardware bring-up cycle absorbs this work cheaply** / fork PostGIS+pgvector ARM64 builds in-house if upstream packages incomplete ~1-3 days engineering / pivot to Cand 1 if PostGIS+pgvector co-installation reveals blocking incompatibility). **Recommendation**: D-C6-5 = (a) verify on Jetson MVE.

6. **D-C6-6 NEW (Cand-2-only contingent) — pgvector descriptor-storage-type choice** (`vector` full-precision float32 with 2,000-dim max for HNSW per Source #95 — JUST EXCEEDED by MixVPR 2048-D / **`halfvec` half-precision 2-byte with 16,000-dim max + 50% cache savings + ~0-2% Recall@K loss RECOMMENDED — covers all C2 VPR descriptor candidates consistently** / `sparsevec` for sparse descriptors / `bit` for binary descriptors via Hamming distance). **Recommendation**: D-C6-6 = (b) halfvec for the primary path.

7. **D-C6-7 NEW (CROSS-COMPONENT — affects both Cand 1 and Cand 2; forced by Cand 2 selection) — IF Cand 2 selected → cascade-changes-back-to-suite-satellite-provider strategy choice** (cascade PostGIS+pgvector adoption back to satellite-provider for cross-suite consistency ~1-3 days engineering at suite + onboard / keep satellite-provider on btree-only and gps-denied-onboard on PostGIS+pgvector ~accept divergence + maintenance burden / migrate satellite-provider to PostGIS+pgvector in a separate ticket post-MVP / **leave satellite-provider unchanged + maintain Cand 1 throughout — no cascade needed RECOMMENDED if Cand 1 selected as primary, which is the closure verdict**). **Recommendation**: per user's session-start clarification "if improvement is small, then there is no sense to change anything at all" — IF Cand 2's MATERIAL improvement justifies adoption (currently NO per closure verdict), cascade via separate ticket; OTHERWISE stay with Cand 1 throughout the suite.

---

## C6 — Cross-row dependencies + working summary

- **C6 row depends on Source #92 parent-suite satellite-provider pattern verification** — direct filesystem read at `/Users/obezdienie001/dev/azaion/suite/satellite-provider/` confirms PostgreSQL + Dapper + .NET 8.0 + filesystem tile storage + pure btree composite indexes; NO PostGIS/extensions at suite level. This is the **strongest project-pattern signal** for C6 candidate selection per coderule.mdc.
- **C6 row provides storage + index for global descriptors that C2 VPR queries at 3 Hz**. Both candidates pass through C2 dimension choice (D-C2-9 NetVLAD + D-C2-10 EigenPlaces + D-C2-6 SALAD) without preference; D-C6-1 (Cand-1) and D-C6-6 (Cand-2) both recommend halfvec for 2× cache savings.
- **C6 row provides geographic prefilter for C2's hierarchical retrieval pattern** per Fact #21 SQ2 conclusion canonical pattern. Cand 1 satisfies via app-side intersection (round-trip ~1-2 ms); Cand 2 satisfies via single SQL statement (in-DB ~0.5 ms).
- **C6 row consumes C5's WGS84 position estimate** at min-3-Hz as the (query_lat, query_lon) input. Cache miss feeds back into C5's source-label state-machine demotion per AC-NEW-8.
- **C6 row depends on C10 pre-flight cache provisioning** for the LOAD side. C6 owns QUERY at flight time; C10 owns LOAD before flight. D-C6-3 NEW (descriptor-cache-rebuild-trigger) is jointly owned with C10.
- **C6 row depends on C7 on-Jetson inference runtime** for the Postgres + (FAISS or PostGIS+pgvector) ARM64 install + tuning + benchmark on Jetson Orin Nano Super at Jetson MVE phase per D-C1-2 + D-C6-5 NEW.

**Closure summary**: C6 batch 1 closed at 2/N on 2026-05-08. **Cand 1 (mirror-suite-pattern) is RECOMMENDED PRIMARY**; Cand 2 (PostGIS+pgvector) is DEFERRED secondary with explicit re-evaluation criteria. Seven Plan-phase Choose blocks raised (D-C6-1 through D-C6-7). Subsequent C6 candidates (e.g., MBTiles single-sqlite-file, LMDB+geohash, FAISS-only-no-Postgres) deferable — current 2-candidate breadth satisfies engine Component Option Breadth rule for the user's pinned-Postgres scope; further candidate evaluation only if Cand 1 fails Jetson MVE per D-C1-2.
