The same six things go missing from first-time LiDAR procurement briefs with surprising regularity. Each one looks technical enough to leave to the operator; each one quietly determines whether the delivery is engineering-grade or marketing-grade. The fixes are one sentence each.
If you've ever assembled a LiDAR procurement brief, sent it to three providers, and received three quotes that look comparable on price but actually cover wildly different scopes of work, you've met the procurement-checklist problem. Most first-time briefs miss six specific items. Operators interpret the gaps differently. Quotes diverge accordingly. The cheapest one wins the contract; the delivery is whatever the cheapest interpretation was.
This article is the consolidated buyer-side checklist drawing on the deeper articles across the rest of this site. Six items worth specifying in every brief, why each gets missed, what happens without it, and the single sentence that fixes each.
What it is. Post-Processed Kinematic correction of the GNSS+IMU trajectory against a logged base station — the processing step that turns capture-time positioning into audit-defensible cm-grade accuracy.
Why it gets missed. PPK sounds like operator-side workflow detail. Buyers reasonably assume the operator picks the right processing pipeline. Quotes don't typically separate "PPK" as a line item.
What goes wrong without it. Operators who don't carry PPK infrastructure use real-time RTK only. RTK is good when the radio link holds; it falls back to standalone GNSS (±1-3 m accuracy) for any segment where the link drops. The result is a delivery that's internally consistent and absolutely off by metres in places — discoverable only via independent control checkpoints at QA.
(The RTK vs PPK article covers the full technical case.)
The sentence to add. "Trajectory must be PPK-corrected against a logged base station RINEX. Base log to be supplied with the QA pack."
What it is. Surveyed control points captured by the LiDAR but withheld from the trajectory calibration — used purely to validate the final cloud against ground truth.
Why it gets missed. "Ground control" sounds like a single concept. Buyers don't realise there's a meaningful distinction between control marks used in calibration (guaranteed to fit the solution) and marks withheld for validation (the only honest accuracy measure).
What goes wrong without it. Operator validates the cloud against control marks that were used in the calibration. The residuals look great because they were forced to. Independent audit later reveals the cloud is off by significant amounts in areas the calibration didn't touch.
(The accuracy article and the QA report article both cover this in depth.)
The sentence to add. "QA pack must report residuals at independent ground control checkpoints — marks withheld from the trajectory calibration. Minimum 20 checkpoints across the project area."
What it is. The operator's commitment to retain raw source data (RINEX logs, sensor files, IMU log, original processing configuration) for a defined period after delivery.
Why it gets missed. First captures focus on the immediate deliverable. The question of what happens 18 months later when a reprocess request arrives doesn't surface until 18 months later.
What goes wrong without it. Project owner returns for a reprocess request — different format, additional deliverable, tighter contour interval. Operator's archive policy retains 6 months by default; data is gone; the only option is full re-fly at full price. The reprocess that would have cost 20% of original capture becomes a 100% capture.
(The re-fly vs reprocess article covers what's recoverable from archive vs what isn't.)
The sentence to add. "Operator to retain raw archive (trajectory, RINEX, sensor logs, processing configuration) for minimum 12 months from delivery, with reprocess pricing schedule documented in the contract."
What it is. A documented bundle of metadata, capture parameters, trajectory quality, strip alignment results, checkpoint residuals, classification quality, density coverage map, surface QA notes, deliverable manifest and sign-off.
Why it gets missed. "We need the point cloud and the DTM" covers the visible deliverables. The QA pack sounds like internal documentation rather than buyer-facing material.
What goes wrong without it. Delivery arrives as point clouds + surface files. No residuals report, no classification quality metrics, no density coverage map. The accuracy claim is unverifiable; problems surface only when the design team finds anomalies downstream. By then the operator has moved on.
(The QA report article details what every section should contain.)
The sentence to add. "Delivery must include a QA pack documenting capture parameters, trajectory quality (covariance plot), strip alignment residuals, independent control checkpoint residuals (stratified by cover class), classification quality summary, density coverage map and sign-off by an independent reviewer."
What it is. Specific format, version, compression, tile structure, naming convention and manifest format for every deliverable.
Why it gets missed. "LAS files" is the obvious answer. Buyers don't realise LAS has versions (1.0 to 1.4), can be compressed (LAZ) or not, can be tiled or single-file, can be named in multiple conventions, and may or may not ship with a manifest.
What goes wrong without it. Delivery arrives as LAS 1.2 single-file in operator's default naming. Project's design software needs LAS 1.4 tiled by 500 m grid. Conversion takes a day of in-house effort and risks losing extended classification classes that LAS 1.2 can't store.
(The LAS/LAZ article and the tile structures article both cover the details.)
The sentence to add. "Primary deliverable in LAS 1.4 LAZ-compressed (PDR 6 minimum), tiled by 500 m grid aligned to MGA coordinates, coordinate-based filenames, JSON manifest documenting tile structure + datum + classification scheme."
What it is. Reporting checkpoint residuals separately for bare ground vs sparse vegetation vs moderate vegetation vs dense canopy, rather than as a single aggregate number.
Why it gets missed. RMSE is a single number; project specs quote a single number; everyone agrees on the number; nobody asks for breakdown.
What goes wrong without it. Project accepts capture against aggregate ±25 mm RMSE. Bare-ground areas are at ±18 mm; dense canopy areas are at ±60 mm. Design team works against assumption of 25 mm tolerance and discovers the canopy areas drift by twice that. Diagnosable only via stratified report.
(The reading residuals article walks through the diagnostic patterns.)
The sentence to add. "Residuals report must stratify checkpoint residuals by cover class (bare / sparse / moderate / dense), reporting RMSE + mean + maximum per class."
Combining the six fixes into a single brief paragraph:
"Engineering-grade drone LiDAR capture, target ±20 mm RMSE vertical at independent ground control checkpoints (minimum 20 marks across project, withheld from calibration). Trajectory PPK-corrected against logged base station RINEX. Point cloud delivered as LAS 1.4 LAZ-compressed PDR 6, tiled by 500 m grid aligned to MGA coordinates with coordinate- based filenames + JSON manifest. DTM at 0.5 m resolution as GeoTIFF + LandXML, hydro-enforced at structures listed in Appendix A. Full QA pack including capture metadata, trajectory covariance plot, strip alignment residuals, cover-class-stratified checkpoint residuals, classification quality summary, density coverage map, sign-off by reviewer independent of processor. Operator to retain raw archive (RINEX, sensor logs, processing configuration) for 12 months minimum with reprocess pricing schedule documented in contract."
That paragraph is ~120 words and eliminates the entire class of ambiguity that drives the variance in comparable quotes.
The flip side: three things buyers often pin down that they shouldn't, because doing so either inherits a stale constraint or limits the operator's ability to deliver efficiently.
Sensor brand or model. "Must use RIEGL VUX-1" without explaining why. Specify the capability (density, accuracy, range, return depth) and let the operator pick. (See sensor classes article.)
Platform brand or model. "Must use Wingtra" without explaining why. Specify the project envelope (area, access, endurance need) and let the operator pick the airframe class. (See platform trade-offs article.)
"Highest possible accuracy" without need. Specifying engineering grade ±20 mm for a feasibility study that's fine at ±100 mm doubles the project cost and adds nothing. Specify what the deliverable actually needs.
Beyond the brief content, two operator-side things worth confirming before requesting quotes:
CASA approvals. ReOC + RePL minimum; any specific approvals your project needs (BVLOS, populous areas, controlled airspace). The CASA permits article covers the 6-document validation checklist.
Insurance. Public liability minimum $10-20M for survey operations; higher for projects in populated areas or with specific contract requirements.
Operators that can't produce certificates within a day of request are signalling something about their administrative maturity that matters more than their quote.
Six items first-time LiDAR buyers reliably miss:
Each fix is one sentence in the brief. Together they eliminate most of the post-delivery surprises that drive procurement regret.
Three things to NOT over-specify: sensor brand, platform brand, "highest possible accuracy" without need.
Combine the six fixes into the clean procurement brief example above (~120 words) and quotes against it are genuinely comparable. Quotes against a vaguer brief are quotes against different work, dressed up as the same number.
Send through the draft. We'll cross-check against the six-item list and the 'do not over-specify' patterns, then quote against the cleaned version. The brief that comes back is the one you should send to other operators too — comparability across quotes is the whole point.
The 10-section pack item 4 of this checklist requires — what each section should contain and why.
Where each of the six items affects the price band — and where over-specifying inflates cost without engineering value.