The Rework Leak You Can't See in the Model

The Plan You Believe vs. The Job You Build

Pull a finished job and sit with what actually happened. The schedule said one thing. The field says another. Nobody caused the difference in one move. It leaked out in dozens of small ones: a wall type swapped in a Tuesday meeting, a mechanical shaft rerouted after coordination, a door schedule that grew by nine doors between two model versions.

Most teams run the coordination once, at the start of a phase, then treat it as settled. The model keeps moving after that. A design change lands in Revit, the architect approves it verbally, and the trades never hear about it. The package is still sitting on version three while the model is on version eleven. That gap is the leak. It is quiet, and it compounds.

Here is the part that stings. Every one of those changes had a consequence. Somebody knew about it at the moment it happened. The detailer knew. The PM knew. The GC's superintendent knew. What nobody had was a live record tying that geometry to the people who had to act, so the change got absorbed into the next meeting and the job took the hit.

Think about it the way a safety lead thinks about a near miss. The incident never starts the day it hits the schedule. It builds through small signals nobody tracked, until the crew is standing idle. Teams that handle it early log the signals as they appear: catch the small thing while it is still small. Your model has the same signals. They sit in the geometry.

So the honest question is not whether the job moved. It did. The question is whether you can point to the exact model commit where it started moving, and who owned the fix. Almost nobody can. That is the leak you cannot see.

Where the Leak Starts

The leak starts the moment a design change stops being a design change and becomes someone else's problem. A partition shifts two feet to clear a beam. The architect is happy. The framing trade never sees it. Six weeks later the crew builds what they have, and it is not what the model says.

Untracked model versions are the other half. Your team keeps every version of the file, which is good, but nobody compares version five to version six and asks what moved. Quantities of work drift. A wall that was 200 linear feet becomes 218. A ceiling drops six inches and the duct has to be rerouted. Each change is defensible in isolation. The sum is not.

Change orders work the same way. They do not announce themselves. They show up as a revised sheet, a markup, a chat message at 4:40 on a Friday. You only see them if you are watching the right feed at the right frequency. That is why teams lose about 11 hours a week working out which model version is current.

Your RFI log and your coordination notes are a stream of small signals. Read individually, they are noise. Read as a trend against the model, they are a live record of where the job is slipping.

BidLight does one thing here that matters. It keeps one live record of the project inside Revit and Navisworks, so the history is never a separate document from the model. Every publish is a versioned snapshot with its own files, author and milestone. When the geometry moves, the diff shows it, in minutes. You do not get a report about the leak next month. You see it happen and you decide who acts.

The Version You Forgot to Reconcile

Ask any coordination lead how many versions of the model they handled last quarter. The honest answer is somewhere between three and nine, and they reconciled maybe half of them by hand. The rest went into a folder that nobody opened after kickoff.

The cost of that gap is real. Comparing two versions by eye eats an afternoon, and it still misses things. That is before you count the rework when something was missed. The comparison in BidLight takes about 15 minutes instead of a 90-minute meeting.

This is not a coordinator problem. It is a plumbing problem. The model and the issue list are two different systems, and every time the model moves, someone has to manually carry the change across. Manual carry is where the mistake lives. It is also where the hours go. The coordinator becomes a copy and paste between two files, and the schedule leaks while they are pasting.

BidLight compares revisions element by element, grouped by category: structural, MEP, envelope, interior. When a quantity of work changes, the diff lists it, and the record shows what moved and when. You get a trail, not a guess.

That trail is what makes your reporting honest. On the next job, when the client asks why the schedule moved between design development and construction documents, you do not shrug. You point at the model commits and the issues that rode along with them. The conversation stops being about trust and starts being about evidence.

Catching It Before It Is a Crisis

Crisis is a strong word for a construction job, but it fits here. The moment you realize a section was built wrong is rarely a quiet moment. It is usually a field walk, a stop-work call or a GC meeting. By then, the leak has been running for weeks and the fix costs more than the time you were trying to protect.

The teams that avoid that meeting do one thing differently. They track the trend, not the snapshot. A clash caught in the model costs about $50. The same clash found in the field costs $5,000 to $50,000. An unresolved one can burn $15K to $50K a week in idle field labour. One that sat 47 days burned $28,000.

Applied to a model, that means watching the issue curve as the design matures, not just reading it at milestones. A cluster of issues on the curtain wall between 60% and 90% is a problem you can still solve. One you only see in the field is a problem you just inherited.

BidLight is set up for exactly this. Every issue is pinned to the element it concerns and carries the sheet and revision that raised it. It closes only with a screenshot, a tagged user and the model commit that fixed it. That is not a perfect answer to every problem. It is a defensible answer to almost every one, which is what a GC meeting needs.

The last piece is who does the watching. On most jobs, nobody does. BidLight adds a 6am digest so each owner sees what they hold, at the start of the day, without anyone remembering to send it. If the model moved overnight, the diff moved with it, and you know before the first coffee.

What Changes When the Record Is Live

The first thing that changes is how you answer questions. When your record rides on the same model the client is reviewing, you can answer the 4:55 PM question on the spot. You do not say you will get back to them. You open the comparison, see the delta and tell the room what it touches while they are still talking. That is the difference between catching a change and absorbing it.

The second thing that changes is your service offering. Once the comparison is fast and defensible, you can build on it. Clients value a coordinated model that carries its own history, because it lets them make decisions while decisions are still cheap. Teams that run it this way stop treating coordination as a cost center and start treating it as how the job gets delivered.

The third thing that changes is your internal hours. Coordinators stop being file clerks. They stop reconciling versions by hand, stop hunting for the missing nine doors in a 1,200-door model, and stop redoing the same comparison four times because the model moved between drafts. That reclaimed time goes into the parts of the job that need a human: sequencing, risk and the conversation with the trades.

Put plainly: a version check that took a 90-minute meeting now takes about 15 minutes. On the hyperscale programme, that discipline stood behind 18,000+ hours saved, 8,900+ issues resolved and $12.3M in cost saved. That is not a productivity slogan. That is time and money you get to redeploy.

The plans are simple. Basics is $260 per licence per year. Max is $590. Enterprise is custom. If you want the done-for-you side, we also do BIM work: execution plans, 4D sequencing, fabrication detailing and spooling. The software and the service run on the same principle, which is that the model and the record should never be two different documents.

Here is the takeaway. The job is not a plan you set at kickoff and defend later. It is a live record that moves every time the design moves. The teams that keep it on schedule are the ones that watch it daily, in the same file, with evidence attached. Stop chasing scattered updates and 47 versions of the same markup. One live record of the project inside Revit and Navisworks is what turns a leak into something you can defend.