Back to Blog
MEP

The change cascade: MEP coordination is a graph problem

James Reed|June 11, 2026|8 min read

Key Takeaways

  • -The expensive failure in MEP is rarely the first design — it is the change that ripples through several documents and gets missed in one.
  • -WYRM MEP's Project Terminal models the job as a dependency graph: change one element and it flags every downstream effect across disciplines, proposes the fix, and tracks sign-off.
  • -Effects are batched into a daily digest, not a stream of pings — so coordination is something you review once, not a constant interruption.
  • -Every proposed change is a draft until a human signs it, and every engineering knock-on is re-derived by the algorithmic calc engines, not estimated.

Ask an experienced MEP engineer where projects actually go wrong and very few will point at the original design. The first pass is usually sound, because that is the part the engineer was trained for and paid attention to. The failures cluster around change — the late client request, the swapped chiller, the relocated damper — because a single change in one discipline ripples into others, and on a busy job one of those ripples gets missed. The missed ripple surfaces on site, or in a clash, or in a compliance check that should have moved and did not.

The reason this is hard is that an MEP design is not a list of independent decisions. It is a dependency graph. The cooling load depends on the IT load and the redundancy stance. The pump duty depends on the flow and the temperature difference. The cable size depends on the diversified load and the route. The breaker rating depends on the cable and the coordination study. Move any node and a set of edges light up — and a human tracking those edges by memory, across separate documents in separate tools, under deadline, is exactly the situation where one gets dropped.

WYRM MEP's Project Terminal treats the job as that graph explicitly. Every element carries its dependencies, so when something changes the system walks the edges and surfaces what else has to move. Change an air-conditioning unit and it flags the affected electrical loads and the drawings that show them, proposes the corrected sizing, and tracks the sign-off. The classic worked example is a relocated fire/smoke damper: move it to clear a revised ceiling grid and, because its actuator sits on a maintained supply, the final circuit has to follow it — which misaligns the adjacent fan-coil power, which lifts the diversified load on the distribution board, which can push a breaker out of coordination. One physical move, four linked consequences. The Terminal catches the chain; a person mid-deadline often catches two of the four.

Crucially, the knock-on engineering is re-derived, not estimated. When the diversified load on a board rises, the algorithmic BS 7671 check re-runs: does the existing Type B breaker still coordinate, does the volt-drop still sit inside the limit, does the cable still hold. The Terminal does not guess that a 20 A breaker probably needs to become 25 A — it computes it, against the standard, and attaches the calc pack. The coordination is only as trustworthy as the numbers behind it, and the numbers come from the same codified engines that produce the original design.

The interaction design matters as much as the graph. A coordination engine that fired a notification for every downstream effect, the instant it computed one, would be unusable — it would bury the engineer in pings and train them to ignore it. Instead the effects are batched into a daily digest. Coordination becomes something you sit down and review once, with the full set of consequences laid out together, rather than a stream of interruptions to the profitable work. The engineer sees the change, the cascade, the proposed fixes, and the items that need a human call, in one place.

And nothing applies itself. Every item in the cascade is a draft until the engineer signs it. The system can propose that the breaker uprates, the duct resizes, the pump re-duties — but the decision, and the responsibility, stay with the human. That is the same principle that runs through the rest of WYRM MEP: the machine does the legwork and shows its working; the engineer reviews and signs. The Terminal's job is to make sure that when the engineer signs, they are looking at the whole consequence of the change, not just the part that happened to be in front of them.

This is why coordination, not drafting, is often the clearest place to feel what WYRM MEP does. Drafting speed is easy to imagine. The change cascade is the thing that quietly costs practices money — in rework, in site queries, in the compliance miss that gets found late — and it is precisely the kind of bounded, relational problem that a dependency graph plus deterministic engines handles better than memory under pressure.

The Project Terminal is part of WYRM MEP, one of WYRM's two flagship engineering products alongside WYRM Data, bundled as WYRM Engineering at £250 per seat. The interactive issue view on the WYRM MEP page lets you orbit a few of these cascades and click each flagged element to see the reasoning — the relocated damper, the chiller swap, the duct upsize — exactly as the Terminal surfaces them.