Survey specification review checklist

What is actually being bought, stated tightly enough to price and to reject.

• Is the survey objective stated as a decision the data must support, not just an area and a method? A contractor can meet an area-and-method spec perfectly and still deliver data that answers nothing.
• Are all deliverables listed by name, format and content — not as 'industry standard deliverables'?
• Is it explicit which deliverables are contractual (rejectable) and which are informational?
• Are corridor widths, coverage overlaps and infill obligations quantified?
• Does the specification say who owns raw data, and whether it must be delivered alongside processed products? Processed-only delivery makes every future dispute unresolvable and every reprocessing impossible.
• Is there a defined mechanism for scope change offshore — who can authorise it and at what price basis?

The single most common root cause in survey failure analysis. None of these are pedantry.

• Is the project CRS named by full identity (datum, realisation/epoch, projection, units) rather than an ambiguous shorthand? 'WGS84' names a family, not a frame. Metre-level ambiguity enters projects exactly here.
• Are transformation parameters between acquisition, processing and deliverable CRS stated explicitly, with their source?
• Is the vertical datum defined — including the separation model and its version — for every depth or elevation deliverable?
• If legacy data will be integrated, is the CRS of that data verified from records rather than assumed from its age?
• Does the spec require the contractor to state, in the deliverable metadata, every CRS decision they made?
• Has someone competent checked that the specified CRS is actually appropriate for the project area and its client systems?

Claims are cheap; the spec must make them checkable.

• Are positioning accuracy requirements stated with a confidence level (e.g. 95%) and a reference frame, not as bare numbers?
• Is the required positioning redundancy specified — and what happens operationally when it degrades?
• Are calibration requirements (USBL, MBES patch test, gyro, lever arms) specified with acceptance values and required records? An uncalibrated spread produces confident, wrong data. Records are the only defence after the fact.
• Does the spec require verification of equipment condition and firmware against what was tendered?
• Are GNSS-denial and interference scenarios addressed for the project area — fallback sensors, alert thresholds, abort criteria?
• Is subsea positioning accuracy specified at the depth and geometry of the actual worksite, not at the transducer?

The platform constrains the survey more often than the sensors do.

• Are vessel requirements stated as capabilities (station keeping, noise, power, deck space) rather than as a named class only?
• If DP is required, is the DP class justified by the operation — and are DP incident reporting obligations written in?
• Are mobilisation and demobilisation scope, location and acceptance defined — including who witnesses the trials?
• Is simultaneous-operations (SIMOPS) interaction with other contractors addressed, with a named coordination mechanism? Separately contracted parties on one site is where responsibility quietly evaporates.
• Are permits, notifications and marine licences allocated to a named party with dates?

The spec buys people as much as instruments.

• Are key roles (party chief, senior surveyor, online/processing leads) specified with competence requirements, not just headcount?
• Does the spec require named CVs for key personnel — and consent rights over substitutions after award? The team that wins the tender and the team that mobilises are frequently not the same people.
• Are minimum experience requirements tied to the actual work type and area, not generic years-in-industry?
• Is there a defined competence expectation for the client's own representative offshore?

If acceptance criteria cannot be tested, the client has agreed to accept everything.

• Is every acceptance criterion measurable with the data and records the spec itself requires to be delivered?
• Are accuracy requirements traceable to a recognised standard (e.g. IHO S-44 order) — and is that standard's edition stated?
• Are QC procedures during acquisition specified — crossline requirements, real-time monitoring, rejection thresholds?
• Is there a defined client review gate before demobilisation, while re-survey is still cheap? Deficiencies found after the vessel sails cost an order of magnitude more to fix.
• Does the spec define what happens on failure — re-survey obligations, at whose cost, on what timeline?
• Are audit rights (records, calibrations, raw data, personnel) written in explicitly?

Deliverables that cannot enter the client's systems were never delivered.

• Are formats specified by version (not 'CAD format' or 'GIS-compatible'), and confirmed loadable by the client's actual systems?
• Is deliverable metadata specified — content, schema, and the CRS statements from the geodesy section?
• If the client uses a data model (e.g. IOGP SSDM), does the spec require compliance with a named version of it?
• Are delivery milestones tied to review windows, not delivered as one package at demobilisation?
• Is data security and transfer method specified for each deliverable class?

Weather optimism is a commercial decision disguised as a technical one.

• Are operational limits stated per activity (not per vessel), with the parameter and threshold that suspends work?
• Is the weather-downtime allowance derived from data for the actual area and season — and is the derivation available for review? A downtime figure copied from the last project is the most expensive line in the spec.
• Is the boundary between weather standby and contractor delay defined sharply enough to invoice from?
• Are metocean measurement obligations during the survey (if any) specified with instruments and QC?
• Does the schedule have named decision points for seasonal deterioration, rather than an implicit hope it holds?

Where technical gaps become invoices.

• Does the pricing structure match how risk is actually allocated (lump sum vs day rate vs hybrid), or does it contradict it?
• Are standby, re-survey and re-processing rates agreed in the contract, not left to negotiation offshore?
• Is liability for data errors addressed explicitly — including errors discovered after acceptance?
• Are insurance and indemnity requirements consistent with the SIMOPS and vessel sections above?
• Has the whole specification been reviewed by someone independent of both the template it came from and the project schedule pressure? The review this checklist structures. A spec nobody outside the project has read is an assumption, not a document.