More trust before the run: stricter QA and reproducible benchmarks in WatDis

Some weeks, the strongest story is not a flashy feature or a big solver claim. This was one of those weeks. In WatDis, the most solid progress landed in two areas that matter a lot for trust: catching impossible geometry earlier and making the evidence behind solver prioritization much more reproducible.

More useful QA before a run even starts

The most direct user-facing change was new validation for extremely small pipes. WatDis now raises a critical finding for any pipe below 5 mm in diameter, and it also warns on tiny pipes with extreme length-to-diameter ratios.

That matters because many apparent analysis problems do not begin inside the solver. They begin earlier, with questionable imports, inconsistent geometry, or data that arrives with implausible units or scale. Catching that signal before a run helps teams avoid spending time interpreting results that were already compromised at the input stage.

This was not shipped as hidden logic alone. The change also landed with localized English and Spanish diagnostics messaging, focused tests, and QA changelog updates. It is a concrete improvement in how WatDis supports technical modeling work.

Benchmarking with better traceability and less anecdote

The second major theme was the benchmark program. WatDis added a committed external sweep covering 233 networks with aggregate convergence results, and it also produced a deterministic 471-case queue for the technical campaign.

What really matters here is reproducibility. The campaign now filters for clean EPANET references before promoting cases, and it keeps versioned source snapshots so a clean checkout can regenerate the same artifacts. That sharply reduces the risk of arguing over ambiguous cases, rerunning poorly defined experiments, or relying on informal memory to explain why a case was prioritized.

Put simply, the solver roadmap is now anchored to stronger shared evidence.

A useful week precisely because it stays honest

There was also a lot of documentation and protocol work around the solver campaign. That is real progress, but it should be described carefully: it is not the same thing as a confirmed runtime improvement or a solved convergence story.

In fact, the week is more valuable because of that honesty. WatDis made clearer separations between invalid inputs, noisy benchmark cases, and real numerical issues. When those boundaries improve, the product becomes more trustworthy and engineering effort becomes more focused.

Why it matters

For people using WatDis in technical work, this translates into something practical: fewer chances of trusting a poorly built network, and a better foundation for understanding which cases truly deserve solver attention.

This is not a week for claiming a dramatic numerical win. It is a week for making the path toward that win much more credible. In engineering tools, that difference matters.