Levels of Accuracy & Detail

Level of Accuracy (LOA) is the answer to a simple, crucial question: *how closely does the model match the real building?* It is about fidelity to reality — how far a modelled surface is allowed to deviate from where that surface actually is, as measured in the cloud. A high-LOA model hugs the real geometry to a tight tolerance: the modelled walls sit within a few millimetres of the real ones, the sloping floor is modelled as sloping, the out-of-plumb column leans as it really leans. A low-LOA model is a looser abstraction: walls idealised to clean planes that may be centimetres from reality, floors modelled flat though they sag, the real deviations smoothed away. Note that LOA refers to the *model's* fidelity to the measured data; it is distinct from, and downstream of, the *survey* accuracy of the cloud itself — a model can be a faithful (high-LOA) representation of a cloud that is only moderately accurate, and no amount of careful modelling can make the model more accurate than the data beneath it.

There are two useful faces of LOA worth separating. One is the measured accuracy: the actual, checkable deviation between model and reality, which you can verify with a deviation analysis (the cloud coloured by distance from the model surfaces) and express as a tolerance. The other is the represented accuracy: the level you *intend* and claim for the model, which the brief should state so everyone knows how far to trust it. Trouble comes when these diverge unspoken — when a model is claimed or assumed to be tight but is actually loose. The discipline is to make the intended LOA explicit and to check the achieved LOA against it.

Why does LOA matter so much? Because people *act* on models. If a fabricator trusts a model to be accurate to a few millimetres and it is actually 50 mm out, the prefabricated part will not fit. If a model is honestly specified as a low-LOA idealisation, the fabricator knows to field-verify critical dimensions before cutting. The failure is rarely the abstraction itself — idealisation is often correct — but the mismatch between the accuracy claimed and the accuracy delivered. And a firm boundary applies: the *binding* accuracy of the underlying survey, and any accuracy figure that must be relied upon for a legal or structural purpose, is the domain of the licensed surveyor, the verified equipment specification and the governing standards — not a number the modeller asserts. LOA as taught here is a design and specification concept; the certified survey accuracy behind it belongs to the professionals.

The second dial is Level of Detail, closely tied in BIM practice to Level of Development (LOD) — and the pair answer a different question from LOA: *how much is in the model?* This has two intertwined parts. Level of Detail is the *graphical* richness — how finely the geometry is modelled. A low-detail wall is a simple slab; a high-detail wall might carry its layers, its skirting, its cornice, its every niche. Level of Development adds the *information* dimension — how much reliable data each object carries and how far it has progressed: is this "a generic wall" or "a 230 mm brick wall, plastered both faces, with these properties"? In existing-conditions modelling, detail usually means: how many element types do we capture (structure and enclosure only, or also MEP, fittings, finishes?), and how richly is each modelled and described?

Crucially, detail is not the same as accuracy, and conflating them is a classic error. You can have a richly *detailed* model — every duct, every fitting, beautifully modelled — that is *inaccurate*, sitting centimetres from where those things really are. You can have a sparse, low-detail model — just walls and floors — that is extremely *accurate* to the real geometry. The two dials move independently (revisit the axes figure). That is why a serious scan-to-BIM brief specifies both: not "an LOD 300 model" alone, nor "an accurate model" alone, but an intended level of detail *and* an intended level of accuracy, element type by element type if need be.

The practical content of a detail specification is a scope list with a depth for each item: which element categories are modelled (e.g. structure: yes, at this detail; internal partitions: yes; MEP: primary ducts and pipes only; finishes: no; furniture: no), and how much descriptive information each carries. This is where cost lives. Every additional element type and every extra increment of detail and information is more skilled manual hours (recall lesson 6.2). A good specification is therefore ruthless about modelling *what the use needs and no more* — rich detail on the systems you will actually work with, nothing on the ones you will not. Detail for its own sake is not virtue; it is unbilled — or over-billed — labour that also makes the model heavier and harder to use.

Here is the governing principle of the whole module, now made sharp: the use of the model sets both its required LOA and its required LOD. You do not choose levels by how good you can make the model, nor by habit, nor by what the software can do — you choose them by asking what decisions the model must support, and then model to exactly that, no more and no less. A concept or feasibility study can live happily at low accuracy and low detail — a rough shell is enough to test massing and ideas. A renovation or fit-out design needs *true geometry where you are intervening* (so new work fits) and moderate detail, but little fidelity or detail in the parts you are not touching. A heritage conservation record or a structural assessment needs high accuracy, faithful-to-deviation geometry, and rich detail — because here the real, imperfect geometry *is* the information. Same building, three entirely different correct answers, each set by the use.

The two failure modes are symmetric and both expensive. Over-modelling — building more accuracy or detail than the use requires — wastes money and time directly (all those extra skilled hours), produces a heavier, slower, harder-to-use model, and often creates a false impression of precision that invites people to over-trust it. It is the commoner sin among enthusiasts: modelling every socket and following every ripple on a job that only needed a clean shell. Under-modelling — less accuracy or detail than the use requires — is the more *dangerous* sin, because it misleads: a model that omits a structural element, idealises away a critical slope, or is looser than the fabrication that relies on it will cause clashes, misfits and bad decisions, often discovered only on site. The cruelty is that an under-modelled model can look completely convincing — nothing on screen warns you it is wrong.

The cure is to specify before you model, and check after. Before: write down, for the stated use, the required LOA and LOD — ideally per element type — so the modeller knows the target and the client knows what they are getting. After: verify the achieved accuracy against the intended LOA (deviation analysis) and confirm the scope and detail were met. And keep the relationship honest across the whole course: you are specifying the *model's* faithfulness and richness to suit a design use; the *certified survey accuracy* of the underlying data — and any figure that must bind legally or structurally — remains the licensed surveyor's responsibility against the governing standards. Match the model to the use, state both levels, check them, and you avoid both the waste of over-modelling and the danger of under-modelling.

The reason LOA and LOD matter beyond theory is that they give a shared, checkable language for a thing that is otherwise dangerously vague. "Give me an accurate model of the building" is not a brief — accurate to what tolerance, detailed to what depth, covering which elements, for what use? Without a stated level, the modeller guesses, the client imagines something else, and the mismatch surfaces late and expensively. A specification that states the intended LOA and LOD — ideally broken down by element type and tied to the use — turns a vague hope into an agreement that can be priced, produced and verified. This is why the topic belongs in a professional-practice frame as much as a technical one, and it is developed further in Module 9 on deliverables, specifications and level of accuracy.

A workable specification for an existing-conditions model typically names, for the stated use: the element scope (which categories are modelled), the level of detail/development for each (how richly modelled and described), the level of accuracy intended (how faithfully the model follows the real geometry, and the fitting tolerance), how deviations and gaps are to be handled and recorded, and whether the point cloud is delivered alongside the model as evidence. It is good practice to note, too, where idealisation has been applied and where the model should *not* be trusted without field verification — the honest counterpart to a stated accuracy. Several industry frameworks exist for expressing these levels (and their definitions and names evolve), so the durable skill is the underlying discipline — state both dials, tie them to the use, check them — rather than memorising any one scheme's labels.

Two honest caveats close the lesson. First, the terminology is genuinely unsettled: different standards and regions define and name "LOD", "level of detail", "level of development" and "level of accuracy" differently, and the same abbreviation can mean different things, so always agree definitions with your collaborators rather than assuming a shared meaning. Second, and most importantly, remember the division of responsibility that runs through the course: specifying a model's detail and its intended fidelity to the data is design and modelling work you own; but the *certified accuracy* of the survey itself — whether the cloud is genuinely good to a stated tolerance, whether it is correctly georeferenced, whether any deliverable is fit for a legally or structurally binding purpose — is the province of the licensed surveyor, the verified equipment specification and the governing standards and regulations (including, in India, the Survey of India framework). Specify the model wisely to the use; defer the binding survey to the professionals; and never let a confidently detailed model stand in for an accuracy nobody actually checked.