Know which roads go under — before the rain stops.
A rainfall total is not a decision. FloodGrid carries the storm all the way through: a predictive rainfall grid from the next fifteen minutes to the next three days, machine-learned stage and inundation for your catchments, and an alerting engine that names the asset, the crossing and the lead time — then publishes how often it was right.
1 km rainfall grid · 15-min forecast step · 0–72 h horizon · machine-learned stage & inundation · threshold, escalation and audit trail · published hit rate, false-alarm ratio and full methods specification
Grid resolution, cadence and horizon are platform specifications. Delivery latency is a design target measured from threshold evaluation to hand-off at the notification provider — not an end-to-end guarantee, since carrier and paging delivery are outside any vendor's control.
Most flood tools stop one step short of the decision.
Radar tells you where it is raining. A gauge tells you what one point measured. A model run tells you what a hydrograph did last night. None of them tell the duty officer at 02:40 whether to close Mill Creek Road, and none of them tell them how much time they have. That last step — from rainfall to consequence to a specific instruction to a specific person — is the whole product.
A schematic of the decision chain, not a product comparison. Every organisation covers some of this already — the question worth asking a vendor is which stage their output actually ends at, and who is expected to do the remaining steps at 3 a.m.
One system from the radar sweep to the phone that rings.
FloodGrid is a single pipeline, not a bundle of point tools. The same quality-controlled rainfall grid that feeds the forecast feeds the machine-learned stage model, the inundation surrogate, the threshold engine and the after-action record — so the number in the alert and the number in the report are the same number.
Predictive rainfall
Radar nowcasting blended into high-resolution numerical weather prediction, on a 1 km grid at 15-minute steps out to 72 hours — with the blend weights published rather than hidden.
Nowcast · blend · NWP ensembleLearned catchment response
A sequence model trained on your own gauge and SCADA history maps rainfall to stage and flow at the points you care about, including the ones with no rating curve and no hydraulic model.
Per-site models · retrained monthlyYour SWMM model, on the forecast
FloodGrid reads the EPA SWMM 5 input file your consultant calibrated — subcatchments, infiltration, LID controls, conduits, pumps, control rules — and runs it on the forecast rainfall every cycle. Nothing is rebuilt in a proprietary schema, and the file you get back still opens in SWMM.
Runoff · dynamic wave · LID · lossless round tripCollection system, not just streams
Inflow and infiltration, interceptor hydraulic grade line and freeboard, regulator and permitted-outfall activation with estimated volume, wet-well trajectory against alarm setpoints, and storage drawdown before the next cell.
HGL · RDII · CSO · pumping · storageConsequence, not just level
Forecast stage is resolved onto terrain and your asset layers: which crossings overtop, which pump stations are exposed, which parcels and critical facilities sit inside the wet edge.
Depth grid · asset exposureNotification that escalates
Thresholds you set, an escalation ladder you control, deduplication so one storm is not forty pages, quiet hours, on-call rotations, acknowledgement tracking and a complete audit trail.
SMS · voice · email · webhook · CAPVerification in the open
Hit rate, false-alarm ratio, critical success index and median lead time — computed per site, per threshold, per season, and visible to you whether the number flatters us or not.
Scored against your sensorsBuilt to be integrated
REST and webhooks, CAP 1.2 for public-alerting stacks, OGC services for GIS, Esri-ready layers, and time series shaped for InfoWorks ICM, SWMM, HEC-RAS and your historian.
API-first · no scraping requiredBuilt for the people who have to make the call.
Water & wastewater utilities
Inflow and infiltration, interceptor surcharge and basement-backup risk, regulator and CSO activation with volume for permit reporting, lift-station wet-well trajectory, storage pre-drawdown, and forecast peak influent at the plant.
Counties & municipalities
Low-water crossings, culvert and storm-drain capacity, repetitive-loss neighbourhoods, and public messaging that is timed to the hazard rather than to the news cycle.
Flood-control & drainage districts
Channel and detention performance under a live storm, gate and pump pre-positioning, and inter-basin awareness when the next basin over is about to hand you its water.
Emergency management
Lead time on the assets that matter — shelters, hospitals, evacuation routes, staging areas — with CAP output that drops into the alerting stack already in use.
State & local DOTs
Route-level closure risk, maintenance-crew staging, and a defensible timeline showing when a segment first crossed a closure threshold.
Dam & levee safety
Inflow forecasting into the reservoir, emergency action plan trigger tracking, and an unbroken, timestamped record of every threshold crossing and every notification sent.
Five stages, every five minutes, whether or not anyone is watching.
Each stage adds a layer to the same square kilometre. Scroll, and watch the stack build: the ground and its sensors, the rainfall analysis above it, the forecast above that, the consequence back on the ground, and the notification that leaves the building.
Ingest and quality-control
Radar mosaics, dual-pol fields, gauge networks, your own rain gauges, level sensors and SCADA tags arrive on their own cadences. Each is range-checked, flatline-checked and cross-checked against its neighbours. A sensor that has failed is marked failed — never quietly interpolated into a zero.
Build the rainfall grid
Radar is bias-corrected against gauges that survived quality control, producing one 1 km analysis at 5-minute steps. The correction method, the gauges used, and the gauges rejected are all recorded per cell so the number can be defended later.
Forecast forward
Radar-extrapolation nowcasting dominates the first ninety minutes, hands over to blended high-resolution NWP through the first day, and to ensemble guidance beyond it. The handover is gradual and the weights are published on the page, not buried in a methods appendix.
Turn rain into consequence
Per-site sequence models produce stage and flow with uncertainty bands. Your SWMM model routes the runoff through the pipes; an inundation surrogate — trained against full hydraulic runs — expands the forecast onto terrain in seconds rather than hours, and intersects it with your assets, roads and critical facilities.
Decide, notify, record
Every threshold you defined is evaluated on every cycle. Crossings escalate along your ladder, notifications are deduplicated and routed to whoever is actually on call, acknowledgements are tracked, and the whole sequence is written to an immutable event record you can export.
Everything an agency can actually do requires a head start.
Flood losses are only partly a function of depth. They are also a function of how many of the cheap actions were taken before the water arrived. Each of these has a minimum notice below which it stops being possible — which is why FloodGrid reports lead time as a first-class metric next to accuracy, rather than as a footnote.
Indicative planning ranges, not measurements. The exact notice each action needs is specific to your crews, your geography and your procedures — capturing those real numbers is part of configuring the escalation ladder during onboarding, and they are what the alerting thresholds are then tuned against.
The technical case is on the site, not behind a signature.
Most evaluations of a flood system run on claims until someone signs something. Ours does not have to: the governing equations, the discretisation and its tolerances, the training and split protocol, the service objectives and the register of everything the model assumes are all published, and three of the figures in the methods section compute their results in your browser rather than showing a picture of a result.
Twenty-two governing equations
Saint-Venant in full dynamic form, the Preissmann slot, Green–Ampt, the RTK unit hydrograph, weir and orifice hydraulics, Z–R and the ensemble state update — each with a note on what keeping that term commits us to, and what dropping it would quietly cost.
Read the equation sheet →Numerical experiments you can run
Choose a time step and watch a crest lose its peak, ring, or diverge; move a sensor’s uncertainty and watch the Kalman gain change size; switch off one error source and see the lead time it was costing you. All solved live, in the page.
Open the solver →Twelve questions for every vendor
Including us — and including the four we cannot answer with production numbers until we have run a season on your basins. A specification you can hold a supplier to is worth more than a claim you cannot check.
See the evaluation matrix →Put your catchments on the grid.
Onboarding starts with your sensors and your asset layers, not with a generic demo. Within a pilot you get a scored record for your own basins — including the events where the model was wrong.
From the next fifteen minutes to the next three days.
No single technique is good at every lead time. Radar extrapolation is unbeatable for the first hour and useless by the sixth. Numerical weather prediction is the only thing that works at day two and is far too coarse and too laggy to catch the cell currently sitting over your interceptor. FloodGrid runs all of them and blends them on a published schedule — so the forecast never quietly changes character without telling you.
Radar nowcast
Optical-flow motion fields extrapolate the observed radar mosaic forward, with growth and decay estimated from the last several sweeps. Updated every five minutes. This is the regime where a warning still changes what a crew can do.
Blended short range
Nowcast skill decays and convection-allowing NWP takes over on a weighted ramp. The blend is bias-corrected against the last several days of local performance, so a model that has been running wet over your basin is discounted before it reaches you.
Ensemble outlook
Multi-member, multi-model guidance carried as a distribution rather than a single trace. At this range the honest output is a probability of crossing a depth, not a number to two decimal places.
An illustrative schedule, not a fixed constant. The real weights are re-estimated continuously from recent verification over your own basins: a nowcast that has been performing well in a slow-moving stratiform event keeps weight longer than one chasing fast discrete cells. The important property is that the ramp is smooth — a forecast that jumps when a source switches produces threshold crossings that are artefacts of the blend rather than of the weather.
The useful question is not “how much rain”. It is “what are the odds it crosses my number”.
A deterministic forecast of 2.4 inches is a statement with no risk content. An operations manager needs the chance that the basin exceeds the depth that has historically put water over Mill Creek Road — and needs it to move honestly as the storm approaches. Set a threshold below and watch the exceedance probability evolve with lead time.
Synthetic ensemble for demonstration. The shape is the point: a probability that climbs early and holds is a storm you can plan around; one that oscillates between 20% and 70% every cycle is telling you the atmosphere has not made up its mind, and that pre-positioning is a better response than evacuation. FloodGrid records both the probability it issued and what subsequently happened, so the reliability of these curves is measurable rather than asserted — see Verification.
“How many inches” is the wrong question. “What return interval, at which duration” is the right one.
Drainage systems are designed against a depth-duration-frequency curve, consent decrees are written against one, and every engineer in the room already thinks in those terms. So the forecast is reported in them: the incoming storm's own depth-duration curve, laid over the design family, with the duration at which it is most severe marked. A storm that is a ten-year event at three hours and a one-year event at twenty-four is a very specific operational problem, and saying “3.6 inches” conceals it entirely.
Synthetic DDF coefficients and a synthetic storm. A production deployment uses the published depth-duration-frequency statistics for your location, and states the source and the edition on the figure — because two different atlas editions can move a five-year depth by enough to change a design decision. Note also that the design family is a statistical statement about a stationary climate; where the local record shows the intensity distribution moving, that is worth saying out loud rather than quietly using the old curves.
Radar sees everywhere. Gauges measure truth. Neither is sufficient alone.
A forecast is only as good as the analysis it starts from. Radar reflectivity is an inference about drop-size distribution, not a measurement of depth; it drifts with calibration, beam blockage, bright band and range. A rain gauge is a direct measurement of one square foot of the planet. FloodGrid corrects one with the other, and writes down what it did.
Radar first guess
Dual-polarization fields give a better rain-rate estimate than reflectivity alone, particularly in heavy rain and mixed precipitation. Mosaicked so the seams between radars are not mistaken for storm structure.
Gauge correction
Multiplicative bias fields and kriging-with-external-drift, computed on rolling windows. More than one method is run; where they disagree materially, the disagreement is surfaced rather than averaged away.
Quality control that admits gaps
Stuck tips, blocked funnels, frozen sensors and comms outages are detected and flagged. A gap is reported as a gap. Nothing is silently backfilled with zero, because a zero is a measurement and a gap is not.
Synthetic storm. The failure mode is not that the gauge is wrong — it is right about the ground under it. The failure is treating one point as representative of a basin whose response is driven by where the core actually sat.
Why this matters for alerting
A threshold defined on a single gauge inherits that gauge's blind spots. If the storm core sits three kilometres away, the threshold never trips and the crossing floods anyway. If the gauge is under the core and the rest of the basin is dry, the threshold trips and a crew is dispatched to a dry road — which is how organisations learn to ignore their own alerts.
What FloodGrid does instead
Thresholds are defined on catchment-integrated grid rainfall, on modelled stage, or on both with an AND condition. The gauge is still used — as a truth source for correcting the grid, and as an independent check that raises a data-quality flag when it disagrees with the grid over its own cell.
And when the radar is down
Coverage degradation is a first-class state. The platform reports reduced confidence, widens the uncertainty bands, and continues to alert on gauge and sensor evidence — while telling you plainly that it is doing so.
See the forecast on your own basins.
A pilot runs on your catchment boundaries, your gauges and your thresholds — with a hindcast over your last few significant storms so you can see how the forecast would have behaved before you rely on it.
Machine learning where it earns its place — and physics where it does not.
“AI-powered” is not a specification. What matters is which component is learned, what it was trained on, what it does when it meets a storm larger than anything in its training set, and who is accountable when it is wrong. FloodGrid publishes that for every model it runs. Some parts of this pipeline are learned because learning genuinely beats the alternative. Other parts are deliberately not, because a conservation law you can audit is worth more at 3 a.m. than a correlation you cannot.
Sensor quality control & anomaly detection
Learned Rule-checkedEvery incoming gauge, level sensor and SCADA tag is scored against its own history and its neighbours. A gradient-boosted classifier flags stuck tips, drift, freeze, siphoning, submerged transducers and comms dropout; deterministic range and rate-of-change rules run alongside it and can veto. Bad data is quarantined before it reaches the rainfall analysis, because a single stuck gauge reading zero through a storm will drag a bias correction across an entire basin.
The classifier proposes; the rules dispose. Any sensor the model wants to exclude is logged with the reason, and an operator can reinstate it — which is itself recorded as a labelled example.
Rainfall analysis & forecast blending
Physical / statistical Learned weightingThe radar-to-rainfall step is physical and statistical: dual-polarization rain-rate relations, mosaicking, and gauge-based bias correction by kriging with external drift. What is learned is the blending — how much weight nowcast, convection-allowing NWP and ensemble guidance should each carry, conditioned on lead time, storm regime, season and recent local verification.
This is a deliberate boundary. Learning the rain-rate relation from scratch would discard decades of radar meteorology; learning the blend weights recovers exactly the local, seasonal, regime-dependent behaviour that no published constant can capture.
Catchment response — rainfall to stage and flow
LearnedThis is where machine learning is unambiguously the right tool. A recurrent sequence model — LSTM-family, trained per site with regional pooling — maps a window of catchment-integrated rainfall, antecedent wetness, recent observed stage and static basin attributes onto stage and flow at 15-minute steps. It is trained on your own historical record, which means it learns your basin's actual behaviour, including the parts no one ever wrote into a model: the culvert that has been half-blocked since 2019, the way the interceptor surcharges once the tide is above a certain level, the diurnal irrigation signal.
Crucially it works at sites with no rating curve and no calibrated hydraulic model — which is most sites. Regional pooling lets a site with two years of record borrow structure from neighbours with fifteen.
Collection-system response — RDII, surcharge and regulator activation
Learned Model-anchoredA sewer is not a stream, so it gets its own model. Metered basin flow is decomposed into base sanitary flow, groundwater infiltration and rainfall-derived inflow and infiltration; the RDII component is what the model learns to predict, conditioned on rainfall, antecedent wetness and season. Predicted basin flows are then routed on your hydraulic model schematic to give depth at metered manholes, the hydraulic grade line between them, and the point at which each regulator starts diverting.
The learned part is the basin response — the part that depends on how leaky your pipes actually are, which no schematic contains. The routing stays anchored to the network you already model, so a result can always be traced back to a pipe with an invert and a diameter.
Inundation surrogate — stage to depth on the ground
Learned surrogate Physics-trainedFull two-dimensional hydraulic simulation is the gold standard and is far too slow to run on every forecast cycle. So it is run offline, hundreds of times, across a designed sweep of boundary conditions — and a convolutional surrogate is trained to reproduce the resulting depth grids from terrain, the drainage network and the forecast boundary stage. At runtime the surrogate produces a depth grid in under a second.
The surrogate never invents hydraulics; it interpolates a physics-based response surface. Where a forecast stage falls outside the sweep it was trained on, it says so and the cell is returned as out-of-envelope rather than as a confident number.
Threshold evaluation & alert decision
Deterministic rulesDeliberately not a learned component. Whether an alert fires is a policy decision an agency owns, expressed as explicit rules on explicit quantities: this stage, at this site, with this probability, sustained for this long. A learned classifier here would be unauditable, would drift without anyone noticing, and would make it impossible to answer the only question that matters in an after-action review — why did this alert fire?
Machine learning informs this layer by supplying the forecast and its uncertainty. It does not get to decide the policy.
The operator
Human in the loopAn operator can suppress, escalate, extend or override any alert, and every one of those actions is recorded with who, when and why. Overrides are not treated as noise to be engineered away — they are the highest-quality supervision signal the system receives, and they feed directly into the next retraining cycle and into the threshold review.
If a site is repeatedly overridden, that is a finding about the threshold or the model, and it appears in the monthly review rather than waiting for someone to notice.
A forecast is a distribution that narrows as the storm arrives.
Below is a single synthetic site through one synthetic event. Move the issue time to see what the model was saying at each point — how wide the band was, where the central estimate sat, and when the threshold crossing first became likely. This behaviour, not a single headline accuracy figure, is what determines whether a forecast is usable in an operations room.
Synthetic site and synthetic event. Note what the early issue times do: the median is close but the band is wide, which is a correct and useful statement — it says prepare, do not commit. A model that reported a narrow band eight hours out would look more impressive and be considerably more dangerous.
No hidden inputs. No mystery features.
Illustrative attribution for one synthetic catchment. The pattern is the transferable part: at short lead times the model is mostly reading the river, and at long lead times it is mostly reading the sky. A model whose attribution did not shift this way with lead time would be a warning sign.
Dynamic inputs
Catchment-integrated rainfall (observed and forecast), antecedent rainfall over 3, 7 and 30 days, observed stage and rate of change at the site and at upstream sites, upstream reservoir releases where telemetered, tide or downstream boundary stage in coastal basins, and seasonal terms.
Static attributes
Drainage area, time of concentration, imperviousness, slope and hypsometry, soil hydrologic group, land cover, channel and storm-network density, and detention storage. These are what let a site with a short record borrow from a hydrologically similar neighbour.
Deliberately excluded
Anything that would not be available at forecast time, anything derived from the target it is predicting, and anything that encodes the answer through a back door. Data leakage is checked by re-running validation on a strictly time-forward split — never a random one.
Every model ships with its limits written down.
A model card travels with each deployed model and is visible in the application, not filed in a report. It states what the model was trained on, how it was validated, where it is known to be weak, and when it will be retrained. If a model card cannot be produced for a component, that component does not go into production.
Catchment response — stage
Learned- Purpose
- 15-minute stage and flow forecast at instrumented sites, 0–72 h.
- Training data
- Site record plus regionally pooled neighbours; minimum 24 months, target 60+ months of 15-minute stage and matched grid rainfall.
- Validation
- Strictly time-forward split. Held-out final season never seen in training or tuning. Scored on peak timing and peak magnitude error, not only on mean error, because a model can win on RMSE while missing every crest.
- Known weaknesses
- Events materially larger than anything in the training record; step changes after construction, channel works or a new detention facility; sites where the stage sensor itself was relocated mid-record; frozen-precipitation and snowmelt-driven response where the training record is thin.
- Retraining
- Monthly on a schedule, and out of cycle after any event exceeding the prior record or after physical works in the basin.
- Degradation behaviour
- Widens quantile bands and raises a confidence flag rather than narrowing on thin evidence. Falls back to persistence plus routed rainfall if the sequence model is unavailable.
Inundation surrogate — depth
LearnedPhysics-trained- Purpose
- Sub-second depth grid from forecast boundary stage, for asset and roadway exposure.
- Training data
- Offline two-dimensional hydraulic simulations across a designed sweep of boundary stages, durations and initial conditions on the client's own terrain and drainage network.
- Validation
- Held-out simulations plus, where available, observed high-water marks and documented closure records from past events.
- Known weaknesses
- Boundary conditions outside the trained sweep — returned as out-of-envelope, never extrapolated. Blockage-driven flooding the underlying hydraulic model did not represent. Terrain changes since the survey. Levee and floodwall breach behaviour, which is explicitly out of scope.
- Retraining
- On terrain or network updates, on hydraulic model revision, and annually.
- Degradation behaviour
- Falls back to a static stage–depth lookup at instrumented sites and reports the reduced fidelity in the alert payload.
Collection-system response — RDII
LearnedModel-anchored- Purpose
- Forecast wet-weather flow at metered basins, and the surcharge and regulator activation that follows from it.
- Training data
- Flow-monitoring records at basin meters — ideally a full monitoring season including both dry and wet periods — with matched grid rainfall and the utility's hydraulic model schematic.
- Validation
- Held-out storms, scored on peak flow, volume and time to peak, plus activation skill at each regulator. Dry-weather performance is scored separately, because a model that nails wet weather and drifts on the diurnal curve will mislead every threshold set on absolute flow.
- Known weaknesses
- Basins whose network has been rehabilitated since the monitoring period — the R-value the model learned no longer exists. Private-side inflow that appears only in extreme events. Blockages and collapses the schematic does not know about. Snowmelt-driven infiltration where the record is thin. Tide-influenced outfalls without a downstream boundary record.
- Retraining
- After each flow-monitoring campaign, after rehabilitation work in the basin, and annually.
- Degradation behaviour
- Falls back to the utility's own RTK unit-hydrograph parameters where they exist, and reports reduced confidence where they do not.
Sensor anomaly detection
LearnedRule-vetoed- Purpose
- Flag failed or degraded sensors before their values reach the analysis.
- Training data
- Historic maintenance records, operator overrides and synthetic fault injection.
- Validation
- Precision and recall against held-out maintenance tickets; tuned to favour recall, since a missed bad sensor corrupts a basin while a false flag costs one review.
- Known weaknesses
- Slow drift that resembles genuine seasonal change. Novel fault modes not present in the record. Newly installed sensors with no personal history.
- Retraining
- Quarterly, and whenever a fault class is added to the maintenance taxonomy.
- Degradation behaviour
- Deterministic range, flatline and rate-of-change rules continue to run independently and can quarantine a sensor on their own.
Forecast blending weights
Learned- Purpose
- Set the weight given to nowcast, convection-allowing NWP and ensemble guidance by lead time and regime.
- Training data
- Rolling local verification of each source against the gauge-corrected analysis over the client's own footprint.
- Validation
- Continuous — the blended product is scored against the same analysis it is trying to predict, on a strictly forward-looking basis.
- Known weaknesses
- Regimes rare in the local record, such as a first tropical remnant in an inland basin. Periods immediately after an upstream model upgrade, where recent skill is no longer representative.
- Retraining
- Continuous, with a floor on how fast weights are allowed to move so a single bad day cannot swing the blend.
- Degradation behaviour
- Reverts to a conservative published default schedule when recent verification is unavailable or unrepresentative.
A model that is not being watched is not in production. It is just running.
Input drift and performance drift are monitored separately. Input drift catches a changing world — a new subdivision, an upgraded upstream model, a relocated sensor — often before performance visibly degrades. Performance drift catches everything else. Either one crossing its control limit opens a review; neither silently retrains the model on its own.
New model versions run in shadow before they run in anger. A candidate scores against live data alongside the incumbent for a full retraining cycle. It is promoted on a documented margin across peak timing, peak magnitude and threshold-crossing skill — not on aggregate error alone, which is the metric most easily gamed.
Every promotion is reversible. Model versions are immutable and addressable; the version that produced any historical alert can be re-instantiated and re-run against the exact inputs of that moment. An after-action review never has to reconstruct what the model "probably" said.
Out-of-envelope is a state, not an error. When conditions exceed the range a model was trained on, the platform says so in the alert payload and in the interface. It does not extrapolate confidently into a regime it has never seen — which is precisely the regime that produces record floods.
Overrides and misses are reviewed monthly, with people in the room. Every missed event, every false alarm and every operator override is listed. Some are model problems, some are threshold problems, and some are correct behaviour that looked wrong. Telling them apart is not something to automate.
Ask us the hard questions about the models.
We would rather spend the first call on training windows, validation splits and failure modes than on a slide deck. Bring your hydrologist.
Your SWMM model, running every five minutes.
FloodGrid does not ask you to rebuild your network in a proprietary format. It reads the EPA SWMM 5 input file your consultant calibrated — subcatchments, subareas, infiltration, LID controls, junctions, conduits, storage, pumps, orifices, weirs, RDII and control rules — and drives it with the forecast rainfall grid on every cycle. The runoff engine generates the hydrology; the flow-routing engine solves the hydraulics; both produce the same objects your engineers already argue about, under the same object names.
This page is the hydrology half of the story. It is where rainfall becomes flow: what infiltrates, what is held in depression storage, what runs off an impervious surface in nine minutes and a lawn in forty, what green infrastructure takes out of the peak, and what the street does when the pipe below it is already full. The pipes themselves are on the Collection system page; the equations behind both are on Methods.
Where the rainfall actually goes.
SWMM treats a subcatchment as two nonlinear reservoirs side by side — one impervious, one pervious — each shedding water over a Manning surface once its depression storage is full. That structure is why the same inch of rain produces a flashy nine-minute response from a parking lot and a slow, half-absorbed one from the lawn beside it. The figure below integrates both reservoirs live; change the parameters and watch the split move.
Two things in this figure are worth arguing with your modeller about. First, the infiltration capacity falls through the storm — the ground is not a fixed sink, and a second cell arriving three hours in meets a catchment that has already spent most of its capacity. Switch the antecedent condition to wet and watch the runoff coefficient move without a single change to the rainfall. Second, the pervious contribution is not small and it is not fast: it arrives late, it broadens the recession, and it is the part a design storm computed with a single runoff coefficient throws away entirely. SWMM applies the full subcatchment width to both subareas, which is a modelling convention rather than a physical claim, and it is one of the parameters calibration actually moves.
The first table any modeller opens, published on the website.
Every SWMM run ends with a continuity report, and every experienced modeller reads it before looking at a single hydrograph — because a run that has lost four percent of its water is not a forecast, whatever else it says. FloodGrid computes the same report on every cycle, stores it with the forecast, and refuses to publish a run that fails the threshold. The table below is computed from the integration in the figure above, so it moves when you move the controls.
| Runoff quantity continuity | Depth (in) | Volume (ac-ft) |
|---|---|---|
| Total precipitation | — | — |
| Evaporation loss | — | — |
| Infiltration loss | — | — |
| Surface runoff | — | — |
| Final surface storage | — | — |
| Continuity error | — | — |
Why continuity is the honest metric
It cannot be tuned. Calibration can make a hydrograph fit an observation for the wrong reasons, and a plausible-looking peak tells you nothing about whether the model conserved water getting there. Continuity error is arithmetic: it either balances or it does not.
What a bad number means
Above roughly 1% in the flow-routing engine, look for a time step too long for the shortest conduit, a node with almost no surface area, or a control rule oscillating a pump every step. Above 5%, the run is not usable and no amount of parameter adjustment will fix it.
What we do with it
Store it with the forecast, plot it over time, and alarm on the trend. A continuity error that has been creeping upward for three weeks is usually a network edit nobody flagged — a conduit with a bad invert, a new storage node with a missing curve.
Where the equivalent for the hydraulics lives
The flow-routing continuity error, the solver tolerances and the Courant cap are on the Methods page, with a figure that lets you break the scheme deliberately.
What the LID controls in your model are actually buying you tonight.
Green infrastructure is usually justified on an annual volume-capture number and then never looked at again during an event. That is a waste of an asset you have already paid for: a bioretention cell that is empty at midnight and full by two is a different asset at each moment, and the operational question — how much peak is it taking off this storm, and will it still have room when the second cell arrives — is answerable from the same LID objects already sitting in your input file.
Read the storage curve, not only the peak. The purple trace is the control filling, and the operationally interesting moment is where it flattens at the top: past that point the asset is contributing nothing and every additional inch runs off as though it were not there. On this storm the controls ride out the first cell comfortably and saturate part-way up the main one, which is exactly why a green-infrastructure programme sized on annual capture can post an excellent yearly number and take almost nothing off the event that floods the street. A cistern behaves differently on purpose — it drains slowly, so it holds its water longer and keeps less room in reserve, which is the right trade for volume and the wrong one for back-to-back cells. FloodGrid reports both, per control, per event.
LID parameters, as SWMM expects them
These are the layer definitions read from your [LID_CONTROLS] section. FloodGrid does not invent them.
What we add on top
The parts a static model run does not give you, because they only exist once a forecast does.
The street is part of the drainage system whether it is in the model or not.
A runoff hydrograph arriving at a node assumes the water got into the pipe. Between the two sits an inlet with a finite capacity, leaves on it, and a hydraulic grade line underneath that may already be above the gutter. This is where most surface flooding actually originates, and it is the part a model with no surface pathway simply cannot see: the water is delivered to the node on paper while in reality it is running down the street to the sag two blocks away.
The inlet is a weir until it drowns, and then it is an orifice — the same pair of equations as the regulators on the collection-system page, at a different scale. That transition is why inlet capacity is not a single number on a datasheet, and why a grate rated for four cubic feet per second passes barely one when the water is shallow. Set the sewer beneath to above the rim and the sign flips: the driving head is now in the pipe, the inlet becomes a source, and the street fills to whatever level the hydraulic grade line reaches. No amount of grate cleaning fixes that case, which is the distinction between an inlet problem and a capacity problem — and it is a distinction a resident reporting street flooding cannot make for you.
We read your model. We do not become the only thing that can open it.
The most expensive thing a utility owns in this space is not software; it is twenty years of calibration argument encoded in an input file. A platform that imports that file and then holds it hostage in a proprietary schema has taken an asset off you and given you a subscription. FloodGrid reads SWMM 5 natively, keeps every object under its original name, and writes back a file that opens in EPA SWMM, PCSWMM, XPSWMM or anything else that speaks the format — whether or not you are still a customer.
| Input section | Read | Simulated | Written back | Notes |
|---|---|---|---|---|
| [SUBCATCHMENTS] [SUBAREAS] | Yes | Yes | Unchanged | Area, width, slope, %imperv, routing between subareas |
| [INFILTRATION] | Yes | Yes | Unchanged | Horton, modified Horton, Green–Ampt, modified Green–Ampt, curve number |
| [AQUIFERS] [GROUNDWATER] | Yes | Yes | Unchanged | Two-zone aquifer; matters on the long recessions that keep a system in wet-weather posture for days |
| [LID_CONTROLS] [LID_USAGE] | Yes | Yes | Unchanged | All layers, including clogging factors and drain control rules |
| [SNOWPACKS] | Yes | Yes | Unchanged | Rain-on-snow is a real northern failure mode and is not skipped |
| [JUNCTIONS] [OUTFALLS] [STORAGE] [DIVIDERS] | Yes | Yes | Unchanged | Ponded area, surcharge depth and outfall boundary type all honoured |
| [CONDUITS] [XSECTIONS] [LOSSES] | Yes | Yes | Unchanged | Including irregular and custom shapes, force mains, and entry/exit losses |
| [PUMPS] [ORIFICES] [WEIRS] [OUTLETS] [CURVES] | Yes | Yes | Unchanged | Pump curves by type, weir coefficients, outlet rating curves |
| [CONTROLS] | Yes | Yes | Unchanged | Rules run as written. FloodGrid does not rewrite your control logic |
| [HYDROGRAPHS] [RDII] | Yes | Yes | Unchanged | RTK unit hydrographs, per sewershed, with initial abstraction |
| [DWF] [PATTERNS] [INFLOWS] | Yes | Yes | Unchanged | Dry-weather patterns replaced by the live diurnal estimate during a run, restored on export |
| [TIMESERIES] [RAINGAGES] | Yes | Replaced | Unchanged | The one substitution: gage series are driven by the forecast grid at run time. Your original series stay in the file |
| [POLLUTANTS] [LANDUSES] [WASHOFF] | Yes | No | Unchanged | Carried, not simulated. FloodGrid models quantity. Water quality is out of scope and is not implied |
| [COORDINATES] [POLYGONS] [MAP] [TAGS] | Yes | — | Unchanged | Geometry and tags preserved so the file still draws correctly in your editor |
Two of those options decide more than the rest put together. ALLOW_PONDING YES is the difference between a model that quietly deletes the water that will not fit and one that keeps it at the node where it will actually be — and a model set to NO will happily report no flooding while the street is under a foot of water. SURCHARGE_METHOD SLOT is the Preissmann slot from the methods page, and it is why the surcharge propagation in these runs is stable rather than an oscillation the modeller has learned to ignore. If your file has ponding off, that is worth a conversation before anything else on this page matters.
What we never change
Network geometry, invert elevations, cross-sections, calibrated roughness, RTK parameters, control rules and LID layer definitions. If a number in your file changes, it is because you changed it.
The single substitution
Rain gage time series are driven by the forecast grid during a run. Your historical series are preserved untouched in the file, and any run can be replayed against them instead.
Version handling
SWMM 5.1 and 5.2 input files are both read; a 5.1 file is not silently upgraded. InfoWorks ICM comes in through ICM Exchange, and what could not be translated is listed explicitly rather than dropped.
Getting your model back
Export at any time, including after the contract ends, as a plain .inp with the geometry, tags and coordinates intact. Also on the data ownership terms.
Where the calibration lives
With you. FloodGrid can propose parameter adjustments from the residual record, but a change to a calibrated model is a modeller's decision with a modeller's name on it, and it is versioned.
Send us the input file.
The most useful first step is your existing .inp and one storm you have flow monitoring for. We will run it, show you the continuity report, the hydrographs and where our forecast disagrees with your gauges — and tell you plainly whether the model is in good enough shape for any of this to be worth doing.
Wet weather is a collection-system problem before it is a street problem.
Long before water shows up on a road, it is already in the pipes. Inflow and infiltration climb, the interceptor surcharges, regulators start diverting, wet wells rise faster than the pumps can draw them down, and somebody has to decide whether to open the storage tunnel now or hold capacity for the second cell. FloodGrid forecasts that sequence at the same cadence it forecasts the rainfall driving it — on your network, your regulators, your permitted outfalls.
Interceptor capacity
Forecast depth and hydraulic grade line at metered manholes, with remaining freeboard to the crown and to the surcharge threshold.
Regulator & CSO activation
Which permitted outfalls are forecast to activate, when they start, how long they run and the estimated volume — with the confidence attached.
Pump & lift stations
Wet-well trajectory against pump-on and high-level alarm setpoints, firm capacity margin, and the stations where run-time is about to exceed what the duty pumps can hold.
Storage & treatment
Tunnel and basin fill trajectory, drawdown time before the next cell arrives, and forecast peak influent at the water resource recovery facility.
The network, not the watershed.
The same storm produces very different answers depending on which sewershed it lands on: a separated basin with a large detention pond behaves nothing like a combined basin with 1890s brick and a regulator that starts diverting at forty percent of design flow. This view is drawn on the collection system — trunk sewers, regulators, permitted outfalls, stations, storage and the plant — not on topography alone.
Entirely synthetic network, synthetic basins, synthetic flows. Nothing here corresponds to a real utility. A deployment is built on your own hydraulic model schematic, your regulator setpoints and your NPDES-permitted outfall list, so every label matches what your operators already call it.
The chart operators actually argue over.
A flow number is abstract. A hydraulic grade line rising toward the crown, then above it, then above the rim at manhole 14 is a specific, arguable, checkable statement about what is happening underground. FloodGrid forecasts the profile along each modelled reach at every cycle — so surcharge and overflow are things you see coming rather than things you reconstruct afterwards from a complaint log.
Synthetic reach and synthetic storm. Surcharge is not failure — most interceptors are designed to surcharge in wet weather. What matters is the freeboard left to the nearest rim, how long the reach stays surcharged, and whether the surcharge propagates upstream into laterals, which is what turns a hydraulic condition into a basement backup. Those three quantities are what this figure exists to show.
Where the profile comes from
Level and flow telemetry at metered manholes anchors the profile; the shape between meters comes from your hydraulic model schematic — invert elevations, diameters, slopes, rim elevations — combined through the same surrogate approach used for surface inundation.
What it will not tell you
A blockage the model does not know about, a collapsed segment, or a lateral connection that is not in the schematic. If observed level at a meter diverges from the forecast profile by more than a configured tolerance, that divergence itself becomes an alert — often the earliest signal that something physical has changed in the pipe.
Why the freeboard number matters more than the flow
Crews cannot act on a flow. They can act on “forty minutes of freeboard left at MH-14, on the block where we had four backups in 2024”.
Duration matters as much as peak. A reach that touches surcharge for six minutes is a different operational problem from one that holds it for three hours. Synthetic.
Which outfalls activate, when, for how long, and roughly how much.
For a combined system under a consent decree or a long-term control plan, this is the number that gets reported. FloodGrid forecasts activation ahead of the event and records what actually happened afterwards — the same record, produced the same way, whether the answer flatters the model or not.
Synthetic scenario. The comparison worth reading is the one between the two control postures: forecast-informed operation trades storage that would otherwise sit empty at the start of the event for volume that would otherwise leave through an outfall. FloodGrid does not operate your gates — it produces the forecast and the recommended pre-positioning; the decision and the SCADA command stay with your operators and your control system.
Activation records export in the shape your permit asks for. Start and end time, duration, estimated volume, receiving water, the rainfall that drove it, and the telemetry that evidences it — with the forecast that was issued beforehand kept alongside, so pre-event awareness is documented and not merely asserted.
Volume is an estimate and is labelled as one. Where an outfall is metered, the record uses the meter. Where it is not, the volume comes from the hydraulic model with its uncertainty stated. The two are never presented as the same class of number.
When the forecast and the telemetry disagree, both are kept. An outfall that activated without being forecast is a miss, appears in the verification record as a miss, and is reviewed. So is one that was forecast and did not activate.
This is decision support, not a compliance determination. What gets reported to a regulator, and in what form, is the utility's judgement and its counsel's. FloodGrid produces the underlying record.
Separating the rain from the sewage.
Wet-weather flow is three things stacked: base sanitary flow that follows the diurnal curve, groundwater infiltration that moves with the season, and rainfall-derived inflow and infiltration that arrives within hours of the storm. Telling them apart is what lets a utility forecast the third one — and what turns a flow meter into an argument for where the next rehabilitation dollar goes.
Synthetic basin, synthetic meter. The R-value is the fraction of rainfall falling on the basin that ends up in the sewer, and it is the number that separates a basin worth rehabilitating from one that is already tight. Watch it move with antecedent condition: the same storm on saturated ground puts far more water into an old combined basin than it does on dry ground, which is exactly why a forecast that ignores antecedent wetness is not usable for wet-weather planning.
Every station, one screen, ranked by how much time is left.
During a wet-weather event the pumping supervisor is not reading twelve trend screens. They need one ordered list: which wet well reaches the high-level alarm first, which station has lost redundancy, and where the bypass pump should be staged now rather than in an hour.
| Station | Wet well | Forecast level | Duty pumps | Firm capacity margin | Time to high-level alarm | State |
|---|
Synthetic stations. “Firm capacity” is the station's rated capacity with the largest pump out of service — the number that matters when a unit is down for maintenance during a storm. A station at 96% of firm capacity with all pumps running is a different problem from one at 96% with a spare available, and the board distinguishes them.
Storage you did not empty in time is storage you did not have.
A storage tunnel that is still forty percent full when the next cell arrives cannot capture what it was built to capture. Drawdown takes hours and is limited by what the plant can accept, so the decision to start dewatering has to be made on a forecast, not on an observation. This figure shows the same synthetic storm run two ways.
Synthetic tunnel and synthetic storm. The lesson is the shape of the trade: draw down too early on a forecast that busts and you have spent plant capacity and pumping energy on nothing; draw down too late and the storage is not there when the second cell arrives. FloodGrid gives the probability and the timing so the trade can be made deliberately — it does not issue the command, and the recommendation is always shown with the forecast confidence that produced it.
Bring your model schematic and one wet-weather event.
Give us a hydraulic model export, your meter list and a storm your team remembers well, and we will replay it — HGL, activations, station levels and all — against what your telemetry actually recorded.
A stage forecast becomes useful the moment it lands on something you own.
“Mill Creek will reach 9.6 feet” means something to a hydrologist and nothing to a maintenance supervisor. “Route 9 low crossing goes under at 05:10, the Ridgeview lift station access road follows twenty minutes later, and the elementary school stays dry” is the same forecast expressed as a decision. The translation between them is terrain, a drainage network, and your own asset layers.
Entirely synthetic geography, synthetic assets and synthetic depths. Nothing on this map corresponds to a real place. A production deployment runs on your terrain, your drainage network and your own asset register — and reports out-of-envelope cells rather than guessing at them.
The list a supervisor can act on without opening a GIS.
Crossings are ranked by time to threshold, not by depth, because time is what determines the order in which a limited number of crews can get anywhere. Each row carries the forecast, the confidence, and the threshold that was used — so the decision can be defended and, later, scored.
| Crossing | Status | Time to threshold | Forecast depth over deck | Confidence | Threshold basis |
|---|
Synthetic scenario. “Confidence” is the share of ensemble members crossing the threshold within the stated window, not a subjective rating. Rows update with the forecast valid time selected on the map above.
Your assets, not a generic layer
Pump and lift stations, treatment facilities, cabinets and control panels, manholes and regulators, critical customers, shelters and evacuation routes — loaded from your own register with your own identifiers, so an alert names the asset the way your work-order system names it.
Thresholds tied to real elevations
Deck elevations, low-chord clearances, panel and vent heights, door sills and access-road grades. A crossing threshold is a surveyed number, not an assumption — and where the elevation is unknown, the platform says the threshold is provisional rather than presenting it as certain.
Honest about what it cannot see
Blockage-driven flooding, surcharge from a collapsed line, breach behaviour at levees and floodwalls, and depths outside the trained hydraulic envelope are all outside scope and are reported as such. A model that never says “I don't know” has simply hidden the cases where it doesn't.
Hydraulic fidelity, at forecast speed.
Build the response surface offline
Your calibrated two-dimensional hydraulic model is run across a designed sweep of boundary stages, storm durations and antecedent conditions. This is the expensive step and it happens once, on a schedule — not on every forecast cycle.
Train the surrogate on those runs
A convolutional encoder–decoder learns to reproduce the simulated depth grids from terrain, the drainage network, and the boundary conditions. It is validated on held-out simulations and, where they exist, on surveyed high-water marks and documented closures from past events.
Evaluate it every cycle
At runtime the surrogate turns the current forecast stage into a depth grid in under a second, for every valid time in the horizon. That is what makes a live, forward-looking inundation view possible at all.
Intersect with the asset register
The depth grid is overlaid on crossings, facilities and parcels; exposure is computed against surveyed thresholds; and the resulting list is what feeds the alert payload and the operations view.
Refuse to extrapolate
Any cell whose boundary condition falls outside the trained sweep is returned as out-of-envelope. It appears on the map as an explicit hatched state, is counted in the exposure tiles, and is never rendered as a confident depth.
Why not just run the hydraulic model live?
Because a two-dimensional run over a meaningful area takes minutes to hours, and a forecast cycle is five minutes. Running it live would mean either a much coarser mesh, a much smaller area, or a forecast that is stale before it is delivered. The surrogate keeps the fidelity of the full model and pays for it in offline compute instead of in latency.
What if we don't have a 2-D model?
Many agencies do not. Deployment then starts from stage–depth relationships at instrumented sites plus terrain-based flood extent, which is a coarser product and is labelled as such. Building the hydraulic basis is a normal part of a phased rollout rather than a precondition for getting value.
Does the surrogate drift?
It drifts when the world changes — new construction, a rebuilt culvert, a revised terrain survey, a recalibrated hydraulic model. Each of those triggers a retrain. It does not drift on its own, because unlike the catchment-response model it is not learning from a moving observational record.
Put your crossings and assets on the map.
Send an asset register and a terrain surface and we will show you the exposure view for a storm you already remember — including which thresholds we could not establish from the data provided.
An alert that does not say what to do is just anxiety with a timestamp.
The hardest problem in flood notification is not detection. It is credibility. An organisation that has been paged forty times for a storm that produced nothing will not answer on the night it matters. Everything in this layer — deduplication, escalation, quiet hours, acknowledgement, the published false-alarm ratio — exists to protect the one thing that actually saves property: whether people still believe the alert.
Specific
Names the site, the asset, the road segment, the forecast depth and the time. Not “flooding possible in your area”.
Timed
States the lead time remaining and the confidence, so the recipient can tell a prepare from a commit.
Deduplicated
One storm, one thread. Updates amend the existing incident instead of starting a new page every cycle.
Accountable
Delivery, acknowledgement and every override are recorded, exportable and admissible in an after-action review.
Write the rule in the language of the decision.
Thresholds are authored as explicit, versioned conditions on quantities an engineer can defend — not as a sensitivity dial. Change the rule below and watch the message that would be delivered change with it.
Trigger definition
Rules are versioned. Editing one records the change, the author and the reason, and the previous version stays retrievable — so a review can establish what rule was in force on the night in question.
Illustrative rendering of an SMS or push payload. The same incident is delivered simultaneously as an email digest, a webhook payload and, where configured, a CAP 1.2 message — all carrying the same incident identifier so downstream systems can thread them.
The right person, at the right hour, on the channel they will actually answer.
Escalation is configured per site and per level, because the person who needs to know that a detention basin is filling is not the person who needs to know that a crossing is about to overtop. Quiet hours apply to advisory levels and never to emergency ones.
Nothing is sent. The record is still kept.
Conditions are logged continuously whether or not anything crosses. When an event is reviewed six months later, the quiet hours before it are part of the record too.
Duty officer, one message, no siren.
Sent to the on-call duty officer and the operations channel. Subject to quiet hours: between configured hours this becomes a queued digest rather than a page, unless it escalates.
Paged, and chased until acknowledged.
Primary on-call is paged immediately. If no acknowledgement arrives inside the configured window, the alert escalates to the secondary, then to the supervisor. Quiet hours do not apply.
Everyone on the list, simultaneously, no suppression.
Fan-out to the full notification group with no deduplication delay and no quiet-hour handling. CAP output is emitted for downstream public-alerting systems. Suppression is disabled at this level by design — an operator can annotate, but cannot silence.
Every false alarm spends credibility you cannot buy back.
A threshold is a trade. Lower it and you catch more events and cry wolf more often; raise it and every alert is real but some floods arrive unannounced. There is no setting that avoids the trade — there is only choosing it deliberately, with the numbers in front of you, rather than by accident. Move the threshold below and watch both sides move.
Synthetic five-year record for one site. Notice that lead time falls as the threshold rises — the certainty you gain by waiting is paid for in the time your crews lose. The right setting is not a technical answer; it depends on what the action costs and what the miss costs, which is a conversation FloodGrid structures rather than one it makes for you.
One incident per storm per site. Subsequent cycles amend the open incident — raising or lowering its level, updating the forecast — instead of paging again. Recipients see a thread, not a flood of messages.
Alerts clear on a lower threshold than they set on. Without hysteresis a forecast hovering on the boundary produces a set-clear-set-clear cycle that is worse than no alert at all.
A crossing must persist for a configured number of cycles. One noisy cycle does not page anyone. This is the single most effective false-alarm control available, and it costs only the sustain window in lead time.
Configurable per level, never applied to emergency. Advisory traffic queues into a digest overnight; life-safety traffic never does, and the interface makes that distinction impossible to misconfigure by accident.
On-call schedules, handovers and escalation chains are first-class. The alert goes to whoever is actually on duty at that minute, with automatic escalation when acknowledgement does not arrive.
During a declared event the posture changes. Sustain windows shorten, digests are suspended, and everything routes live — because the cost of a delayed alert during an active storm is not the same as it is on a quiet Tuesday.
Six months later, someone will ask what you knew and when.
Every incident carries a complete, timestamped, immutable chain: the inputs that were available, the forecast that was produced, the model version that produced it, the rule that fired, the messages that were sent, who acknowledged and when, every override with its stated reason, and what was observed afterwards. It exports whole, in machine-readable form, without a support ticket.
MC9-WATCH-v4 · model catch-lstm 2026.07.2 · sent to duty officer via SMS + TeamsIllustrative record for a synthetic event. The details are invented; the structure is not. Every field shown here is captured on real incidents, including the ones where the forecast was wrong — especially those, because an error record that only contains successes is not a record.
Bring your current thresholds. We will show you what they would have done.
A hindcast over your last three years scores your existing triggers against what actually happened — hits, misses, false alarms and lead time — before a single new alert is configured.
A forecast only counts once somebody has done something with it.
Utilities do not lack weather information. What they lack is a defensible link between a forecast and an action: who declares storm mode, at what threshold, which crews go where, what the plant does with its wet-weather train, and what the record shows six months later when the after-action review asks why a decision was taken at 02:40 rather than at 05:00. This section is about that link.
An illustrative structure, not your playbook. Every utility's version of this differs, and the version that matters is the one your own staff wrote and will follow. What FloodGrid contributes is the trigger: each cell is bound to a forecast condition, so the band advances on evidence rather than on somebody's read of a radar loop — and every advance is timestamped into the event record.
Limited crews, ordered by the clock rather than by the phone.
During an event, dispatch order is usually set by whoever calls in first. Forecast exposure lets it be set by which asset runs out of time first — and it makes the trade explicit when there are six priorities and four crews.
Synthetic tasks and synthetic travel times. The point of showing the unreachable tasks is that the shortfall is a decision, and somebody should make it knowingly — call in overtime, request mutual aid, or accept that one crossing gets barricaded late. A scheduler that quietly drops the tasks it cannot fit is worse than no scheduler.
How old is the information you are deciding on?
Every input arrives on its own clock. A radar sweep is minutes old; a model run can be over an hour old before it reaches you; a rain gauge polled on a fifteen-minute schedule may have been read fourteen minutes ago. None of that is a defect — but a decision made at 02:40 is not made on the state of the world at 02:40, and an operations team should be able to see the difference rather than assume it away.
Illustrative ranges for common public and utility data sources; your own telemetry latency depends on your SCADA polling and comms. Each figure in the FloodGrid interface carries the age of the data behind it, and any input older than its configured staleness limit degrades the product that uses it rather than being silently carried forward.
A forecast is only as good as the sensors still telling the truth.
Rain gauges block. Level transducers foul and drift. Radios drop out on exactly the night the storm is worst. The anomaly detector described in the AI section runs on every reading; this board is where its verdicts become somebody's work order.
Synthetic fleet. Every state change writes a record with the reason, and quarantines above a configured rate raise a maintenance ticket rather than sitting in a dashboard nobody opens. The important property is that a quarantined sensor degrades the confidence of the products that depended on it and says so, instead of being dropped silently and leaving the forecast looking as certain as it did yesterday.
The threshold is an economic choice wearing a technical costume.
Where to set an alert threshold is not a hydrology question. It is a question about what the action costs, what the miss costs, and how often each occurs — and it has a defensible answer only when those three numbers are written down. FloodGrid structures that conversation; it does not have opinions about your budget.
Synthetic. Move either slider and watch the optimum move. When a miss costs twenty times an unnecessary callout, the defensible threshold is far lower than instinct suggests — and that is an argument you can take to a budget meeting, not just to a hydrologist.
What belongs in “cost of acting”
Crew callout and overtime, equipment mobilisation, pumping and energy for a pre-drawdown, the operational risk of moving assets, and the credibility spent on a public message that turns out to be unnecessary.
What belongs in “cost of a miss”
Basement backup claims and cleanup, road closure and detour costs, emergency repairs at premium rates, regulatory exposure where an overflow was avoidable, and the much larger and less measurable cost to public trust.
What this deliberately does not do
It does not monetise life safety, and it does not set your threshold. Where life safety is on the table, the expected-cost framing stops being the right tool and the threshold becomes a policy decision made by people with the authority to make it.
Why it is on the page at all
Because “what should the threshold be?” is the first question every operations team asks, and answering it with a shrug and a default value is how alerting systems end up ignored.
The record writes itself, because nobody writes it at 4 a.m.
Handover notes and after-action reports are the first casualty of a long night. FloodGrid assembles the factual spine automatically — what was forecast, what was observed, what fired, who acknowledged, what was overridden and why — so the human contribution is judgement rather than transcription.
Shift handover packet
Current state of every monitored site, open incidents and their acknowledgement status, what the next twelve hours are forecast to do, and the actions the outgoing shift started but did not finish.
Event chronology
One timestamped sequence covering rainfall, system response, thresholds crossed, notifications sent, acknowledgements, overrides and observed outcomes — exportable whole, in machine-readable form.
After-action scoring
Forecast against observation at every site, lead time actually delivered, misses and false alarms, and the specific threshold or model behaviour that produced each one — assembled before the review meeting rather than during it.
Duty officer, pumping supervisor, collections supervisor, plant operator, GIS, communications and emergency management see different default views of the same record. The underlying data is one set of facts; what differs is which forty of the two hundred sites are on the first screen.
Past events replay at full fidelity. A new duty officer can run last September's storm from the beginning, see what the forecast said at each cycle, and make the calls before finding out what actually happened — which is the only realistic way to build judgement about a system that produces a real test four times a year.
The record survives staff turnover. Institutional knowledge about which crossing floods first and which basin responds fastest currently lives in the heads of people who are retiring. Structured event history is the only version of that knowledge which stays after they leave.
Start from the storm that went badly.
The most useful onboarding session is a walkthrough of an event your team still talks about — what was known when, what was decided, and where an earlier signal would actually have changed the outcome.
Do not take our word for it. Read the record.
Every forecast FloodGrid issues is stored with the time it was issued and the model version that produced it. When the observation arrives, the two are matched automatically. Nothing is re-scored after the fact, nothing is quietly dropped for being an outlier, and the resulting numbers are visible to you continuously — not assembled for a renewal meeting. This page is the part of the product we would want to see first if we were buying it.
Both panels are synthetic demonstrations of the format, not achieved results. A reliability curve below the diagonal means the forecast is over-confident — when it says 70% it should be right about 70% of the time, and if it is right 45% of the time that is a defect to be corrected, not a presentation to be reframed. Baselines are shown deliberately: a flood model that cannot beat persistence at three hours and climatology at three days has not demonstrated anything, and any vendor unwilling to show those two lines should be asked why.
Named, defined, and computed the same way every time.
Flood verification is full of numbers that sound similar and mean different things. These are the definitions FloodGrid uses, stated once so that a score can be compared across sites, seasons and vendors without a translation step.
| Metric | Definition | What it is good for | How it misleads |
|---|---|---|---|
| POD Probability of detection | Hits ÷ (hits + misses) | The share of real events you were told about. The number a public-safety audience cares about most. | Trivially driven to 1.0 by alerting constantly. Meaningless without FAR beside it. |
| FAR False alarm ratio | False alarms ÷ (hits + false alarms) | The share of alerts that were wrong. The number that predicts whether people keep answering. | Trivially driven to 0 by never alerting. Meaningless without POD beside it. |
| CSI Critical success index | Hits ÷ (hits + misses + false alarms) | Combines both sides into one number. Ignores correct quiet periods, which is appropriate for rare events. | Hides the trade-off it summarises. Two very different operating points can share a CSI. |
| Lead time Median, on hits | Time from first qualifying alert to observed threshold crossing | The only metric that maps directly onto what a crew can actually do. | Computed on hits alone, so a system that misses hard events can post a flattering lead time. |
| Peak timing error | Forecast crest time minus observed crest time | Reveals systematic early or late bias that mean error conceals entirely. | Undefined for events with a flat or multi-peaked crest; reported with the crest shape noted. |
| Peak magnitude error | Forecast crest stage minus observed crest stage | What matters for depth, exposure and closure decisions. | Small absolute errors can be large relative errors on shallow, flashy sites. |
| Brier skill score | Brier score against a climatology reference | Scores the probability itself, not just the yes/no decision derived from it. | Dominated by the many quiet periods unless events are stratified out. |
| Reliability | Observed frequency within each forecast-probability bin | Tests whether a stated probability means what it says. Directly checks over-confidence. | Needs a large sample per bin; thin bins produce noisy curves that invite over-reading. |
Including the ones we got wrong.
Every event above a configured significance is scored individually and kept. Misses and false alarms are shown at the same size and in the same list as hits, because a record that surfaces only successes tells you nothing about what will happen on the night that matters.
Synthetic composite. Seasonal structure like this is normal and worth stating plainly: summer convection is harder to forecast than a winter frontal passage, so error grows and lead time shrinks. Thresholds and staffing postures should differ by season for exactly this reason, and FloodGrid reports the seasonal breakdown rather than a single annual average that conceals it.
Overflows are scored the same way everything else is.
For a combined system, the forecast that gets reported to a regulator is the one about outfall activation and volume — so it is verified against the telemetry with the same discipline as stage. Every activation, and every non-activation, ends up on this chart.
Synthetic record. Volume error matters less than activation skill: a utility can live with a volume estimate that is thirty percent high, and cannot live with an activation nobody saw coming. That is why the two axes carry the misses and false alarms as explicit shapes rather than dropping them for being un-plottable.
What counts as an activation
Telemetry at the regulator, where it exists — a level crossing the weir with a duration filter to reject spikes. Where an outfall is not instrumented, activation is inferred from the hydraulic model and is labelled inferred, never presented as measured.
Why non-activations are scored too
Because a system that forecasts activation on every storm would score perfectly on hits and be useless. The false-alarm column is the one that determines whether anybody pre-positions anything.
What goes to the regulator
The observed record, with the forecast kept alongside it. Whether and how the forecast is referenced in a regulatory submission is the utility's decision and its counsel's — FloodGrid produces the evidence, not the filing.
Your record stays empty until your catchments are on the grid.
Every figure on this page is a synthetic demonstration of a format. The only verification numbers worth anything to your agency are the ones computed on your basins, your sensors and your thresholds — and those do not exist until FloodGrid has run through a season with you. We will not show you someone else's scores and imply they are yours.
The equations, the solver, and the numbers we can be held to.
This page is the technical appendix, published rather than promised. It states the governing equations FloodGrid solves, the scheme it solves them with, the tolerances it holds itself to, how the models are trained and split, what the system is measured against, and where it is known to be weak. None of it is behind a signature.
There is a reason to put this in public. A flood-warning system is bought on trust and used at three in the morning, and the only durable basis for that trust is a specification precise enough to be argued with. Marketing claims cannot be falsified. A stated Courant cap, a named friction formulation, a published train–test protocol and a reproducibility guarantee all can — which is exactly why they are worth writing down.
Symbols, once, so nothing below is ambiguous.
Hydraulics and machine learning both reuse the same two dozen letters for different things. This is the dictionary the rest of the page is written in. Internal computation is in SI; presentation is in US customary units, and the conversion happens in exactly one place.
| Symbol | Quantity | Unit |
|---|---|---|
| A | Flow area of the wetted cross-section | ft² |
| Q | Discharge | ft³/s |
| h | Water-surface elevation (hydraulic head) | ft |
| V | Section-mean velocity, Q/A | ft/s |
| R | Hydraulic radius, A/P | ft |
| T | Top width — free surface, or the slot when full | ft |
| S0 | Bed slope | ft/ft |
| Sf | Friction slope | ft/ft |
| n | Manning roughness coefficient | s/ft1/3 |
| qL | Lateral inflow per unit length | ft³/s per ft |
| a | Pressure-wave celerity in the Preissmann slot | ft/s |
| c | Surface-wave celerity, √(gA/T) | ft/s |
| g | Gravitational acceleration | 32.174 ft/s² |
| Δx, Δt | Spatial and temporal discretisation step | ft, s |
| C | Courant number | — |
| Symbol | Quantity | Unit |
|---|---|---|
| i(t) | Rainfall intensity | in/h |
| F | Cumulative infiltration | in |
| Ks | Saturated hydraulic conductivity | in/h |
| ψ | Wetting-front suction head | in |
| Δθ | Soil-moisture deficit | ft³/ft³ |
| Rk | RTK capture fraction, k-th reservoir | — |
| Cw, Cd | Weir and orifice discharge coefficients | — |
| Z | Radar reflectivity factor | mm⁶/m³ |
| Kdp | Specific differential phase | °/km |
| xf, xa | Forecast and analysis state vector | mixed |
| P | State error covariance | mixed |
| K | Kalman gain | — |
| σ | Standard deviation of a forecast distribution | ft |
| p | Forecast probability of exceedance | — |
| C/L | Cost-to-loss ratio for an action | — |
Twenty-two equations, and what each one commits us to.
Every equation below is standard. That is the point: none of this is a secret, and a vendor claiming a proprietary alternative to conservation of momentum should be asked to write it down. What separates one implementation from another is which terms are kept, which are dropped for speed, and whether the dropped ones are disclosed. Ours are, in the note under each.
A · Conveyance and pressurisation
What the water in a pipe or a channel is obliged to do. FloodGrid solves these; it does not learn them. A network model that cannot conserve mass has no business issuing a warning.
where A is flow area, Q discharge and qL lateral inflow per unit length.
Water that enters a reach and does not leave it raises the surface. Every solver claims this; the test is the reported continuity error at the end of a run, which is on the specification sheet below.
h is water-surface elevation, Sf friction slope, S0 bed slope.
The full dynamic form, kept rather than simplified. Kinematic and diffusive approximations drop the first two terms and with them backwater, surcharge propagation and flow reversal — which is to say, the three things a combined system does during the storm you care about.
k = 1.486 ft1/3/s in US customary units, 1.0 in SI; R = A/P.
The Q|Q| product, not Q2: it keeps the sign of the resistance correct when flow reverses, which it does upstream of a surcharged junction. Manning’s n is the one honestly empirical term in this group and it absorbs structural error, so it is reported as a calibrated parameter with its range, never as a measured property.
Af is the full-pipe area; c the wave celerity used in the step limit below.
A pipe running full is no longer a free-surface problem, and switching governing equations mid-storm is where models fall over. The slot keeps one set of equations by adding a notional gap of width Ts above the crown, sized so the free-surface celerity equals the pressure-wave celerity a. For a 5-foot pipe at a = 150 ft/s the slot is about a third of an inch wide — narrow enough not to store meaningful volume, wide enough to keep the solve stable.
Δx is the reach length, Δt the time step.
The Courant number: how far information travels in one step, in cells. An explicit scheme diverges above 1. The implicit box scheme FloodGrid uses is stable well beyond it but not accurate beyond it, so the cap is set on accuracy grounds and stated. The figure below computes the difference rather than asserting it.
B · Loading — how rain becomes flow
The largest single source of error in a collection-system forecast is not the hydraulics. It is how much of the rain arrives in the pipe, and when.
Ks saturated conductivity, ψ wetting-front suction, F cumulative infiltration.
Physically based rather than a curve number, because the antecedent term Δθ is a state the system can actually carry forward between storms. Two identical rainfalls a week apart do not produce identical runoff, and a model with no soil-moisture state cannot express that.
i(τ) is rainfall intensity; uk the unit response of reservoir k.
The RTK formulation: three linear reservoirs standing for the fast, medium and slow paths by which rain reaches a sanitary pipe it was never meant to enter. ∑Rk is the capture coefficient — the fraction of rain on the sewershed that ends up in the sewer — and on an old system it is the number that decides whether the interceptor surcharges.
ds is depression storage, i rainfall intensity, f infiltration.
How a subcatchment sheds water in SWMM: each subarea is a reservoir that ponds to its depression storage and then drains over a Manning surface. The exponent is what makes it nonlinear, and it is why a parking lot responds in nine minutes and the lawn beside it takes forty. The width W is a shape parameter, not a survey measurement — it stands for the length of the overland flow path, and it is one of the two or three numbers a calibration actually moves.
Γ is the gamma function; time to peak is (k−1)β.
A two-parameter gamma kernel, so the shape parameter k and the scale β separate how quickly a basin responds from how long it takes to drain. Both are fitted per sewershed from observed flow monitoring, and both are shown to you with their confidence, not buried.
t is cumulative wet time; f0 and f∞ the initial and final capacities.
The other infiltration option, and the one most legacy models are calibrated in. Its antecedent memory is short — at a decay constant of 4/hr the capacity is at its floor within twenty minutes — so a wet catchment is represented by a reduced parameter set, not by the equation remembering last week. Where the antecedent state genuinely drives the answer, Green–Ampt with an explicit moisture deficit or the groundwater module is the honest choice, and the figure on the runoff page shows the difference between them on the same storm.
C · Hydraulic structures
Regulators, weirs, gates and pumps are where a collection system's behaviour is decided, and where a model that treats them as generic nodes stops being useful.
L weir length, H head over crest, Ao orifice area, Δh head difference.
Two different exponents, which is why substituting one for the other quietly ruins a diversion forecast. A regulator is usually both — orifice at low head, weir once it drowns out — and the transition is where CSO activation actually begins.
Hu, Hd are upstream and downstream heads on the crest.
When the receiving water rises, the weir stops behaving like a weir. Ignore this term and a model will happily forecast a diversion into a river that is already higher than the weir crest — a failure mode that appears exactly during the events you built the system for.
Aw wet-well plan area, Qp(h) the pump curve against system head.
A wet well integrates. That single fact is why a station can be comfortably inside its firm capacity for an hour and then flood the street: level is the running integral of the imbalance, not a function of the current inflow. Every pump figure on this site is driven by this equation rather than by a drawn curve.
D · Surface water
Once water leaves the system it is a two-dimensional problem, and the thing being forecast changes from a flow rate to a depth at an address.
h depth, (u,v) depth-averaged velocity, z bed elevation, τ bed shear.
Solved with an HLLC flux and a second-order limited reconstruction, because a first-order scheme smears the wet–dry front and a naive second-order one oscillates at it. The inundation surrogate described in the AI & ML section is trained on the output of this solver, not on the observations directly — the physics generates the labels.
E · Observation, bias and assimilation
The measurement is not the truth either. Radar estimates rainfall indirectly, gauges measure one point exactly, and the two disagree; the arithmetic of reconciling them is stated here rather than described as proprietary.
Z in mm6/m3, R in mm/h, Kdp in degrees per kilometre.
A power law with regime-dependent coefficients — roughly a=300, b=1.4 in convection and a=200, b=1.6 in stratiform rain. Choosing the wrong pair can be a factor-of-two error in rate, so the regime is classified per scan rather than fixed, and where dual-polarisation is available the Kdp estimator is preferred in heavy rain because it is nearly immune to attenuation and partial beam blockage.
Gi, Ri are paired gauge and radar accumulations in window W.
A mean-field bias over a moving window, applied multiplicatively to the radar field, with the window long enough to be stable and short enough to track the storm. The adjustment is logged with every QPE grid: if a single mis-sited gauge is dragging the whole field, that has to be visible after the fact, not inferred.
xf forecast state, y observation, H the observation operator.
The analysis is the forecast plus a fraction of its disagreement with the observation. That fraction — the gain — is set by the ratio of model to sensor uncertainty, so a noisy sensor moves the state less than a trusted one, automatically, without anyone editing a config. The gain is capped so that one failed sensor cannot drag a whole reach.
Pxy, Pyy are ensemble covariances; R the observation-error covariance.
Computed from the spread of the ensemble rather than from a fixed matrix, which is what lets the correction propagate to unobserved parts of the network: if the ensemble says two manholes rise together, an observation at one moves the estimate at the other. The normalised innovation is monitored; when it drifts from unity, one of the two uncertainties is mis-specified and it is a defect, not noise.
F · Scoring and the decision
A probabilistic forecast has to be scored as a probability. These are the losses the models are trained on and the scores the record is kept in — deliberately the same ones, so that nothing is optimised for one number and reported in another.
F is the forecast CDF, y the observation, 1{·} the indicator function.
The distributional analogue of absolute error: it collapses to exactly mean absolute error when the forecast is a single value, so a probabilistic system and a deterministic one can be compared on one axis without a translation step. Lower is better; it is reported in feet, which is a unit an operator can argue with.
τ is the target quantile; nine are fitted, from 0.05 to 0.95.
Deliberately asymmetric, and that asymmetry is the point: for a flood forecast, under-predicting a crest is not the same kind of mistake as over-predicting one. The upper quantiles are weighted more heavily in training, and the weighting is published rather than tuned quietly.
pi the issued probability, oi the outcome, 0 or 1.
Skill is meaningless without the reference, so the reference is always named: climatology at long lead, persistence at short lead. A system that cannot beat “the river will be where it is now” at three hours has demonstrated nothing, and any vendor unwilling to plot that line should be asked why.
p is the forecast exceedance probability for the threshold in question.
The cost–loss rule. If acting costs C and being caught out costs L, the expense-minimising threshold is their ratio — which means the threshold is a policy decision about your costs, not a model output. FloodGrid computes p. The utility sets C/L, in writing, with the consequences of each choice shown before it is committed.
What is deliberately absent. There is no equation here for the alert decision, because there is not one: the threshold is a policy the utility writes, evaluated against the probability the models produce. There is also no term for sediment transport, water quality or structural scour — FloodGrid does not model them and does not imply that it does. A specification is as much a list of what a system declines to claim as of what it computes.
A discretisation is a modelling choice. Here is ours, and what it costs.
Two vendors can solve the same equations and disagree by a foot, because the answer depends on the step sizes and the scheme as much as on the physics. The figure below is not an illustration of that idea — it integrates the advection equation in your browser, with the step sizes you choose, and draws what comes out. Move the time step and watch a crest lose its peak, drift late, or diverge outright.
Read the peak-retained number, not the picture. Three results here are worth more than any claim on the rest of this site, because you can reproduce all three. One: the implicit box scheme is unconditionally stable and, at a coarse time step, quietly returns a crest at half its true height — nothing looks wrong, which is what makes it the dangerous failure. Two: drop θ to 0.5 and the damping disappears entirely, but the error has not gone anywhere — it reappears as ringing, and the scheme invents negative water ahead of the crest. Three: the explicit scheme is at its most accurate exactly at C = 1, where its numerical diffusion vanishes, and diverges immediately above it. An optimum that sharp is unusable in production, which is the entire reason operational models are implicit and the entire reason FloodGrid caps the Courant number on accuracy rather than stability.
Conduit network solver
One-dimensional, full dynamic wave, applied to the pipe and channel network.
Two-dimensional surface solver
Runs offline to generate inundation training data; runs online only when the surrogate declines.
The model is wrong, the sensor is wrong, and the arithmetic for combining them is not a secret.
A forecast that ignores the level sensor is a simulation. A forecast that simply adopts the level sensor is a chart recorder. What FloodGrid does between those two is one line of algebra — equation KF above — and the only thing that matters is where the gain comes from. Drag the sensor uncertainty and watch the correction change size.
The gain is the whole argument. Set the sensor uncertainty low and the analysis snaps onto the observation, which feels responsive and will chase every spike a fouled sensor produces. Set it high and the model ignores real information. Neither number is a preference: both are estimated from the residual record and audited, and the normalised innovation is the audit — if it persistently exceeds one, the stated uncertainties are too small and the system is over-confident, which is a defect with a ticket, not a tuning taste. The gain is also capped per sensor, so a single transducer that fails high cannot drag an entire reach with it.
Where the error comes from, by lead time — and which parts we could ever fix.
Total error is the least useful number in forecasting, because it hides which term is responsible. Decompose it and the strategy becomes obvious: at short lead the state estimate dominates and better sensors pay; past twelve hours the rainfall forecast dominates and no amount of hydraulic refinement will help. Switch a source off below to see the ceiling it imposes.
Synthetic magnitudes, real structure. The shapes are what matter and they are not arbitrary: initial-state error peaks a few hours out because that is how long the basin remembers where it started, and rainfall error grows superlinearly because a forecast rainfall field decorrelates faster than it accumulates. The honest consequence is on the counterfactual chips. Perfect sensors barely move the 24-hour curve; a perfect rainfall forecast nearly flattens it. Anyone selling a 48-hour street-level flood forecast is, whether they say so or not, selling you a rainfall forecast — and should be asked to show its verification, not the hydraulic model’s.
Why the surrogate exists, arithmetically rather than rhetorically.
A two-dimensional hydraulic solve is not slow because the code is bad. It is slow because halving the cell size quadruples the cells and doubles the number of steps the stability condition allows — so cost grows roughly with the three-halves power of the cell count while a forward pass through a trained surrogate grows linearly. That single exponent is the entire reason street-level inundation can be produced inside a five-minute cycle. Move the resolution and read the numbers.
Indicative scaling, not a benchmark. The constants depend on hardware nobody should take on trust from a web page; the exponents are properties of the algorithms and do not. The honest reading is the uncomfortable one: the surrogate is not more accurate than the solver — it is an approximation of it, and it is used because an exact answer that arrives after the water does is worth nothing. That trade is stated on every inundation product, the surrogate is scored against the solver it was trained on, and where a storm falls outside its training envelope the system says so and falls back rather than extrapolating quietly.
Offline: generating the training set
The surrogate learns from the physics solver, not from observations. This is what standing that data up costs.
Online: the five-minute cycle
What the wall clock is spent on between a radar sweep landing and a phone ringing.
Which uncertain input actually moves the answer.
Calibration effort is finite, so it should go where the derivative is largest. This is a one-at-a-time screening: each input is perturbed across its plausible range with everything else held at its central value, and the effect on the chosen response is plotted. The result reorders most people’s intuition — roughness gets argued about in meetings, and rainfall dominates it by a factor of four.
One-at-a-time screening has a known blind spot, so here it is. Varying inputs individually cannot see interactions, and in a collection system the interactions are real — tailwater and pump capacity matter enormously together and hardly at all apart. Screening is the cheap first pass used to decide what to instrument; a variance-based decomposition over the joint distribution is what actually gets run before a calibration is signed off, and it is reported with its sample size and convergence. A vendor that shows you a tornado chart and calls it a sensitivity analysis has done the first ten percent of the work.
How the models are split, fitted and calibrated — the part that decides whether a score means anything.
Almost every implausible accuracy claim in this field traces back to the same two mistakes: a random train–test split on autocorrelated data, and features computed from information that was not available when the forecast would have been issued. Both inflate scores enormously and neither is visible in the result. The protocol below exists to make them impossible rather than unlikely.
Splitting
The single most common way to produce a number that will not survive contact with a storm.
Point-in-time correctness
A feature the model could not have had is a feature the model does not get.
Fitting
Stated so the numbers below can be reproduced rather than admired.
Calibration and coverage
A probability that does not mean what it says is worse than no probability.
Timing targets, stated as objectives with a measurement method attached.
A latency number without a definition of where the clock starts and stops is decoration. Each objective below names both ends of the interval and how it is instrumented. The right-hand column stays empty until FloodGrid is running on your infrastructure, because the only measured values worth quoting to you are your own.
| Objective | Target | Clock starts / stops | Your measured value |
|---|---|---|---|
| Radar frame to QPE grid | ≤ 45 s | Volume-scan completion timestamp → adjusted grid written | — |
| QPE to forecast issued | ≤ 90 s | Grid written → ensemble forecast committed with its version hash | — |
| Forecast to alert decision | ≤ 5 s | Forecast committed → rule evaluation returns | — |
| Decision to first channel dispatched | ≤ 15 s | Decision recorded → first provider accepts the message | — |
| End to end — sweep to phone | ≤ 3 min | Volume-scan completion → carrier acceptance of the first notification | — |
| Cycle cadence | 5 min | Alarm on two consecutive missed cycles; degradation posture on three | — |
| API read latency | p95 ≤ 250 ms | Request received at the edge → last byte sent | — |
| Availability, alerting path | 99.9% / month | Synthetic end-to-end probe every 60 s from three regions | — |
| Recovery point / recovery time | RPO 5 min · RTO 30 min | Measured by scheduled failover exercise, not by assertion | — |
| Forecast retention | 7 years | Every issued forecast, with inputs and model hash | — |
An error budget is a policy, not a statistic. Publishing 99.9% means committing to stop shipping when the budget is three-quarters spent — which is the part that is actually hard, and the part worth asking about. It also means being explicit that the alerting path and the analytics path have different budgets: a dashboard that is slow during a storm is an annoyance, and a notification that does not go out is the whole product failing.
Degradation, in order
Each step is automatic, announced on the product, and logged. Nothing silently substitutes a worse input for a better one.
1 — Radar unavailable
Fall back to gauge-interpolated rainfall, widen the intervals, mark every affected product as degraded.
2 — Telemetry partially lost
Assimilation proceeds on the remaining sensors with an inflated state covariance. Reaches with no observation are labelled model-only.
3 — Surrogate out of envelope
Inundation reverts to the physics solver at reduced resolution, or is withheld with a reason if the cycle cannot carry it.
4 — Forecast pipeline down
Threshold alerting continues directly from live telemetry. Lead time collapses to zero and the product says so in those words.
5 — Everything down
The on-call number in your runbook, and a documented manual procedure that does not require this product to work.
Any forecast we ever issued, re-run bit for bit.
After an event there is a meeting, and in that meeting somebody asks what the system was saying at 02:40 and why. The only satisfactory answer is the forecast itself, its inputs, and the exact code that produced it — not a reconstruction, not a screenshot, and not a re-run against today’s model that quietly gives a different answer. Every issued forecast is stored as a manifest of content hashes, and re-running it is a single command.
Three things this makes possible, and one it makes impossible. It supports an honest after-action review, an audit that does not depend on trusting us, and a regression test that replays a real historical storm against a candidate model before it ships. What it makes impossible is quietly improving a past score — the manifest is written when the forecast is issued, the match is automatic when the observation lands, and a scored event is never reopened. If you want the number to be better next time, the only available route is a better forecast.
Twelve questions to put to every flood-forecasting vendor. Including us.
These are not gotchas. Each one is answerable in a sentence by anyone who has actually built the thing, and each one is close to unanswerable by a system assembled out of a dashboard and a rainfall API. We publish them because a market where these questions get asked is a market we would rather compete in — and because a specification you can hold us to is worth more than a claim you cannot.
| Ask | Why it separates the field | What a weak answer sounds like | Ours |
|---|---|---|---|
| Show the reliability diagram for your probabilities. | Anyone can emit a number between 0 and 1. Only a calibrated system can show that 70% means 70%. | “Our model is 95% accurate.” | Verification |
| Plot your skill against persistence and climatology, at every lead time. | Skill without a baseline is not skill. Most flood models lose to persistence inside two hours. | “We benchmark internally against our earlier models.” | Verification |
| Show me the misses. | The distribution of failures is the product. A record with no misses has been curated. | “Here are three case studies.” | Event scorecards |
| How is the train–test split constructed? | A random split on autocorrelated hydrology inflates every score, invisibly and enormously. | “Standard 80/20 split.” | Splitting |
| Prove no feature used information unavailable at issue time. | Latency leakage is the second-largest source of unearned accuracy, and it never shows up in a chart. | “We use the historical archive.” | Point-in-time correctness |
| Where does the model decline to answer? | Every model has an envelope. The ones that never say so extrapolate silently on the night it matters. | “It works everywhere.” | Out of distribution |
| Which decision is learned, and which is a rule? | An alerting threshold is a policy about the utility’s costs. A model cannot own it and no regulator will accept that it does. | “The AI decides when to alert.” | The rule composer |
| What is the end-to-end latency, sweep to phone, and where does the clock start? | Undefined endpoints are how a 3-minute claim becomes 11 minutes in practice. | “Real-time.” | Service objectives |
| Reproduce a forecast from fourteen months ago, bit for bit. | If it cannot be replayed, no after-action review is possible and no audit means anything. | “We can re-run it with the current model.” | Forecast manifest |
| What happens when the radar feed dies mid-storm? | The degradation path is where systems either announce their limits or quietly invent numbers. | “We have redundancy.” | Degradation, in order |
| What is the cost model behind the threshold, and who owns it? | Every threshold implies a cost–loss ratio. If nobody wrote it down, somebody chose it by accident. | “Industry-standard thresholds.” | Decision economics |
| What happens to our data at the end of the contract? | Exit terms reveal how a vendor thinks about the relationship more reliably than any reference call. | “We’ll work with you on that.” | Data ownership |
Every assumption above, and where it bites.
A model is a set of assumptions with a user interface attached. These are ours, kept as a live register rather than a disclaimer, because an assumption you know about is a risk you can manage and an assumption you inherit silently is the one that ends up in the after-action report.
| Assumption | Where it stops holding | What we do about it |
|---|---|---|
| Design rainfall statistics are stationary | Where the local record shows the intensity distribution shifting, a “10-year” storm is not a 10-year storm any more. | The atlas edition is named on every figure that uses it, and the observed record is plotted against it so the drift is visible rather than assumed away. |
| One-dimensional flow in conduits | Complex junctions, hydraulic jumps, and any structure where the flow is genuinely three-dimensional. | Loss coefficients calibrated to observation at those structures, and the structures flagged in the model as approximations rather than resolved geometry. |
| The DEM resolves what matters | Curb inlets, gratings, driveway crowns and small walls all sit below a 1 m grid and all redirect real water. | Inlet capacity curves per structure from the asset layer; sub-grid features surveyed where a repeat complaint says they matter. |
| The network is as-built and unblocked | Debris, sediment, a collapsed lateral, a contractor’s plug nobody recorded. | Blockage is offered as a scenario, never a forecast. Persistent model–observation residuals at one structure raise an inspection, which is often how a blockage is found. |
| Radar rainfall is accurate over the basin | Far range, beam blockage, bright band, hail contamination, and the last mile before the storm reaches the gauge network. | Regime-dependent Z–R, dual-polarisation estimators in heavy rain, mean-field bias against gauges, and the adjustment logged with every grid. |
| The surrogate generalises | Any storm outside the envelope its training set was sampled from — which includes the record-breaking one. | An explicit envelope check per cycle, fallback to the physics solver, and a labelled product rather than a silent extrapolation. |
| Manning’s n is a roughness | In practice it is a lumped calibration parameter that absorbs every structural error in the reach. | Reported as a calibrated parameter with its range and its fitting record, and never used to explain away a residual that has a physical cause. |
| Sensors are telling the truth | Drift, fouling, ice, a stilling well silted to the transducer, a datum shifted by a maintenance visit nobody logged. | Automatic fault screening, per-sensor gain caps in assimilation, and a health surface on the operations page rather than a hidden filter. |
| There is enough data to learn from | Three years of record on a small flashy basin may contain four qualifying events. That is not a regularisation problem. | Physics carries the extrapolation and machine learning corrects within it; scores are reported with their event counts, and a thin record is stated as a thin record. |
| People will act on the alert | The failure mode is social, not technical: a system that cries wolf is switched off inside a season, and then the lead time is irrelevant. | Alert fatigue is treated as a first-class metric, thresholds carry an explicit cost–loss rationale, and the quiet-hours and escalation policy is the utility’s to write. |
Why publish this at all
Because the alternative is discovering it together during an event. Every item here is known to anyone who has built one of these systems; the only question is whether it is written down before the storm or reconstructed after it.
It is also the fastest way to have a serious conversation. An engineer reading this page can tell within a minute whether we understand their system — and if we have missed something that matters on their network, we would rather hear it in the first meeting than the third.
What would change our mind
Each assumption above is falsifiable on your data. If flow monitoring shows the capture coefficient is stable where we assumed it varies, or the residuals at a structure are systematic rather than random, the model changes — and the change is versioned, hashed and visible in the record, not applied quietly between releases.
The register is reviewed at every model freeze and is part of the deliverable. It is not marketing copy that ages; it is a document with a revision history.
Bring us your hardest reach.
The most useful first meeting is not a demo. It is an hour with your engineer, your network model and the storm that embarrassed you most recently — and a straight answer about which parts of this specification would actually help.
Nobody needs another dashboard nobody opens.
FloodGrid has an operations interface, and on a quiet Tuesday nobody will be looking at it. So the platform is built API-first: everything visible in the interface is available as a documented endpoint, a webhook, a standards-compliant message or a file in a format your existing tools already read. The goal is for FloodGrid to show up inside the systems your people are already watching.
Webhooks
Signed JSON on every incident open, amend, escalate, acknowledge and close. At-least-once delivery with retry and replay, so a downstream outage does not silently lose an event.
REST API
Forecasts, observations, thresholds, incidents, exposure and verification. Cursor-paginated, versioned, OpenAPI-described, with sensible rate limits and a sandbox that returns synthetic data.
CAP 1.2
Common Alerting Protocol output for public-alerting stacks, IPAWS-compatible pipelines and EOC systems — emitted under your authority and your approval workflow, never ours.
OGC services & Esri
WMS, WMTS and OGC API – Features for the rainfall grid, depth grid and exposure layers; plus feature services and file geodatabase exports for ArcGIS Pro and Enterprise.
Hydraulic & hydrologic
Rainfall time series and grids shaped for InfoWorks ICM (CSV and RED), EPA SWMM, HEC-HMS and HEC-RAS boundary conditions, plus NetCDF and GeoTIFF for anything else.
SCADA & historian
OPC UA and MQTT for inbound telemetry; forecast tags written back to the historian so operators see the forecast next to the measurement on screens they already trust.
Comms & paging
SMS, voice, email, Microsoft Teams, Slack, and pager or incident-management integrations with on-call rotation, acknowledgement and escalation handled natively.
SSO & access control
SAML 2.0 and OIDC single sign-on, SCIM provisioning, and role-based access down to the site and threshold level, with every configuration change attributed and reversible.
Every payload carries its own provenance block. A downstream system — or an auditor two years later — can establish exactly which rule fired, which model versions produced the numbers, whether the inputs were complete, and which sources were degraded at the time. Synthetic example; field names are illustrative.
Where FloodGrid sits in a utility's stack.
Nothing here replaces a system you already run. Telemetry keeps flowing to your SCADA and your historian; your GIS stays the authority on the network; your CMMS stays the authority on work. FloodGrid sits alongside them, consumes what they publish, and writes forecast and consequence back into the places your staff already look.
The two footnote lines are the important part of this diagram. A vendor who cannot draw this boundary for you — which components are learned, which are deterministic, and where the policy decision sits — is asking you to take the whole pipeline on trust.
Your data stays yours, and leaves with you.
Your sensor data, asset register and thresholds remain your property. FloodGrid holds a licence to process them for the purpose of delivering the service, and for nothing else. They are not pooled into a shared training corpus and not used to train models for other customers unless you specifically agree in writing.
A full export is available at any time, without a support request. Historical forecasts, observations, incidents, configuration, verification records and model cards, in open formats. An exit that requires a professional-services engagement is not an exit.
Managed cloud by default; single-tenant and government-cloud options where procurement requires it. Air-gapped installation is possible for the alerting and threshold layers, with the caveat that forecast quality depends on continuously ingested public data feeds.
Alerting degrades gracefully rather than failing closed. If the forecast pipeline is unavailable, threshold evaluation continues on live observations alone, at reduced lead time, and says so explicitly in every message it sends.
Role-based, attributed and reversible. Who may author a threshold, who may suppress an alert and who may only read are separate permissions. Every configuration change is versioned with an actor and a reason.
Set by you, not by us. Retention periods for observations, forecasts and incident records are configurable to match your records-management schedule, including indefinite retention where a regulator requires it.
A pilot that produces a defensible answer, not a demo.
Scope — one basin, real assets
Pick a catchment that already causes trouble. Provide the sensor list, the asset register, the terrain surface and whatever thresholds are currently in use, even if they are informal.
Hindcast — score what you already do
Before configuring anything new, your existing triggers are replayed against three years of history. That produces the hit rate, false-alarm ratio and lead time of the status quo, which is the only fair baseline for anything that follows.
Build — models, thresholds, ladder
Catchment-response models are trained on your record, the inundation basis is established at whatever fidelity your data supports, thresholds are authored with your engineers, and the escalation ladder is configured against your actual on-call reality.
Shadow — alerts nobody has to act on
The system runs live for a full season, generating alerts into a shadow channel. You see what it would have sent, and when, without anyone being paged. Thresholds are tuned against real storms rather than against assumptions.
Cut over — and keep scoring
Live notification begins when the shadow record justifies it. Verification does not stop at go-live: it is the permanent operating record, reviewed monthly, and it is what tells you whether the system is still earning its place.
Send us your asset register and a bad storm.
The fastest way to evaluate this is a hindcast on an event you remember well, scored against what actually happened.
Frequently asked — answered plainly.
Does FloodGrid replace National Weather Service warnings?
How much history do you need before the models are useful?
What happens in a storm bigger than anything in your training data?
We run a combined system under a consent decree. What does FloodGrid actually give us?
Will it work on a separate sanitary system, or a stormwater-only utility?
How much flow monitoring do you need for the RDII model?
Do we need a calibrated 2-D hydraulic model first?
How do you keep us from drowning in alerts?
What is actually machine learning here, and what is not?
Can we see your accuracy numbers before we buy?
Who owns the data, and what happens if we leave?
What happens when a radar goes down mid-storm?
How does this relate to GridRain?
What does it cost?
Is any of the data on this website real?
Shared vocabulary, so meetings go faster.
Nowcast
A very short-range forecast produced by extrapolating current observations — here, motion fields derived from successive radar sweeps — rather than by solving atmospheric equations. Dominant skill from 0 to roughly 90 minutes.
QPE / QPF
Quantitative precipitation estimate (what fell) and quantitative precipitation forecast (what will fall). QPE is an analysis of the past; QPF is a prediction. Conflating them is a common source of confusion in specifications.
Antecedent moisture
How wet the catchment already was when the storm began. The single largest reason the same rainfall produces very different responses on different days, and a primary input to the catchment-response model.
Action / warning stage
Stage thresholds at a site: action stage is where preparation begins, warning stage is where impacts are expected. FloodGrid treats these as configurable per site rather than inheriting a default.
Surrogate model
A fast approximation trained to reproduce the output of a slow, physically-based simulation. Used here so a full 2-D hydraulic response can be evaluated every forecast cycle instead of every few hours.
Out of envelope
A condition outside the range a model was trained on. FloodGrid reports this state explicitly instead of extrapolating — which matters most in exactly the record-breaking events where extrapolation is most tempting.
RDII
Rainfall-derived inflow and infiltration — the wet-weather flow that enters a sanitary or combined sewer within hours of a storm, over and above base sanitary flow and groundwater infiltration. The component a wet-weather forecast has to predict.
R-value
The fraction of rainfall falling on a sewershed that ends up in the sewer. The single most useful number for ranking basins for rehabilitation, and highly sensitive to antecedent wetness.
Hydraulic grade line
The elevation to which water would rise in a manhole at each point along a sewer. Above the pipe crown the reach is surcharged; above the rim it overflows. Freeboard is the distance left to the nearest rim.
Firm capacity
A pump station's rated capacity with the largest unit out of service — the number that matters on the night a pump is already down.
Hysteresis
Clearing an alert at a lower threshold than the one that set it, so a forecast hovering on the boundary does not produce a set-clear-set-clear cycle.
CAP 1.2
Common Alerting Protocol — the OASIS standard message format used by public alerting systems. FloodGrid emits CAP so your existing stack can consume it under your authority.
Courant number
How many grid cells a wave crosses in one time step. Above one, an explicit scheme diverges; an implicit scheme survives but loses crest height quietly, which is why the cap is set on accuracy rather than stability.
Preissmann slot
A narrow notional gap above a pipe crown that lets a free-surface solver keep running once the pipe runs full, by giving the pressurised flow an equivalent surface width. Roughly a third of an inch on a five-foot pipe.
Continuity error
The volume a hydraulic run gains or loses that it should not have. The first number to ask any modeller for, because a run with a large one is not a forecast, whatever else it says.
CRPS
Continuous ranked probability score — the standard way to score a forecast distribution against what actually happened. It collapses to mean absolute error for a single-value forecast, so probabilistic and deterministic systems compare on one axis.
Kalman gain
The share of the disagreement between model and sensor that the model adopts, set by the ratio of their uncertainties. A noisy sensor moves the state less than a trusted one, automatically, without anybody editing a threshold.
Point-in-time correctness
Building every training feature from only what had actually arrived at the moment the forecast would have been issued. Its absence is the most common invisible cause of accuracy claims that do not survive a real storm.
Cost–loss ratio
What acting costs divided by what being caught out costs. It is the expense-minimising alerting threshold, which means the threshold is a policy decision about your costs and not a model output.
Error budget
The downtime an availability target permits — 99.9% buys 43 minutes 12 seconds a month. Treating it as a budget rather than a statistic means agreeing in advance to stop shipping when most of it is spent.
Subcatchment width
In SWMM, a shape parameter standing for the length of the overland flow path — not a measurement. It sets how quickly a subcatchment responds and is one of the few numbers a calibration genuinely moves.
Nonlinear reservoir
SWMM's runoff engine: a subarea ponds until its depression storage is full, then drains over a Manning surface at a rate proportional to depth to the five-thirds power. The exponent is why impervious response is flashy and pervious response is not.
Depression storage
The water held in surface irregularities before any runoff occurs — a twentieth of an inch on pavement, a fifth on turf. Small, and the reason a light shower produces no flow at all.
Node flooding
Water leaving the system upward at a manhole or inlet because the hydraulic grade line has risen above the rim. With ponding allowed it is stored at the node and returns; with ponding off, most models simply delete it.
See your watershed on the grid.
Tell us the basin that keeps you up at night. The most useful first conversation is usually thirty minutes with whoever actually gets called at 2 a.m., plus whoever owns the asset data.
What a good first call looks like
Thirty minutes, three questions. Which events do you wish you had known about earlier? What do you currently do when a storm is coming, and who does it? What data already exists — sensors, asset register, terrain, hydraulic models — and what state is it in?
What we will send afterwards
A written scope for a pilot on one basin, with deliverables, the data we need from you, what we will measure, and exit terms. No pricing table dressed up as a proposal.
Bring the sceptic
The most productive sessions have included the engineer who does not believe machine learning belongs anywhere near a flood warning. Those are the questions this product was designed to survive, and the model cards exist to answer them.