Marine Survey Technology
Survey Report Deliverables: What a Client Actually Receives and How to Read Them
A finished survey is judged by what arrives in the client's hands afterward — not by the acquisition or QA/QC work that happened before it, however carefully that work was done. Knowing what a proper deliverable package actually contains, and what to look for inside it, is what separates a client who can independently trust a survey report from one who simply has to take the contractor's word for it.
A Deliverable Package Is More Than One File
NOAA's own Hydrographic Survey Specifications and Deliverables (HSSD) standard, which governs government hydrographic survey submissions, defines survey products as a set of distinct pieces rather than a single report: BAG (Bathymetric Attributed Grid) files carrying the actual depth surface, a Descriptive Report narrating the conditions and judgment calls made during the survey, smooth sheet images as the traditional cartographic record, geo-referenced side-scan sonar mosaics, textual gridded data, and FGDC/RSE-compliant metadata describing how all of it was produced. No single one of those pieces is the deliverable — the depth grid without the narrative report is data without context, and the report without the grid is context without anything to apply it to.
The Descriptive Report Is Where the Judgment Calls Live
The Descriptive Report is explicitly a narrative metadata document — it describes the conditions under which the survey was conducted and discusses the factors affecting the adequacy and accuracy of the results, rather than simply restating the numbers already present in the data files. NOAA's specification requires surveyors to discuss every case where a feature's classification deviated from default criteria, meaning the report is where a client finds the judgment calls a data file alone can't communicate: why a particular area was flagged for reduced confidence, why a re-survey line was or wasn't run, what equipment or environmental conditions might have affected a specific section of the survey area. A deliverable package without this narrative context puts the burden of interpreting every anomaly back on the client, who wasn't there to see the conditions that produced it.
A Parallel Example From an Adjacent Discipline
Geotechnical survey work offers a useful point of comparison for what a mature, structured deliverable standard looks like in practice. The AGS (Association of Geotechnical and Geoenvironmental Specialists) data format, first developed in 1992 and now the de facto standard across the UK, Ireland, Singapore, Australia, New Zealand, and Hong Kong, structures borehole logs and test reports into a defined, machine-readable CSV-style format organized into data groups and fields, rather than leaving factual ground investigation data to be delivered as unstructured PDF reports. The parallel to hydrographic deliverables is direct: a well-structured deliverable standard doesn't just make data easier to read for a human client, it makes that data reusable in a GIS, an engineering model, or a future comparative survey without someone having to manually re-transcribe it first.
Reading Uncertainty Instead of Skipping Past It
Every credible hydrographic deliverable includes an uncertainty figure attached to the data, not as a disclaimer to be skimmed past but as a specific, load-bearing number a client needs to read against their own intended use of the data. A depth grid that meets IHO S-44 Special Order uncertainty is suitable for berth clearance in a busy port; the same nominal accuracy claim without a stated uncertainty behind it tells a client nothing verifiable at all. A deliverable package that states an uncertainty figure without the calibration and validation evidence behind it — the kind of a priori and a posteriori chain covered elsewhere on this site — is making an assertion, not demonstrating a result.
What a Client Should Actually Check
In practice, a client evaluating whether a deliverable package is complete and trustworthy rather than merely "finished" should expect to find: raw or processed depth data in a documented format, a descriptive or narrative report explaining conditions and any deviations from standard criteria, supporting acquisition and control documentation (the DAPR/HVCR equivalent for the project type), a stated uncertainty figure tied to a recognized standard, and metadata sufficient to understand how the data was produced without contacting the surveyor directly. A package missing any of those pieces isn't necessarily wrong — but it is asking the client to trust the result rather than verify it.
The Deliverable Is the Contract, Not Just the Output
A survey's technical quality and its deliverable's completeness are two different things, and only the second one is directly visible to a client who wasn't on the vessel. Structured metadata, a genuine narrative report, and an honestly stated uncertainty figure are what let a client extend trust based on evidence rather than reputation alone — and what let that same data still be usable, and auditable, years after the survey team has moved on to the next project.
References
- NOAA Office of Coast Survey, "Hydrographic Survey Specifications and Deliverables (HSSD)," https://www.nauticalcharts.noaa.gov/publications/documents/HSSD_2026-0-00.pdf
- NOAA National Centers for Environmental Information, "National Ocean Service (NOS) Hydrographic Survey," https://www.ncei.noaa.gov/products/nos-hydrographic-survey
- Digital Geotechnical, "Introducing the AGS Data Transfer Format," https://digitalgeotechnical.com/2024/03/introducing-the-ags-data-transfer-format/
- Association of Geotechnical and Geoenvironmental Specialists, "Electronic Transfer of Geotechnical and Geoenvironmental Data AGS4," https://www.ags.org.uk/content/uploads/2020/11/Electronic-Transfer-of-Geotechnical-Data-4th-Edition-Addendum-4.pdf
- British Geological Survey, "AGS Data Format," https://www.bgs.ac.uk/ngdc/ags-data-format/
Related Articles
