What this is built with,
and where to check.

Sixteen sources, sixteen different shapes

This is most of the work and the least visible part of it. Black Marble arrives as HDF5 on an authenticated NASA endpoint; ERA5 arrives through a request queue that can take hours; Sentinel-1 arrives as compressed GRD scenes that have to be found by STAC query, orbit-corrected and reduced to per-cell time series before a model sees anything. The counts below are cases whose pipeline code reads the source, not cases that cite it.

The geospatial and data layer

Used by two or more of the 10 cases. Each pipeline is a separate uv project with its own pinned dependencies, so one case cannot break another and any single case can be re-run on its own.

Specialist, one case each

What is actually fitted

Gradient boosting and regularised linear models on raster-derived features. Listed with the file that fits them, because the interesting part of a model is rarely the estimator — it is the loss, the calibration, the weights and the metric.

Eleven static apps, no server rendering

Each case is its own Astro app with its own base path, built to static files. There is no backend behind any dashboard: the numbers are computed in the pipeline and shipped as JSON, or recomputed in the browser from a small table. Where a figure has tens of thousands of marks, the dense layer goes on a canvas so the axis text stays selectable text.

No high-level charting library — no Plotly, no Chart.js, no Vega. Charts are composed from d3's scales, axes and shape generators, which means the projection, the domain and the hit-testing are decisions in the code rather than options in a config object. Where a chart has tens of thousands of marks, the dense layer goes on a canvas and the axes, legend and labels stay in SVG so the text is still text.

Serving this is small. Rebuilding it is not.

The footprint below is what it costs to serve these pages, and it would be easy to read it as what it costs to reproduce them. It is not, by more than an order of magnitude. Two of the ten cases train a convolutional network on a GPU, and several ingest stages peak in gigabytes while reprojecting satellite granules. Anyone who cloned this and started on the serving box would meet the memory wall rather than a result — which is how this project lost three pipeline runs to out-of-memory kills, each against a hand-typed ceiling rather than a measured one.

• To serve — two cores and 1.9 GB, as described below. Nothing on the public site needs more.
• To train fire-haze’s network — g4dn.xlarge: 4 vCPU, 15.4 GB, Tesla T4 with 14.6 GB VRAM. folds at batch 16 over a 88,179-parameter model, last run 2026-09-05. Training parameters recorded in dl_results.json; the hardware stamped by the run itself.
• To train rice-security’s network — g4dn.xlarge: 4 vCPU, 16 GB, NVIDIA T4 with 16 GB VRAM. 6 folds at batch 4,096 over a 50,838-parameter model, last run 2026-09-02. Training parameters recorded in dl_results.json; the hardware declared by the operator, not yet stamped by a run.
• To run the ingest stages — several gigabytes each, and more disk than anything else here: the fetched granules, reanalysis fields and API responses that .gitignore excludes.

What this page will not tell you yet, and why. There is no honest number here for peak memory. The gauge that should have recorded it read ru_maxrss as bytes on Linux, where it is kilobytes, so the run on the machine that mattered reported 4.22 GB — a memory gauge failing a thousandfold low on the GPU box, the one place it was needed. The arithmetic is fixed and ops/pipeline now derives every cap from a recorded peak rather than a guess, but the stored record still carries that zero and the ledger behind it holds one row. So the figure is absent rather than estimated, and it appears here once a run has measured it. A remembered number in this slot would contradict the page that promises none of these are typed. What can be said without measuring it is the ceiling: the training host carries 15.4 GB, so the peak was under that or the run would have died — which is a bound, not a measurement.

Eleven apps on two cores and 1.9 GB

Eleven Astro dev servers cost about 4.5 GB between them, which would have needed a four-times-larger machine to serve pages that are already fully static. So one nginx serves the built output of all of them from a single origin, each case under its own slug.

• ops/serve-static derives port, base path and directory for every app from the repository, then generates the entire nginx configuration — server blocks, redirects for retired paths, aliases for paths a reader would guess, cache headers for hashed assets. The config is not hand-edited, so it cannot disagree with the apps it serves.
• HTTPS via Let's Encrypt on a multi-name certificate, renewed automatically.
• Deploys are an rsync and a build, one app at a time, because two concurrent Astro builds will exhaust the memory on this box.
• ops/review runs house rules against the rendered output rather than the source, so a check cannot pass on a template that fails in the page.
• ops/glossary keeps one set of plain-language definitions in step across ten separate Astro apps, and each article scans its own source at build time to render only the terms it uses — no per-article list to go stale.