Renzo Malatesta is a fictitious maritime accident investigator — a composite character drawn from publicly documented investigation methodologies, NTSB marine accident reports, and IMO casualty investigation standards. He does not exist, which is probably for the best, since a real person with his opinions about VDR manufacturers would have been sued by now. His surname, as he would tell you, means "bad head" in Italian, a fact he considers destiny rather than coincidence for someone who has spent a career reconstructing other people's worst decisions.
Maritime accident investigators are last responders. They show up when the debris field has settled and the question shifts from what do we do to what actually happened. Their tools have changed enormously in the past two decades. Voyage data recorders now capture bridge audio, radar sweeps, GPS positions, and dozens of parametric channels.1 AIS transponders broadcast vessel identity and movement to satellite and shore receivers.2 Email servers preserve weather advisories timestamped to the second.
The volume of data available to a modern investigator would have been unimaginable to someone conducting a wreck inquiry in 1920. Whether that volume has made reconstruction proportionally better is a question Malatesta finds genuinely funny.
You came to maritime investigation from aviation. What was the adjustment?
Renzo: The shock. Pure shock. In aviation, the flight data recorder captures sixty-some mandatory parameters in a standardized format. Any investigator with the right software can read any box from any aircraft. I walked into my first maritime VDR case expecting something comparable and discovered that every manufacturer uses proprietary formats, proprietary replay software, and the regulations say nothing about recording format.3 So you recover a capsule from the ocean floor after months of searching, and then you call the manufacturer and say, "Please help us read your device." You are dependent on their cooperation to access evidence in your own investigation. It would be like a police detective needing the gun manufacturer's permission to examine a bullet.
Does that actually impede the work?
Renzo: In at least one very public case, yes. Researchers working with the Costa Concordia VDR found useful data through reverse engineering that the official replay software didn't even display.4 The device captured information that the manufacturer's own tool chose not to show. If the investigators had trusted only the official playback, they would have missed it. And most investigators do trust only the official playback, because they don't have forensic data recovery teams sitting around waiting for interesting problems.
When you start a reconstruction, what's the first thing you look for?
Renzo: Timestamps. Everything else is secondary.
I need a backbone of time. Machine-generated, continuous, not dependent on someone remembering to write something down. GPS positions every few seconds. Speed over ground as a continuous curve. Heading from the gyrocompass. These are the bones. Everything else — audio, logbooks, witness interviews — gets hung on that skeleton. Without it, you're assembling a puzzle where you don't know if the pieces are from the same hour or the same watch or the same day.
And when the timestamps have gaps?
Renzo: Then you have a hole in the story, and you say so. AIS is self-reported, unencrypted, and it drops out for three basic reasons: system saturation in busy waters, equipment problems, or someone turned it off.5 You often cannot tell which. In one well-documented sinking, the last AIS position was recorded nearly four hours before the ship went down. Four hours. The entire terminal phase — flooding, loss of propulsion, the actual sinking — happened in a gap.6
You've described a hierarchy of evidence before. Things you trust more or less.
Renzo: Sure, but understand this hierarchy lives nowhere in any manual. You develop it. You get burned enough times and you start sorting.
At the top: machine-generated parametric data from independent sensors. GPS speed, gyrocompass heading, radar images captured at fixed intervals. These can't be retroactively edited. They don't depend on anyone paying attention or choosing to record something. A continuous speed plot over twenty-six hours will tell you more about a ship's deteriorating situation than every logbook entry combined, because the logbook captures what someone decided to write at the top of each watch. The speed plot captures what was actually happening between those entries.7
Below that: VDR audio. Invaluable, because it's contemporaneous. You hear the actual words people said, not what they remember saying six months later in a hearing room. In multiple investigations, the audio directly contradicted sworn testimony. A master who said he didn't realize his ship had struck a navigational aid — the VDR captured his verbal reaction to the impact.8 But audio has its own blind spots. Microphone placement, background noise, the fact that internal phone calls only capture the bridge side of the conversation. You hear the officer say "yeah" and "okay" but you have no idea what the engine room just told him.9
Then: maintenance logs, email records, logbooks. These are records of what was recorded. Full stop. A maintenance system can have hundreds of entries and still not tell you the actual oil level in the sump on the day that mattered.10 An email server can tell you exactly when a weather file was sent, when it arrived, and when someone downloaded it — which is extraordinary, actually. There's no historical analog for that kind of precision about information flow.11 But the weather file itself might contain data already twelve hours old by the time anyone looked at it.
And at the bottom, which will offend people: witness testimony. I don't mean it's worthless. I mean it's the thing I verify against everything else, not the thing I use to verify everything else.
What about inspection records?
Renzo: [long pause]
Inspection records are the most dangerous category. A record that says "inspection conducted, no deficiencies found" can be worse than no record at all, because it implies someone looked and the thing was fine. But what it actually documents is that a procedure was followed. Whether that procedure was capable of finding the deficiency — completely different question.
In one case, a classification society surveyed a vessel seven times in a single year. Seven times. After the casualty, investigators examined the sister ship and found severe corrosion inside ventilation trunks. The surveyors had been using an inspection port to check fire dampers. They weren't entering the trunks. The corrosion was invisible to the method.12
The record said the ship was fit for service. The record was, in a narrow procedural sense, accurate. The ship was not fit for service.
How do you teach people to see that distinction?
Renzo: You mostly can't, until they've lived through a case where it mattered. People — regulators, operators, lawyers — treat the existence of a record as evidence that the thing the record describes is true. But a record is evidence that someone created a record. The relationship between the record and reality is exactly the thing you have to investigate. It is not something you get to assume. That sentence should be tattooed on every auditor's forearm, but nobody asks me about tattoo policy.
Is there a category of question that records consistently fail to answer?
Renzo: What people knew.
Not what information was available. I can reconstruct that with timestamps and server logs and delivery receipts. But what someone understood from the information they had? Whether they recognized that two data sources were showing different things because one was twelve hours older than the other? Whether they knew the maximum angle at which their engine would keep running?13 That's the institutional question — authorization, awareness, responsibility. The physical reconstruction, I can usually get. The institutional reconstruction almost always has holes. The records were designed for compliance. I need them to answer questions their designers never imagined anyone would ask.
Does more data solve this?
Renzo: More data solves the problems that were caused by too little data. It creates entirely new problems of its own.
A twelve-hour rolling audio buffer means the beginning of a decision sequence gets overwritten by the end of it.14 You can hear the catastrophe. You can't hear the meeting three days earlier where someone decided on the route. More sensors with proprietary formats means more dependencies on manufacturers. More logbook fields means more places where someone can write "precautions observed" without specifying a single precaution.15
Volume is not fidelity. I have never once opened a case file and thought, "The problem here is that there weren't enough records." The problem is always that the records that exist don't answer the question that matters.
Footnotes
-
IMO, "Voyage Data Recorders." https://www.imo.org/en/ourwork/safety/pages/vdr.aspx ↩
-
NTSB, Sinking of US Cargo Vessel SS El Faro, Marine Accident Report NTSB/MAR-17/01, 2017, p. 47. https://www.ntsb.gov/investigations/accidentreports/reports/mar1701.pdf ↩
-
Cantelli-Forti, A. et al., "Insights from field experience: digital forensics of event and voyage data recorders," International Journal of Information Security 24(4), 2025. https://link.springer.com/article/10.1007/s10207-025-01084-2 ↩
-
Ibid. ↩
-
PLOS ONE, "Detecting suspicious activities at sea based on anomalies in AIS transmissions," 2018. https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0201640 ↩
-
NTSB El Faro Report, p. 47. ↩
-
NTSB El Faro Report, pp. 19, 54. ↩
-
NTSB El Faro Report, p. 177. ↩
-
NTSB El Faro Report, p. 234. ↩
-
NTSB El Faro Report, pp. 39–42. ↩
-
NTSB El Faro Report, pp. 100–101. ↩
-
NTSB El Faro Report, pp. 169–171. ↩
-
NTSB El Faro Report, pp. 187–188, 221–222. ↩
-
NTSB El Faro Report, pp. 48–50. ↩
-
NTSB El Faro Report, pp. 12, 220. ↩
