Navigation Test Evidence

Navigation tests must connect a scientific claim to an independent reference, an explicit budget, or a refusal invariant. A parser round trip cannot prove an orbit model, and one solved position cannot prove integrity, convergence, or uncertainty.

Select Evidence By Claim

flowchart TD
    change["navigation change"]
    format{"decoder or format?"}
    model{"orbit, time, or<br/>correction model?"}
    estimator{"SPP, PPP, RTK,<br/>or integrity?"}
    state{"state continuity or<br/>checkpoint?"}
    parserProof["valid, malformed,<br/>and boundary inputs"]
    referenceProof["independent vectors<br/>and numerical budget"]
    estimatorProof["accepted, degraded,<br/>refused, and fault cases"]
    continuityProof["uninterrupted versus<br/>restored or long run"]

    change --> format
    format -- yes --> parserProof
    format -- no --> model
    model -- yes --> referenceProof
    model -- no --> estimator
    estimator -- yes --> estimatorProof
    estimator -- no --> state --> continuityProof

Use the narrowest target that proves the moved claim, then add adjacent evidence only when the contract crosses a real boundary.

Current Evidence Families

Claim family	Representative evidence	Limits
broadcast decoders	BeiDou decode, GLONASS decode, and the LNAV golden fixture	representative messages and fixtures, not every valid or malformed frame
RINEX and observation channels	RINEX channel coverage and constellation-specific observation tests	checked-in files and supported mappings only
broadcast orbit and clocks	broadcast orbit reference, accuracy budget, and clock reference	selected satellites, epochs, and declared tolerances
precise products	SP3 reference accuracy, CLK reference accuracy, and precise-product queries	reduced fixtures and feature-dependent behavior
time systems	constellation time conversions and UTC leap seconds	selected boundaries, not an exhaustive historical time corpus
corrections and combinations	measured ionosphere, ionosphere-free code, and bias corrections	declared constellations, frequencies, and fixture assumptions
positioning and refusal	position solution, protection levels, and position refusal	scenario-specific geometry and error models
public-data SPP and PPP	RTKLIB position comparison, PPP convergence, and station truth	one public station family and checked-in reductions
RTK and ambiguity	ambiguity fixing, baseline accuracy, and double differences	modeled baselines and declared bias evidence
faults and integrity	fault injection, RAIM exclusion, and underdetermined refusal	injected fault classes, not all real receiver failure modes
continuity	checkpoint behavior and long-run EKF stability	EKF-focused integration evidence; PPP checkpoint coverage is source-local

The package test guide gives the broader family map. It does not turn every checked-in file into independent truth.

Build A Credible Reference Chain

flowchart LR
    provenance["documented source"]
    reduction["reviewable reduction"]
    parser["independent fixture reader"]
    expected["expected value or budget"]
    production["production result"]
    residual["residual and refusal evidence"]

    provenance --> reduction --> parser --> expected
    production --> residual
    expected --> residual

A reference-backed test should expose:

• source and licensing or redistribution basis
• exact satellite, epoch, signal, frame, and time system
• transformations applied to reduce the source
• units and tolerance derivation
• residuals or diagnostics on failure
• why the expected value is independent of the production path

If a helper calls the same model under test, it is setup reuse, not an oracle.

Treat Generated Fixtures Carefully

The public PPP convergence target can rewrite its checked-in report when a specific environment variable is set. Regeneration is a review action, not a normal verification mode. When behavior intentionally changes:

1. run the calculation without regeneration and inspect the drift
2. explain the scientific reason and budget impact
3. regenerate only the owned fixture
4. review the full fixture diff
5. rerun without the regeneration variable

Never refresh expected output merely to make a changed implementation pass.

Cover Claims And Refusals

Estimator evidence should include:

• a solvable case with an explicit accuracy or residual budget
• insufficient geometry or missing prerequisites
• malformed, stale, or inconsistent products
• outlier and fault behavior
• degraded versus refused outcomes
• uncertainty or protection behavior when claimed
• state reset, gap, or checkpoint continuity when relevant

Assert structured status and diagnostic evidence, not only Some versus None.

Use Focused Targets

Representative invocations from the repository root:

cargo test -p bijux-gnss-nav --test integration_broadcast_orbit_reference
cargo test -p bijux-gnss-nav --test integration_position_refusal
cargo test -p bijux-gnss-nav --test integration_checkpoint

For precise-product changes, compare the default feature set with --no-default-features. A default-feature pass alone does not prove the fallback or refusal contract.

Do Not Overstate A Green Target

• A format test does not prove estimator accuracy.
• A public-data comparison does not generalize beyond its station, epochs, and reduction.
• The long-run target covers EKF stability, not every PPP or RTK state.
• Checkpoint tests prove scientific restoration, not durable file persistence.
• Guardrails prove package policy, not numerical validity.
• A precise-product fixture does not prove all interpolation edges or gaps.

Record the target, fixture, budget, feature set, and residual coverage in the verification note. Navigation evidence is credible when a reader can trace the claim from source data or invariant to the exact assertion without trusting the production implementation as its own reference.