Skip to main content
School of Engineering JudgmentThe verification gateA mapping call, at no cost
WhatsApp058-4887876
A mapping call, at no cost

All articles

Right answer, wrong reasoning: what a source check misses

Published

The number is right, the reason is wrong, the source check passes. A reason you wrote first catches it.

When a tool gives a correct result with an incorrect justification, a source check passes and the error stays with the engineer. What catches it is a reason you wrote yourself before you opened the tool. This is failure class G7, right answer - wrong reasoning.

It is the one class of seven that a source check was not designed to catch. It also rests on field observation alone, and nobody has measured it. Those two facts decide how to work with it.

Why the check cannot see it

A source check asks one question: does the value in the output match the value in the source? Here it does. Under the decision rule, an item that matches its source passes. The check did exactly what you asked of it.

The gate is the primary control for six of the seven failure classes. G7 is the exception. A right answer with wrong reasoning passes a source check, and it has to be caught somewhere else.

The damage does not show up on the day it happens. That day's deliverable is correct. The engineer absorbs a wrong justification that looks sound and carries it into the next decision. There the conditions differ, and the reasoning no longer holds.

An example

This example is built for illustration. It is not a measured case.

A technician asks whether the filter in an air-conditioning unit needs replacing. The tool says yes, because the filter is past its service life. The unit's manual sets the criterion as pressure drop across the filter. The pressure drop here is high, so the answer is right. The reason the tool gave is not the reason in the manual.

The technician checks against the manual: replace. Match. The item passes and the report is correct.

A few months later there is a fairly new filter that has clogged early. The technician remembers the explanation he got: service life. This filter has not reached it, so it stays in. Nothing in the first report would lead anyone back to this mistake.

Calculations do the same thing. A second example: a number comes out right because two errors balance each other, one in the formula and one in a unit conversion. The result matches the source. Anyone who copies that method into the next calculation gets a wrong number.

What is known and what is not

This part needs saying straight. G7 entered the taxonomy from field observation, and nobody has measured it. We have no figure for how common it is, and we will not offer one. The working paper names it as the class most likely to change in version 1.0.

The nearest measurement sits close by and is a different thing. A study on licensing exams classified 172 errors by a language model, 48 of them reasoning errors on calculation questions (Choi, Lee, and Kim 2025). Those are errors on an exam. They do not measure a right answer with a wrong reason.

Another important finding: the answer consistency was 97 percent. So asking again reveals nothing. A tool repeating its explanation does not make the explanation right.

Why your reason has to come first

The control that catches G7 is Step A of the procedure: do it yourself. That is where the engineer's own reasoning exists, so there is something to compare against.

Order is the point. An estimate made after seeing the answer anchors to it. Once you have read a persuasive explanation, you stop asking what you would have said without it.

The motivation for this principle comes from a field experiment with nearly one thousand secondary students (Bastani et al. 2025). Open access to a standard chat tool raised practice grades. Once the researchers took the tool away, those students scored below students who never had it. A version with safeguards that withheld direct answers largely mitigated that drop. The study is in secondary mathematics, not engineering practice. We take it as motivation, and it proves nothing about engineers.

What to do tomorrow

Take one task where the reason matters as much as the result: a fault diagnosis, a choice of spare part, an out-of-range reading.

  1. Before you open the tool, write one line saying what you expect and why. Step A takes five to twenty minutes. An estimate you did not write down does not count.
  2. In the prompt, ask for the reasoning and its source as well, with the instruction: do not invent, write MISSING.
  3. Check the result against the source, as usual.
  4. Separately, check the reasoning against the engineering source and compare it with the line you wrote.
  5. If the reasoning does not hold, log it: what the tool said, verbatim, gap class G7, and the correct reasoning in the correction field.

Step 4 is the only addition to normal work. It is also where most engineers will say they have no time. So do not run it on everything. Run it where the explanation is about to enter the next decision, a technician's training or a procedure.

Four questions help at this step.

How to tell if it works for you

The second control is the error-hunt quiz. It holds six tool outputs from the working domain, each with one error of class G1 to G7. The candidate identifies the error, classifies it, and names the verification that would have caught it. It runs with no tool access, so no tool can bypass it.

Once a quarter, collect the logs and look at which failure classes recur, and in which deliverables. If G7 never appears, the likelier explanation is that nobody is looking for it. After a quarter like that you will hold a first figure of your own, which is more than we have.

Where this stops

The comparison catches a gap between two reasons. If both are wrong in the same way, it shows nothing.

It takes competence. Verification requires the competence to read the source, and the procedure assumes that competence and does not supply it. A junior engineer with no reason of their own yet should ask a senior colleague, and leave the second tool closed. The output of a second tool is not an authoritative source.

And the whole mapping is a design claim. The procedure intends this step to catch G7, and no measurement backs that yet. The working paper is not peer-reviewed, and it reports no collected data. The other classes are in seven failure classes. A failure that does rest on peer-reviewed measurement is reading a table from an image.

References