The worst thing about building to a superseded drawing is that it isn't discovered when it happens. Nobody stands on site the day the new revision is issued and points out that what is being built has just become wrong. Discovery comes weeks later — at an inspection, or when another trade arrives to conditions that don't match their drawing. The cost of demolition and rework is the smaller half of the problem; the larger half is the argument about who pays for it. And that argument isn't settled by memory. It's settled by whether you can show which revision was current on that day, who approved it, and when it reached site.
Key takeaways
- Overwriting a drawing file under the same name is convenient and destroys the record: afterwards there is no answer to "which revision were we building to in March?"
- Approval belongs to a specific version, not to the document — so a new revision has to drop the previous sign-off and send the document back for review.
- Bumping the revision letter on an approved drawing set without clearing its approval means site is building to a revision no engineer ever signed.
- Whoever uploads doesn't approve, and whoever approves must be approving the version they actually read — not a newer one that landed while they were reading.
- Editing a document's metadata (name, type, folder) must not invalidate its approval; replacing its content always must. Conflating the two makes a system either annoying or untrustworthy.
The drawing everyone was working from
Every contractor has this story: a wall in the wrong place, an opening that doesn't exist, rebar that doesn't match the detail. The cause is the same every time — an older version of a drawing stayed in use after a newer one was issued. The problem isn't that the new revision wasn't produced. It's that it didn't arrive, or it arrived and nothing distinguished it from the one before.
| Route | Why it fails |
|---|---|
| An email chain | Whoever joined late never sees the earlier attachments, and whoever forgot to reply doesn't know they forgot |
| A photo of a print | Travels faster than any formal issue, and carries neither a date nor a revision |
| A shared folder where the file is overwritten | Same name, different content — nobody notices the change and nobody can go back |
What all three share is that none of them leaves a trail you can go back to. And when a claim lands, the only question asked is: which revision was current on that date, and who received it? Plenty of systems answer only the first half.
A revision chain, not a file you overwrite
The easiest way to upload an updated drawing is to replace the old file under the same name. It is also the way that erases the record: afterwards nothing remains of what the document used to be, who uploaded it, or when it became current.
The alternative is to archive the outgoing file as a numbered revision before the new one takes its place. Nothing is deleted: every revision keeps its file, its author, its date and a note explaining why it changed. The result is that "what were we building to?" becomes a question with an answer rather than a topic of discussion.
| Version | What happened | Status afterwards |
|---|---|---|
| v1 | First upload from the design team | Draft → approved |
| v2 | Revised after a consultant comment | Draft — v1's approval cleared |
| — | Name corrected and moved to the right folder | Unchanged — approval intact |
| v3 | Coordination change with MEP | Draft → approved after review |
The third row is the whole distinction: the file did not change, so nothing was invalidated. In the other two the content changed, so the document went back for review each time. And that same chain is what later answers the question "which one was current when this part was built?"
Whoever produced the outgoing version, not whoever replaced it
One small detail is easy to get wrong: the archived revision row should carry the name of whoever produced that version, not whoever uploaded the version replacing it. Recording the second in place of the first shifts every version's authorship one step down the chain — which is precisely what you don't want when the log is being read to find where an error came from.
Approval belongs to a version, not a document
This is the rule that separates real document control from a file archive: a sign-off attaches to a specific version. When a new revision is uploaded, the document must return to draft and lose its previous approval, its approver and its approval date. Approval is not inherited by the next version.
The same applies to drawing sets. Bumping the revision letter from A to B on an approved set while it stays "approved" means the new package inherited a sign-off that was never given to it. Site then builds to a revision that looks signed and that nobody read.
The new revision is uploaded
The previous file is archived as a numbered revision with a note explaining what changed and why.
The approval drops automatically
The document returns to draft and the approver and approval date are cleared — no sign-off is left hanging on content that changed.
Someone other than the uploader reviews it
Review starts again on the new content, not on the old document's reputation.
It is approved and the team is told
Approval on its own delivers nothing — notifying the team that a new revision is current is what closes the distance between the office and the site.
Uploaders don't approve, and approvers approve what they read
The separation of duties here is simple: whoever produced the content does not sign off on its correctness. It's a principle that needs enforcing explicitly, because the same person usually holds both permissions — a project manager uploads and approves under the same role.
The one sensible exception is a company with a single eligible approver. Blocking them from approving what they upload leaves a document that can never be approved at all. The right rule is to waive the block in that case only, and re-engage it automatically the moment a second approver exists.
The read-then-approve race
A case that sounds rare and happens constantly: a reviewer opens revision 2, reads it, goes to a meeting, comes back and clicks approve — and revision 3 landed in between. With no guard, an approval gets recorded against content the approver never saw. The correct behaviour is to refuse it with a message saying a newer revision arrived and has to be reviewed first.
| Document state | Deletion | Why |
|---|---|---|
| Draft | Allowed | Nobody has relied on it yet |
| Rejected | Allowed | An explicit decision not to approve was already taken |
| Under review | Blocked | A decision is in progress — it shouldn't vanish under the reviewer |
| Approved | Blocked | A signed contractual record; reject it first if it genuinely must go |
Sets, sheets, and pinning an issue to its location
A standalone document is enough for contracts and reports, but drawings are issued in packages: a group of sheets sharing one revision letter and one issue date. The set is the unit of issue; the sheet is the unit of work.
| Property | Document | Drawing set |
|---|---|---|
| Unit of revision | A version number on the document | A revision letter on the whole set |
| Contents | One file | Multiple sheets, each with a number |
| Typical use | Contract, permit, specification | Architectural, structural, MEP |
| What must be unique | A clear name within its folder | The sheet number within the set |
Sheet-number uniqueness within a set is not cosmetic validation: every reference made on site is made by number. Two sheets sharing a number make "check sheet 201" a meaningless instruction — and it is an instruction given dozens of times a day.
Markups and pins: tying an issue to where it is
Marking up the sheet — a cloud, an arrow, a comment — makes the observation visible to everyone who opens it, instead of living on a printed copy in somebody's truck. The step beyond that matters more: attaching a real record to a specific point on the sheet, so an RFI, a non-conformance or a punch item sits at a coordinate rather than in a text description like "near the east stair".
The safety condition for that link is that the pin points at a record that actually exists, on the same project. A dangling pin pointing at nothing is worse than no pin at all, because it implies follow-up that isn't happening.
Getting the current revision to the person building it
Approval is not publication. A document approved in a system the team never hears about is equivalent to a document that does not exist. Every new revision should therefore be followed by a notification that something changed, rather than appearing silently in a list.
- A notification when a new sheet or revision lands, reaching the people it affects rather than everyone.
- Folders that mirror how people actually search — by discipline and stage, not by upload date.
- The ability to open the sheet on a device at the workface, where signal is at its weakest inside a concrete frame.
- An immediate answer to one question: is this the latest approved version?
How document control works in muqawil
Documents in muqawil live inside a project, classified by type and folder, and each one has a current version plus a chain of earlier revisions. Uploading a new revision archives the outgoing file against whoever produced it with a note explaining the change, and returns the document to draft so review starts again.
- Approval never carries across revisions: a new revision clears the previous approval, its approver and its date.
- Whoever uploaded the current version cannot approve it — unless they are the only eligible approver on the account, and the block returns automatically once a second one exists.
- An approval can be tied to the version number the reviewer was shown, so a newer revision landing mid-review is refused rather than recorded against content they never read.
- Approved and under-review documents cannot be deleted; only drafts and rejected ones can.
- Drawing sets carry a revision letter and an issue date, and raising the letter on an approved set clears its approval instead of letting the new revision inherit it.
- Sheet numbers are unique within their set, and a pin on a sheet must reference an RFI, non-conformance, inspection or punch item that exists on the same project.
Frequently asked questions
What's the difference between uploading a revision and creating a new document?
A revision keeps the same document with its history, its reviewers and everything referencing it, and archives the previous file rather than deleting it. A new document breaks that chain, leaving two records where nobody can tell which one is current.
Does a document stay approved after a new revision is uploaded?
No. Approval belongs to a specific version, so the document returns to draft and review starts again. Letting approval carry over means a signature sitting on content the signer never read.
Can I approve a drawing I uploaded myself?
Not while another eligible approver exists on the account — separating uploader from approver is the whole point of the control. The block is waived only when you are the sole approver, and it re-engages automatically as soon as there is a second.
What if a newer revision lands while I am reviewing the previous one?
The approval is refused, with a message telling you which newer revision to review first. The alternative is far worse: an approval record stating that a version was signed off by someone who never saw it.
Can an approved document be deleted?
No. An approved document is a signed contractual record and one under review is a decision in progress. Deletion is available for drafts and rejected documents only — if an approved document genuinely has to go, an explicit decision is taken on it first.
What is a pin on a sheet for?
It ties a real record — an RFI, a non-conformance, an inspection or a punch item — to a specific point on the drawing instead of an approximate written description. The pin has to reference an existing record on the same project so it never implies follow-up that does not exist.
Upload one revision and watch the approval drop
Take an approved drawing, upload a new revision over it, and watch the sign-off clear and the document return to review — that exact moment is what stops site building to a revision nobody signed.