# Parent-suite design tasks for `satellite-provider`

**Date created**: 2026-05-09 (Plan Phase 2a.0 outcome — `gps-denied-onboard` workspace)
**Workspace this leftover lives in**: `gps-denied-onboard`
**Workspace work needs to happen in**: `/Users/obezdienie001/dev/azaion/suite/satellite-provider/`
**Type**: cross-workspace dependency surfaced from this Plan cycle, NOT a tracker write blocker

---

## Why this is a leftover

During Plan Phase 2a.0 (Glossary + Architecture Vision) for `gps-denied-onboard`, two assumptions in `_docs/01_solution/solution.md` were validated against the actual `satellite-provider` codebase and found broken:

1. **AC-8.4 — mid-flight tile upload to the Service**: `solution.md` and `acceptance_criteria.md` both assume the onboard system uploads orthorectified mid-flight tiles to `satellite-provider` after landing. **`satellite-provider` has no inbound ingest endpoint.** It is read-only from the onboard side (downloads tiles from Google Maps + serves them).

2. **AC-NEW-7 — multi-flight ingest-side voting / trust layer**: `solution.md` assumes the Service operates "a multi-flight ingest-side voting layer that gates onboard-tile promotion to 'trusted basemap' until multiple independent flights agree on geo-alignment". **No such layer exists in `satellite-provider`.**

Both gaps are parent-suite design / build tasks. They are tracked in this onboard workspace as **D-PROJ-2** and surfaced to the parent suite via this leftover file.

`gps-denied-onboard` will proceed in this Plan cycle treating both as planned external capabilities; the architecture document references them as such.

---

## Why these are NOT replayed automatically

Per `.cursor/rules/tracker.mdc` § Leftovers Mechanism, this leftover does NOT block onboard progress and does NOT auto-replay because:

- Replay requires writes against a different workspace's `_docs/` (and tracker entries against `satellite-provider`'s tracker scope).
- The next `/autodev` invocation in the **`satellite-provider`** workspace should pick this up at its own Bootstrap step. Cross-workspace leftover replay is intentionally human-gated.

If you (the human) explicitly want me to write these design tasks into `satellite-provider/_docs/` from this conversation, say so — I have the user's permission from the 2026-05-09 turn ("If it doesn't provide sufficient information, then analyze the repository, think about the best solution to tile selection process, and document it there"). I held back to respect the workspace boundary discipline this autodev session was operating under.

---

## Design task #1 — Inbound tile ingest endpoint

**Trigger**: AC-8.4 (mid-flight tile generation, post-landing upload) per `gps-denied-onboard/_docs/00_problem/acceptance_criteria.md`.

**Contract sketch (from the onboard side)**:

```
POST /api/satellite/tiles/ingest
Content-Type: multipart/form-data

Fields per tile (one or more per request, batched):
  - tile_blob:              JPEG body, byte-identical to satellite-provider's existing tile format
  - zoomLevel:              int — same semantics as satellite-provider's existing tiles table
  - latitude:               double — center latitude (composite key element)
  - longitude:              double — center longitude
  - tile_size_meters:       double
  - tile_size_pixels:       int
  - capture_timestamp:      ISO 8601 — when the onboard companion generated the tile
  - flight_id:              UUID — which flight this tile came from
  - companion_id:           string — which deployed unit produced it
  - quality_metadata:       JSON blob (per AC-8.4 quality metadata for the Service's voting pipeline):
      - estimator_label:    "satellite_anchored" | "visual_propagated" | "dead_reckoned"
      - covariance_2x2:     [[σ_xx, σ_xy], [σ_yx, σ_yy]]   — horizontal sub-matrix at tile-emit time
      - last_anchor_age_ms: int  — AC-1.3 binning input
      - mre_px:             double — reprojection error at the contributing match
      - imu_bias_norm:      double — VIO health proxy
  - signature:              optional — onboard companion's per-flight key signature over the payload (for source authentication; Plan Phase 2a.0 carryforward)

Response: 202 Accepted with batch UUID + per-tile ingest status (queued / rejected / duplicate / superseded).
```

**On-disk persistence**: tiles stored in the same `./tiles/{zoomLevel}/{x}/{y}.jpg` layout as existing Google-Maps-sourced tiles. Service's existing `tiles` table extended with: `flight_id`, `companion_id`, `capture_timestamp`, `source` (`googlemaps | onboard_ingest`), `quality_metadata` (jsonb), `voting_status` (`pending | trusted | rejected`).

**Design questions for `satellite-provider`'s Plan phase**:
- How to authenticate the onboard companion (mTLS? per-flight ephemeral keys? signed payload?). Companion is a remote untrusted endpoint by threat model.
- How to rate-limit ingest (a compromised companion could DOS the basemap).
- How to expose an admin/operator UI to inspect ingested-but-not-yet-trusted tiles.

---

## Design task #2 — Multi-flight trust / voting layer

**Trigger**: AC-NEW-7 (cache-poisoning safety budget; cross-flight error compounding) per `gps-denied-onboard/_docs/00_problem/acceptance_criteria.md`.

**Goal (from the onboard side)**: when `satellite-provider` serves tiles to a future flight's pre-flight cache build, tiles ingested from prior flights must NOT be served as "trusted basemap" until multiple independent flights agree on geo-alignment for the same area.

**Algorithmic intent (not prescriptive — Service team owns the design)**:
- Tiles enter with `voting_status = pending`.
- A tile is promoted to `voting_status = trusted` when ≥N independent companions (different `companion_id`) have ingested geometrically-consistent tiles covering the same lat/lon/zoom cell, weighted by the quality metadata above.
- The pre-flight cache builder (operator-side tool) consumes only `trusted` tiles by default; can be overridden to accept `pending` tiles for stale-area refresh, with explicit operator confirmation.
- Stale tiles (per AC-8.2 freshness) are demoted on age regardless of trust status.

**Design questions for `satellite-provider`'s Plan phase**:
- N (votes-required threshold) — driven by AC-NEW-7's safety budget back-solved against measured per-flight pose error CDF.
- How to detect adversarial agreement (multiple compromised companions colluding) — out-of-band integrity checks against Google Maps ground truth?
- What "geometric consistency" means quantitatively (pixel-level RANSAC on overlapping tiles? GTSAM factor-graph over multi-flight poses?).
- What happens when `trusted` tiles disagree with newly ingested `pending` tiles in active-conflict sectors (legitimate scene change vs. cache poisoning).

---

## Hand-off

Next time `/autodev` runs in the **`satellite-provider`** workspace:

1. Bootstrap should detect this leftover via cross-workspace search (`/Users/obezdienie001/dev/azaion/suite/gps-denied-onboard/_docs/_process_leftovers/`) — NOTE: cross-workspace leftover detection is not yet implemented in autodev; human operator must surface this manually for now.
2. The Plan skill should add Design Task #1 + Design Task #2 to the satellite-provider Plan cycle as new components / endpoints.
3. After both are implemented, this leftover can be deleted from `gps-denied-onboard`.

Until then, `gps-denied-onboard` Plan / Decompose / Implement phases will proceed with the architecture vision treating both capabilities as **planned external dependencies** (not yet available, but contract is sketched above).