Revise acceptance criteria and restrictions documentation to clarify recent updates and specifications. Key changes include enhanced definitions for position accuracy, image processing quality, and operational parameters, as well as updates to camera specifications and validation requirements. This revision aims to improve clarity and ensure alignment with project goals.

_docs/00_problem/acceptance_criteria.md

@@ -1,22 +1,25 @@
 # Acceptance Criteria
 
-> **Last revised**: 2026-04-29 (visual-blackout / GPS-spoofing degraded-mode addendum).
+> **Last revised**: 2026-05-01 (Phase 1 AC/restrictions assessment clarifications).
 > Changes vs. previous version (2026-04-25): AC-1.2 split into hard-floor + stretch; AC-1.4 made quantitative; AC-2.2 split per pipeline stage; AC-3.4 dual-trigger; AC-4.3 autopilot-pinned; AC-5.2 N pinned; AC-7.1 scoped to level flight; AC-8.2 freshness by sector; six new AC added (AC-NEW-1 … AC-NEW-6).
 > Changes 2026-04-26: AC-4.3 extended to dual-channel hybrid (GPS_INPUT primary + ODOMETRY auxiliary); AC-8.6 added (VPR retrieval-unit + change-robustness); AC-NEW-7 added with confirmed numeric thresholds (cache-poisoning safety budget).
 > Changes 2026-04-29: AC-3.5 and AC-NEW-8 added for temporary visual blackout/cloud occlusion during GPS spoofing, including IMU-only degraded navigation, covariance growth, and failover limits.
+> Changes 2026-05-01: AC-1.3 anchor-age reporting clarified; AC-2.1 split so the >95% rate applies to VO registration, not every satellite re-anchor; AC-5.2 and AC-NEW-2 now require ArduPilot Plane SITL trigger verification; AC-8.3 storage accounting and AC-NEW-7 Satellite Service ownership clarified.
 
 ## Position Accuracy
 
 - **AC-1.1** — The system shall determine GPS coordinates of frame centers within **50 m** of true GPS for **≥80%** of photos in normal flight segments.
 - **AC-1.2** — The system shall determine GPS coordinates of frame centers within **20 m** of true GPS for **≥50%** of photos in normal flight segments.
-- **AC-1.3** — Maximum cumulative VO drift between two consecutive satellite-anchored fixes shall be **<100 m** (VO-only fallback) or **<50 m** (when IMU is fused). Drift is measured as ‖VO-extrapolated centre − next anchor centre‖ at the moment of the anchor fix.
+- **AC-1.3** — Maximum cumulative VO drift between two consecutive satellite-anchored fixes shall be **<100 m** (VO-only fallback) or **<50 m** (when IMU is fused). Drift is measured as ‖VO-extrapolated centre − next anchor centre‖ at the moment of the anchor fix. Every emitted estimate shall include `last_satellite_anchor_age_ms`; validation results shall be binned by anchor age, and the solution draft must define the maximum anchor age after which estimates are treated as degraded (`vo_extrapolated` or `dead_reckoned`) with monotonically growing covariance.
 - **AC-1.4** — The system shall report a **quantitative confidence score** per position estimate, comprising:
   - the 95% covariance ellipse semi-major axis in meters, AND
   - a categorical label `{satellite_anchored, vo_extrapolated, dead_reckoned}`.
 
 ## Image Processing Quality
 
-- **AC-2.1** — Image registration rate **>95%** for normal flight segments (defined as: nadir flight ±10° bank / pitch, ≥40% overlap with prior frame, daytime, season-matched satellite tile).
+- **AC-2.1** — Image registration rate is split by registration type:
+  - **AC-2.1a — VO registration**: frame-to-frame visual registration shall succeed for **>95%** of normal flight segments (defined as: nadir flight ±10° bank / pitch, ≥40% overlap with prior frame, daytime, usable texture, no full visual blackout).
+  - **AC-2.1b — Satellite-anchor registration**: cross-domain UAV-photo to satellite/cache registration is measured separately and is not hidden inside AC-2.1a. Satellite anchoring must satisfy AC-1.1 / AC-1.2 position accuracy, AC-2.2 cross-domain MRE, AC-8.2 freshness, and AC-8.6 retrieval behavior on season-matched tiles.
 - **AC-2.2** — Mean Reprojection Error (MRE):
   - **<1.0 px** for VO frame-to-frame homography on overlapping aerial pairs;
   - **<2.5 px** for satellite-anchored cross-domain (UAV photo ↔ ortho satellite tile) registration.
@@ -31,7 +34,7 @@
 
 ## Real-Time Onboard Performance
 
-- **AC-4.1** — End-to-end latency from camera capture to GPS coordinate output to the flight controller shall be **<400 ms p95**. Up to ~10% of frames may be dropped under sustained load (skip-allowed).
+- **AC-4.1** — End-to-end latency from camera capture to GPS coordinate output to the flight controller shall be **<400 ms p95**. Up to ~10% of frames may be dropped under sustained load (skip-allowed). Heavy global VPR / cross-domain re-ranking shall be conditional, not part of the steady-state per-frame path, unless profiling proves the full path stays inside the latency and memory budgets on the target Jetson.
 - **AC-4.2** — Memory usage shall remain below **8 GB** shared on Jetson Orin Nano Super (CPU and GPU share the same 8 GB LPDDR5 pool).
 - **AC-4.3** — The system shall output its position estimate to the flight controller via **two parallel MAVLink channels**, both emitted by **pymavlink** (general telemetry uses MAVSDK):
   - **Primary**: `GPS_INPUT` targeting **ArduPilot** with `GPS1_TYPE=14` (MAVLink GPS substitute). Matches the "replacement for the GPS module" framing of the build.
@@ -45,7 +48,7 @@
 ## Startup & Failsafe
 
 - **AC-5.1** — The system shall initialise using the last known valid GPS position from the flight controller's EKF, plus IMU-extrapolated position at the moment of GPS denial.
-- **AC-5.2** — If the system fails to produce any position estimate for **>3 s**, the flight controller shall fall back to IMU-only dead reckoning and the system shall log the failure.
+- **AC-5.2** — If the system fails to produce any position estimate for **>3 s**, the flight controller shall fall back to IMU-only dead reckoning and the system shall log the failure. Because ArduPilot failsafe timing depends on vehicle type and parameters, this fallback behavior must be verified specifically in ArduPilot Plane SITL with the production parameter set; Copter defaults are reference evidence only.
 - **AC-5.3** — On companion computer reboot mid-flight, the system shall attempt to re-initialise from the flight controller's current IMU-extrapolated position. See AC-NEW-1 for the cold-start time-to-first-fix budget.
 
 ## Ground Station & Telemetry
@@ -66,7 +69,7 @@
   - **<6 months old** for active-conflict sectors;
   - **<12 months old** for stable rear sectors.
   System shall reject or downgrade-confidence on tiles older than these thresholds (see AC-NEW-6).
-- **AC-8.3** — Satellite imagery for the operational area shall be **pre-loaded and pre-processed** onto the companion computer before flight. Offline preprocessing time is not time-critical (minutes/hours). Pre-extracted tile descriptors (e.g., SuperPoint keypoints/descriptors and DINOv2-VLAD global descriptors) are part of the cache.
+- **AC-8.3** — Satellite imagery for the operational area shall be **pre-loaded and pre-processed** onto the companion computer before flight. Offline preprocessing time is not time-critical (minutes/hours). Pre-extracted tile descriptors (e.g., SuperPoint keypoints/descriptors and DINOv2-VLAD global descriptors) are part of the cache and count against the storage budget unless the solution draft explicitly defines a separate descriptor/index budget.
 - **AC-8.4** — **Mid-flight tile generation & write-back**: during flight, the system shall continuously orthorectify navigation-camera frames into tiles aligned with the basemap projection and store them in the local cache, **deduplicated** so each ground sector is stored at most once (latest / highest-quality tile wins). On landing, the companion computer shall upload newly generated tiles back to the Azaion Suite Satellite Service so that the next mission cache contains imagery refreshed by the previous flight.
 - **AC-8.5** — **Storage policy**: the system shall **not** retain raw navigation-camera frames or AI-camera frames as part of normal operation. Tiles are the only persistent imagery artifact. Forensic exception: a low-rate (≤0.1 Hz) thumbnail log of frames that **failed** tile generation may be retained for debugging within the FDR budget (AC-NEW-3).
 - **AC-8.6** — **VPR retrieval unit + change-robustness**:
@@ -93,9 +96,9 @@
 
 **Why it matters.** Without this gate, the FC may continue to follow a spoofed real-GPS source while our valid estimate sits idle. 3 s is short enough to keep the FC from acting on a malicious heading change but long enough to ride out a single-frame anomaly.
 
-**Implementation drivers.** Subscribe to `GPS_RAW_INT`, `EKF_STATUS_REPORT`, `SYS_STATUS`. Maintain an internal "real-GPS health" rolling average; switch to "primary" mode (raise our `GPS_INPUT` `fix_type` to 3D and assert) when health drops below threshold for ≥1 s. Emit `STATUSTEXT` to QGC on every promotion / demotion.
+**Implementation drivers.** Subscribe to `GPS_RAW_INT`, `EKF_STATUS_REPORT`, `SYS_STATUS`, and any ArduPilot Plane EKF/GPS status messages available in the production firmware. Maintain an internal "real-GPS health" rolling average; switch to "primary" mode (raise our `GPS_INPUT` `fix_type` to 3D and assert) when the verified Plane-specific health trigger stays below threshold for >=1 s. Emit `STATUSTEXT` to QGC on every promotion / demotion.
 
-**Validation.** SITL: simulate spoofing (inject false `GPS_RAW_INT` from a malicious node); measure time from spoof onset to our promotion. Pass = 95% percentile <3 s.
+**Validation.** ArduPilot Plane SITL: simulate spoofing (inject false `GPS_RAW_INT` from a malicious node); verify the exact trigger signals used by the production parameter set; measure time from spoof onset to our promotion. Pass = 95% percentile <3 s.
 
 ### AC-NEW-3 — Flight Data Recorder
 
@@ -150,7 +153,7 @@
 
 **Implementation drivers.**
 - Service-source tiles are immutable within freshness budget (AC-8.2); onboard tiles overwrite only stale or other-onboard tiles.
-- The Suite Satellite Service ingest applies a **2-flight voting layer**: an onboard tile gets promoted to "trusted basemap" only after **N≥2 independent flights** confirm consistent geo-alignment within X m of each other. (Active sectors per AC-NEW-6 may use single-flight promotion when σ_xy ≤ 3 m AND OSM-road-overlap ≥ 70 %.)
+- The onboard GPS-Denied system writes tile-quality metadata required by the Suite Satellite Service. The Service-side ingest applies a **2-flight voting layer**: an onboard tile gets promoted to "trusted basemap" only after **N>=2 independent flights** confirm consistent geo-alignment within X m of each other. (Active sectors per AC-NEW-6 may use single-flight promotion when σ_xy <= 3 m AND OSM-road-overlap >= 70 %.) The voting layer is an external Suite Satellite Service dependency, not implemented inside this onboard build, but its contract is required for AC-NEW-7 to pass end-to-end.
 - The Component-1b parent-pose covariance is a **hard gate** in the local quality score: σ_xy ≤ 5 m for a hard write (`trust_level = candidate`); σ_xy ≤ 3 m for `trust_level = candidate` with full quality; tiles written in the σ_xy ∈ (3, 5] m band are marked `trust_level = soft` in the sidecar.
 - Eligibility check (Component 1b) tightens generation gate from σ_xy ≤ 10 m to σ_xy ≤ 5 m.
 

_docs/00_problem/input_data/expected_results/results_report.md

@@ -0,0 +1,86 @@
+# Expected Results Mapping
+
+## Scope
+
+`coordinates.csv` is the current source of truth for the provided nadir image set. It gives expected WGS84 frame-center coordinates for `AD000001.jpg` through `AD000060.jpg`.
+
+This data is sufficient for black-box frame-center geolocation tests against still images. It is not sufficient for final BASALT VIO, IMU-fusion, blackout, spoofing, or flight-controller tests because synchronized IMU/attitude/airspeed/altitude and ground-truth trajectory are not present in this sample set.
+
+## Pass / Fail Rules
+
+- **Normal frame-center geolocation**: estimated frame center is within 50 m of the expected WGS84 coordinate.
+- **Stretch accuracy bin**: estimated frame center is within 20 m of the expected WGS84 coordinate.
+- **Dataset aggregate**: at least 80% of mapped images pass the 50 m threshold and at least 50% pass the 20 m threshold.
+- **Output shape**: each result must include image name, estimated `lat`, estimated `lon`, error in meters, source label, 95% covariance semi-major axis, and `last_satellite_anchor_age_ms`.
+
+## Input To Expected Output Map
+
+| Input image | Expected latitude | Expected longitude | Primary threshold | Stretch threshold |
+|-------------|-------------------|--------------------|-------------------|-------------------|
+| AD000001.jpg | 48.275292 | 37.385220 | <= 50 m | <= 20 m |
+| AD000002.jpg | 48.275001 | 37.382922 | <= 50 m | <= 20 m |
+| AD000003.jpg | 48.274520 | 37.381657 | <= 50 m | <= 20 m |
+| AD000004.jpg | 48.274956 | 37.379004 | <= 50 m | <= 20 m |
+| AD000005.jpg | 48.273997 | 37.379828 | <= 50 m | <= 20 m |
+| AD000006.jpg | 48.272538 | 37.380294 | <= 50 m | <= 20 m |
+| AD000007.jpg | 48.272408 | 37.379153 | <= 50 m | <= 20 m |
+| AD000008.jpg | 48.271992 | 37.377572 | <= 50 m | <= 20 m |
+| AD000009.jpg | 48.271376 | 37.376671 | <= 50 m | <= 20 m |
+| AD000010.jpg | 48.271233 | 37.374806 | <= 50 m | <= 20 m |
+| AD000011.jpg | 48.270334 | 37.374442 | <= 50 m | <= 20 m |
+| AD000012.jpg | 48.269922 | 37.373284 | <= 50 m | <= 20 m |
+| AD000013.jpg | 48.269366 | 37.372134 | <= 50 m | <= 20 m |
+| AD000014.jpg | 48.268759 | 37.370940 | <= 50 m | <= 20 m |
+| AD000015.jpg | 48.268291 | 37.369815 | <= 50 m | <= 20 m |
+| AD000016.jpg | 48.267719 | 37.368469 | <= 50 m | <= 20 m |
+| AD000017.jpg | 48.267461 | 37.367255 | <= 50 m | <= 20 m |
+| AD000018.jpg | 48.266663 | 37.365888 | <= 50 m | <= 20 m |
+| AD000019.jpg | 48.266135 | 37.365460 | <= 50 m | <= 20 m |
+| AD000020.jpg | 48.265574 | 37.364211 | <= 50 m | <= 20 m |
+| AD000021.jpg | 48.264892 | 37.362998 | <= 50 m | <= 20 m |
+| AD000022.jpg | 48.264393 | 37.361086 | <= 50 m | <= 20 m |
+| AD000023.jpg | 48.263803 | 37.361028 | <= 50 m | <= 20 m |
+| AD000024.jpg | 48.263014 | 37.359878 | <= 50 m | <= 20 m |
+| AD000025.jpg | 48.262635 | 37.358277 | <= 50 m | <= 20 m |
+| AD000026.jpg | 48.261819 | 37.357116 | <= 50 m | <= 20 m |
+| AD000027.jpg | 48.261182 | 37.355907 | <= 50 m | <= 20 m |
+| AD000028.jpg | 48.260727 | 37.354723 | <= 50 m | <= 20 m |
+| AD000029.jpg | 48.260117 | 37.353469 | <= 50 m | <= 20 m |
+| AD000030.jpg | 48.259677 | 37.352165 | <= 50 m | <= 20 m |
+| AD000031.jpg | 48.258881 | 37.351376 | <= 50 m | <= 20 m |
+| AD000032.jpg | 48.258425 | 37.349964 | <= 50 m | <= 20 m |
+| AD000033.jpg | 48.258653 | 37.347004 | <= 50 m | <= 20 m |
+| AD000034.jpg | 48.257879 | 37.347711 | <= 50 m | <= 20 m |
+| AD000035.jpg | 48.256777 | 37.348444 | <= 50 m | <= 20 m |
+| AD000036.jpg | 48.255756 | 37.348098 | <= 50 m | <= 20 m |
+| AD000037.jpg | 48.255375 | 37.346549 | <= 50 m | <= 20 m |
+| AD000038.jpg | 48.254799 | 37.345603 | <= 50 m | <= 20 m |
+| AD000039.jpg | 48.254557 | 37.344566 | <= 50 m | <= 20 m |
+| AD000040.jpg | 48.254380 | 37.344375 | <= 50 m | <= 20 m |
+| AD000041.jpg | 48.253722 | 37.343093 | <= 50 m | <= 20 m |
+| AD000042.jpg | 48.254205 | 37.340532 | <= 50 m | <= 20 m |
+| AD000043.jpg | 48.252380 | 37.342112 | <= 50 m | <= 20 m |
+| AD000044.jpg | 48.251489 | 37.343079 | <= 50 m | <= 20 m |
+| AD000045.jpg | 48.251085 | 37.346128 | <= 50 m | <= 20 m |
+| AD000046.jpg | 48.250413 | 37.344034 | <= 50 m | <= 20 m |
+| AD000047.jpg | 48.249414 | 37.343296 | <= 50 m | <= 20 m |
+| AD000048.jpg | 48.249114 | 37.346895 | <= 50 m | <= 20 m |
+| AD000049.jpg | 48.250241 | 37.347741 | <= 50 m | <= 20 m |
+| AD000050.jpg | 48.250974 | 37.348379 | <= 50 m | <= 20 m |
+| AD000051.jpg | 48.251528 | 37.349468 | <= 50 m | <= 20 m |
+| AD000052.jpg | 48.251873 | 37.350485 | <= 50 m | <= 20 m |
+| AD000053.jpg | 48.252161 | 37.351491 | <= 50 m | <= 20 m |
+| AD000054.jpg | 48.252685 | 37.352343 | <= 50 m | <= 20 m |
+| AD000055.jpg | 48.253268 | 37.353119 | <= 50 m | <= 20 m |
+| AD000056.jpg | 48.253767 | 37.354246 | <= 50 m | <= 20 m |
+| AD000057.jpg | 48.254329 | 37.354946 | <= 50 m | <= 20 m |
+| AD000058.jpg | 48.254874 | 37.355765 | <= 50 m | <= 20 m |
+| AD000059.jpg | 48.255481 | 37.356501 | <= 50 m | <= 20 m |
+| AD000060.jpg | 48.256246 | 37.357485 | <= 50 m | <= 20 m |
+
+## Known Gaps
+
+- No synchronized IMU, attitude, airspeed, altitude, or timestamp stream is present for these images.
+- No ground-truth trajectory exists beyond per-image center coordinates.
+- The sample cadence is slower than the target 3 fps runtime profile.
+- Final acceptance requires additional public and representative datasets with synchronized camera/IMU/ground truth.

_docs/00_problem/problem.md

@@ -1,2 +1,2 @@
-We have a wing-type UAV with a camera pointing downwards that can take photos 3 times per second with a resolution 6200*4100. Also plane has flight controller with IMU. During the plane flight, we know GPS coordinates initially. During the flight, GPS could be disabled or spoofed. We need to determine the GPS of the centers of the next frame from the camera. And also the coordinates of the center of any object in these photos. We can use an external satellite provider for ground checks on the existing photos. So, before the flight, UAV's operator should upload the satellite photos to the plane's companion PC. 
+We have a wing-type UAV with a fixed downward navigation camera that can take photos 3 times per second. The authoritative navigation-camera spec is defined in `restrictions.md` as the ADTi 20MP 20L V1, APS-C sensor, about 5472 x 3648 px; older higher-resolution references are superseded. Also plane has flight controller with IMU. During the plane flight, we know GPS coordinates initially. During the flight, GPS could be disabled or spoofed. We need to determine the GPS of the centers of the next frame from the camera. And also the coordinates of the center of any object in these photos. We can use an external satellite provider for ground checks on the existing photos. So, before the flight, UAV's operator should upload the satellite photos to the plane's companion PC. 
 The real world examples are in input_data folder, but the distance between each photo is way bigger than it will be from a real plane. On that particular example photos were taken 1 photo per 2-3 seconds. But in real-world scenario frames would appear within the interval no more than 500ms. We also don't have IMU data for the test. For now we have to search for the public data for that in internet. We've tried to record that with Mavic 3 Pro Mini, but failed, cause of the closed system if DJI.

_docs/00_problem/restrictions.md

@@ -1,6 +1,6 @@
 # Restrictions
 
-> **Last revised**: 2026-04-26 (post Mode B Solution Assessment + user-driven addendum on camera spec & zoom level).
+> **Last revised**: 2026-05-01 (post Phase 1 AC/restrictions assessment clarifications).
 
 ## UAV & Flight
 
@@ -12,7 +12,7 @@
   - **Transit corridor**: ~**50 km × 1 km = 50 km²** strip in/out of the sector.
   - **Total operational area: up to ~400 km²** of pre-cached satellite imagery per mission. Cache is **persistent across flights** (not redownloaded each mission). Storage budget **~10 GB** for the satellite tile cache; see AC-NEW-3 for flight-data-recorder budget.
 - Altitude: pre-defined, **≤1 km AGL**. Terrain is assumed flat (operational area is rolling steppe / agricultural land); height differences are negligible.
-- Weather: predominantly sunny daytime operations.
+- Weather: predominantly sunny daytime operations. Validation must still cover the seasonal/visibility classes that affect visual matching in the operational area: summer crop/field patterns, autumn/winter bare fields, cloud/smoke/haze, snow if missions can occur in winter, and low-texture agricultural repetition.
 - Sharp turns occur but are the exception, not the rule. Two consecutive photos may share <5% overlap during a turn (see AC-3.2).
 - **No photo-count cap.** The previously stated "up to 3000 photos per flight" was a legacy operator number from a Mavic-class workflow; it is dropped because (a) it is inconsistent with 8 h × 3 fps, and (b) the system does **not store raw photos at all** (see AC-8.5). Storage is bounded by the tile-cache + FDR caps (~10 GB persistent + 64 GB / flight, AC-NEW-3).
 
@@ -32,7 +32,7 @@
 - **Mid-flight tile generation (AC-8.4)**: during the mission the companion computer generates fresh tiles from the navigation camera, orthorectified into the basemap projection, deduplicated against the existing cache, and stored locally. On landing, those new tiles are uploaded back to the Suite Satellite Service for ingestion, so the next mission's cache is refreshed by the previous flight.
 - **No raw photo storage** (AC-8.5): the tile is the unit of persistence. Raw nav-camera and AI-camera frames are not retained (except a low-rate failure-thumbnail log for forensics).
 - **Resolution at the cache interface**: 0.5 m/pixel minimum, 0.3 m/pixel ideal (AC-8.1). The architecture is provider-agnostic at the cache boundary; whatever the Suite Satellite Service supplies must meet that bar.
-- **Storage tile resolution convention**: cache imagery is specified by source pixel size, not by assuming a universal zoom-to-meter mapping. The cache interface accepts **0.5 m/px minimum, 0.3 m/px ideal** imagery, and every tile manifest records CRS, tile matrix convention, tile dimension, latitude-adjusted meters-per-pixel, capture date, source, and compression. If an XYZ/WebMercator tile pyramid is used, its zoom level is documented as a provider convention rather than treated as proof of physical resolution. The matcher (Component 3) needs ≤~4× scale ratio between the UAV frame (~12 cm/px GSD at 1 km AGL with the 20 MP APS-C camera) and the reference; 0.3–0.5 m/px reference imagery gives a ~2.5–4.2× ratio. Storage budget across the 400 km² operational area remains capped at **10 GB** for the persistent cache and must be validated against the final provider format/compression. **VPR retrieval unit is decoupled from the storage tile** (see AC-8.6 below): VPR chunks are derived from the tile cache at ground-footprint scale (~600–800 m chunks with 40–50 % overlap), independent of the storage tile convention.
+- **Storage tile resolution convention**: cache imagery is specified by source pixel size, not by assuming a universal zoom-to-meter mapping. The cache interface accepts **0.5 m/px minimum, 0.3 m/px ideal** imagery, and every tile manifest records CRS, tile matrix convention, tile dimension, latitude-adjusted meters-per-pixel, capture date, source, and compression. If an XYZ/WebMercator tile pyramid is used, its zoom level is documented as a provider convention rather than treated as proof of physical resolution. The matcher (Component 3) needs <=~4x scale ratio between the UAV frame (~12 cm/px GSD at 1 km AGL with the 20 MP APS-C camera) and the reference; 0.3-0.5 m/px reference imagery gives a ~2.5-4.2x ratio. Storage budget across the 400 km² operational area remains capped at **10 GB** for the persistent cache and must be validated against the final provider format/compression. The 10 GB budget includes cache imagery, manifests, overviews, and any precomputed global/local descriptors unless the solution draft explicitly splits a separate descriptor/index budget. **VPR retrieval unit is decoupled from the storage tile** (see AC-8.6 below): VPR chunks are derived from the tile cache at ground-footprint scale (~600-800 m chunks with 40-50 % overlap), independent of the storage tile convention.
 - **Freshness gates** (AC-8.2 / AC-NEW-6) are enforced at runtime: tiles older than 6 months (active-conflict sectors) or 12 months (stable rear sectors) are rejected or down-confidence-weighted. Tiles generated mid-flight are timestamped with the current flight date and treated as fresh.
 - **Free public imagery (Sentinel-2 etc.)** is not on the runtime path. If the Suite Satellite Service ever returns Sentinel-class tiles, the cache rejects them as below the 0.5 m/px floor.
 
@@ -46,6 +46,7 @@
 ## Sensors & Integration
 
 - High-rate **IMU** data is available from the flight controller via MAVLink.
+- The provided sample imagery does **not** include synchronized IMU or ground-truth pose. Prototype validation may use public datasets or synthetic IMU injection, but final acceptance claims require synchronized navigation-camera frames, FC IMU/attitude/airspeed/altitude, emitted MAVLink messages, and ground-truth trajectory from a representative flight or replay rig.
 - The system communicates with the flight controller via MAVLink. Telemetry plumbing uses **MAVSDK**; the `GPS_INPUT` injection path is implemented via **pymavlink**, since MAVSDK does not expose a native `GPS_INPUT` API.
 - **Autopilot target: ArduPilot only** (with `GPS1_TYPE=14` for MAVLink GPS injection). PX4 is out of scope for the build; if it ever returns to scope it will use `VISION_POSITION_ESTIMATE`, not `GPS_INPUT`. (See `_docs/00_research/00_ac_assessment.md` Q-1.)
 - The system outputs WGS84 GPS coordinates to the flight controller as a replacement for the real GPS module (MAVLink GPS_INPUT, AC-4.3).