Assemble and audit a municipal stormwater model from open data

Why use this

1. Open drainage-network data may omit elevations, dimensions or boundary conditions needed for a useful model. A simulation that finishes can still be unsuitable for the engineering question if the forcing data does not exercise the system being assessed.

2. This job could organize a model candidate around input completeness and diagnostic review. Keeping unsupported conclusions visible would help an engineer decide whether more data, a different scenario or calibration is needed before interpreting capacity or flood risk.

Why an agent / simpler alternative

Useful judgment

Reconcile network inputs and explain model diagnostics under an engineer-defined question.

Simpler alternative

Use a validated existing model when it already represents the network and scenario of interest.

Unsuitable when

The output would support public-safety or design decisions without qualified engineering validation.

Proposed inputs

1. Name

   Network-data package

   Owner

   Municipal data owner or engineer

   Minimum scope

   Authorized geometry, elevations, dimensions and boundary metadata

   Quality check

   Identify missing attributes, disconnected elements and inconsistent units.

2. Name

   Scenario and observations

   Owner

   Reviewing engineer

   Minimum scope

   Approved rainfall period, model objective and available calibration observations

   Quality check

   Check whether the forcing and observations can answer the requested question.

Access and setup — proposed or unknown

Proposed minimum

1. Use copied open data and an isolated model workspace; propose checks before any executable simulation.

Compatibility unknowns

1. Unknown: SWMM tool versions, data suitability, numerical stability and runtime compatibility.

External actions requiring approval

1. Installing software, downloading restricted datasets or distributing engineering conclusions.

Expected deliverable and review checks

Proposed artifact

Model candidate and diagnostic plan with input gaps, assumptions and limits on interpretation.

Critical checks

1. Continuity, topology and unit checks precede substantive conclusions.

2. Run completion is distinguished from adequate calibration or scenario coverage.

Missing output evidence

No new run or output inspection in this editorial layer; see linked source-specific limits.

Failure signals and proposed responses

1. Signal

   The selected weather period provides little runoff stimulus.

   Why it matters

   The model cannot support a strong capacity conclusion from quiet conditions.

   Proposed response

   Reframe the result as limited and ask the engineer to select an appropriate scenario.

2. Signal

   Network links connect inconsistent elevations or units.

   Why it matters

   Numerical output may be physically implausible.

   Proposed response

   Trace the affected inputs and stop interpretation until the geometry and units are reconciled.

Effort and cost — unknown

Setup work

1. Inventory input gaps and define diagnostic acceptance criteria.

Ongoing review

1. Review failed runs and revise assumptions only with engineering justification.

Unknowns

1. Unknown: data preparation, compute costs and calibration effort.

First check — proposed, unexecuted

Status

proposed_unexecuted

Synthetic fixture

A synthetic drainage network has a disconnected pipe and a scenario with no meaningful rainfall.

Acceptance checks

1. The topology defect blocks readiness.

2. The scenario is not presented as evidence of storm capacity.

Stop conditions

1. Critical inputs are missing or consequential conclusions exceed the available observations.

Limits

1. Simulation output is conditional on model quality and scenario adequacy; a finished run is not engineering validation.