Why a converged solution can still be wrong
What convergence proves, and the much larger set of things it does not.
A converged solution can still be wrong because convergence only proves that the arithmetic reached a stable, self-consistent state, and says nothing at all about whether the equations, the mesh, or the boundary conditions feeding that arithmetic described the real problem in the first place.
A test the solver sets and marks itself
Convergence is a statement about the solver's own internal bookkeeping. Each iteration checks how far every cell's equation still is from balancing, sums that imbalance into a single residual, and the run is called converged once that residual has dropped far enough and stopped falling with further iterations. What that certifies is that the solver has found a fixed point of the arithmetic it was given and is no longer drifting away from it. Even the threshold for calling it converged is often just a software default.
Nowhere in that check does the solver compare its answer against anything outside itself. It can only compare a cell's value against its neighbours and against what the same cell held on the previous iteration, so it never asks whether the mesh represented the real geometry, whether the turbulence model suited the flow, or whether the boundary conditions matched what happens at the inlet of the real part. A wrong set of equations, meshed badly and fed the wrong boundary values, converges just as cleanly as a right one.
Retracing footprints in snow
Retracing your own footprints across a snow-covered field to check you walked the right way proves something, though less than it feels like it proves. If the return trip lands squarely inside each of the original prints, the two walks followed the same path, and that is all. Someone who set off in the wrong direction can retrace the mistaken route with perfect fidelity, footprint sitting exactly inside footprint, in a field that never held what they were looking for.
A solver comparing iteration nine thousand against iteration eight thousand nine hundred and ninety nine is matching footprints to footprints. The check is useful, catching an unstable run before it wastes hours diverging into nonsense, and it confirms the walk has stopped drifting. Whether the walk set off in the right direction is outside what it can see.
The residual plot looks the same either way
A residual that has fallen a thousandfold and then flattened out looks identical on the monitoring graph whether the setup behind it is sound or badly flawed. A residual that never flattens is the easier failure, since an unconverged run is visibly still changing and nobody mistakes it for a finished answer. The hard case is a clean, convincing flattening on top of a setup that was wrong from the first iteration.
That gap is where independent checking has to step in: a hand calculation for a simplified version of the same problem, a physical test, or known behaviour from a similar part built before. None of these can be skipped when a project runs late, because convergence cannot substitute for any of them. A flat residual line is best treated as the start of the checking process, the point at which the arithmetic has finished its job and handed the harder question, whether any of it was true, back to the person who set the run up.