Error Code Says One Thing, Symptom Says Another: Decision Tree

Why this matters

You pull up to a job, the board is throwing a code for one fault, and the customer's description does not match it at all. Replace the part the code names and you might be back in a week, because either the code is misleading, the symptom is misleading, or both are true and pointing at the same root cause from different angles. Sorting that out before you open a panel is what separates a one-visit fix from a parts-cannon repair.

Start here: is this a hazard first

If the mismatched code or symptom involves gas, an overheating electrical component, standing water near power, or anything arcing, sparking, or smoking, stop and handle the hazard before you diagnose anything. De-energize the circuit or shut off the fuel source, verify it is actually off, and only then continue. No code or symptom is worth working around a live hazard.

Step 1: confirm what the symptom actually is

Get the specifics from whoever reported the problem, not the summary. "It's not working" and "the code says compressor fault" are two different data points and neither is a diagnosis. Ask when it happens, how often, and what "not working" looks or sounds like. Watch it happen if you can, rather than working from a description alone.

• If you can reproduce the symptom on demand, note exactly what you did to trigger it and move to Step 2.
• If you cannot reproduce it and the code is also gone, you are chasing an intermittent. Pull any fault history the board stores and match timestamps against known events (a storm, a power blip, a specific cycle) before condemning parts.

Step 2: does the code's trigger condition match what you can measure right now

Every code has a specific measurement or signal behind it. Test that exact measurement independently of the board, with your own meter or gauge.

• If your independent measurement agrees with the code (the pressure really is low, the temperature really is out of range), the code is accurate and the mismatch is in the reported symptom, not the diagnosis. Go to Step 3.
• If your independent measurement disagrees with the code (pressure is normal but the board says low pressure), you have a sensor, wiring, or connector fault in the code's own measurement path. Trace that path: connector corrosion, a pinched or chafed wire, a failed sensor, before you touch anything else. This is the single most common reason a code and reality disagree.

Step 3: does the customer's symptom make sense given the confirmed fault

Now that you have verified the code is reporting something real, check whether the reported symptom is a plausible downstream effect of that fault.

• If yes (low pressure really would cause the reported short-cycling, or a bad limit switch really would cause the reported no-heat), you have one root cause explaining both. Repair the confirmed fault.
• If no (the confirmed fault would not produce the symptom described), you likely have two separate problems happening at once, or the reported symptom is describing something upstream of the whole system (a power issue, a thermostat/control setting, user operation). Treat them as two tickets: fix the confirmed fault, then re-evaluate the original complaint with that fault removed from the picture.

Step 4: still unresolved after both checks

If the code checks out as real, the symptom is a plausible match, and the repair does not clear the complaint, widen your view past the component the code named. A correctly-firing code and a matching symptom can both trace back to a cause neither one names directly: airflow restriction upstream of a limit switch, a supply-side issue upstream of a pressure fault, a wiring fault shared across two circuits. Walk the system one step further out before condemning another part.

Recap

1. Confirm the actual symptom by observation, not description.
2. Independently verify the code's own trigger condition.
3. Check that the reported symptom is a believable result of the confirmed fault.
4. If the code and a plausible symptom still do not resolve the complaint, look one system further upstream.

References

• Manufacturer documentation on sensor and fault-trigger specifications
• Trade-standard practice for independent verification before parts replacement
• See related: Reading an Error Code, the Discipline Not the Lookup; Codes That Lie: Sensor Failure vs Real Condition