Why Single-System Testing Misses Interaction Faults

Why this matters

You ran the full test sheet. Every reading landed inside spec, you wrote "operating normally," and you were back on the same address eleven days later for the identical complaint. That is not a missed step. That is a test method doing exactly what it was designed to do and telling you nothing about the condition that actually breaks the system, because the fault only exists when a second load is running and your method exists to make sure no second load ever is.

This card is about the negative space in a test protocol: not what it measures, but what it deliberately holds still, and why the thing it holds still is where interaction faults live.

Isolation is the feature, and it is also the blind spot

Every repeatable test method in every trade is built the same way. Vary one thing, hold everything else constant, read the result. That is what makes a reading comparable to the nameplate, comparable to last year's reading, and comparable to what the next tech gets. Without isolation you cannot attribute a result to a cause.

The cost of that discipline is specific and it is not a matter of care or thoroughness. When you shut off the other fixtures so your flow reading is clean, when you kill the other loads so your voltage reading is stable, when you test the unit on a bench instead of in its cabinet, you have removed the exact variable that the customer's complaint depends on. A better technician running the same method more carefully gets the same clean result, faster.

So the question a test sheet cannot answer for you is: what did I hold constant, and does the customer hold it constant?

The negative space: what a solo test writes out of the picture

This is the part worth memorizing, because it is invisible by construction. A single-system test excludes:

• Shared supply capacity. Your reading at the source under one load says nothing about the reading at the point of use under three.
• Shared return, drain, or vent path. Two systems that drain, exhaust, or return into a common path can each be within spec alone and back each other up together.
• Thermal accumulation from a neighbor. A unit tested cold in a cabinet that is cold behaves differently in a cabinet that has had something else running beside it for two hours.
• Control interaction. A shared sensor, a shared thermostat, a shared enable signal, an interlock, or two controllers that each assume they own a resource.
• Sequencing and timing. A component that gets its resource fine when it asks first and not when it asks second.
• The customer's schedule. Loads overlap on a human pattern, not a random one. Morning, dinner, laundry night, the hour the irrigation timer fires.

Notice that none of these are exotic. They are the ordinary condition of a real building. The test sheet is the abnormal condition.

Reading the shared resource

The pattern across all five rows: solo testing measures capability, concurrency measures availability. A component can be fully capable and still never get what it needs.

An interaction fault is not an intermittent fault

This distinction decides which method you reach for, and getting it backwards costs days.

An intermittent fault fires unpredictably under conditions you have not identified. It rewards logging over time, forcing techniques, and patience.

An interaction fault is completely deterministic. It fires every single time the concurrency condition is met and never when it is not. It looks intermittent only because you are watching the calendar instead of watching the other system. Logging it by date produces noise. Logging it against what else was running produces the answer on the first pass.

The tell: ask the customer not when it fails but what else is happening when it fails. If they can name a companion event ("only when the washer is filling," "only after the second unit has been on a while," "only during watering"), stop treating it as intermittent. You have a deterministic fault with an unstated condition, and your job is to reproduce the condition, not to wait.

The measurement that exposes it

Three changes turn a blind test into a revealing one, and all three have to be made together:

1. Measure at the point of use, not at the source. The loss you are hunting happens between them. A source reading under load is a reading of the supply's health, not the equipment's diet.
2. Measure under the worst realistic simultaneous demand, built from the customer's actual pattern, not the maximum the building could theoretically produce.
3. Measure simultaneously, not sequentially. Two readings taken four minutes apart while conditions moved are not a comparison. If you have one instrument, use a helper to hold the concurrent load steady and call the reading.

Index everything to your own solo reading rather than chasing absolute values you cannot verify. Call the solo reading at the point of use 100 and express every later reading as a share of it. That makes the loss legible in any trade and survives an instrument you do not fully trust.

Worked example: the appliance that only fails at bath time

A residential appliance fails to complete its cycle and throws a supply-related fault. Two techs before you tested it, both solo, both clean. It had been replaced once already and the replacement did the same thing.

Set the baseline. With nothing else drawing, the reading at the appliance's own supply connection is called 100 on the index. Then add the household's real overlaps, one at a time:

• One other draw open: 62
• Two other draws open: 41

The unit's documentation states a minimum supply value to complete its fill inside its cycle window. Converted onto the same index, that minimum sits at 55.

Now the arithmetic tells the whole story. At 100 it passes with 45 points of margin. At 62 it still passes, with 7 points of margin. At 41 it is 14 points short and cannot finish, every time, without exception. The fault is not random and it never was.

Match that against the household. Two draws overlap for a stretch each morning, and the appliance is programmed to start inside that stretch. It failed on 4 of the last 7 mornings, which is what a schedule collision looks like rather than what a failing appliance looks like. On the 3 mornings it completed, the family had left earlier than usual.

The proof cost nothing. The homeowner moved the appliance start two hours later for one night. It completed. That single test eliminated the appliance as a candidate more convincingly than any bench check, because it changed only the concurrency and nothing else.

The permanent fix was upstream of everything anyone had replaced: the branch feeding that leg gives up a share of its capacity that grows with total demand, so it is fine alone and short under load. After that work, the two-draw reading came back at 71 against the 55 minimum, which is 16 points of margin.

Why 16 points and not "it passes." Household demand is not a fixed thing you get to certify once. Set a headroom rule and hold to it: at the worst realistic concurrency you can construct, require at least 15 index points above the stated minimum on the same index, measured at the point of use. At 7 points of margin, which is what the one-draw case gave before the repair, you have a system that will fail the first time the customer adds a fixture, a guest, or a hotter month.

What a tech who skipped the concurrency step concludes. That the appliance is defective, because it is: it fails, repeatably, in the customer's house. That conclusion survives two replacements and three clean test sheets, and each replacement makes the shop look worse while the actual condition sits untouched in the wall.

Where this frame is the wrong one

• The fault also appears with nothing else running. Then concurrency is an aggravator, not the cause, and you are back to an ordinary fault plus a marginal supply. Fix the fault first, then re-run the concurrency check to see if the margin is still thin.
• The concurrent load is itself faulted. A neighbor drawing far more than it should is a different repair with a different owner. Check the companion's own draw against its rating before you condemn shared capacity.
• You cannot construct the concurrency safely. Never create simultaneous demand by defeating a protective device, bypassing an interlock, wedging a relief path, or running a combustion appliance outside its normal control sequence to load a shared supply. If the only way to reproduce the condition is to disable something that exists to stop a hazard, monitor the real event instead: leave logging in place and capture the customer's own overlap.

How to verify you got this right

Verification here is not "it works now," because it worked before too. Prove all three:

1. Reproduce the failure on demand by re-creating the concurrency, before you repair anything. If you cannot make it fail on purpose, you have a theory, not a diagnosis.
2. Show the margin, not the pass. Re-measure at the point of use, at the same constructed worst case, and write down both the reading and the minimum on the same index. A pass with 2 points of headroom is a callback with a date on it.
3. Write the condition into the record. Note what you had running, at what point you measured, and the index values. The next tech opening a clean solo test sheet with no concurrency note will repeat the whole cycle, and that is a shop failure, not an individual one.

References

• Manufacturer documentation for minimum supply values and the conditions under which they are stated
• Trade-standard practice for measuring at the point of use under load rather than at the source
• See related: How to Map Which Loads Share a Circuit or Supply
• See related: How to Separate Runtime-Driven Faults From Ambient-Driven Ones