The Drawing QA/QC Process in 4 Stages: Check, Correct, Verify, Close

Short answer: The drawing QA/QC process runs in four stages — check, correct, verify, close. A reviewer checks the drawing set and raises issues, the responsible person corrects each one, someone other than the corrector verifies that the fix is right, and only then is the item closed with a record of what changed. The discipline that separates real quality control from theatre is the verify stage. Archi Check runs this exact loop, turning every markup into a tracked comment with an owner, a status, and an audit trail that moves from check through close.

Most drawing review effort goes into finding problems. People are good at spotting a clash, a missing dimension, or a door that swings into a wall, and a coordination meeting can generate a long list of them in an afternoon. The trouble starts after the list exists. Issues get emailed, half of them get fixed, a few get fixed wrongly, and nobody is quite sure which ones are still open when the set goes out. The set ships with the original defects buried under a layer of well-intentioned activity.

The fix is not more checking. It is treating quality control as a closed loop rather than a one-off review — a process with four distinct stages, each with an owner, where nothing is considered done until it has been confirmed done by someone other than the person who did it. This article walks through that loop stage by stage, explains who runs each one, and is honest about what goes wrong when a stage is skipped.

Why drawing QC is a loop, not a single review

The most common failure mode in drawing quality control is treating the review as the whole process. A senior architect sits down with the set, marks it up in red, hands the markups back, and considers their job done. Everything after that — making the corrections, confirming they were made correctly, recording that the item is resolved — is left informal. And informal is where defects survive.

Think about what a markup actually represents: a statement that something is wrong and needs to change. That statement has a lifecycle. It is raised, it is assigned to someone, the change is made, the change is confirmed correct, and the item is retired. If any link in that chain is missing, the markup can be lost. A red cloud on a printout that nobody transcribes is gone the moment the printout is filed. A correction made without anyone checking it can introduce a new error nobody catches. An item that is "probably done" but never formally closed sits in a grey zone where it is neither tracked nor resolved.

Structuring the work as four named stages forces each link to exist. The vocabulary varies between offices — some say review, rectify, back-check, sign-off — but the underlying loop is the same everywhere QC is done seriously. The four stages below are the canonical version.

The rest of this guide takes each stage in turn. If you want the wider framing of what QA/QC means before the process detail, see what is drawing QA/QC.

Stage 1 — Check: find and record every issue

The check stage is the review proper. A competent reviewer goes through the drawing set looking for the things that cause problems on site: missing or conflicting dimensions, inconsistencies between plans and sections, details that do not match the elements they detail, drawings that disagree with the specification, and clashes between disciplines. This is the stage everyone already does, so the temptation is to assume it is the only stage that matters. It is not — but it is the foundation, and a sloppy check poisons everything downstream.

The quality that distinguishes a useful check from a noisy one is precision of recording. A markup that says "fix this" floating near a corner of the sheet is almost useless a week later: which element, what exactly is wrong, what does "fixed" look like. A useful issue states its location, describes the problem in a sentence, and is specific enough that the person correcting it does not have to guess what the reviewer meant.

What good checking captures

• A precise location. The sheet, the gridline or detail reference, and ideally a mark placed on the drawing itself so the issue points at the exact spot.
• A clear description. What is wrong, in plain language — "door D-12 swing conflicts with radiator on A-201" beats "check this door".
• A category. Whether it is a coordination clash, a dimensional error, a compliance question, or a drafting inconsistency, so similar issues can be grouped and patterns spotted.
• An owner. Who is responsible for the correction, assigned at the moment the issue is raised rather than worked out later from a spreadsheet.

The output of the check stage is a register of open items, not a marked-up PDF. The distinction matters: a PDF of red marks is a static picture of one moment, while a register is a living list that the next three stages act on. For the practical mechanics of doing this well, see how to check construction drawings.

Stage 2 — Correct: make the change and say what you did

Correction is where the responsible author acts on each raised issue. This is usually a different person from the checker — the checker is often a senior reviewer, and the corrector is the drafter or designer who produced the affected drawing and is best placed to fix it. The split is deliberate: the person who knows the drawing intimately makes the change, and a fresh pair of eyes checked it in the first place.

The work of this stage is the obvious part — open the drawing, make the change, save it. The part that is routinely neglected is recording what was done. A correction made silently is a correction that nobody downstream can verify efficiently, because the verifier has to reconstruct what the corrector intended before they can confirm it is right. A one-line note against the item — "moved radiator 300mm, re-dimensioned, door swing now clear" — turns the verify stage from a re-investigation into a quick confirmation.

Why corrections need their own record

Two failure modes live in this stage. The first is the partial fix: the corrector addresses the obvious half of an issue and misses a consequence. Moving the radiator clears the door swing but now fouls a power outlet that was never mentioned. The second is the wrong fix: the corrector misreads the issue and changes the wrong thing entirely. Neither of these is caught by the corrector — by definition, if they could catch their own mistake they would not have made it. They are caught at verify, and verify can only do its job if the correction stage handed it a clear account of what changed. The corrector's job is not finished when the change is saved; it is finished when the change is saved and described well enough for someone else to check it.

Stage 3 — Verify: the stage everyone skips

Verification is the stage that turns activity into quality, and it is the stage most often dropped when a deadline looms. The principle is simple and non-negotiable: the person who made a correction does not get to declare it correct. Someone else confirms it. This is not bureaucracy for its own sake — it is the single most effective defence against defects reaching the issued set, because it is the only stage designed to catch errors introduced by the correction itself.

Skipping verify is seductive because it feels redundant. The corrector is competent, they made the change, surely it is fine. But the entire reason QC exists is that competent people make mistakes they cannot see. When the corrector marks their own work done, the loop has no independent confirmation, and you are back to the email-and-hope model with extra steps. The set ships carrying corrections that were never checked, and the failures that result — a fix that broke something adjacent, an issue marked done that was never actually addressed — are exactly the failures the process was supposed to prevent.

What goes wrong when verify is skipped

• Corrections that introduce new defects go undetected. The radiator move that fouls the outlet ships, because the only person who looked at it was the person who created it.
• "Done" stops meaning done. When anyone can mark their own item closed, the register fills with items that are optimistically resolved rather than confirmed resolved, and the closed list becomes untrustworthy.
• Accountability dissolves. If a defect surfaces after issue, there is no record of who confirmed the fix, because nobody did — so the post-mortem has nowhere to start.
• The check stage is wasted. A carefully raised issue that is corrected wrongly and never verified is no better than an issue that was never raised; the review effort is spent with nothing to show for it.

Good verification is a genuine re-check against the original issue, not a glance. The verifier reads the raised item, looks at the correction, and decides one of two things: the fix is correct and complete, in which case the item can move to close; or it is not, in which case the item goes back to correct with a note saying why. That second path — the rejection — is what keeps the loop honest. A verify stage that only ever passes things is not verifying; it is rubber-stamping. The verifier must have a real route to send work back, and using it has to be normal rather than confrontational.

Stage 4 — Close: confirm, record, and clear for issue

Closing is the formal retirement of an item and, in aggregate, the clearing of the set for issue. An item is closed only when it has been verified — close is not a synonym for "I think this is done", it is the recorded confirmation that the loop completed. The project lead or approver owns this stage, because closing carries authority: it asserts that this issue is genuinely resolved and the set is one step closer to being safe to release.

The output of the close stage is the thing that makes the whole process defensible after the fact: a complete audit trail. For every issue, the record shows who raised it and when, who corrected it and what they changed, who verified it, and when it closed. That trail is what you reach for when a question comes up months later — a contractor queries a detail, a defect appears on site, a dispute needs evidence that the set was properly checked. Without the trail, "we did QC on this" is an assertion. With it, it is a record.

Keeping the loop closed under pressure

The close stage is also where the project lead can see, at a glance, what is actually outstanding. A trustworthy register answers the only question that matters at issue time: are there any open or unverified items left. If the answer is no — every item raised has been corrected, verified, and closed — the set is clear. If the answer is yes, the lead knows exactly which items are blocking and who owns them, rather than discovering an unresolved issue after the set has gone out. The loop stays closed because closing is gated on verification, and issue is gated on closing.

A worked example: one issue through all four stages

It helps to follow a single issue through the whole loop, because the value is in the handoffs between stages, not in any one stage alone.

• Check. The reviewer, going through sheet A-201, marks a clash: the swing of door D-12 conflicts with a radiator shown on the same wall. The issue is raised against A-201, categorised as coordination, described in one line, and assigned to the architect who drew the bay.
• Correct. The architect opens A-201, relocates the radiator 300mm along the wall, re-dimensions the run, and confirms the door now swings clear. They note exactly that against the item: "radiator moved 300mm east, run re-dimensioned, swing now clear."
• Verify. A second reviewer — not the architect who made the change — opens the item, reads the correction note, and checks the drawing. They confirm the swing is clear, and they also check the consequence: does the moved radiator now clash with anything else. It does not, so they pass the item.
• Close. The project lead sees the item is verified, closes it, and it drops off the open list. The full history — raised, corrected, verified, closed, with names and dates — stays in the record. When the set issues, A-201 carries no open items.

Now picture the same issue with verify removed. The architect moves the radiator, marks the item done, and the set ships. Nobody noticed that the relocated radiator now sits under a window, or that the re-dimensioned run no longer adds up. The defect reaches site, where it costs far more to fix than the thirty seconds a verifier would have spent. That gap — between an item marked done and an item confirmed done — is the entire reason the four-stage loop exists. For how this maps onto recurring defects across a project, see defect tracking on drawings.

Who runs each stage

The four stages imply a separation of duties, and getting the right people on the right stages is half of making the loop work. The non-negotiable rule is that the verifier is never the corrector — independence at the verify stage is the whole point. Beyond that, the typical mapping looks like this.

• Checker. Usually a senior architect or a dedicated reviewer with the experience to spot problems. Owns the check stage and raises issues.
• Corrector. The author of the affected drawing — the drafter or designer who produced it and can fix it accurately. Owns the correct stage.
• Verifier. A reviewer who did not make the correction. This can be the original checker or a different senior person, but never the corrector. Owns the verify stage and has the authority to reject.
• Project lead or approver. The person with authority to close items and clear the set for issue. Owns the close stage and the integrity of the register as a whole.

On a small job one person may wear several hats across different issues, and that is fine — what matters is that for any single item, the corrector and the verifier are different people. For the full breakdown of roles and how permissions map to them, see who does what in drawing QC.

Where Archi Check fits

Archi Check is purpose-built QC software for architectural drawing sets, and the four-stage loop in this article is exactly the loop it runs. Every markup you place is a tracked comment, not a static red mark: it carries an owner, a status, the sheet and revision it sits on, and a date. As an issue moves through check, correct, verify, and close, its status moves with it, and the register shows you the live state of every item at once.

The verify stage is enforced rather than hoped for. Verification in Archi Check is done by someone other than the author — the role and permission model keeps the corrector from signing off their own work, so the independence that makes verify worthwhile is built into the tool instead of relying on goodwill under deadline pressure. An item cannot quietly become "done" without a second person confirming it, and the project lead closing the set can see at a glance whether any open or unverified items remain.

The two-screen workflow keeps the loop fluid: the register and workspace sit on one monitor while the full-size drawing fills the other, so you mark up at full scale on one screen and watch the tracked items update beside it. Because the whole history is captured — who raised, who corrected, who verified, who closed, with dates — you finish with a complete audit trail rather than a folder of disconnected PDFs. And because Archi Check is folder-first and local, your QC data lives in your own project folders rather than a vendor cloud, so the audit trail belongs to you. Archi Check runs on Windows today, with macOS coming soon, and there is a 14-day free trial.

FAQ

What are the four stages of the drawing QA/QC process?

The four stages are check, correct, verify, and close. A reviewer checks the drawing set and raises each issue as a tracked item, the responsible author corrects each one, a different person verifies that the correction is right and complete, and the project lead closes verified items and clears the set for issue. The loop stays honest because closing is gated on verification and verification is done by someone other than the corrector.

Why is the verify stage so important?

Verification is the only stage designed to catch errors introduced by the correction itself. Competent people make mistakes they cannot see, so when the corrector declares their own work done there is no independent confirmation that the fix is right or that it did not break something adjacent. Skipping verify means corrections ship unchecked, "done" stops meaning done, and the review effort spent in the check stage is wasted on issues that were never confirmed resolved.

Who should do the verification in drawing QC?

Anyone except the person who made the correction. The verifier can be the original checker or another senior reviewer, but never the corrector — independence is the entire reason the stage exists. The verifier re-checks the correction against the raised issue, confirms it is correct and complete, and either passes it to close or sends it back to correct with a note saying why.

What happens if you skip a stage in the QC loop?

Skipping check means issues are never found. Skipping correct means they are found but not fixed. Skipping verify — the most common omission — means fixes ship without confirmation, so corrections that introduced new defects go undetected and the closed register becomes untrustworthy. Skipping close means resolved items are never formally retired, so nobody can say with confidence whether the set is clear for issue.

How do you keep the QC loop closed under deadline pressure?

Make closing depend on verification and make issue depend on closing, so the loop cannot be short-circuited even when time is tight. Keep every issue as a tracked item with an owner and a status rather than a loose markup, so nothing can quietly disappear, and give the project lead a live view of open and unverified items. Tracking each decision with an audit trail — who raised, corrected, verified, and closed it — means the state of the set is always visible rather than assumed.

Run the whole loop in one place

A drawing QC process only protects a project when every stage actually happens and nothing closes without being verified. If your loop still runs on emailed markups and good intentions, see how Archi Check turns each markup into a tracked item that moves from check to close with a complete audit trail: Try Archi Check free for 14 days.

Related guides

Keep building out your drawing QC process with Archi Check and these related guides:

• What is drawing QA/QC?
• Defect tracking on drawings
• Who does what in drawing QC
• How to check construction drawings

Archi Check is an independent product by Archi for architectural drawing QA/QC. Product names and trademarks referenced belong to their respective owners and are used for identification only.