Geospatial change detection built around sensor and format agnosticism. Operational today on Sentinel-1. Designed to accept the imagery you actually have, not the imagery you wish you had.
AURORA is a geospatial change detection system built on a single architectural principle. The system should accept whatever imagery is available, process it through a common analytic core, and produce discrete change polygons with confidence-weighted attribution. Every ingestion gap is treated as a defect against that principle, not as a constraint to be worked around.
Today the production pipeline runs on Sentinel-1 synthetic aperture radar data. The pipeline is end-to-end operational. It pulls scenes from the Copernicus Data Space Ecosystem, preprocesses them through ESA SNAP, performs adaptive change detection between revisit pairs, and exports analyst-ready polygons with full provenance metadata. The architecture is designed to extend to additional SAR sensors, to optical sources such as Sentinel-2 and Landsat, and to any future product format an operational customer needs to ingest.
The design premise is straightforward. Persistent monitoring of areas of operational interest cannot depend on optical sensors that fail under cloud cover, smoke, or darkness. SAR sees through all of it. Optical sees the visible spectrum SAR cannot. A serious change detection system handles both. AURORA is built to make that capability available at scale, without the cost structure of commercial GEOINT platforms and without binding to any single sensor or vendor.
AURORA is built around an explicit boundary between ingestion and analysis. Each supported sensor exposes its data through a common product interface. A processor stage converts that product into a unified analysis-ready data model carrying named bands with explicit units, a valid-data mask, a single CRS, and a provenance block. The change detection and export stages downstream consume that analysis-ready model. They do not know or care which sensor produced it.
New sensors are integrated by writing a new product and processor pair, not by rewriting the pipeline. The boundary is testable and extensible by design. Sentinel-1 has been the workhorse for a decade. ICEYE, Capella, Umbra, and other commercial constellations are now producing operational imagery. Optical missions including Sentinel-2 and Landsat sit on the same side of the boundary. Additional SAR sensors are planned for cross-band validation.
For procurement officers, this matters. Sensor-specific GEOINT platforms create vendor lock-in. AURORA does not. Every analysis-ready output carries enough metadata to be cited or correctly not cited in proposal documents. Provenance is enforced in code, not in code review.
SAR change detection lives or dies on the threshold. Set it too low and the system reports false change everywhere. Set it too high and it misses what matters. Fixed thresholds also break the moment you move between regions, because radar backscatter statistics shift dramatically between geographies. The Mekong Delta does not behave like the Atacama. Boreal forest does not behave like an urban industrial corridor.
AURORA does not use fixed thresholds. The system applies Otsu's method, a well-established statistical algorithm that derives the optimal change threshold directly from the backscatter difference distribution of each AOI. Instead of asking an analyst to guess, the system computes the threshold that separates the two underlying pixel populations with minimum intra-class variance. The threshold is recomputed for each new AOI from the data the system actually sees.
The adaptive threshold is paired with two practical refinements that turn academic Otsu into operational Otsu. A configurable noise floor prevents the algorithm from chasing speckle in low-signal scenes. A component-aware edge buffer distinguishes inland change polygons from scene-edge artifacts that arise from acquisition geometry rather than ground change. Together these handle the practical failure modes that show up in real Sentinel-1 acquisitions over real geography.
The result is region-portable change detection. The same pipeline that produced clean polygons over the Mekong Delta produces clean polygons over arid terrain, urbanized environments, or boreal forest without manual retuning. The framework stays constant. Only the threshold value changes, computed fresh from each AOI.
Combined with the ingestion boundary, this gives AURORA two independent axes of portability. Sensor and format agnostic at the input. Region-adaptive at the analysis stage. A new sensor over new geography requires neither a new pipeline nor a new threshold heuristic. The system adapts.
AURORA runs as a five-stage pipeline. Each stage has a single responsibility and a typed contract with the stage downstream of it. The pipeline is not a notebook. It is an end-to-end service that can be invoked from the command line, scheduled, or driven by an external system through its REST interface.
A SQLite-backed scheduler polls the Copernicus Data Space Ecosystem for new admissible scenes over each configured AOI, tracks revisit pairs as they become available, and triggers full pipeline runs without analyst intervention. A multi-channel notifier reports run status through email, Slack, and structured logs. An analyst-in-the-loop queue holds detections for review and downstream tasking. A Flask REST API exposes detections, manifests, and queue state to integrating systems. QGIS QML sidecar files ship alongside every GeoJSON output so an analyst can drag the file into QGIS and see the right symbology immediately.
The point of all this is that AURORA is not a demo. It is a small operational system, run by one person today, designed to be run by a team in a tasked environment tomorrow.
Production validation runs on a 30 km land-only AOI in the western Mekong Delta of Vietnam, an inland zone of rice paddies, canals, and aquaculture where the underlying backscatter behavior is dense, dynamic, and difficult. The system processes paired Sentinel-1 GRD acquisitions on the same orbital geometry, computes backscatter difference statistics, applies the adaptive threshold described in §03, and produces tens of thousands of change polygons under operational data conditions.
The AOI was selected because it presents the harder cases for SAR change detection. Heavy seasonal flooding. Dense agricultural activity. Continuous land use change. The kind of complex backscatter signatures that defeat naive thresholding approaches. A system that produces clean results here is a system that will produce useful results in operationally relevant geographies.
Validation extends to additional AOIs that exercise different failure modes. A Hurricane Helene flood and landslide AOI over the Western North Carolina mountains tests the system on rapid-onset damage assessment against ground truth. AOIs over the Spratly Islands and Luzon exercise maritime and tropical-urban regimes. Each AOI is windowed at read time, so a 30 km box loads roughly 28 million pixels rather than 580 million for a full scene, allowing the pipeline to run on workstation-class hardware without sacrificing AOI density.
Validation refinement against the full SNAP processing chain is ongoing. Final quantitative metrics will be published in support of the active SBIR pursuit.
AURORA development is staged to match how a real GEOINT system matures from research code into operational capability. Each phase exits with concrete, testable contracts. Each phase produces something demonstrable before the next is begun.
End-to-end pipeline running on Sentinel-1 GRD. Adaptive Otsu thresholding with component-aware edge buffer. SQLite-backed scheduler. Multi-channel notifier. Flask REST API. AITL queue. GeoJSON output with full provenance metadata and QGIS QML sidecar styling. Operational today.
Explicit product and processor boundary between data ingestion and analysis. An analysis-ready data model with named bands, explicit units, valid-mask, single CRS, and a provenance block. Sentinel-1 SAFE and COG_SAFE as first-class cases. The architectural property the entire system is named around stops being aspirational and becomes a property the code actually has.
Optical missions including Sentinel-2 and Landsat ingested through the same boundary. Commercial SAR constellations integrated as product types. SAR-domain pretrained model weights replace the generic warm-start in the feature extraction stage. Pure-Python radiometric terrain correction closes gaps in the open-source SAR processing ecosystem.
SAR change polygons cross-referenced with optical, thermal, and OSINT signals where available. The output is no longer "something changed here." The output is "something changed here, in this context, with these correlated signals."
AURORA is built in Python on a foundation of established geospatial and scientific libraries. The processing chain uses ESA SNAP via pyroSAR for SAR preprocessing, segmentation_models_pytorch for U-Net feature extraction, scikit-learn for Random Forest attribution, and the standard scientific Python geospatial stack for everything else. xarray and rioxarray provide the labeled n-dimensional array model the boundary refactor consumes.
The toolchain is deliberately not exotic. Operational GEOINT systems live or die on reproducibility and maintainability. AURORA uses the libraries that the broader geospatial community already trusts. No proprietary dependencies. No vendor-licensed tooling. No black boxes.
Credentials are managed through the operating system keystore, not plaintext environment variables. The resolution chain is documented and inspectable. Provenance metadata on every output enforces citability gating in code, so non-citable runs cannot accidentally reach proposal documents. Conda environment lockfiles support reproducible deployment across machines. Apache 2.0 licensed. SBIR Data Rights apply to government-funded deliverables under DFARS 252.227-7018.
AURORA is in active development. The system is not currently available for license, evaluation, or commercial use.
Inquiries from primes, federal stakeholders, and serious technical collaborators are welcome. Inquiries from SaaS aggregators, dashboard integrators, or organizations seeking to white-label the capability will not be answered.