Component Tests Good but System Fails: Misleading Decision Tree

Why this matters

You pulled the suspect component, tested it, and it passed. You bench-checked the motor, the valve, the board, the element, and every one reads good. Yet the system still fails. This is one of the most frustrating and instructive situations in diagnosis, because every individual part is telling the truth and the system is still broken. The fault is not in any component you can isolate; it is in how the components interact, or in a condition that only exists when they run together.

The trap is to keep re-testing parts that already passed, or to start replacing good components in hope. Both waste time and money. The way out is to recognize that a system fault that survives good component tests is almost always one of a few things: an interaction the bench test cannot reproduce, a load or condition the component only sees in the system, a connection or interface between good parts, or an out-of-spec input feeding good parts. Each has a distinct test approach.

Universal: a good thermostat and good furnace that will not stage together, good faucet and good supply that deliver poor flow, good motor and good drive that will not start under load, good sensor and good board that miscommunicate.

Symptom presentation

The signature is a contradiction between component and system. Each part passes in isolation; the assembled system fails. Two profiles dominate. The interaction profile: parts that are individually fine fail to work together, often a timing, sequencing, or signaling mismatch. The condition profile: a part that passes on the bench fails in the system because the system subjects it to a load, temperature, or input it does not see on the bench.

A frequent variant is the interface fault: the components are good, but what connects them (a connector, a fitting, a wire, a linkage) is bad, so the system fails while every part you can remove and test passes.

Quick checks

• Did you test the component under the same load and conditions the system imposes? Bench-good at no load can be system-bad under load.
• Are the connections and interfaces between good components sound? The fault may live between parts, not in them.
• Are the inputs feeding the good components in spec? Good parts fed bad inputs produce system failure.
• Does the fault appear only when multiple components operate together? Interaction faults vanish when parts are tested alone.

Isolation tree

Step 1: Reproduce the failure in the assembled system. Confirm the system actually fails when fully assembled and running. This anchors the diagnosis to the real condition and rules out a test artifact.

Step 2: Test for load and condition gaps. The most common reason a good component fails in a system is that the bench test did not impose the system's load, temperature, voltage, or pressure. Re-test the suspect component under the actual operating condition, in place if necessary. A motor that spins free on the bench may stall under system load; a valve that seals at test pressure may pass at operating pressure.

Step 3: Inspect the interfaces. If components pass under real conditions, suspect what connects them. Connectors, terminals, fittings, linkages, and wiring between good parts are classic system-fault locations precisely because you cannot remove them and bench-test them. Test continuity, sealing, and mechanical engagement at every interface.

Step 4: Verify the inputs to each good component. A good component fed an out-of-spec input behaves badly through no fault of its own. Measure the actual input each component receives in the system: supply voltage, control signal, feed pressure, command sequence. An input fault explains a system failure with all-good parts.

Step 5: Test the interaction directly. If parts, conditions, interfaces, and inputs all check out individually, the fault is in the dynamic interaction: timing, sequencing, feedback, or signaling between components. Observe the system through its operating sequence and find the step where the interaction breaks down.

Confirming diagnosis

The diagnosis is confirmed when you can show the specific interaction, condition, interface, or input that fails in the system but is invisible to isolated component testing, and correcting it restores system operation. ISO 13379-1 distinguishes component-level from system-level diagnosis and notes that some failure modes only manifest at the system level under operating interaction, which is the formal description of this entire situation.

A confirmed system-level diagnosis explains why each part tested good and the system still failed, with no contradiction left unresolved.

Next steps

Once you locate the interaction, condition, interface, or input fault, correct it and verify by running the full system through its operating sequence, not by re-bench-testing the parts.

Resist replacing components that have already passed under representative conditions. Replacing good parts on a system fault is the costliest dead end in this scenario and rarely fixes it.

Document why the component tests passed and where the system-level fault actually lived. That record explains the apparent contradiction to the customer and to anyone reviewing the repair, and it keeps the next tech from re-testing the same good parts.

References

• ISO 13379-1, Condition monitoring and diagnostics of machines, component-level versus system-level diagnosis.
• ISO 17359, Condition monitoring and diagnostics of machines, system interaction effects.
• ISO 14224, reliability and maintenance data, interface and interaction failure modes.
• NFPA 70B and ACCA service guidance on testing components under in-system operating conditions.