QA vs QC in Construction Drawings: What's the Difference (and Why It Matters)
Short answer: Quality assurance (QA) is the system you set up to stop errors reaching a drawing in the first place — the standards, templates, checklists, and review process that make good work the default. Quality control (QC) is the act of checking a finished drawing against those standards and catching what slipped through. QA is the process that prevents defects; QC is the inspection that detects them. They are two halves of one loop, and you need both. Archi Check is the tool for the QC half — it turns each check into a tracked comment with an owner and a status, and the resulting audit trail becomes the evidence your QA system demands.
Few phrases in construction are used as loosely as "QA/QC." They are written as one word, printed on the same stamp, and run by the same person, so most people treat them as synonyms for "checking the drawings." They are not synonyms. They describe two different activities that happen at two different points, owned in principle by two different responsibilities, and confusing them is how quality systems quietly fail.
The confusion has consequences. A practice that thinks it "does QA" because someone checks drawings before issue is actually only doing QC, and has no system preventing the same errors from recurring. A practice that has written procedures but never inspects the output has QA on paper and no QC in fact. This guide separates the two cleanly, applies them specifically to drawings and drawing sets, and shows how they work together so neither one carries the whole weight alone.
QA and QC are not the same thing
Start with the cleanest distinction. Quality assurance is about the process; quality control is about the product. QA asks "is our way of working sound enough that good drawings come out of it?" QC asks "is this particular drawing actually correct?" One is a property of the system, the other is a property of the deliverable.
That difference cascades into everything else. QA is proactive — it works before the error happens, by designing the way drawings are produced so mistakes are unlikely. QC is reactive — it works after the drawing exists, by inspecting it and finding the mistakes that occurred anyway. QA prevents; QC detects. A good QA system reduces how much QC has to catch, but no QA system is perfect, so QC is never optional.
The relationship is often described as QC being a subset of QA, and on drawings that holds up well. The checking activity — QC — is one of the things a quality system puts in place. But the checking itself, the moment a person compares a drawing to a standard and raises a defect, is a distinct act with its own tools, its own owner, and its own record. It is worth treating it as its own thing, because that is where Archi Check lives and where most quality processes actually break.
A simple test to tell which one you mean
When you are not sure whether something is QA or QC, ask what it operates on. If the activity operates on the way drawings are made — a template, a layer standard, a checklist, a sign-off procedure, a training session — it is QA. If it operates on a specific drawing or sheet — checking dimensions, comparing against the structural model, finding a missing detail tag — it is QC. The template is QA; using the template to check this sheet is QC.
What QA looks like on drawing sets
Quality assurance on a drawing set is everything you do so that the set is likely to be right before anyone checks it. It is invisible when it works, which is part of why it gets neglected — there is no satisfying "found it" moment, just a steady reduction in the number of defects that ever appear.
In a design office, QA is the standing infrastructure of drawing production:
- Drawing standards and templates. A consistent title block, layer or category standard, line-weight convention, and sheet-numbering system, so every drawing starts from a known-good baseline rather than from scratch.
- Checklists and review procedures. A defined list of what gets checked at each stage and a rule that nothing issues without that check — the procedure exists whether or not any single drawing has been checked yet.
- Roles and sign-off rules. A clear statement of who checks, who corrects, and who has authority to approve a set for issue, so responsibility is not improvised per project.
- Competence and training. Making sure the people producing drawings know the standards and the software, because the cheapest defect to prevent is the one a trained author never makes.
- Document control. Revision management, status codes, and a single source of truth for the current set, so people are not checking — or building from — superseded drawings.
None of these activities inspect a particular drawing. They shape the conditions under which every drawing is produced. That is the signature of QA: it is upstream of the deliverable, and it is owned by whoever is responsible for how the practice works, typically a quality manager, a BIM or design-systems lead, or a principal who sets office standards.
What QC looks like on drawing sets
Quality control is the hands-on inspection of a real drawing. It is the part everyone pictures when they think of "checking the drawings," and it is the half this site is most concerned with, because it is where defects are actually caught and where they most often slip away uncaught.
QC on a drawing set is concrete and sheet-specific:
- Checking a sheet against the standard. Confirming the title block, scale, revision, and notation are correct on this drawing, not in general.
- Coordinating across disciplines. Overlaying architectural, structural, and services drawings to find clashes, mismatched grids, or a beam running through a door.
- Verifying details and references. Confirming that every detail callout points to a detail that exists, that dimensions add up, and that schedules match the plans.
- Reviewing submittals and shop drawings. Comparing a fabricator's drawing against the design intent and marking it up with a decision.
- Closing the loop on corrections. Confirming that a defect raised on a previous review was actually fixed on the current revision.
Every one of these is an act of comparison: a person, or a tool, holds the drawing against a standard and records where they diverge. The output of QC is a set of findings — markups, comments, defects — each of which needs an owner, a correction, and a verification. QC is typically owned by a checker who did not author the drawing, because the value of QC depends on independence: you cannot reliably check your own work.
QA vs QC at a glance
The two are easiest to hold apart side by side. Read each row as the same question answered from the two perspectives.
| Aspect | Quality assurance (QA) | Quality control (QC) |
|---|---|---|
| Focus | The process that produces drawings | The drawing itself, as a product |
| Goal | Prevent defects from occurring | Detect defects that occurred |
| Timing | Proactive, before the drawing exists | Reactive, after the drawing exists |
| Question it answers | Is our way of working sound? | Is this drawing actually correct? |
| Typical activities | Standards, templates, checklists, procedures, training | Checking, coordinating, marking up, verifying corrections |
| Output | A documented, repeatable system | A set of findings and a record they were closed |
| Usually owned by | Quality manager, design-systems or BIM lead | An independent checker, project lead |
The last row matters more than it looks. When QA and QC are owned by the same person with no separation, the system loses its independence — the author who sets the checklist and runs the check and signs the approval has no one auditing the result. Even in a small practice, keeping the checking act distinct from the production act is what makes QC trustworthy.
How QA and QC work together
The point of separating QA and QC is not to choose between them. It is to see that they form a loop, each feeding the other. QA sets the standard; QC checks against it; and what QC finds feeds back to improve QA.
That feedback is the part most teams miss. When QC keeps catching the same defect — say, detail callouts that point to nothing — that is not just a drawing to fix, it is a signal that the QA system has a gap: maybe the template has no callout-checking step, or the authors were never trained on the convention. A mature quality process treats recurring QC findings as inputs to QA. You fix the drawing now (QC), and you fix the process so the defect stops recurring (QA). Without that loop, QC becomes an endless game of catching the same errors forever.
There is also a sequencing relationship across a project. QA is heaviest at the start — setting up templates, standards, and procedures before drawings are produced. QC is heaviest at each issue — checking the set before it goes out. But neither ever stops. You revise standards mid-project as you learn (QA), and you re-check at every revision (QC). The two run in parallel for the life of the job.
A worked example
Consider a missing fire-rating annotation on a door schedule. The QC activity is the checker comparing the schedule against the spec, finding the blank field, and raising it as a defect with an owner. The QA activities sit on either side: the template that should have prompted the annotation (prevention, before), and the standard that says door schedules must carry fire ratings and the training that taught the author that rule (also prevention). If this defect shows up on three projects running, QC has done its job each time, but QA has failed — and the fix is to change the template, not just the drawing.
Who owns QA and who owns QC
Ownership is where the QA/QC distinction stops being academic. They are different responsibilities and, ideally, different people.
QA is an organisational responsibility. Someone has to own the standards, maintain the templates, define the procedures, and decide that they get updated when reality changes. In a large practice this is a quality manager or a design-systems lead; in a small one it is usually a principal. The defining feature is that QA ownership is about the practice, not any one project — the same standards apply across jobs.
QC is a project responsibility, and a deliberately independent one. The checker who runs QC on a set should not be the person who drew it, because self-checking misses the errors you are blind to in your own work. On most projects, QC is owned by a project lead who assigns checking to a checker, routes corrections to a corrector, and reserves approval for someone with the authority to release the set. That separation of checker, corrector, and approver is itself a QA rule — the system that says who is allowed to do what — being enacted through a QC activity. The two are interleaved, but the roles stay distinct.
Where Archi Check fits
Archi Check is purpose-built QC software for architectural drawing sets — it is the tool for the checking half of the loop, the moment a person compares a drawing to a standard and records what they find. Its core workflow is Check → Correct → Verify → Close, and the two stages that map most directly onto QC are the first and third: Check, where a checker marks up the drawing and raises each finding, and Verify, where someone independent confirms the correction was actually made before the item closes.
The reason QC fails in most offices is not that checkers miss things. It is that a finding gets raised, the drawing moves on, and nobody confirms the fix — the open item quietly disappears. Archi Check closes that gap by making every markup a tracked comment with an owner, a status, and the sheet and revision it was placed on. A defect raised in the Check stage cannot vanish, because it stays open until the Verify stage confirms it and the item is closed. You mark up the full-size drawing on one screen while the register tracks every finding beside it on the other.
This is also where QC produces the evidence that QA needs. Quality assurance demands proof that checking happened — that the procedure on paper was followed in fact. In Archi Check, the audit trail is that proof: a complete, time-stamped record of who checked what, what they found, who fixed it, and who verified the fix. That trail is your QA evidence, generated automatically as a by-product of doing QC properly. And because Archi Check keeps your QC data in your own project folders rather than a vendor cloud — folder-first, local-only storage — the record belongs to you and stays with the project. Archi Check runs on Windows today, with macOS coming soon, and there is a 14-day free trial.
FAQ
What is the difference between QA and QC in construction?
QA (quality assurance) is the process that prevents defects — the standards, templates, checklists, and procedures that make good work the default before any drawing is checked. QC (quality control) is the inspection that detects defects — the act of checking a finished drawing against those standards and catching what slipped through. QA is proactive and operates on the process; QC is reactive and operates on the product. You need both: QA reduces how much QC has to catch, but no system is perfect, so QC is never optional.
Is quality control part of quality assurance?
Yes, QC is generally considered a subset of QA. Quality assurance is the whole system that ensures quality, and the checking activity — quality control — is one of the things that system puts in place. But the checking act itself is distinct enough, with its own tools, owner, and records, that it is worth treating separately. QA sets up the rule that drawings must be checked; QC is the act of actually checking them.
What is an example of QA versus QC on a drawing?
A drawing template that carries the correct title block, layer standard, and required annotations is QA — it shapes how every drawing is produced. Using that standard to check a specific sheet, find a missing detail callout, and raise it as a defect is QC. The template is QA; the act of inspecting this sheet against it is QC. A simple test: if the activity operates on the way drawings are made, it is QA; if it operates on a particular drawing, it is QC.
Who is responsible for QA and QC on a project?
QA is an organisational responsibility, usually owned by a quality manager, design-systems or BIM lead, or a principal who maintains the standards and procedures across all projects. QC is a project responsibility, ideally owned by a checker who did not author the drawing, because independent checking catches errors that self-checking misses. On most projects a project lead assigns the checking, routes corrections, and reserves approval for someone with authority to release the set.
Does Archi Check do QA or QC?
Archi Check is QC software — it is the tool for the checking half of the loop, mapping to the Check and Verify stages of its Check → Correct → Verify → Close workflow. It does not replace your QA system of standards and procedures, but it produces the evidence that system needs: every check becomes a tracked comment with an owner and a status, and the resulting audit trail is a complete record that checking happened, which is exactly the proof QA demands.
Turn your checking into a tracked, auditable loop
QA and QC only protect a project when the checking actually happens and the findings are followed through to closure. If your QC still lives as markups on a printout with no record they were resolved, see how Archi Check turns each check into a tracked decision 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?
- The drawing QA/QC process in 4 stages
- How to check construction drawings
- Drawing approval stamps explained
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.