Holding document status across every party on a capital project

On an engineered equipment project, the question that eats the most oxygen is rarely whether a drawing exists. It is where the drawing stands, and the answer keeps moving because the drawing keeps changing hands.

Count the parties on one job: your own engineering, your fabrication shop or a third-party shop, a set of sub-suppliers each owing their scope’s documents, and a customer whose reviewers return things on their own clock. A single document can touch all of them in one cycle: drafted in engineering, sent for approval, returned with comments, corrected, re-issued, released to the shop, its certificates arriving from a sub-supplier in parallel. A project like this does not live inside one company, and that is precisely why the status question is hard: each party keeps its own records, and the truth about one document is scattered across four sets of them.

The symptoms are familiar. The standing meeting where status is assembled verbally. The customer asking about a document your record says is with them. The shop building from a revision that engineering superseded on Tuesday. None of these are competence problems; they are the natural physics of many parties and no shared record.

What a working record has to do is specific. One entry per document, whatever party currently has it. The dates in both directions, when it went and when it is expected back, per party, so lateness is visible before it is felt. Enough history that “what happened with this drawing” is a lookup, not an interview. And when a customer rejects a file, the record has to drive the response: the return routed to everyone who has to act on it, together, and the correction held out of the customer queue until your own review clears it, because the route a document takes inside your company is yours, whatever the customer’s specification says about formats.

The sequencing matters as much as the visibility. Issue purposes run in order on this work: fabrication releases only when the for-approval document is approved, the for-construction issue goes out right after, and that approval moves to the shop so building starts on the right revision. A record that cannot see those steps cannot protect them.

This is the ground DocBoss is built on: the record that holds across company lines. One entry per document with its status, revisions and history; what is out with each sub-supplier, what is inside your own review, what the customer has had and for how long, with days out with each party on the project reports. Shops and sub-suppliers work through a portal, uploading into your project and collecting what you send, so their documents land in the record instead of an inbox. Receipt is confirmed too: you can see when the customer downloaded a submittal, which is mostly useful for reminding them when they have not.

Every party on the project keeps their own books. Yours should be the one that does not need the meeting.