Level of Detail is usually discussed as a floor. Clients worry the model will not be detailed enough, that a supplier will hand over LOD 200 when the job needed LOD 300. That risk is real and it is worth watching. The opposite failure gets almost no attention and drains just as much budget: detail nobody asked for, added carefully, on a project that never needed it.
What over-modelling looks like in practice
On a recent low-LOD project we found bookshelves in the model. A junior had modelled them by cutting the wall with voids shaped like each shelf. On screen it read as a solid wall with a neat set of niches. Patient, careful work, entirely outside the agreed scope.
Two problems came out of it. The first was obvious. A level of detail this LOD never called for, paid for in hours nobody had budgeted. The second was worse and much less visible. The voids were cutting real volume out of the wall, so in the material schedules that wall was no longer a full wall. The quantities were quietly wrong. Anyone pulling a take-off from that model would have been working from corrupted numbers with no reason to suspect it.
We caught it in internal QA, before delivery. The shelves came out, the wall geometry went back to normal, and the quantities matched what actually goes into production again. Had it shipped, the discovery would have happened at procurement, in someone else's spreadsheet, several weeks later.
LOD is a budget agreement, not a quality setting
It is tempting to read a higher level of detail as better work. It is not. The LOD written into the scope is an agreement about what the client is paying for and what they are deliberately not paying for. A model built to LOD 200 for early coordination is doing its job perfectly at LOD 200. Pushing individual elements to LOD 350 because it feels more thorough breaks that agreement in two directions at once. It burns hours the client never authorised, and it produces a model that is inconsistent with itself, heavily detailed in the corners a modeller happened to enjoy and generic everywhere else.
That inconsistency is the real damage. A coordinator opening a model expects a predictable amount of information across all of it. When some elements carry far more geometry and data than the LOD calls for while the rest carry exactly what was agreed, the model stops being readable as a whole. Schedules become unreliable. Clash results get noisy with detail that was never meant to be there. One wall with hand-cut shelf voids costs you confidence in every wall around it.
The quantities are where it hurts
Geometry that exceeds the LOD is annoying. Geometry that changes a computed value is expensive.
Anything modelled as a void, a swept blend or an in-place element inside a host will show up in volumes and areas whether or not it belonged in the scope. Those numbers feed take-offs, cost plans and material orders, and none of the people downstream have any way of knowing that a wall reads 0.4 m³ light because a junior modeller was being thorough. The model looks correct. The schedule looks correct. The error is invisible until concrete arrives and someone is short.
This is why we treat over-modelling as a data problem rather than a stylistic one. A wall with the wrong finish is a preference. A wall with the wrong volume is a wrong number in a document the client will act on.
How we hold the line
Two habits keep this from reaching a client.
The first is writing the LOD into the project template and the modelling instructions before anyone opens Revit. The target has to be explicit and visible in the file itself, otherwise every modeller resolves the ambiguity by personal judgement, and the careful ones over-build. That is worth saying plainly, because over-modelling is almost always done by good modellers. Nobody adds shelf voids out of laziness.
The second is checking for over-modelling in QA with the same attention as checking for missing detail. A pre-delivery review that only hunts for gaps will pass an over-built model without comment. Missing detail announces itself, someone opens the model and cannot find what they need. Over-modelling fails silently, in the schedules, and the client finds it long after handover when the numbers stop reconciling.
If you are not sure what you received
If a model has landed on your desk and you are not certain it matches the LOD you agreed and paid for, in either direction, that uncertainty is worth resolving before the model starts feeding decisions.
That is what a model audit is for. We check that the level of detail is consistent across the model rather than concentrated in a few places, that the parameters behind the geometry hold real data instead of defaults, and that the quantities you are about to build a cost plan on can actually be trusted.
