Automation without verification just ships wrong answers faster

Here is a failure mode we hit in an automated simulation study, and why it did not end up in the client's report.

A post-processing step had a sign-convention error. A force-and-torque integration came out with a flipped sign, the kind of mistake that is easy to make when your solver, your mesh tool, and your reporting code each define "positive" differently. The number was not noise. It was a clean, confident, wrong value.

In a fully automated pipeline with no checks, that value would have flowed straight through: from the solver, into the aggregation step, into the summary table, into the PDF, onto someone's desk. Automation does not hesitate. It does not squint at a torque pointing the wrong way and think "that cannot be right." It formats the number nicely and moves on.

What caught it was a verification step whose only job is to ask whether the physics is plausible. A torque that opposes the rotation it should be driving, a drag force pointing upstream, a lift coefficient that falls as angle of attack increases while the flow is still attached: these are cheap to check and expensive to miss. The check flagged the inconsistency, we traced it to the sign convention, fixed it, and the report went out with the right number.

Automation amplifies whatever you feed it

Speed is not selective. A pipeline that can produce a correct answer in twenty minutes can produce a wrong one just as fast, and with the same polished formatting that makes it look trustworthy.

Manual workflows have accidental safety nets. An engineer running a case by hand watches the residuals, notices that the mesh looks strange, remembers that this geometry usually gives a different number. Those instincts are friction, and automation removes friction. Remove the human staring at intermediate results and you remove the person who would have caught the flipped sign.

So the question is not "can we automate this?" Almost always, yes. The question is "what replaces the judgment we just automated away?"

Verification is where the value is

Our answer is that agentic simulation is only safe when the agents check each other, adversarially, at every stage. Not a single QA pass bolted on at the end, but checks embedded where mistakes are actually made:

• Geometry review: is the CAD watertight, correctly scaled, and oriented the way the boundary conditions assume?
• Mesh QA: are cell quality, aspect ratio, and boundary-layer resolution within bounds for the physics being solved?
• Solver QA: do the boundary conditions and turbulence model match the physics, are the schemes stable at this Courant number, and is any of it what the study actually called for?
• Run monitoring: are residuals falling and forces settling, or have the residuals stalled while the force monitor parks on a plausible-looking but meaningless value?
• Post-processing review: are the integrated forces and moments in the frame and sign convention the report claims, and do they agree with an independently derived expectation?

Each of these is a place where a confident wrong answer can be born, and each gets its own reviewer. The reviewers are not there to rubber-stamp. They are there to disagree. A geometry agent that has never rejected anything has not been tested, only trusted.

Why the checker has to disagree

A checker that shares the same assumptions as the thing it checks will miss the same errors. If your verification takes its expected sign from the same configuration file, or reuses the same transform, the flipped sign passes both. Sharing a convention is fine; sharing the code that applies it is not. The value of a separate verification step comes precisely from its reasoning independently, from physical first principles, not from the pipeline's internal bookkeeping.

That is what a physical-plausibility check does. It does not ask "did the code run?" It asks "does this result obey the physics we know must hold?" Conservation, expected signs, order-of-magnitude sanity, monotonic trends where monotonicity is guaranteed. These are the checks a good engineer runs in their head, made explicit and repeatable.

These checks have a hard ceiling, and it is worth being blunt about it. They catch results that are wrong in an obvious direction: flipped signs, magnitudes off by orders, trends that run backwards. They do not catch a drag coefficient that is fifteen percent high because the turbulence model was wrong for the separation, or a first cell that landed in the buffer layer, or a boundary condition that is defensible but not the one the study needed. Those results are physically plausible. They are just not right. A plausibility check raises the floor. It does not certify the answer.

The check is cheap, the miss is not

A sign flip is a small bug. Finding it after it has shipped is not a small problem. Once a wrong number is in a report, it does not stay in the report. Someone sizes a motor against it, sets a safety factor from it, or green-lights a design review on the strength of it. The cost of the error grows the further downstream it travels. The cost of the check itself does not: it is the same cheap test wherever you run it.

This is the asymmetry that justifies verification. A physical-plausibility check is cheap: seconds of compute for the deterministic assertions, one model call for the ones that need judgement about the case. A wrong result that reaches a design decision costs a redesign, a schedule slip, or worse. You are trading a tiny, certain cost now against a large, uncertain cost later, which is the trade most engineering processes should take, up to the point where the checks cost more attention than the errors they catch.

It also matters where the check sits. Catching the flipped sign in post-processing is cheap. Catching it after the summary table has been built means re-running the aggregation. Catching it after the PDF has gone to the client means an awkward correction email. The earlier the reviewer sits in the chain, the less the error costs to unwind, which is why the checks belong at each stage rather than in one pass at the end.

What this means for building agentic CAE/CFD

The reason we build agentic simulation the way we do, with review agents at the geometry, mesh, solver, run, and post-processing stages, is not to add ceremony. It is because we have watched automation carry a single upstream error all the way to a formatted, finished-looking deliverable, and we have watched a verification agent stop it one step before the client saw it.

If you take one thing from this: the value of an automated simulation pipeline is capped by the quality of its checks. An unchecked pipeline is not faster engineering, it is faster risk.

That is how we build agentic simulation at Curlscape. Worked examples are in the Lab.

Speed without verification does not reliably get you to the answer sooner. Often it gets you to the wrong answer sooner, and then asks you to trust it.