Quality assurance and quality control get used interchangeably often enough that most people assume they're two names for the same activity. On a construction or commissioning project, treating them as the same thing creates a specific and predictable blind spot.
QC is the inspection: did the installed system match the drawing, the spec, the submittal. QA is the process behind it: is there a disciplined, repeatable method ensuring that every system, not just the ones someone happened to check closely, gets built and verified the same way. Conflate the two and a project can pass every inspection it runs and still fail the owner, because no one was verifying that the inspection process itself was complete.
QC Asks Was It Built Right, QA Asks Will It Keep Working Right
Quality control is inherently reactive and specific. An inspector checks a piece of installed equipment against its documentation and either it matches or it doesn't. That's necessary work, but it only covers what someone thought to inspect. QC has no mechanism for catching the system nobody scheduled a check on.
Quality assurance is the layer above that: the systematic process that defines what gets checked, how often, by whom, and what happens when a check turns something up. QA is what makes sure QC coverage is complete rather than incidental, and what makes the zero-defect goal of commissioning something more than an aspiration painted on a project charter.
Where the Conflation Causes Real Problems
The projects that run into trouble are usually the ones where QC activity is happening, sometimes at real volume, without a QA framework governing it. Inspections get logged, deficiencies get written up, but nobody is tracking whether the inspection plan itself has gaps. A control loop on a less visible piece of process equipment can go unchecked for the same reason nobody notices a missing stair — it wasn't on anyone's list, and there was no QA process asking whether the list was complete.
This shows up most clearly at handover. A facility can arrive at substantial completion with a clean QC record and still have systems that were never fully exercised under real operating conditions, because QC verified installation while QA — the process ensuring every system got the same rigor — was thin or absent.
Frequently Asked Questions
Can a project have QC without QA?
Yes, and it's common — inspections happen, deficiencies get logged, but without a QA framework there's no assurance that the inspection coverage itself is complete or consistent across systems.
Which one catches more problems, QA or QC?
They catch different kinds of problems: QC catches installation defects in the systems it inspects, while QA catches gaps in what gets inspected in the first place, which is often where the more expensive surprises hide.
Should QA and QC be handled by the same team?
They're often executed by overlapping teams, but they need distinct authority and reporting lines so that QA can honestly evaluate whether QC coverage is adequate, rather than simply validating its own inspection work.
Building a Process That Assures, Not Just Inspects
Getting to a genuinely low-defect handover requires both disciplines doing their separate jobs well — QC checking what's in front of it thoroughly, QA making sure nothing was left off the list in the first place.
Owners evaluating a commissioning provider's quality program should ask about both, specifically and separately. A long list of completed inspections says something about QC. It says nothing about whether the plan behind those inspections was ever complete.
