The Fault That Moves Between Zones: Decision Tree

Why this matters

A fault that shows up in zone one today and zone three tomorrow, with zone two never affected, looks like it defies the normal rule that problems stay put. It does not. A moving fault almost always means the cause is not fixed at any one zone at all: it is shared, time-based, or load-dependent, and it shows wherever the weakest link happens to be at that moment. Chasing it zone by zone treats a symptom that will just reappear somewhere else. This tree gets you to the actual pattern behind the movement.

Start here: does the movement pattern include any hazard signal

If any of the affected zones have reported a hazard indicator, gas smell, burning odor, arcing, or an electrical fault paired with moisture, at any point during the movement pattern, treat the whole system as hazard-relevant even if the current zone shows no symptom right now. A fault that moves between zones is, by definition, capable of showing up in a zone you have not checked yet. Do not clear a zone as safe just because it is quiet today.

Step 1: log every occurrence with time, zone, and conditions

Before you can find the pattern, you need the data. Pull whatever fault history exists, and if it does not go back far enough, start logging now: which zone, what time of day, what the outdoor or ambient conditions were, and what the building's overall load or occupancy looked like at that moment.

• If you have at least three or four logged occurrences, go to Step 2.
• If you only have one or two, you likely need to leave monitoring in place (a temporary logger, a request that staff record the next occurrence precisely) before you can responsibly diagnose further. Guessing from one data point on a moving fault wastes a visit.

Step 2: check whether the movement correlates with time or load, rather than zone

Lay the logged occurrences next to each other. Does the fault move to whichever zone has the highest demand at that moment (heaviest load, most occupants, longest run time)? Does it cluster around a specific time of day, a shift change, a peak-demand period, rather than a specific zone?

• If the pattern tracks load or demand rather than a fixed zone, the cause is very likely a shared resource that is being overwhelmed at its weakest point each time: a shared supply, a shared electrical feed near its capacity, a shared pump or fan sized for average rather than peak demand. Go to Step 4 with that theory.
• If the pattern does not obviously track load or time, go to Step 3.

Step 3: check whether the "moving" zones actually share a branch point

A fault that looks like it is jumping between unrelated zones may actually be moving along a shared branch that serves all of the affected zones, even if that is not obvious from the building layout. Map which physical system, electrical, hydronic, ductwork, or plumbing branch, actually feeds each affected zone, and check for a common point upstream of all of them.

• If a common branch point exists, treat this as a shared-system fault at that branch point (see the related articles on tracing a fault through a commercial distribution system and building-wide vs single-unit scope), not as a per-zone issue.
• If the affected zones genuinely share no common branch, you may be looking at a control-level cause instead of a physical distribution cause: a shared scheduling system, a shared control sequence, or a software/setpoint logic that rotates or load-balances between zones and is exposing a weakness differently each time. Go to Step 4 with that theory instead.

Step 4: test the theory before repairing anything

Whichever theory you arrived at, load-driven weak point or shared control logic, verify it before committing to a repair. For a load theory, monitor the shared resource under a deliberately induced high-demand condition and confirm it approaches its limit. For a control-logic theory, review the actual schedule or sequence and confirm it explains the specific pattern of which zone failed when.

• If the theory is confirmed, repair or resize the shared resource, or correct the control logic, rather than servicing individual zone equipment.
• If the theory does not hold up under test, return to Step 1 and log more occurrences; a moving fault with no discoverable pattern yet needs more data, not a guess.

Recap

1. Any hazard signal anywhere in the pattern: treat the whole system as hazard-relevant.
2. Log occurrences by time, zone, and conditions before theorizing.
3. Check for a load or time correlation across occurrences.
4. Check for a shared branch point connecting the affected zones.
5. Test the resulting theory before repairing; do not repair a zone the fault has already moved away from.

References

• Trade-standard practice for multi-zone and shared-resource fault diagnosis
• Manufacturer documentation on control-sequence and scheduling logic where applicable
• See related: Tracing a Fault Through a Commercial Distribution System; Building-Wide vs Single-Unit Fault (decision tree)