# FT-P-03 + FT-P-14 — Estimate schema + WGS84 output coordinate system

**Task**: AZ-411_ft_p_03_14_schema_wgs84
**Name**: Estimate output schema + source-label semantics + WGS84 coordinate validation (AC-1.4, AC-4.3, AC-6.3)
**Description**: Combined coverage for FT-P-03 (output schema + source-label) and FT-P-14 (WGS84 coordinate validation). Both are small format/contract checks on the same outbound message.
**Complexity**: 2 points
**Dependencies**: AZ-406, AZ-407
**Component**: Blackbox Tests / Positive (epic AZ-262)
**Tracker**: AZ-411
**Epic**: AZ-262 (E-BBT)

## Problem

Two thin contract checks on the SUT's outbound message — schema completeness (AC-1.4 / AC-4.3) and WGS84 coordinate-range validity (AC-6.3) — must be exercised, but each scenario alone is too small for an independent task. They share the fixture and only differ in their assertion set.

## Outcome

- pytest scenario at `e2e/tests/positive/test_ft_p_03_14_schema_wgs84.py` with two test methods: `test_schema_and_source_label` (FT-P-03) and `test_wgs84_coordinate_range` (FT-P-14).
- Both methods push a single image (default `AD000001.jpg`) and read the resulting outbound message + the out-of-band source-label channel (`STATUSTEXT` or `NAMED_VALUE_FLOAT` per AC-4.3).
- AC-3 implements the `set_contains` rule on the source label; AC-2 implements the `schema_match` rule on field presence + types.

## Scope

### Included
- Schema match: `lat:float`, `lon:float`, `cov_semi_major_m:float`, `last_satellite_anchor_age_ms:int` present and well-typed in the outbound message; per AC-4.3 these fields ride either inside the `GPS_INPUT` / `MSP2_SENSOR_GPS` payload OR on a paired side-channel.
- Source-label set containment: the out-of-band label channel emits one of `{satellite_anchored, visual_propagated, dead_reckoned}`.
- WGS84 range check: `lat ∈ [-90, 90]`, `lon ∈ [-180, 180]`, scaled per protocol convention (AP `GPS_INPUT.lat/lon` are 1e-7 scaled int32, iNav `MSP2_SENSOR_GPS.lat/lon` likewise — the test parses correctly and checks the decoded float is in WGS84 bounds).

### Excluded
- Per-image accuracy — owned by FT-P-01 (AZ-409).
- Honest-covariance-vs-95%-confidence cross-check — owned by FT-N-04 (AZ-426) and AC-NEW-4 in NFT-RES-03.
- Signing handshake — owned by FT-P-09-AP (AZ-416).

## Acceptance Criteria

**AC-1: schema completeness**
Given any single outbound message with paired source-label channel
Then all of `lat:float`, `lon:float`, `cov_semi_major_m:float`, `last_satellite_anchor_age_ms:int` are present and parse to the documented types.

**AC-2: source-label set containment**
Given the source-label channel emission
Then the label is exactly one of `{satellite_anchored, visual_propagated, dead_reckoned}`.

**AC-3: WGS84 coordinate range**
Given the decoded lat/lon
Then `lat ∈ [-90, 90]` AND `lon ∈ [-180, 180]` AND the scaling factor matches the protocol convention (AP: 1e-7 scaled int32; iNav: per `MSP2_SENSOR_GPS` schema in `docs/SITL/SITL.md`).

**AC-4: parameterization**
Given the conftest's `(fc_adapter, vio_strategy)` parameterization
Then both test methods run for each parameterization.

## System Under Test Boundary

End-to-end through public boundaries; SITL-observed.

- **Allowed**: SITL receipt, mavproxy listener for STATUSTEXT/NAMED_VALUE_FLOAT.
- **Forbidden**: parsing SUT internal logs for the schema fields; the schema must be visible at the outbound boundary (or it's a real defect).

## Constraints

- The source-label side-channel mechanism is documented per AC-4.3 ("MAVLink `STATUSTEXT` or `NAMED_VALUE_FLOAT` per AC-4.3"). Both encodings are accepted by this test as long as the label arrives within ≤500 ms of the paired `GPS_INPUT` / `MSP2_SENSOR_GPS`.

## Document Dependencies

- `_docs/02_document/tests/blackbox-tests.md` § FT-P-03, § FT-P-14
- `_docs/02_document/tests/test-data.md` § Position accuracy (FT-P-03 row)
