Inspect evidence: Turning information into diagnostic direction
2 September 2026 
In the second article in our series from Darren Quinn of Mechanic Mindset, we explore the ‘Inspect evidence’ stage in the ‘FIXDIT’ diagnostic framework. Other articles in the series can be found by following this link , with more to be published in the coming months.
Successful diagnostics has never been about luck. The best technicians follow a process.
Whether diagnosing an intermittent electrical fault, a drivability issue or a complex network communication problem, the same fundamental stages must be followed. The challenge is that many technicians don’t consistently apply them. Steps are skipped, assumptions are made, and testing begins before the problem is fully understood.
The FIXDIT framework was created by Mechanic Mindset to provide a simple, memorable way of applying these essential diagnostic stages every time. It stands for Find evidence, Inspect evidence, eXecute diagnostic plan, Determine the cause, Implement repair and Test.
In the previous article, we focused on Finding evidence: gathering information from the customer, carrying out a full function test, inspecting the vehicle, and preserving every piece of available evidence. This month we move on to the second stage: Inspect Evidence.
Think before you test
Modern workshops are full of sophisticated diagnostic equipment. Scan tools, oscilloscopes, multimeters and pressure transducers have transformed the way we diagnose vehicles.
However, none of these tools decides what should be tested next.
That responsibility belongs entirely to the technician.
One of the biggest mistakes in diagnostics is moving too quickly from gathering evidence to testing components. It is tempting to begin checking voltages, disconnecting connectors or measuring signals immediately, but testing without direction often creates more questions than answers.
Professional diagnosticians pause before they test.
They step back from the vehicle and ask a simple question:
“What is the evidence actually telling me?”
The answer to that question shapes everything that follows.
Build a theory
The purpose of the ‘Inspect evidence’ stage is not to identify the fault.
It is to develop the most likely theory based on the evidence collected.
Think of the previous stage as gathering the pieces of a jigsaw puzzle. ‘Inspect evidence’ is where those pieces begin to fit together.
Your theory should explain every symptom you’ve observed. If it doesn’t, either your theory is incomplete or more evidence is needed.
This is a subtle but important shift in thinking.
The next stage of FIXDIT is about proving or disproving the theory you’ve developed here.
Every fault has a story
One of the most valuable questions a technician can ask is: “What changed?”
Vehicles rarely develop faults without a reason. Something has changed within the vehicle’s history, environment or operating conditions.
Perhaps the fault appeared after another repair. Maybe it started following accident damage, a windscreen replacement or prolonged exposure to heavy rain.
These changes often provide the missing link between the customer’s complaint and the underlying cause.
Imagine a vehicle suffering intermittent CAN communication faults. Initial instinct might be to start measuring network voltages and checking termination resistors. However, if the evidence shows the problem began immediately after a replacement windscreen was fitted, the investigation suddenly has direction. Attention shifts towards disturbed wiring, trapped harnesses or water ingress around the A-pillars.
The evidence has created a logical theory.
Look for common denominators
Another habit that experienced diagnosticians will have formed is looking for what the symptoms have in common.
When several faults appear together, resist treating them as separate problems.
Ask yourself: “What do these faults have in common?”
A vehicle may present with inoperative electric windows, intermittent central locking, interior lighting faults and a battery drain complaint.
Rather than investigating each symptom individually, consider what they share. They may all rely on the same body control module, common power supply or shared earth point.
Finding these common denominators quickly narrows the investigation and often points towards the root cause far sooner than testing each symptom in isolation.
Stay objective
Every technician forms an opinion during a diagnosis.
The danger comes when that opinion becomes a conclusion before the evidence supports it.
A fault code may suggest a failed oxygen sensor, but is the sensor actually faulty, or is it responding to another problem such as an air leak or incorrect fuel pressure?
Professional technicians don’t look for evidence that proves their first assumption.
They look for evidence that challenges it.
By remaining objective and allowing the evidence to lead the investigation, unnecessary parts replacement and costly misdiagnoses can often be avoided.
Wiring diagrams are more than test aids
Many technicians only open wiring diagrams once testing begins.
In reality, they should be used much earlier.
A wiring diagram reveals how a system is designed to operate, highlighting shared power supplies, common earths, module relationships and communication pathways.
Understanding the system before testing it allows technicians to choose logical test points instead of probing circuits at random.
The diagram becomes a roadmap for the investigation.
Diagnostic insight
If you’re struggling with a difficult fault, stop asking: “What has failed?”
Instead ask: “What is all of this evidence trying to tell me?”
Changing that one question often changes the direction of the entire diagnosis.
FIXDIT takeaway
Build a theory before you build a test plan.
By the end of the ‘Inspect evidence’ stage, you shouldn’t necessarily know the answer, but you should have a logical theory that explains the available evidence.
In the next article, we’ll move to the third stage of FIXDIT: eXecute diagnostic plan, where every test is designed to prove or disprove that theory.
Because great diagnostics doesn’t begin with testing. It begins with thinking.
To download a copy of the FIXDIT guide, and explore the framework in more detail, simply follow this link.