Deliverables, Specs & LOA

A capture specification is not a procurement ritual; it is the single document that aligns what you imagine, what the capture team delivers, and what the job actually requires. It need not be long — half a page is often enough — but it must name the few things that everything else hinges on. The anchor is always the same: purpose. State, in one plain sentence, what the data is *for* — a heritage record, clash coordination for a services upgrade, a fit-out as-built, a feasibility massing, a facilities model — because purpose silently sets every other line. A spec that skips purpose is a spec that will be interpreted, and interpretation is where mismatches are born.

From purpose flow the rest. Accuracy / LOA: how close to reality the deliverable must be, expressed as a tolerance, not the word "high". LOD / detail: how much is modelled and how richly — bare walls and openings, or services, mouldings and fixtures too. Coverage: exactly which spaces, elevations and extents are in scope, and — just as important — what may be left out (roof voids, plant rooms, a tenanted floor). Deliverable formats: the actual files you will receive and can open. Control: how the data is tied down and how its accuracy will be evidenced. A seventh line, rights and data handling, we treat in the next lesson but belongs in the same document. Write those lines and the brief stops being a guess.

The discipline is to write the spec from the job *backwards*. Start from the decision the data must support and ask what accuracy, detail and coverage that decision genuinely requires — then specify exactly that, with a sensible margin, and no more. Over-specifying is a real cost: survey-grade accuracy and exhaustive detail on a job that needed neither buys you a bigger invoice, heavier files and a slower workflow for no benefit. Under-specifying is worse: it buys you a deliverable that looks impressive and cannot do the one thing you needed. A good spec is therefore an act of design judgement, not paperwork — it is where you decide, consciously, what 'good enough' means for this job. And where any figure in it must be certified or legally binding, the spec hands that line to a licensed surveyor rather than asserting it itself.

Two ideas do most of the work in a capture spec, and conflating them causes real trouble. Level of Accuracy (LOA) describes how closely the data and the model match the real world — the tolerance, the permissible deviation from reality. Level of Development or Detail (LOD) describes how much is modelled and how richly — whether a wall is a simple plane or carries its layers, whether services and fixtures are included, how fine the geometry goes. They are independent axes: you can have a highly detailed model that is poorly located, or a sparse, schematic model that is extremely accurate where it exists. A spec must state both, because asking for one while meaning the other is a classic route to disappointment.

Picture the two-by-two. A model can be *high detail, low accuracy* — richly modelled services that are in roughly the wrong place, convincing and misleading at once. It can be *low detail, high accuracy* — just the walls and openings, but each one reliably within a tight tolerance, which is exactly right for a coordination shell. It can be *high-high*, the expensive ideal reserved for where it is truly needed, or *low-low*, a quick massing that is honest about being approximate. None of these is 'better' in the abstract; each fits a different purpose. The skill is to place *your* job in that grid deliberately and specify the LOA and LOD that box requires.

There is a further honesty the spec must carry. Capture accuracy, model accuracy and deliverable accuracy are not the same thing. A point cloud captured to a few millimetres can become a BIM model with larger deviations, because scan-to-BIM is still a largely manual act of interpretation (Module 6) in which a modeller fits idealised, usually straight and square, elements to imperfect, real, out-of-plumb surfaces. So the LOA you specify for the *model* is a statement about the finished deliverable, and it should be stated and checked as such, not assumed to equal the cloud's accuracy. Frameworks exist to standardise these levels, and they evolve — treat any specific grade or number as a convention to be agreed on the project, and defer any binding accuracy statement to verified specifications and, where it must be certified, a licensed surveyor. What matters for your practice is the habit: state both axes, keep them distinct, and never let a beautiful, detailed model be mistaken for an accurate one.

A capture job produces a chain of deliverables, and you pay for very different things depending on where in that chain you stop. At the raw end is the registered point cloud itself — the measured data, exchanged in formats such as E57 (an open, vendor-neutral standard) or vendor formats like RCP. Above it sit derived products: a mesh (a surface skinned over the points, often textured, great for visualisation and communication but not the same as a measured cloud), orthoimages and sections, and at the far end a BIM model delivered as a native file (for example an RVT) or the open IFC exchange format. Each step adds human interpretation, time and cost — and each serves a different use.

The practical point is to specify the deliverables you can actually *use*, in formats your tools can *open*, at the point in the chain your job needs. A common and painful mismatch is paying for a gorgeous textured mesh when what the project needed was a coordinated BIM model — or receiving a BIM model in a native format nobody on the team can open, when an IFC would have served everyone. Ask plainly: will I receive the registered cloud, or only a derived model? In which formats? Can my software read them? Is the BIM native, IFC, or both? Is a QA/registration report included? The answers decide whether the deliverable is an asset or an ornament.

Scale and compatibility also deserve a line in the spec. Point clouds and meshes can be very large (Module 5.4), so agree how the data will be delivered and structured — tiled or decimated versions for lightweight review alongside the full-resolution master — and confirm your hardware and software can handle it. Clarify what you may do with each deliverable: the registered cloud is the durable, reusable asset you will return to for years, whereas a one-off render is spent on delivery. And remember the quiet deliverable that matters most for trust — the report documenting coverage, registration residuals and control — which the previous lesson taught you to demand. Specify the chain you need, the formats you can open, the structure you can handle, and the report that proves it, and you will pay for data that works rather than data that merely impresses. Binding accuracy in that report, as ever, is the surveyor's to certify.

A specification only protects you if you *receive against it*. When a deliverable arrives, the professional act is to check it back line by line against the spec you wrote: does the coverage match what was scoped, is the accuracy evidenced to the LOA you asked for, is the detail at the LOD you specified, are the formats the ones you can open, and is the control and QA report present? This is the moment the quality skills of Lesson 9.1 meet the specification of this lesson — the spec tells you what to expect, and the quality audit tells you whether you got it. Receiving without checking against the spec is simply writing a spec and then ignoring it.

Handle the inevitable gaps as a conversation, not a confrontation. Most mismatches are honest — a room was locked, a format was assumed, an extent was ambiguous — and a spec gives you the shared reference to resolve them fairly: "the scope named the second floor; it is not in the delivery" is a factual sentence both sides can act on, where "this isn't what I wanted" is not. This is why the spec protects the capture team as much as the client: it defines done, so that what was delivered can be measured against what was agreed rather than against what either party privately imagined. Clear specs make for fair dealing and repeat relationships.

Finally, treat each job as a chance to sharpen your own specifying. Note what you had to ask for that should have been in the spec, what you over-specified and paid for needlessly, what formats actually served the team, and what the checking found. Over a few projects this turns into a reliable house template — your standard capture spec — that you adapt rather than reinvent, and that steadily raises the quality of what you receive while lowering the friction of getting it. And keep the firm boundary in view throughout: where the brief requires certified or legally binding accuracy, georeferencing to a national datum, or any survey-grade deliverable, that line is not yours to specify into existence — it is commissioned from a licensed surveyor, and your spec simply says so. Specify clearly, receive rigorously, defer honestly, and capture stops being a gamble and becomes a service you can direct.