The Submittal You Reworked Because Nobody Checked the Model

The Submittal That Was Wrong Before It Left the Building

You reworked a submittal that the model already showed was wrong. A detailer pulls the shop drawing, a PM routes it, a fabricator builds it, and six weeks later the field comes back with a problem the model flagged on day one. The rebar conflicts with the duct. The wall assembly does not fit the structural opening. The submittal log says approved. The model says no.

The rework is the visible cost. There is a second one hiding behind it: the schedule slip while the submittal goes back out, gets marked up, and comes back approved a second time. A fabricator holds a slot they cannot use, and idle labour behind an unresolved conflict can run $15K to $50K a week. It lands on your general conditions line whether you booked it or not.

The part that stings is that nothing about the fix required new information. The clash existed in the coordination model the week it was federated. The geometry, the dimensions, and the clearance rule were all sitting in a file somebody opened, exported, and closed without running a check against the submittal scope.

That is the whole problem in one scene. The project record lives in five places: the model, the submittal log, the RFI log, the markups, and somebody's memory. They disagree, and the disagreement always gets resolved in the field, at full cost. Caught in the model, the same clash costs about $50. Found in the field, it costs $5,000 to $50,000.

BidLight keeps one live record of the project inside Revit and Navisworks. Every publish is a versioned snapshot, and the issue about the clashing geometry is pinned to the element. When the design moves, the comparison shows it, and the clash is not a surprise waiting in a submittal review meeting.

Why the Disconnect Shows Up in Submittals First

Submittals are where the model and the paperwork stop agreeing. The model moves fast during design development. The submittal log moves at the speed of email. Somebody updates the ceiling height in the model on Tuesday and the shop drawing for the acoustic panel system was already issued against Monday's dimension. Nobody is lying. The two records simply live apart.

Traditional coordination has the same gap, just pointed the other way. The review gets done from a drawing set, the drawing set gets superseded, and the notes carry dimensions that no longer match what is being built. When the submittal is drawn from the stale set, the error compounds. Now you have a review built on one version of the project and a shop drawing built on another, and neither one matches the model.

The fix is not more review meetings. It is making the model the single source that both the review and the submittal pull from. When the dimension comes out of the same geometry the detailer is drawing against, the contradiction surfaces on the screen instead of in the field.

That is what a live record means in practice. Not a dashboard and not a report. The model itself is the record, and everything downstream, including the issue list, reads from it. LOD 400 is not a badge you earn once. It is the level where geometry and metadata are specific enough that a submittal drawn from the model is drawing from the same reality the coordination review sees.

What LOD 400 Actually Buys You for Coordination

A LOD 400 Revit model is not about pretty geometry. It is about specificity you can coordinate against. At LOD 400 the element knows what it is: a specific pipe size, a specific hanger spacing, a specific connection type, a specific fabrication detail. That specificity is what lets a clash and a shop drawing agree without a human translating between them.

At LOD 300 you get a duct of roughly the right size in roughly the right place. That is fine for design coordination. It is not fine for a submittal, because the fabricator needs the actual fitting, the actual clearance, and the actual penetration. When the model never reaches that level of detail, the gap gets filled by hand, and the hand does not always check the model first.

When the model is built to LOD 400 and the record is riding on it, three things change. The dimensions are true to the fabrication scope. The clashes that would have shown up in the submittal review show up in the model review instead. And the comparison, when it updates, updates against the geometry the shop drawing was drawn from.

Version comparison depends on this too. Two published revisions compare element by element, grouped by category: structural, MEP, envelope, interior. That only tells you something if the geometry is detailed enough to compare. LOD 400 gives the comparison something real to read. A rough mass and a name do not.

How the Comparison Reads the Model

How does the comparison work, in plain terms? It reads the model the same way a good coordinator does: by element, by type, by location, by category. The difference is that it reads every element, at once, against the previous revision instead of a spreadsheet from last quarter.

BidLight reads geometry and metadata from each published revision and lists every element that was added, removed, or modified. That listing is the part that used to eat a week. A coordinator opens two models, groups elements by trade, and cross-checks sheets and revisions by hand. The comparison does the grouping and the cross-check, then a human reviews the output. The reviewer is checking judgment calls, not doing copy-paste.

BidLight does not run automated clash detection. It tracks the changes and the clashes and issues raised between revisions, pinned to the elements, and each issue carries the sheet and revision that raised it. That matters because a flagged clash is only as good as the record behind it. An element flagged against an old revision is still a wrong answer.

Where this earns its keep is speed. A review that took a 90-minute meeting comes back in about 15 minutes. The record updates when the design changes, which means the submittal review meeting can open with a current comparison instead of a week-old one. The model and the submittal are both reading from the same record, so the contradiction that forced the rework gets caught in minutes instead of after fabrication.

The Workflow, Without the Ceremony

A model-first coordination workflow sounds elaborate. In practice it is four steps. Publish the model. Compare against the last milestone. Review the changes by owner. Let the record update as the design moves. The ceremony is what you cut.

The publish is the one action. You publish from Revit and the snapshot lands in minutes, with its own files, author, and milestone. No separate markup file. No re-keying notes into a spreadsheet. The model is the record.

Then the model changes. The architect moves a wall, the structural engineer resizes a beam, the mechanical scope shifts. In a traditional workflow that change kicks off a re-review, a re-markup, and a re-issue, and the notes are stale again by the time anyone reads them. In a workflow where the record rides the model, the picture is current the moment the model is current.

That is where the submittal problem dissolves. The submittal was drawn from the model. The review was drawn from the model. If the model says the geometry does not clear, the submittal meeting sees it before the drawing goes out, not after it comes back.

The model-first approach is not a debate about which method is more rigorous in theory. It is a question of which record the review and the paperwork are both reading from. When they read from one record, the rework does not get funded in the first place.

What This Looks Like on a Real Job

Picture a mid-size commercial fit-out. The model has 1,200 doors, a ceiling grid at a specific height, and a mechanical scope with a handful of tight clearances. The submittal for the door hardware package is drawn, issued, and approved. Then the ceiling height moves six inches for a structural reason. Every door in that elevation needs a new frame detail. That is the submittal you rework.

With one live record, the ceiling move shows up in the comparison the same day it happens. The doors whose frames are affected get flagged because the model knows they are affected, and the issue is pinned to those elements with the owner tagged. The submittal goes out once, against the correct dimension, and the fabricator holds the slot they were already holding.

Plans are straightforward. Basics is $260 per licence per year, up to Max at $590, with custom Enterprise terms and unlimited projects on every plan. If you want the BIM work done for you, BidLight does execution plans, 4D sequencing, and fabrication detailing and spooling as a service. For a firm that offers coordination as a service, the software is a line item, not a capital project.

The honest pitch is this. Stop chasing scattered updates and hunting for the current version. Catch the clash in the model for about $50. Close issues with a screenshot, a tagged user, and the model commit that fixed them, so the same problem does not come back on site. None of that requires a new process. It requires the model and the paperwork to be the same record.

That is what BidLight does. One live record of the project inside Revit and Navisworks, with every export versioned and every change diffed. The reworked submittal is the cost of keeping them apart.