The Duct Bank Clash That Showed Up Twice: Once in the Model, Once in the Field

The Tuesday Diff That Nobody Read

The clash was flagged in the diff on a Tuesday. A new duct bank export had just been versioned and compared element by element against the previous one. The diff caught it: a 6-inch offset between the electrical duct bank and the storm line, concrete already formed around the storm line, duct bank scheduled to be set the following week. The clash was pinned to the element, the sheet was attached, the revision was noted. The system did its job. Then the digest went out at 6am Wednesday. By Thursday afternoon, the concrete was formed. The duct bank crew was standing by. Nobody had read the digest.

This is not a story about bad software. It is a story about a gap that opens when coordination lives in one place and the field lives in another. The diff was right. The pin was right. The proof was there. But the electrician foreman was not in the model. He was on site, looking at a formed wall and a duct bank that had nowhere to go. The general contractor's superintendent was not in the model either. He was in a trailer, working through a schedule that did not mention a clash. The BIM coordinator saw it Tuesday. The field felt it Thursday. That gap cost four days of standby labour, a change order, and a concrete pour that had to be re-sequenced.

What makes this case worth telling is that it is not unusual. It is the default outcome when coordination runs in a separate portal, when issues live in a log that only the BIM team opens, when the field finds out about a clash because a crew is standing in front of it. The clash did not show up twice because the model was wrong. It showed up twice because the model and the field were not looking at the same record. The diff caught it. The digest sent it. But nobody closed the loop.

The fix is not more meetings. It is not another portal. It is making the model the live record that the field checks, and making the field's ownership visible in the model before the concrete is formed. That is what BidLight does. But before we get to the fix, let's walk through how this happens on real jobs, because the pattern repeats.

Why the Clash Reached the Field

The clash was caught early. That is the frustrating part. The diff flagged it on Tuesday, which is exactly when you want to catch a duct bank clash. But catching it is not the same as closing it. The issue was pinned to the element, but the pin lived in a coordination tool that the field crew did not open. The digest went to the project manager, who was in a meeting. The superintendent was copied, but the email landed in a folder he checks on Fridays. The electrician foreman never saw it because he was not on the distribution list. By the time the information moved through the chain, the concrete was poured.

This is the scattered-updates problem. The model knows. The diff knows. But the knowledge sits in a tool that the field does not use, and the field is where the cost lands. A clash caught in the model costs about $50 to fix. The same clash found in the field costs $5,000 to $50,000. That range is wide because it depends on how far the work has gone. If the duct bank is not set, it's a reroute. If the concrete is formed, it's a break-out, a re-pour, and a crew standing by. The field cost is not just the fix. It is the idle labour behind it, which can burn $15K to $50K a week while the clash is unresolved.

The four days of standby in this case were not caused by a missed clash. They were caused by a missed owner. The issue had an owner in the model, but that owner was not the person who could stop the concrete. The person who could stop the concrete did not know the issue existed. The digest went out, but it did not land. That is the gap. It is not a technology gap. It is an accountability gap. The model record was right, but the field record was separate.

This is where clash detection services for Revit models often stop. They find the clash. They log it. They send a report. But they do not make the field check the log. They do not make the owner visible to the person who controls the schedule. They do not close the issue with proof that the field can see. That is the missing piece. And it is the piece that turns a $50 model fix into a $50,000 field problem.

The Real Cost of a Clash That Waits

The numbers are not abstract. A clash caught in the model costs about $50. That is the time to reroute a duct bank in Revit, push the change through the diff, and close the issue with a screenshot and a model commit. The same clash found in the field costs $5,000 to $50,000. That range covers the break-out, the re-pour, the re-inspection, the schedule slip, and the change order. And that is before you count the idle labour. An unresolved clash can burn $15K to $50K a week in idle field labour while crews wait for direction. Four days of standby is not four days of nothing. It is four days of payroll, equipment, and overhead that nobody planned for.

The cost does not stop at the clash itself. It spreads. The concrete contractor has to re-sequence. The electrician has to re-mobilize. The superintendent has to explain the slip to the owner. The BIM coordinator has to defend the coordination process. The project manager has to process a change order that could have been avoided. Each of these has a cost, and none of them show up in the model. They show up in the job cost report. And they show up again in the next project when the owner asks why coordination did not catch it.

This is why the 11 hours a week coordinators lose working out which model version is current matters. It is not just the time. It is the delay. If the coordinator spends Monday morning reconciling versions, the clash caught in Tuesday's diff does not get to the field until Wednesday. By then, the concrete might be formed. The 15 minutes it takes to see what changed in a versioned diff instead of a 90-minute meeting is not just a time saving. It is a schedule saving. It is the difference between catching the clash before the pour and catching it after.

The same logic applies to the 6am digest. It is not a nice-to-have. It is the mechanism that puts the clash in front of the owner before the crew mobilizes. When every owner gets a daily digest of what they own, the electrician foreman knows about the duct bank clash on Wednesday morning. He can stop the concrete. He can reroute the duct bank. The $50 fix happens. The $50,000 field problem does not. That is the cost control. It is not in the pricing. It is in the timing.

How BidLight Closes the Gap

BidLight keeps one live record of the project inside Revit and Navisworks. Every export is versioned and compared element by element, so the diff that flagged the duct bank clash on Tuesday is not a separate report. It is the model record. The clash is pinned to the element, the sheet and revision are attached, and the issue is visible to everyone who opens the model. But visibility is not enough. The issue also carries an owner, and that owner is tagged in the 6am digest. The digest goes to every owner, not just the BIM team. The electrician foreman sees it. The superintendent sees it. The concrete contractor sees it. The clash is not buried in a log. It is in their inbox at 6am, with a link to the element and the proof that it is real.

Closing the issue is gated. It closes only with a screenshot, a tagged user, and the model commit that fixed it. That means the duct bank reroute is not just marked resolved. It is proven resolved against the model. The screenshot shows the new route. The commit shows the change. The tagged user shows who did it. When the field crew opens the issue, they see the proof. They do not have to trust a status. They can see the element and the commit. That is how you stop the same clash from coming back on site. It is also how you stop the four days of standby. The issue does not close until the fix is real, and the field can check it before they mobilize.

The project view shows every issue against its owner. That is where the accountability lives. If the duct bank clash is sitting with the electrical contractor and the concrete is scheduled for Thursday, the project view shows it. The superintendent can see who is behind while there is still schedule left to move work. That is the difference between finding out on Thursday that the clash was never closed and finding out on Tuesday that it is still open. The 6am digest and the project view are not reporting tools. They are schedule tools. They put the clash in front of the person who can stop the pour before the pour happens.

The same record supports the field. The issue carries the sheet and the revision that raised it. The field crew can open the model on a tablet, tap the issue, and see the clash in context. They do not need to call the BIM coordinator to ask what changed. They do not need to wait for a meeting. The model is the record, and the record is live. That is what makes the $50 fix believable. It is not a promise. It is a process that has been run on real jobs.

The Proof Is in the Record

The hyperscale programme is the example we point to because the numbers are real. 18,000+ hours saved. $12.3M cost saved. Those numbers did not come from catching more clashes. They came from catching the same clashes earlier and closing them with proof. The duct bank clash that showed up twice is the counterexample. It is what happens when the diff is right but the field is not in the loop. When the loop is closed, the clash shows up once. In the model. On Tuesday. And it is closed before the concrete is formed.

The record is what makes it defensible. Every issue has a screenshot, a tagged user, and a model commit. Every export is versioned. Every change is diffed element by element. That record is not just for the BIM team. It is for the owner, the lender, the insurer, and the attorney who might ask why the duct bank clash was not caught. The record shows it was caught. It shows who owned it. It shows when it closed. That is the difference between a coordination log and a coordination record. A log is a list. A record is proof.

This is also where the brand topics for case studies become useful. The story of the duct bank clash is not a story about software. It is a story about a process that failed because the field was not in the model. The fix is not more software. It is a process that puts the field in the model, with ownership, proof, and a daily digest that lands before the pour. That is what BidLight does. It is not a portal. It is the model record, with the field in it.

If you are running coordination on real jobs, you have seen this pattern. The clash caught in the model. The field finds out too late. The crew stands by. The change order lands. The fix is to close the gap between the diff and the field. That is what the 6am digest and gated issue closure are for. They are not features. They are the mechanism that turns a $50 model fix into a $50 model fix, not a $50,000 field problem. The record is the proof. The proof is the saving.

What to Do Before the Next Pour

Start with the digest. If your coordination issues live in a tool that the field does not open, they are not coordination issues. They are model notes. The field needs to see what they own before they mobilize. The 6am digest does that. It puts the issue in front of the owner with a link to the element and the proof that it is real. If the electrician foreman is not on the digest, the duct bank clash is not going to stop the concrete. That is the first fix.

Next, gate the closure. An issue that closes without proof is not closed. It is deferred. The same clash comes back on site because nobody checked the model commit. The screenshot, the tagged user, and the model commit are not bureaucracy. They are the proof that the fix is real. When the field crew opens the issue, they see the proof. They do not have to trust a status. They can see the element. That is how you stop the four days of standby. That is how you stop the change order.

Then, look at the project view. Who is behind? Where is the schedule still recoverable? The project view shows every issue against its owner. It shows who is behind while there is still time to move work. That is the schedule tool. It is not a report. It is the view that tells you whether the duct bank clash is going to stop the concrete. If it is, you move the concrete. If it is not, you move the duct bank. Either way, you do it before the pour, not after.

The duct bank clash showed up twice because the model and the field were not looking at the same record. When they are, it shows up once. In the model. On Tuesday. And it is closed before the concrete is formed. That is the saving. It is not in the software. It is in the record. The record is the proof. The proof is the schedule. The schedule is the cost. That is what BidLight is for.