The design office is the only party without its own system

The design office is typically the only party in a newbuild project without its own system of record. The shipyard runs PLM or ERP. The owner has asset management and project tracking. The class society operates a submission portal with structured workflows, versioning, and comment tracking built into its architecture. The design office, which generates and processes substantial technical correspondence across every project phase, typically operates on email, a shared drive, and whatever spreadsheet discipline the project manager happens to enforce. This is not a marginal inefficiency. It is a structural mismatch between where accountability sits and where infrastructure has been built.

The yard's position is worth stating plainly. A modern build programme involves thousands of line items — fabrication sequences, material call-offs, subcontractor packages, deviation records. The yard manages this complexity with software that is purpose-built for it: bills of materials that link to the build schedule, engineering change orders that route through defined approval chains, document control functions that track revision status across disciplines. The document controller at the yard knows, at any moment, which revision of a given drawing is current on the shop floor and who signed it off. That is not an accident of organisational competence. It is what the system is designed to do.

The owner's infrastructure is organised around a different problem: asset lifecycle. The owner needs to know what was specified, what was built, and what will be maintained. Project management platforms serve the commercial layer — milestone tracking, budget control, variation management. Some owners run dedicated project controls teams. Others rely on the yard's document management system as the project record, which works well enough for the owner because the yard carries the build risk. The owner's exposure, once the asset is delivered, is to the as-built record and the operating manuals. That record is someone else's problem to compile.

The class society's submission portal is the most instructive comparison. Every plan submitted for approval is logged against a unique identifier. The revision history is preserved automatically — revision A, revision B, revision C with each supersession recorded and the superseded version retained. Comments are raised against specific items on a specific drawing at a specific revision. The status of each comment is tracked: open, responded to, closed by the surveyor, or escalated. The design office receives these comments and is expected to respond to them serially, closing each one before the next review cycle opens. The portal maintains this record indefinitely. The design office's copy of the same correspondence lives in an email thread.

Consider what the design office actually produces over the course of a project. Hundreds of drawings, each going through multiple revision cycles before approval. Transmittals to the yard, to the owner's representative, to the class society — each carrying a document list, a revision reference, and a purpose code. Requests for information from the yard, responded to in writing, with technical justifications that carry direct liability implications. Comment resolution sheets. Hold point notifications. Concession requests. Change orders with associated design revisions. The volume is not the problem. The problem is that none of this correspondence has a home in a system designed to track it. It accumulates in inboxes and on shared drives organised by project instinct rather than by any structure that would survive the project manager's departure.

The accountability tail for a design office is long. Classification societies retain the right to audit design decisions years after delivery. Flag state administrations can initiate investigations following an incident that reference design documentation from the original approval process. Owners pursuing warranty claims will go back to the transmittal record to establish what the design office knew, when it knew it, and what it communicated. In those circumstances, the question is not whether the design office did the right thing. The question is whether it can prove it. Proof, in correspondence-heavy disputes, is a record problem before it is a technical problem.

The persistence of this mismatch has a straightforward explanation. Design offices are small relative to the other parties in a newbuild project, project-based in their revenue model, and thin on administrative infrastructure by design. They do not commission enterprise software. They live, on every project, as tenants inside the systems other parties control — uploading to the class portal, responding to the yard's document management queries, reporting into the owner's project tracker. Each of those systems is built to serve its owner's interests. None of them is organised around the design office's liability exposure or its need to maintain a coherent project record across the full correspondence lifecycle.

The result is that the party with the heaviest correspondence burden in a newbuild project — and the longest tail of professional liability attached to that correspondence — maintains its records by the weakest means available. Every other party has solved this problem for itself. The design office has not, and no one else has solved it on the design office's behalf. That is the gap. It is specific, it is structural, and it has been present on every project most readers of this piece have worked on. The fact that projects are generally completed successfully does not mean the gap is not there. It means the risk has not yet been called.