A pipeline inspection report is not finished when the data is processed. It is finished when it survives the client review. That review usually has two parts: the client's comments on the document, and a meeting where the survey team has to explain the results face to face. This article is based on the review and rectification notes for a side scan sonar inspection report on a 14-inch subsea gas pipeline. I was involved as project surveyor and surveyor. The notes list what had to be corrected in the report, and the questions the team expected the client to ask, with the answers we prepared. Client, pipeline and location details are left out. The survey in short The pipeline was inspected with a towed side scan sonar (a StarFish 452F) to map its condition from the outside: free spans, pipe supports, debris, seabed features such as pockmarks and coral, and any sign of movement. The results were compared with a previous survey of the same line. The report ran to well over a hundred pages, with listings of free spans and pipe supports in the appendices. Part 1: the corrections None of the review comments were about the interpretation itself. All of them were about consistency: the same fact written differently in different places. That is typical, and it is exactly what a client reviewer is good at finding. The corrections fell into a few groups. Equipment description. The sonar model was written as "StarFish 450" in one place and had to be corrected to the model actually used, the 452F. In the equipment configuration, the sonar was also described with the wrong label: it is a towfish, not a transducer for the sub-bottom profiler. A wrong model number looks small, but it makes the reader ask what else in the report was copied from an older document. Geodesy. The UTM zone in one section of the report was wrong. The data had been processed in the correct zone; only the text was wrong. But a client cannot know that from the document. A wrong zone in a report is a red flag, and it has to be fixed even when the data is right. A debris position repeated three ways. One linear debris item appeared at three slightly different KPs in different parts of the report. All three were corrected to the same value, the one from the processed contact list. When one item is reported in the summary, the main text and the chart, all three should come from the same source and not be typed again by hand. Pipe support counts. The number of pipe supports found was given as 47 in several places and had to be corrected to 46, including in the summary, the free span appendix and the conclusions. One free span had been recorded with two supports when there was one. A single correction in the listing changed the total, and the total appeared in five places. Feature dimensions. The height of a coral feature was corrected from about 13 m to 11 m, to match the measured data. Typing errors. A water depth range written with a stray symbol, and a misspelled word. Small, but they all go in the review log. The lesson from this list is not "check harder". It is that every number in a report should have one source. Totals, KPs and counts that are typed into the summary separately from the listings will drift apart. The fix is to generate summary tables from the same data as the appendices, and to search the whole document for every number that changes. Part 2: the questions we prepared for Before the review meeting, the team wrote down the questions the client was likely to ask, with a short answer for each. This is one of the most useful habits in survey reporting. The questions were all about the same thing: can we trust this result, and what does it mean for the pipeline? "Compared with the previous survey, has the pipeline moved?" The new position of the pipeline was compared with the previous survey. There were small differences, but they were within the positioning tolerance of the two surveys, so the conclusion was that the pipeline had not moved. The answer also pointed to the physical evidence: if a pipeline is moved by anchor drag or strong current, it leaves marks on the seabed, such as scars or a displaced trench. None were seen in the new data. "The smart pig found a possible anomaly. Why did the side scan not see it?" This is a fair question, and the honest answer is that the two tools look at different things. An intelligent pig measures the pipe wall from the inside. Side scan sonar sees the outside of the pipe and the seabed around it. A pig can stop or record a suspect location for reasons that are not visible from the outside. What the side scan can say is that, at that location, there was no visible bend, buckle, external damage or other anomaly. Both statements can be true at the same time. "How accurate is the survey, and how confident are you?" Accuracy depends on the whole chain: vessel positioning, the USBL tracking of the towfish, the sonar itself and the processing. The answer gave two numbers with different meanings. Absolute position accuracy was in the order of 5 m, consistent with the previous survey. The image resolution at the suspect locations was much finer, about 10 cm per pixel, which is what matters for seeing small features on the pipe. Separating "where is it" from "how much detail can we see" makes the answer much clearer. "Why are there 289 more free spans than in the previous survey?" Free spans change over time, and the answer listed the natural causes: - Pockmarks: shallow gas escaping through the seabed leaves depressions. A section of pipe that was resting on the seabed can end up spanning a new pockmark. - Seabed currents scouring sediment from under the pipe. - Fish and other marine life feeding or nesting directly under the pipeline, which can slowly excavate the seabed. "Why did 97 free spans disappear?" The same processes can work the other way. Currents move sediment back under the pipe, and a span that existed before can be filled in naturally. These spans were reported as naturally rectified. Both answers make the same point: a free span list is a snapshot. The comparison between surveys is as important as the list itself, because it shows where the seabed is active. What I took from it - Most review comments are about consistency, not interpretation. Build the report so that each number has one source. - Treat geodesy errors in the text as seriously as errors in the data. The client cannot tell them apart. - Write the likely questions down before the meeting, with answers. If you cannot answer a question in two or three sentences, the report probably does not explain it well enough either. - Be clear about what each tool can and cannot see. Side scan and intelligent pigging answer different questions, and saying so builds more trust than defending one result against the other. - Separate position accuracy from image resolution. They are different numbers and clients often mix them up. - Present changes between surveys as information, not as a problem. New and disappeared spans tell the client where the seabed is moving.