Skip to content

Validation evidence

This section records how SpectralBridge functions behave across explicit input variations. Each row comes from a machine-readable campaign result rather than a hand-written success claim.

How to use this section

Validation is presented in three connected layers:

  1. Module contract pages explain the inputs varied, every Boolean check, every recorded diagnostic, and the limits of the evidence.
  2. Stage QA test guide explains the checks emitted by a completed pipeline in acquisition-to-table order.
  3. Real flightline walkthrough interprets one 2.4 GB R10C run and links its complete HTML and JSON reports.

A green offline contract does not imply scientific validation. A real stage WARN does not imply a crash. Read the stated evidence boundary on each page before comparing statuses.

Current evidence

Module Variations Passed Failed Skipped Detailed test guide Real stage QA
NEON HDF5 download 5 5 0 0 Inputs, checks, and results Matching stage
HDF5 to raw ENVI 5 5 0 0 Inputs, checks, and results Matching stage
Topographic correction 5 5 0 0 Inputs, checks, and results Matching stage
BRDF correction 5 5 0 0 Inputs, checks, and results Matching stage
Sensor convolution 5 5 0 0 Inputs, checks, and results Matching stage
Parquet extraction and CSV conversion 5 5 0 0 Inputs, checks, and results Matching stage
Save and restart behavior 5 5 0 0 Inputs, checks, and results Matching stage
QA plots and diagnostics 5 5 0 0 Inputs, checks, and results Matching stage

Two validation tiers

  1. Offline contract campaign: small deterministic inputs, safe for local or CI execution. It checks dimensions, numerical invariants, schemas, restart behavior, and diagnostic generation.
  2. Live NEON campaign: opt-in real data selected from a pinned inventory. It measures download reliability, full-stage behavior, correction support, performance, and QA usefulness across sites and acquisition conditions.

These tiers must remain separate. Repeating synthetic inputs 100 times can expose numerical and state bugs, but it cannot establish network reliability or scientific validity across 100 real flightlines.

Example figures from the real test run

The figures below are generated artifacts from R10C · D10 · L002 · 2021-09-15. Their axes and map scales follow plot-contract version 1.1 so later runs can be compared directly.

R10C input reflectance overview
The real exported ENVI is reviewed spatially and spectrally after scale and NoData metadata are applied.
R10C before and after correction overview
Matched maps and spectra show the combined persisted BRDF/topographic result; the pipeline does not store a topo-only intermediate.
R10C Landsat ETM+ brightness audit
Configured and fitted brightness adjustments overlap; this verifies application, not scientific optimality of the coefficients.
R10C Parquet extraction and merge overview
The real run compares rows, schema width, and file size for 18 readable extracted and merged tables.

Recorded campaigns

Campaign Mode Revision Dirty tree Generated (UTC) Total Passed Failed
offline-contract-5-per-module offline bebf707 true 2026-08-14T18:05:29.385201+00:00 40 40 0

Interpretation rules

  • A pass means every explicit software-contract check for that variation passed.
  • A failure remains visible and includes its diagnostics or exception.
  • A skip must state why evidence was not collected.
  • Synthetic checks must not be described as external scientific validation.
  • QA thresholds should be changed only after a representative real-data campaign and scientific review.

The underlying JSON records live in validation/results/ and are the source of truth for these pages.

Last updated: 2026-08-14