The Fault That Lives in the Interaction, Not the Part

Why this matters

Some faults do not live in any component. Every part you pull tests good, every reading sits in range, and the system still misbehaves. The fault is in how two correct parts relate: they fight, they stack, they load each other, they are timed wrong against one another. If you keep condemning parts one at a time you will replace good hardware, keep the complaint, and burn your credibility. The skill is to recognize when "everything tests good" is not a dead end but a signature, one that says stop looking at parts and start looking at the connections between them.

The signature: correct alone, wrong together

Bank this frame. When each component passes on its own but the assembled system fails, the fault is emergent. It exists only because the parts are combined, and it disappears the moment you test them in isolation, which is exactly why bench-testing each one clears it and the complaint survives every swap. An interaction fault is quiet on a component check and loud only in the running, loaded, assembled system.

The tell that you are in this territory: a string of good test results and a persistent symptom, or a fault that changes when you touch a component that itself is fine. Those are not signs you are missing a bad part. They are signs the bad relationship is doing its work between the parts you keep clearing.

The kinds of interaction that create faults

The adjacent-system case, where another trade's newer install moves a shared condition, is one family of this and has its own article. But interactions inside a single system cause the same headache:

  • Two controls fighting. Two devices act on the same variable with overlapping authority and hunt against each other, swinging around a setpoint neither can hold. Each control is fine; the conflict is that both are steering.
  • Tolerance stack-up at an interface. Two parts each within tolerance land at opposite ends of their range, and where they meet the sum is out of spec: a gap too tight, a fit too loose, a clearance gone. Neither part is bad; the pair is.
  • Source and load mismatch. A supply and the thing it feeds interact through impedance, pressure, or flow. Each is within rating, but together the load pulls the source off its point, or the source overdrives the load, only under real operating conditions.
  • Timing and sequence. Two events are each correct but ordered wrong or overlapped: one device commands before another is ready, two draws coincide, a signal and its response drift out of step.
  • Feedback and resonance. A loop feeds its own output back into its input, or two components trade energy at a shared natural frequency, and a small disturbance grows instead of settling.

Why swapping parts does not fix it

Replace one half of a bad interaction with an identical good part and the interaction returns, because the relationship, not the part, was wrong. This is the money pit of interaction faults: each swap is defensible in isolation and useless in aggregate. If a replacement of a good-testing part did not change the symptom, that is information. It argues for an interaction and against a component, and it should push you to change your approach rather than order the same part again.

How to test a relationship instead of a part

You cannot ohm out an interaction. You provoke it and watch:

  • Change one thing and watch the other. Move one component's setting, load, or timing and see whether the fault tracks it. A fault that moves with a variable is coupled to that variable.
  • Break the loop. Temporarily open the coupling: isolate one control, decouple two stages, separate a shared path. If the fault clears the instant the parts stop interacting, you have found where it lives.
  • Reproduce it assembled and loaded. Interaction faults only exist in the running whole, so test there, under the real load and real conditions, not on a bench where the relationship is severed.

Lead with safety when you provoke a system. Never open a loop or force a condition on a system carrying stored energy, pressure, or a combustion or shock hazard without first controlling that hazard, and never override an interlock to reproduce a fault.

The deliverable

The honest fix names the relationship: these two parts, both good, conflict in this way under these conditions, and the correction is to change how they meet, not to replace either one. That might mean re-coordinating two controls, correcting a clearance, matching a source to its load, re-sequencing an operation, or damping a loop. The diagnosis of the interaction is the value. A pile of good parts you did not need to replace is the cost of missing it.

References

  • Trade-standard practice for system-level and emergent-fault diagnosis
  • Manufacturer commissioning and control-coordination guidance
  • See related: The Newer System Next Door That Broke Your Old One; Reading Whether a New Adjacent Load Overloaded Your System