Skip to content

How document control works

A document control workspace answers one question, repeatedly: which revision of this drawing are we building from, who said so, and what came back.

Everything below follows from that question being harder than it sounds. The yard has an opinion, the owner has another, class has a third, and the review that settles it takes weeks — so the workspace records all of it against the revision it was said about, rather than collapsing it into one flag.

The register

The register is Documents — one row per document, not per revision. A row carries the document’s identity — its number, the originator’s own number for it, its cost code, its type, who originated it — and then the part that changes: Has current revision, with its date, its file and the yard’s status.

The tabs split the register on Active: In use is what the page opens on; Not in use holds the documents that have been taken out of use. Nothing is deleted in document control, because the drawings that were issued are still on board — so the tab the page opens on is never the whole register.

A document has revisions; a revision has a state

A document is a container. The revisions underneath it are the things with dates, files and statuses, and at most one of them is current.

Which one is a field on the revision, Status: Concept while it is being drawn, Actual when it is the one to build from, Superseded when a later revision has taken over. So “make rev. C current” is an edit to one value, and the register’s Has current revision columns follow it without the document row being touched. The document page’s two revision tabs are the same filter seen twice: Actual revisions is status = Actual, Other revisions is everything else.

The old revision does not disappear. It stays, with its file and the comments raised against it, because somebody on board is holding a printout of it.

Three statuses on one revision

Besides Status, a revision carries two more, and it is worth being precise about them because all three are called “status” somewhere:

FieldWhose opinionValues
Statusthe register’s — where this revision sits in its document’s historyConcept, Actual, Superseded
Status (builder)the yard’s — what the engineering department thinks of the drawingIn Progress, For inspection, Under review, Approval from Class, Approval from Client, Approved for Construction, On hold, Voided, Closed, …
Status (owner)the owner’s — what came back from the clientUnder review, Clarification, Accept, Accept with comments, Approved for Construction, Cancelled, …

These are not three names for one thing. A revision can be Actual, Approval from Class and Under review at once: it is the one to build from, the yard has sent it to the surveyor, and the owner has not answered yet. All three are true, and none is a data-quality problem. Reason for change is the fourth field worth knowing: the only one that says what moved between two revisions of the same drawing.

Transmittals: how a revision leaves the building

A revision does not reach class or the owner by being approved. It goes out on a transmittal — a covering document that says what is being sent, to whom and why. Communication → Transmittals lists them: one row each, with the reason (For information, For review and signing off, For Construction and Approval…), the recipients (a +1 badge when the cell cannot show them all), who owns it internally, the cover PDF whose date is the date sent, and the signed copy when it came back.

The column the overview labels Status is the reviewer’s verdict — To do, Approved, Approved with comments, Rejected, Superseded — because that is what a document controller scans the list for. The transmittal’s own state (Concept, Ready for review, Finished) is on the document’s Transmittals tab beside each revision.

Transmittal TR-003 open: recipients, the comments that came back, the documents included, the cover PDF, and the correspondence with two e-mails.
A transmittal's page: who got it, what it carried, what came back — including the e-mails.

A transmittal's page: who got it, what it carried, what came back — including the e-mails.

Comments come back, and they are data

A reviewer’s remarks are not an e-mail. They are comments: records with a text, a status and an author, hung on the thing they are about — the revision, the transmittal they came back on, a space, or a piece of equipment. Communication → Comments lists every one, with tabs per status, and with the revision, document or transmittal beside it.

A comment’s status is the decision about it: Open until somebody answers; then Approved, Approved with comments or Rejected. It is editable wherever the comment is shown, and settling comments is part of the job: the Dashboard shows your open ones, and the document page’s Comments tab splits its revisions’ comments into open and closed.

Created by on a comment is who raised it — the surveyor, the owner’s superintendent, the yard’s engineer — and Created on is when. Together with the revision it hangs on, that is the answer to what was said, by whom, about which drawing, months later.

E-mails belong here too: the correspondence around a transmittal is filed on the transmittal, with a sender and a recipient, and opens in a preview.

Spaces and equipment: what a drawing is about

The ship is in the workspace as well: decks, deck areas, spaces and zones under Configuration, and the equipment placed in the spaces. A revision can be visible in a space — the drawing shows that compartment — and the connection reads from both ends: the document’s page lists the spaces it shows, the space’s Documents tab lists the drawings it appears in, and its inspection reports separately.

The Documents tab of the RSW machinery room: the RSW plant inspection report listed under Is visible in document and again under Is visible in inspection report, with its revision, date and PDF.
A space knows the inspection reports filed against it. Comments on the space itself are on its Details tab.

A space knows the inspection reports filed against it. Comments on the space itself are on its Details tab.

So an inspection report is a document like any other — a type, a cost code, a revision with the PDF — plus one link to the space it inspected. And a comment raised on the space, or on the plant in it, sits beside it.

Cost codes: which part of the ship

Every document has a cost code — the part of the work it belongs to, arranged as a tree under Definition → Cost codes. The document page shows it in the attributes block; the cost code’s own Documents tab shows every document filed under it. It is the second way into the register, after the register itself: what do we have for the main engine is a cost code, not a search.

The client’s own view

The workspace has two portals. Main is the yard’s: everything above. Client is what the owner opens: a Dashboard, the register and the transmittals — the same records, read-only, except that the owner may add comments and settle them on the transmittals they received. Which portal a person can open is assigned per user, and a workspace with no portal you can open does not appear in your selector at all.

Why this shape

Every part of the above exists because a drawing outlives the conversation about it. A revision is kept after it is superseded, a comment is kept against the revision it was raised on rather than against the document, the yard’s opinion of a drawing is recorded separately from the owner’s and from class’s — because each was said by a different person at a different time, and a workspace that averaged them into one field would be unable to answer the only question that matters when something goes wrong on board:

who approved this, and which revision were they looking at.