Drainage studies lose too many hours to data assembly.
I designed small Python tools that take the manual data assembly out of Civil 3D, SewerGEMS, and HydroCAD workflows, so an engineer's hours go to judgment instead of reconciling spreadsheets. What you're reading is the design, not a delivered engagement.
Prototype tools in progress. The walkthrough uses synthetic data; real-project results stay unpublished until the tools run on a live project.
Advisory software only. Designed and exercised on synthetic data; no real-project results yet. Engineer review required before any sealed use.
The friction
In conversation with stormwater engineers, three places came up over and over where the manual data assembly eats hours that should be going to engineering judgment.
A municipal drainage study runs through a long assembly line before any engineering judgment happens. Pull site soils, land cover, and elevation data for the project. Compute a weighted curve number and time of concentration for each subarea. Translate the jurisdiction's stormwater ordinance into design-storm recurrence intervals. Reconcile a Civil 3D pipe network against a SewerGEMS model, invert by invert. Build the worksheet the design engineer imports into HydroCAD. Hand-check that worksheet against the ordinance.
The workbench targets that clerical load. It leaves the engineering to the engineer. The three tools below are my proposed answer: designed, not deployed.
The workbench: three prototype tools
Three prototype tools, designed in response to the friction above. Each takes a real input an engineer already has and returns a draft they can review in minutes. Each is in design; none is deployed on a real project yet. The walkthrough below runs on synthetic data.
Drainage Area Summary
Subarea polygons in (GeoJSON), a HydroCAD-formatted worksheet out. Pulls site soils from the NRCS Web Soil Survey, land cover from the National Land Cover dataset, and elevation from the 3D Elevation Program. Computes draft composite curve number and time-of-concentration inputs for engineer review, using documented assumptions for flow path, slope, cover, and method. Design-storm selector across the 1- to 100-year recurrence intervals, referenced to NOAA Atlas 14.
Ordinance Criteria Extractor
A stormwater ordinance PDF in, a structured criteria table out with a page citation on every value. Design-storm intervals, water-quality volume formulas, detention rules, BMP siting. Cited or absent: a value that cannot be traced to a page is refused, not guessed.
Civil 3D vs SewerGEMS Plan QA
A Civil 3D LandXML or DXF export plus a SewerGEMS spreadsheet or report export in, a discrepancy workbook out. Flags invert, rim, diameter, and pipe-type mismatches above a threshold. The comparison logic is rule-based and deterministic, so the same inputs always give the same result.
What exists today
Three prototype tools run today, exercised on real inputs an engineer already has: the Drainage Area Summary, the Ordinance Criteria Extractor, and the Civil 3D vs SewerGEMS Plan QA, described above. Each returns a draft an engineer can review in minutes. Each is in design; none is deployed on a real project yet.
What has been tested on synthetic data
The walkthrough and the screenshots further down this page run on synthetic test data, but the testing behind them checks engineering correctness, not just output shape. Each computed value is verified against an independent hand calculation, and design-storm depths are checked against a live NOAA Atlas 14 lookup, within defined engineering tolerances. That is still not client validation. Synthetic inputs are clean where a real project's are messy, and no real-project results exist yet.
What remains
Blocked on running the tools against a live Civil 3D, SewerGEMS, or HydroCAD project instead of a clean synthetic export, and on the real-project results that only come once a pilot runs against a client's own data. Whether any specific native project file format beyond the exports already described needs additional support is not yet determined. A production build that a team operates under its normal review workflow is not yet built; that is scoped after a pilot.
What a client engagement would deliver
A Pilot: one tool, one real project, one named deliverable, scoped before it starts, run against your data instead of synthetic inputs. That validates the prototype. A Production build, scoped after the pilot, turns the validated prototype into a tool your team operates under its normal review workflow.
What it does for the workflow
On synthetic test data, the assembly steps that take an engineer hours by hand are reduced to a draft for review in minutes, with the engineer kept in the review loop. Measured results will be published once the tools run on a real project.
The point is not novelty. It is billable hours returned to engineering, schedules that compress on the assembly steps, and a peer-review pass that starts from a cleaner draft.
How it's built
What this means in practice: every reported number comes from a source the engineer can check, the same inputs always produce the same output, and the AI never originates an engineering value.
The design: design criteria are extracted by deterministic parsing of the source text and from NRCS urban-hydrology technical references, formulas, and federal data feeds (soils via the NRCS Web Soil Survey, land cover via the National Land Cover dataset, terrain via the 3D Elevation Program; ordinance text via a deterministic PDF parser). The language model is restricted to a clearly labeled advisory field and never produces a relied-upon number. The Plan QA comparison is rule-based, not model-driven, so results are deterministic and auditable. Hosted on dedicated infrastructure behind a private URL, with no public exposure of project data.
Data handling
Your project data drives the solution, so we scope data handling with the work. I have professional experience working with sensitive, regulated data in secured environments, up to controlled-information (CUI) levels, so ordinary project files are well within what I am set up to protect. The right architecture depends on your requirements: on-premises hardware for the highest confidentiality, a secured private cloud in between, or a commercial business-tier AI subscription where the data allows it. Each carries a different cost and a different confidentiality guarantee, and we choose during scoping.
What it looks like
These are screenshots from the prototype running on synthetic data. They show the format of the draft an engineer receives for review, not a finished deliverable.
How to engage
Three ways to engage, in order:
- Scoping call (free, 30 minutes). Diagnose the friction in your workflow and decide together whether a pilot is worth it.
- Pilot. One tool, one real project, one named deliverable, scoped before it starts. Validates the prototype against your data.
- Production build. Scoped after the pilot. The prototype becomes a tool your team can operate under its normal review workflow.
All engagement is on standard McIntosh Consulting LLC terms.
Common questions
Does the workbench replace the engineer?
No. It removes the manual data assembly. Judgment stays with you: the design storm, where the detention goes, the right BMP for the site.
Does it integrate with Civil 3D / SewerGEMS / HydroCAD?
It does not live inside them. It works with their exports, which keeps it decoupled from the modeling vendors' version cycles.
On-prem or cloud?
For the pilot, dedicated infrastructure behind a private URL. Production deployment follows your data-handling requirements.
Can I see it running?
Yes. Book a scoping call. The walkthrough runs on synthetic data unless you bring a real project for the pilot.