The Change Log That Updates Itself While the Architect Is Still Talking

The Wall Moves and Your Coordination Picture Goes Stale

The architect moves a wall. Your picture of the project stays stale. You are two hours into a design meeting, the client is nodding at a layout, and the model on your laptop is a model of a building that no longer exists. Everyone in that room knows it. You promise to "circulate what this touches tomorrow," and the momentum dies on the spot.

Here is the part nobody says out loud. The summary will not be ready tomorrow either. It will be ready after someone re-exports the model, hunts for the last version, compares sheets by eye, rebuilds a list of affected items, and routes it past two people who have questions. Depending on the size of the change, that is a day or three. By then the conversation has moved on, the MEP trades have drawn another week against the old layout, and a clash is quietly aging toward the field.

The problem is not your coordination skill. It is the distance between the model and the record of what changed in it. The design lives in Revit. The history lives in email, Teams, and 47 versions of the same markup. Nothing connects them, so every design move triggers a manual relay race, and the record is always running behind the design it is supposed to describe.

BidLight closes that gap. One live record of the project sits inside Revit and Navisworks. You publish from the model, each publish becomes a versioned snapshot, and the comparison with the previous revision is there in minutes. No digging for the last file. No rebuilding the change list by hand. What you are looking at is the record for the design in front of the client.

That changes the kind of meeting you can have. You stop being the person who will get back to them. You become the person who already knows what it touches.

How a Revit Model Comparison Actually Works

People ask how to compare revit model versions, and the honest answer starts with what the model actually contains. Revit geometry defines what the thing is: walls, slabs, pipe runs, duct, doors, equipment, footings. Model metadata defines what it is and how it is specified: family type, material, dimensions, level, system assignment. Together those two streams describe a building in enough detail to see exactly what changed.

BidLight stores every publish as a snapshot with its own files, author, and milestone. When you pick two revisions, they compare element by element. Anything added, removed, or modified is listed, and the list is grouped by category: structural, MEP, envelope, interior. A 6-inch partition that moved is a different line from a 6-inch pipe that now sits where the partition used to be, and that second one is the line you really care about, because it is where a clash will start.

The comparison does not stop at a list. Issues attach to the Revit element they are about, and they carry the sheet and revision that raised them. So when the wall move lands, the structural engineer sees the slab edge, the MEP lead sees the duct that now crosses it, and each of them has a named issue instead of an email. BidLight does not run automated clash detection. It tracks the changes and the clashes and issues between revisions, pinned to the elements.

One caution worth stating plainly. The model has to carry real information. If families are modeled as generic blocks with no level, no material, no system assignment, the comparison still shows that something moved, but it tells you less about who has to react. Firms that get the best results are the ones whose models carry real data, which is most of the same discipline BIM teams already apply to coordination.

The payoff is not that software does your job. The payoff is that the mechanical part of coordination, the hunting and the matching, stops consuming your week, and your judgment gets applied to the parts of the project that actually move the outcome.

What a Live Model Record Means in Practice

Ask what a live model record means and you will usually get a diagram with a model on one side and a cloud on the other. That diagram is useless on a Tuesday afternoon. The useful version is simpler: every change is attached to the elements themselves, so when an element changes, its history, owner, and open issues move with it, without anyone re-entering anything.

In practice, that means the record is a live view of the current design rather than a snapshot of a past one. Move a wall in Revit, publish, and the affected doors, ducts, and sheets are in the comparison. Add a run of duct and it appears under MEP. Delete a rooftop unit and the open issues pinned to it surface, so nobody keeps working around equipment that is gone. Nothing sits in a separate file waiting to be reconciled.

Teams also run 4D sequencing alongside this: schedule tied to the same model records. That is how a firm moves from "here is what changed" to "here is what changed and when the field feels it," which is what owners and general contractors actually need to make a decision. The change list and the sequence describe the same building because they read the same record.

For most AEC firms, the practical difference shows up in three places. Early design conversations get real answers instead of promises. Review sessions get settled on the spot, so the client sees the trade rather than waiting a week to hear it. And the owner-facing report carries a record that traces back to model elements, which means it holds up when someone asks how you got there.

A note on the phrase itself. Plenty of tools in this space are shared folders with a viewer attached. That is not a live record. If the history is not riding on the model, it is a better filing cabinet, and you will still be rebuilding the story every time the design moves.

BidLight's own software line runs from Basics at $260 per licence per year to Max at $590, with custom Enterprise terms for firms that want them. Every plan includes unlimited projects. The tiers exist because a firm doing tenant fit-outs and a firm doing a hospital have different appetites for tooling, not because the core idea changes. The core idea is one live record of the project inside Revit, kept as the work happens.

The 15 Minutes Instead of 90, and Where Those Hours Go

A focused comparison pass on a mid-size change used to run in a 90-minute meeting before anyone trusted it. With the model published and compared, that same pass lands in roughly 15 minutes, and most of that time is spent confirming who owns what rather than hunting for files. Across a project, that is where the hours come from. On the hyperscale programme the case study shows 18,000+ hours saved, 8,900+ issues resolved, and $12.3M cost saved, the sum of a thousand small reconciliations that quietly stopped happening.

The hours are not the real story. The real story is what happens to the rework you were going to do because the answer arrived too late. A clash caught in the model costs about $50. The same clash found in the field costs $5,000 to $50,000, and behind it sits $15K to $50K a week in idle field labour. The mechanism is not heroics. It is speed and clarity. You see the change when it is made, so the crew never gets a chance to build it wrong.

Take the design meeting scenario literally. The architect proposes moving a corridor wall to gain three feet of clear width. In the old workflow, that is a note in your margin and a summary next week. In the live workflow, you publish the change from the model and read the delta out loud: two partitions shifted, one door relocated, a duct run now crossing the new line, a sheet revision to chase. The client hears a consequence that matches the screen. The conversation stays on design instead of stalling on "we'll check."

There is a second-order benefit that coordinators notice within a month. When you are not spending the afternoon digging, you spend it on the questions that decide whether the project runs smoothly: sequencing conflicts, trade handoffs, who is behind. The mechanical work shrinks and the judgment work expands, which is the only version of tooling that makes a team better rather than just faster.

And the record you present is the record the model supports. When a trade challenges an issue six weeks later, you open the history, point at the elements, and show the screenshot, the tagged user, and the model commit that closed it. That is a short conversation. The alternative is a long afternoon rebuilding a thread to defend a decision you already made.

The Client Who Won't Pay for a Meeting Will Pay for an Answer

Most firms give away their coordination work. It shows up as free pre-construction effort, a courtesy review at 30% design, a quick sanity check for a repeat client. All of that is real work that produces real value, and none of it appears on an invoice. The reason is simple: a review meeting is a line item someone has to justify, and it looks like overhead.

An answer is different. When you can put a clean change set in front of an owner at 15% design, and again at 40%, and again at the review session, you are not selling a meeting. You are selling decision support, and owners buy decision support. Early reviews become a service you can bill for, and the same live record that produces them makes the billing defensible because the hours and the outputs are traceable.

This is where the done-for-you side of BidLight fits. Beyond the software, the team does BIM work directly: execution plans, 4D sequencing, fabrication detailing and spooling, and as-built modelling. Firms that want to offer these services without staffing them internally can bring BidLight in, and firms that want to run them in-house have the software path. Both routes end at the same place, which is a project record the client can trust.

Think about the pitch from your client's side. They have an owner asking whether the schedule is still real. They have a design team making changes. They have a contractor telling them a clash is "being looked at." What they want is a record that tracks the design, and they want it while the design is still moving. That is what a live record is.

So the commercial argument for this is not that you save a few hours on each review, though you do. It is that you can sell a service your competitors are still giving away, using the same model they are already producing, backed by a trail nobody has to reconstruct later.

What to Check Before You Publish Your First Revision

The first thing to look at is model hygiene. Walk a typical floor and check whether elements carry level, type, and system information or whether they are placeholders. The comparison reads what is there, so a model full of unassigned families produces a coarse change list with a lot of unowned items, and a model with real metadata produces a tight one. This is usually a week of cleanup, not a re-modeling project.

The second thing is your category and ownership structure. Before you rely on the comparison, decide who owns structural, MEP, envelope, and interior changes on this job. If everything rolls up to one person, the 6am digest will show you a single overloaded inbox. Firms that get the best result spend an afternoon naming owners first, and that work pays off regardless of which tool they end up using.

The third is milestones. Each publish carries a milestone, and it is worth deciding what yours are: design development issue, coordination freeze, IFC set. A firm working across several packages will still want its own naming rules layered in. The point of a milestone is that it removes the "which version is current" argument, not that it removes your knowledge of your own project. That argument alone is the 11 hours a week many coordinators lose.

Then run a live comparison. Take a project you have already coordinated, pick two revisions, and put the comparison next to what your team actually flagged at the time. Look at where they diverge and why. Most coordinators find the divergence is in a few odd assemblies that moved without anyone announcing it. That exercise also tells you how much of your current process is hunting and how much is judgment, which is useful information when you are deciding how far to take this.

Finally, plan the meeting where it matters. The value of a live record is not visible in a report. It is visible in the room when the design moves and the change list moves with it. Pick the next design review, put the model and the comparison on the same screen, and let the architect change something. That is the moment the whole idea either lands or does not, and it lands fast.

One Live Record, One Version You Can Defend

The takeaway is short. Stop chasing scattered updates and stale markups. BidLight keeps one live record of the project inside Revit and Navisworks. Every publish is a versioned snapshot. Any two revisions compare element by element, grouped by category. Issues pin to the geometry, carry the sheet and revision, and close only with a screenshot, a tagged user, and the model commit that fixed them. Publish the model and you see what changed in minutes. Move something in the design and the record follows.

What that buys you is not a faster filing system. It is the ability to answer the "what does this touch" question while the design question is still open, which is the moment rework is cheapest to stop. It is the ability to turn early reviews into a service you bill for rather than a courtesy you absorb. And it is a record that traces back to model elements, so when someone asks how you got there, the answer is a thirty-second walkthrough instead of a rebuild.

If you remember one thing about BidLight, remember the architecture. One live record of the project inside Revit, with every export versioned and every change diffed. Everything else, the 6am digest, the closing rules, the done-for-you BIM services, the subscription tiers, is in service of that single idea.

The next time the architect moves a wall in front of the client, you will not be the person promising a summary. You will be the person reading it off the screen.