SPONGE

Inspiration

Flood-resilience planning is full of disconnected inputs: terrain, building footprints, rainfall evidence, drainage assumptions, candidate projects, and budgets. Communities need an understandable way to explore those relationships without pretending that incomplete public data is an engineering survey. SPONGE was built to make early stormwater tradeoffs visible, reproducible, and honest.

The prepared Philadelphia example reflects a real planning problem: dense urban neighbourhoods need decentralized green-stormwater measures alongside conventional drainage upgrades. SPONGE does not replace that engineering workflow; it makes early alternatives easier to question and compare.

What it does

SPONGE loads a sourced neighbourhood terrain bundle and renders simplified 3D buildings, streets, vegetation, and mapped water. A user can configure rainfall, external inflow, prescribed coastal levels, or supported combinations, then run a WebGL2 shallow-water simulation in the browser.

Users can add rain gardens, bioswales, permeable pavement, and detention basins with finite storage, infiltration, clogging, overflow, and optional release assumptions. A bounded physics search evaluates feasible portfolios under a budget against the same baseline storm. The synchronized comparison preserves remaining flooding and local worsening rather than hiding them.

The evidence export contains readable HTML, exact reproducible scenario JSON, selected-design GeoJSON, assumed-cost CSV, and a SHA-256 manifest. If building values, first-floor elevations, or validation data are absent, SPONGE says the estimate is unavailable instead of manufacturing one.

Earth Forward impact

SPONGE follows a defensible impact pathway: make neighbourhood-scale runoff visible, screen several green-infrastructure portfolios under identical storms, expose adverse changes and missing evidence, then hand an auditable shortlist to the people who can survey and engineer it. The environmental outcome is not claimed in advance. A real pilot must still measure whether this workflow reduces analysis time or improves which sites advance to professional review.

What makes it distinctive

Flood dashboards and stormwater models already exist, so the claim is deliberately narrow. SPONGE combines five things in one judge-accessible workflow:

Live browser shallow-water physics rather than a prerecorded overlay or opaque score.
Editable finite-capacity green infrastructure whose saturation, overflow, and return flows remain in the ledger.
Budget search that evaluates alternatives against the same disclosed rainfall-sensitivity ensemble.
Synchronized baseline/planned replay that preserves residual risk and local worsening.
Tamper-checked exports that distinguish software correctness from missing real-world validation.

How we built it

React, TypeScript, Vite, Deck.gl, and MapLibre for the interface and city view.
A WebGL2 fragment-shader HLL shallow-water solver in a worker, with first- and second-order reconstruction.
Python/NumPy reference solver and independent numerical fixtures.
FastAPI, PostgreSQL/PostGIS, Redis, and RQ for sessions, immutable bundles, and preparation jobs.
Rasterio, PyProj, and Shapely for geospatial ingestion and validation.
Docker Compose production stack with migrations, persistent data, strict security headers, and an offline prepared bundle.

The planner is deterministic and simulation-backed; the application requires no runtime LLM or model API key.

Challenges

The hardest challenge was keeping the visual experience honest. Water could not simply disappear into a “green” polygon, so every intervention needed finite storage, overflow, and ledger accounting. Baseline and proposed runs also had to share identical forcing and initial conditions. We added exact input hashes, report reconciliation, and rejection paths for incomplete or altered runs.

Real geospatial data introduced a second challenge: coverage, resolution, survey dates, and vertical references are not interchangeable. SPONGE reports these separately and keeps observed accuracy unvalidated unless evidence supports it.

Accomplishments

Live browser shallow-water physics with CPU parity and conservation checks.
Four intervention types, nonlinear controls, bounded budget search, and synchronized replay.
Rainfall, external-inflow, coastal, and compound scenario contracts.
Interrupted-storm recovery, GPU-context recovery, and duplicated-tab isolation.
Reproducible, tamper-checked evidence exports.
A hardened non-root production deployment with migrations, persistent storage, worker-aware readiness, request limits, and security headers.
Final verification: 334 Python tests, 136 TypeScript tests, and 46 real-browser/GPU tests, plus schema, lint, typing, dependency, build, and production smoke checks.

What we learned

Numerical correctness, agreement with a reference, and agreement with real observations are three different claims. A conservative ledger and a passing numerical fixture are important, but neither proves a neighbourhood forecast. We learned hydrodynamic finite-volume methods, WebGL2 shader constraints, CRS and vertical-datum handling, robust optimization, accessible 2D/3D interaction, browser recovery semantics, and production operations. The most important product lesson was that saying “unknown” is often harder—and more useful—than displaying a confident-looking number.

How we used AI and Codex

Codex acted as an engineering collaborator for requirements analysis, architecture, implementation, debugging, security and lifecycle review, browser QA, testing, and documentation. Generated suggestions were accepted only after repository inspection and automated or browser verification. Physics, planning metrics, constraints, and reports remain reproducible code paths rather than model-generated claims.

Work-period disclosure

SPONGE began during the NextStep Hacks build period. Product architecture and planning started on September 10, 2026, followed by implementation, numerical verification, browser QA, production hardening, and submission preparation through September 20. No SPONGE implementation existed before the event. Earlier files in the workspace concerned a separate product-research concept and were not reused as SPONGE code or presented as this submission.

The project was built by Aditya Jevoor with Codex as an AI engineering collaborator. Aditya directed product decisions and accepts responsibility for the submitted work and claims.

What is next

Next steps are a pilot with a community or stormwater practitioner, observed-event calibration, surveyed catchments and drainage, parcel and utility eligibility, dated local construction quotes, defensible building inventories, and engineered facility geometry. The success measure is whether SPONGE shortens early alternatives review or changes which candidate sites advance to professional study without raising false confidence.

Important limitation

SPONGE is an exploratory screening tool, not a calibrated flood forecast or engineering design. Real decisions require surveyed terrain and drainage, datum confirmation, parcel and utility review, observed-event calibration, current local costs, and professional judgement.