Warn the public. Hold the system. Off the same forecast.

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. UrbanFWS runs all of them and blends them on a published schedule — so the forecast never quietly changes character without telling you.

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.

“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.

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. UrbanFWS corrects one with the other, and writes down what it did.

Six sources, six clocks, one analysis cycle.

Co-registering layers in space is the easy half. The hard half is that every source arrives on its own cadence and with its own latency, and none of them are current at the moment you have to decide. A radar sweep is a couple of minutes old before it lands; a rain gauge polled quarterly-hourly may have been read fourteen minutes ago; a numerical weather model that is nominally the 06:00 run is not usable until well after 07:00. The analysis cycle below sweeps left to right and, at each pass, takes the most recent value that had actually arrived — never the most recent value that exists. Everything else is hindsight, and hindsight is how a verification score gets quietly inflated.

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. UrbanFWS 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.

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.

No hidden inputs. No mystery features.

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.

A model that is not being watched is not in production. It is just running.

Your SWMM model, running every five minutes.

UrbanFWS 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.

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. UrbanFWS 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.

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.

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.

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. UrbanFWS 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.

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, basements on the chronic blocks start taking water, and somebody has to decide whether to open the storage tunnel now or hold capacity for the second cell. UrbanFWS forecasts that sequence at the same cadence it forecasts the rainfall driving it — on your network, your regulators, your permitted outfalls. It is also the half of the event an emergency operations centre normally cannot see at all, which is why the eight facts on the cross-agency schedule are drawn mostly from this page.

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.

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. UrbanFWS 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.

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. UrbanFWS 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.

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.

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.

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.

A stage forecast becomes useful the moment it lands on something somebody owns.

“Mill Creek will reach 9.6 feet” means something to a hydrologist and nothing to a barricade crew, a shift supervisor or a duty official deciding whether to wake eleven thousand people. “The Canal Street underpass goes under at 05:10, the hospital access route follows twenty minutes later, the Ridgeview lift station loses access at 05:40 and the elementary school stays dry” is the same forecast expressed as four decisions belonging to three different organisations. The translation between them is terrain, a drainage network, and asset layers that both agencies contribute to — because the utility knows where its vaults are and the EOC knows where the care facilities are, and neither register is complete on its own.

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 in a council chamber and, later, scored against what actually happened. The same ranking drives three different products: the barricade crew's task list, the utility's crew routing, and the polygon on a public alert draft.

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.

Depth on a street is a nuisance. Depth on a lifeline is a cascading failure.

Water in a road closes a road. Water in a substation, a raw-water intake, a pump station or a hospital driveway does something categorically different: it takes out a service that thousands of people depend on, in a way that outlasts the storm by days. The exposure surface is intersected with the lifeline registers of both agencies, and lifeline hits are ranked separately from ordinary asset hits — because they are not the same kind of number, and averaging them into one “assets exposed” count is how the important one gets lost.

Hydraulic fidelity, at forecast speed.

Two very different things travel down this pipe.

One is a page to somebody who works for you: trained, on a roster, reachable, and able to ask a follow-up question. The other is a message to two hundred thousand strangers, delivered once, on a channel with no formatting and no recall, to people who were asleep four seconds ago. Those are not the same engineering problem, and treating them as one is how agencies end up whispering to their own crews and shouting at the public. UrbanFWS separates them at the threshold engine and keeps them separate all the way to the record.

Where the machine stops and the official starts.

Everything to the left of the gate below is computable: the threshold, the polygon, the forecast depth, the evidence bundle, the character-budgeted wording. Everything to the right of it is a legal act performed by a person whose agency holds public alerting permissions. UrbanFWS is built to make the left side fast enough that the right side has time to think.

Ninety characters is not a design constraint. It is the whole design.

A Wireless Emergency Alert carries up to 360 characters on 4G-LTE and newer handsets, and 90 characters on older ones — and the older ones are still in the polygon. Four decades of warning research say the same thing about what has to be in that budget: who is telling me, what the hazard is, exactly where, until when, what to do, and where to get more. Drop one and people spend their lead time milling around confirming the alert instead of acting on it. Compose below and watch both renderings, and the element checklist, move together.

Illustrative composer. Character counts are computed live and are real; the wording, locations and times are synthetic. Two constraints worth carrying into your own SOP: Spanish-language WEA messages are authored, not machine-translated, and reach only handsets set to Spanish — so the English message still has to work for a bilingual household; and the 90-character version is a separate field, which means an originator who writes only the long form has silently written nothing for part of the polygon.

The polygon is the message.

Alert the whole county for a flooded corridor and you have taught two hundred thousand people that your alerts are not about them — a lesson they will remember on the night one is. Alert only the wet cells and you will miss the family whose access road floods before their house does. Carriers are required to deliver a Wireless Emergency Alert within a tenth of a mile of the polygon you draw, which means the polygon is now precise enough to be wrong precisely. Drag below and watch both errors move.

Write the rule in the language of the decision, not in the language of a sensitivity dial.

Thresholds are authored as explicit, versioned conditions on quantities an engineer can defend in a deposition — a forecast stage, a depth over a crown, a rainfall depth over a catchment — with a confidence requirement, a sustain window and a minimum lead time attached. Change the rule and watch the internal notification it would produce change with it. The public draft is generated from the same crossing, and still waits for a person.

The right person, at the right hour, on the channel they will actually answer.

Escalation is configured per site, per level and per agency, because the person who needs to know that a detention basin is filling is not the person who needs to know that an underpass is about to take a car. Quiet hours apply to advisory levels and never to life-safety ones — and the public rung is different from all of them, because it does not fire.

Every false alarm spends credibility you cannot buy back — and the public account is smaller than the internal one.

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. Two thresholds usually have to be chosen, not one: crews will tolerate a false-alarm ratio that the public will not, and the rung that pages a utility supervisor should sit well below the rung that drafts a Wireless Emergency Alert. Move the threshold below and watch both sides move.

Six months later, someone will ask what you knew, when you knew it, and why you did not send.

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, the public drafts that were assembled and what happened to each one, 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 — and it is designed to be read by a reviewer who is not on your side.

A forecast only counts once somebody has done something with it.

Neither agency lacks weather information. What they lack is a defensible link between a forecast and an action: who steps the EOC up a level and on what evidence, which ESF desks are actually needed for a flood as opposed to a hurricane, which crews go where, what the plant does with its wet-weather train, who called the utility and when — 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, and about making the trigger a written condition rather than a judgement call somebody has to defend alone.

Stepping up a level is expensive. Stepping up late is worse.

Activation is the most consequential decision an emergency manager makes in a flood, and it is usually made on the thinnest evidence: a radar loop, a phone call and a feeling about the last one. UrbanFWS does not make it — it does something narrower and more useful. It writes down the forecast condition that corresponds to each of your levels, evaluates that condition continuously, and puts a recommendation with a reason and a clock in front of the person who owns the decision. What they do with it is logged either way, including the times they overruled it and were right.

Limited crews, ordered by the clock rather than by the phone.

During an event, dispatch order is usually set by whoever calls in first — which means it is set by whoever is awake, articulate and already flooded, and not by which asset runs out of time first. Forecast exposure lets the order be set by the deadline instead, across both agencies' crews at once: barricade teams, swiftwater, vac trucks and bypass pumps drawn from the same clock. It also makes the shortfall explicit when there are six priorities and four crews, which is the number an EOC actually needs in order to ask for mutual aid before it is too late to be useful.

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. This matters most at the moment two agencies compare notes: an EOC looking at a five-minute-old depth grid and a utility looking at a fifteen-minute SCADA poll are not disagreeing about the system, they are disagreeing about what time it is.

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 — and, during an event, where a public-warning draft gets a confidence flag on it, because a polygon drawn from a basin whose only level sensor has been quarantined for ninety minutes is a polygon somebody should be told about before they send it.

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. For a utility both numbers are usually money: a crew callout against a basement backup claim. For an emergency management agency the miss cost is not denominated in dollars at all, and pretending otherwise produces a number that will not survive a council meeting. UrbanFWS structures that conversation and keeps the two currencies visibly separate; it does not have opinions about your budget, and it will not put a price on a life to make an optimisation converge.

Nobody should be retyping the forecast into a situation report at 03:00.

Every operational period generates a situation report, and in most EOCs it is assembled by hand from a dashboard, a radar loop, three phone calls and somebody's notepad — during the exact hours when the person doing it should be thinking instead of typing. The factual half of a SitRep is mechanical: what fell, what is forecast, what crossed, what closed, what was sent, what is out of service. UrbanFWS writes that half and leaves the half that requires judgement blank, deliberately, so nobody mistakes a generated document for an assessment.

Illustrative output with synthetic values. Field names, section order and the operational-period structure are configured to match your existing form during onboarding; nothing here asks an EOC to adopt a vendor's reporting format, because the form is usually the one thing in the room that everyone already knows how to read.

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, and the joint after-action — the one where two agencies reconcile their versions of the same event — is the first casualty of the handover. UrbanFWS assembles the factual spine automatically for both: what was forecast, what was observed, what fired, who acknowledged, what was drafted and not sent, what was overridden and why. The human contribution becomes judgement rather than transcription, and the two agencies argue about interpretation rather than about whose timestamp is right.

The failure is almost never hydrologic. It is a phone call that happened forty minutes late.

Read enough flood after-action reports and a pattern appears that has nothing to do with models. The utility knew the interceptor was surcharging before the EOC knew the streets would flood. The EOC closed a road the utility needed to reach a lift station. Two agencies issued two messages an hour apart with two different footprints, and the public averaged them into indecision. None of that is a forecasting problem. All of it is an interface problem — and an interface is something you can specify, test and exercise, which is exactly what this section is about.

Every decision in a flood belongs to exactly one organisation. Most of them are not obvious.

The grid below is the one artefact worth producing before any software is installed, and it is the one most jurisdictions have never written down. Each row is a decision that gets made during a wet-weather event; each column is who does what about it. The rows to argue about are the ones where the letters are not what your staff assumed — road closure, drawdown timing and the public message about sewage in flood water are the three that produce the most surprise in the room.

What crosses the boundary, in which direction, and on what condition.

This is the part of a shared operating picture that actually does work. Not a common map — a schedule of specific facts that move between two organisations automatically, each with a named trigger, a direction and a recipient. Every one below is a real coordination failure that shows up repeatedly in flood after-action reports, converted into a condition a machine can evaluate at 02:40 without anyone remembering to make a call.

The same facts, on two very different screens.

A shared picture does not mean a shared screen. The EOC needs streets, blocks, facilities and people, ranked by time remaining. The utility control room needs nodes, freeboard, setpoints and volumes, ranked by what will alarm first. Handing both of them one compromise interface produces a screen neither agency uses, which is how a common operating picture ends up being a projector nobody looks at. UrbanFWS derives both views from one state, and puts the small overlap — the cross-agency triggers — in the same place on both.

The neighbours, the region and the people who arrive to help.

Urban flooding rarely respects a jurisdictional boundary, and the basin upstream is somebody else's problem right up until it is yours. The same mechanism that connects an EOC to its utility connects a jurisdiction to the ones on either side of it, at whatever granularity the agreements allow.

Do not take our word for it. Read the record.

Every forecast UrbanFWS 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 both agencies continuously — not assembled for a renewal meeting, and not filtered by whichever organisation holds the contract. This page is the part of the product we would want to see first if we were buying it, and the part a procurement officer should ask about before the demo.

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 UrbanFWS uses, stated once so that a score can be compared across sites, seasons, agencies and vendors without a translation step. Two agencies scoring the same event with two different definitions of a hit is not a disagreement about performance; it is a disagreement about arithmetic, and it is astonishing how far into a review meeting it can survive undetected.

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. Events on which a public alert was drafted are scored twice — once as a forecast and once as a warning decision — and the drafts an official declined are scored too, because “the system said send and the human said no, and the human was right” is a finding worth having on the record.

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.

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 UrbanFWS 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, used at three in the morning, and paid for with public money under procurement rules that expect a defensible basis for award. 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, and why an agency can lift them into a specification and hold whoever wins to them, including us.

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.

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.

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 — UrbanFWS 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.

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 UrbanFWS 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.

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.

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.

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.

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.

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 UrbanFWS is running on your infrastructure, because the only measured values worth quoting to you are your own.

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.

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.

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.

Nobody needs another dashboard nobody opens.

UrbanFWS has an operations interface, and on a quiet Tuesday nobody will be looking at it. On a bad Tuesday an EOC will be looking at its incident management system and a control room will be looking at SCADA, and neither will have a spare monitor. 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 UrbanFWS to show up inside the systems your people are already watching, on both sides of the boundary.

Where UrbanFWS sits in each agency's stack.

Nothing here replaces a system either organisation already runs. Telemetry keeps flowing to SCADA and the historian; the utility's GIS stays the authority on the network; the CMMS stays the authority on work; the EOC's incident management system stays the system of record for the incident; the alerting authority's origination software stays the only thing that talks to IPAWS. UrbanFWS sits alongside all of them, consumes what they publish, and writes forecast and consequence back into the places each agency's staff already look.

Your data stays yours, and leaves with you.

A pilot that produces a defensible answer, not a demo.

Shared vocabulary, so meetings go faster.

Tell us about the storm you both still argue about.

The most useful first conversation is thirty minutes with whoever actually gets called at 2 a.m. — on both sides, if you can get them in the same call — plus whoever owns the asset data. If only one agency is in the room that is fine; a large share of deployments start with one organisation and add the other once there is something concrete to look at.