A shortcut that fit on paper
The task was to make a city simulator distribute water and power across neighborhoods as they grew and changed demand. Generators on one side, consumers on the other, pipes and lines in between. On the map, the network seemed to call for a cleaner sketch. But those connections formed a mesh, with branches, alternate routes, and limits on what each link could carry. Solving flow across that mesh took work. Then came an appealing idea: for easy cases, build a tree, check capacities, and leave the full solver for everything else.
The tree was easy to explain. Each consumer would have a route to a source; add the demand on shared links and check that none exceeded its limit. When the numbers worked, the answer would be cheap. So far, so good. The trap lay in what a failed tree check would be taken to mean.
The city had routes the sketch erased
In the recorded measurement, the nearest-generator tree accepted 12 of 212 allocation attempts. A second version that shared generation across branches accepted the same 12. This did not mean the other consumers could not be served. The mesh had valid routes that neither tree represented.
Imagine two neighborhoods supplied by the same source. The shortest route crosses a narrow link, while a detour around the other side of the network has spare capacity. If the tree picks only the narrow link, combined demand exceeds its limit. Flow on the mesh can split delivery across both sides. The tree answers correctly about the network it was given; the error would be extending that answer to the whole network.
In optimization terms, the simplification restricted the feasible set. Finding a solution inside that set is useful. Failing to find one does not prove the original problem infeasible. That small distinction changes the algorithm: the tree may offer a candidate, but rejection must fall back to the mesh solver.
The old flow carried loops too
The investigation tried another shortcut: reuse the previous allocation and adjust it to the next demand. A calculated flow looked like a promising starting point. But every initial sample contained circulation, loops where resources crossed links without increasing delivery to anyone. During reuse, those loops occupied capacity and made the check fail.
Canceling circulation preserved balance at each node and freed links. That let 48 of the 212 attempts pass the reuse certificate. A variation that admitted new consumers at already supplied taps reached 75. It was a useful clue about the problem's structure, not a ready win: the reuse experiments did not show enough overall benefit to replace the selected method.
I like this detail because it separates two questions that often get folded together. Does the flow meet demand? And is the representation of that flow clean enough to reuse under new constraints? The first may be true while the second fails because of a loop that delivers nothing.
What the measurement could support
One tree variant finished its isolated run faster than the reference. It also had a low acceptance rate, and that measurement was not repeated enough to justify promoting it. The final reuse candidate, after a demand gate, took 101.63 seconds against the reference's 98.70 in the same scenario and used more memory. None of these shortcuts became the default path.
The portable lesson is not that trees are bad or that flow reuse cannot work. It is to know exactly what a shortcut certifies. A feasible candidate for the mesh can shorten the search. A candidate that fails on a subset of routes cannot declare the mesh infeasible. And if total time with fallback does not improve, an elegant certificate has not paid for itself.