Who Does What in Drawing QC: Manager, Project Lead, Checker, Corrector, Viewer

Short answer: A drawing QC process usually runs on five roles. A Manager administers the system and people, a Project Lead owns the standard and the sign-off for a project, a Checker finds and raises issues, a Corrector fixes them, and a Viewer can see the record without changing it. The point of separating them is accountability: the person who corrects a drawing should not be the person who verifies their own correction. Archi Check ships exactly these five roles with a permission matrix, so every comment has a named owner and the Check, Correct, and Verify steps stay in different hands.

Most drawing QC failures are not failures of skill. The checker was competent, the corrector did the work, the drawing was eventually right. What broke was the chain of responsibility: a comment was raised but never assigned, a correction was made but never confirmed, or the same person who made the change also ticked it off as done. When something gets built wrong, the question is rarely "did anyone look at this" — it is "who was responsible, and how do we know they did it."

That is what roles are for. A role is not a job title; it is a defined bundle of responsibilities and permissions that says what a person may do to the QC record and what they are accountable for. Get the roles right and the audit trail more or less writes itself. Get them wrong — or collapse them all into one person — and you have markup, not quality control. This guide sets out the five roles that cover almost every drawing review process, what each one owns, and why keeping certain duties apart is the whole point.

Why roles and separation of duties matter

Quality control is, at heart, an accountability system. Every defect that reaches a drawing has a lifecycle: it is found, it is fixed, and the fix is confirmed. Roles exist so that each of those steps has a clear owner and so that no single person can quietly carry a defect through all three stages unchecked.

The principle underneath this is separation of duties, borrowed from auditing and financial control and just as relevant to drawings. The idea is simple: the person who performs an action should not also be the person who verifies it. A corrector who marks their own work as verified is doing the equivalent of an accountant signing off their own expenses. They may be entirely honest and entirely competent, but the control has been removed, and the record no longer proves anything. The moment the checker, the corrector, and the verifier collapse into one person, the QC trail becomes a story that person tells about their own work.

Separation also forces a second pair of eyes at the point where it matters most — verification. A defect is most likely to slip through not when it is raised, but when it is closed. A correction can look right to the person who made it and still miss the original intent of the comment. Having someone other than the corrector confirm the fix is the cheapest, highest-value control in the entire process. It costs a few seconds and it catches the corrections that were made to the wrong thing, made halfway, or made to the wrong revision.

There is a second benefit beyond catching errors: attribution. When every raised, corrected, and verified item carries a name and a timestamp, the record answers questions after the fact. Who checked this sheet? When was this comment closed, and by whom? On what revision? A role-based process produces that audit trail as a by-product of people simply doing their jobs, rather than as a separate documentation chore nobody has time for.

The Manager: administration and oversight

The Manager is the administrator of the QC system rather than a reviewer of any single drawing. This is the person who sets the system up, decides who exists in it, and holds the keys. On a small team the Manager might also act as a Project Lead or Checker, but the role itself is distinct: it is about the framework within which everyone else works.

The Manager's responsibilities are structural. They create and remove user accounts, assign people to roles, and decide who has access to which projects. They configure the standards that apply across projects — the markup conventions, the stamp set, the status workflow that comments move through. They are accountable for the integrity of the system as a whole: that the right people have the right access, that nobody has more permission than their role needs, and that the audit trail cannot be tampered with.

Crucially, broad permission is not the same as doing the work. A good Manager rarely raises or closes comments themselves; their job is to make sure the people who do have a clean, well-governed place to do it. The danger with an administrator role is permission creep — because the Manager can do almost anything, it is tempting to let them shortcut the process. The discipline is to keep the Manager out of the Check-Correct-Verify loop except where they are explicitly also wearing another role.

The Project Lead: ownership and sign-off

If the Manager owns the system, the Project Lead owns a project. This is the person accountable for the quality of a specific drawing set: that the right checks happened, that open items were resolved, and that the set is fit to issue. Where the Manager's view is across all projects, the Project Lead's view is deep on one.

The Project Lead's responsibilities sit at the top and the bottom of the loop. At the start, they decide what gets checked and to what standard — which sheets, against which criteria, by when. Through the project, they have visibility of every open and closed comment and can see where the bottlenecks are: which sheets have unresolved items, which corrections are stalled, which checks have not started. At the end, they are typically the sign-off authority — the person whose approval says the set has passed QC and may be issued.

This is a coordination and accountability role more than a hands-on one. The Project Lead can usually do everything a Checker can do, and often steps in to check critical sheets personally, but their distinct value is oversight: holding the standard, chasing closure, and putting their name to the decision that the set is ready. When a defect surfaces after issue, the Project Lead is the person who answers for the QC process on that project — which is exactly why the role needs visibility of the whole record, not just the part they touched.

The Checker: finding and raising issues

The Checker is the engine of the process. This is the person who reads the drawing critically, compares it against the standard and against other disciplines, and raises an issue every time something is wrong, missing, unclear, or inconsistent. Checking is a skill in its own right — knowing what to look for, where errors hide, and which inconsistencies actually matter — and it is the role most people picture when they think of drawing QC.

The Checker's core responsibility is to raise issues, clearly and attributably. A good raised comment says what is wrong and, ideally, where it should be fixed — it is specific enough that the corrector knows exactly what to change without a conversation. The Checker marks up the drawing, assigns each comment to whoever owns the fix, and sets it to an open status. What the Checker does not do is close their own comments. Raising and closing are deliberately different acts, often performed by different people, because the person who spotted a problem is not automatically the right person to confirm it was solved.

There is an important boundary here. The Checker identifies problems; they generally do not fix them. Keeping checking and correcting apart matters for the same reason verification stays separate — a checker who both finds and fixes an issue has no independent record that the fix was needed or that it worked. On many teams the Checker also performs verification of corrections they did not make, which is a legitimate use of the role, but the line that must not be crossed is one person checking, correcting, and verifying the same item.

The Corrector: making the fixes

The Corrector is the person who acts on raised comments and makes the actual changes to the drawing. Often this is the author of the drawing or a member of the production team — the people with the tools and the knowledge to change the model or the sheet. The Corrector receives assigned comments, makes the required change, and marks the item as corrected, ready for someone else to verify.

The Corrector's responsibility is to resolve assigned issues accurately and to record what they did. A corrected item should carry enough of a note that the verifier can confirm the right thing happened — "revised door schedule to match plan, rev C" rather than a bare tick. The Corrector moves the comment from open to corrected, but they do not move it to closed. That final step belongs to someone else, and this is the single most important separation in the whole model.

The reason is worth stating plainly. A Corrector who can also close their own corrections can, by accident or under deadline pressure, mark an item resolved that was never properly fixed. Not out of dishonesty, usually — out of optimism, or because the change looked right on their screen, or because there were forty more to get through. Independent verification exists precisely to catch the corrections that the corrector genuinely believed were complete. So in a sound process the Corrector's permission deliberately stops at "corrected"; they can resolve, but they cannot sign off.

The Viewer: read-only access to the record

The Viewer can see the QC record but cannot change it. This is the role for everyone who needs visibility without participation — a client, a consultant from another discipline, a junior team member learning the standard, a manager who wants to watch progress without being part of the workflow. The Viewer can open the drawing set, read the comments and their statuses, and follow the audit trail, but they cannot raise, correct, verify, or close anything.

It is easy to dismiss a read-only role as the least important, but it does real work. Much of the friction in QC comes from people who need to be informed being given more access than they need, then accidentally changing things, or from those same people being shut out entirely and having to ask for screenshots. A proper Viewer role solves both: stakeholders get genuine, current visibility of the QC state, and the integrity of the record is protected because they cannot alter it. It is also the safe default — when in doubt about how much access someone needs, start them as a Viewer and promote them when a real need appears.

The role and capability matrix

The clearest way to see how the five roles fit together is as a matrix of who can do what. The pattern to notice is the diagonal: capability narrows as you move from administration toward read-only, and the Check, Correct, and Verify columns are deliberately spread across different roles rather than concentrated in one.

The matrix is a RACI-style view in miniature: it makes explicit who is responsible for each action and, just as importantly, who is not. The rule that matters most is invisible in any single cell — it is that the Corrector column and the Verify row never meet in the same person for the same item. A Corrector cannot verify, and while a Checker or Lead can verify, they should never verify a correction they themselves made. The permission model enforces the structural separation; team discipline enforces the per-item separation.

How the roles move a defect through the loop

Roles are easiest to understand by following a single defect through the process. The example below is a routine one — a dimension that does not match between two sheets — but the same hand-offs apply to anything from a missing fire rating to a clash between disciplines.

• Project Lead sets the scope. The lead decides that the architectural set for Level 3 is to be checked against the structural set before issue, and assigns a Checker to it.
• Checker raises the issue. Comparing the two sheets, the Checker finds a column grid dimension that reads 6,000 on the plan and 6,100 on the structural drawing. They raise a comment on the plan, note the conflict, and assign it to the drawing's author.
• Corrector makes the fix. The author confirms the correct dimension is 6,000, updates the structural reference, and marks the item corrected with a note saying what changed and on which revision.
• A different person verifies. The Checker — or anyone other than the Corrector — opens the corrected item, confirms both sheets now agree, and only then closes it. Had the Corrector been able to close it themselves, no independent eye would ever have confirmed the two sheets actually match.
• Project Lead signs off. With every comment on the set closed and verified, the lead approves the set as having passed QC, putting their name to the decision to issue.
• Viewer follows along. Throughout, the structural consultant watches the same record read-only, sees the conflict raised and resolved, and never has to ask for a status update.

No step in that chain required heroics. It required each action to have an owner and the close step to be in a different hand than the correct step. That is the entire value of the role model.

Where Archi Check fits

Archi Check is purpose-built QC software for architectural drawing sets, and it ships with exactly these five roles — Manager, Project Lead, Checker, Corrector, and Viewer — governed by a permission matrix like the one above. The roles are not labels you apply by convention and hope people respect; they are enforced by the software, so a Corrector cannot close their own items and a Viewer cannot alter the record by accident.

The separation is built into the core workflow. Every markup in Archi Check becomes a tracked comment with a named owner and a status that moves through Check → Correct → Verify → Close, and the Verify step is structurally distinct from the Correct step. That means the checker who raises a comment, the corrector who resolves it, and the person who verifies the fix are different hands by design, and the audit trail records each transition with a name and a date. When a defect surfaces months later, the record answers who checked, who corrected, who verified, and on what revision.

Because Archi Check is folder-first and local — your QC data lives in your own project folders rather than a vendor cloud — the multi-user record and its role assignments stay under your control. People work the two-screen way they always have, marking up the full-size drawing on one monitor while the register tracks every comment and its owner beside it. Archi Check runs on Windows today, with macOS coming soon, and there is a 14-day free trial. For how the Checker, Corrector, and verifier roles differ in detail, see Checker vs corrector vs approver.

FAQ

What are the main roles in a drawing QC process?

Most drawing QC processes run on five roles. A Manager administers the system and assigns people to roles, a Project Lead owns the standard and the sign-off for a project, a Checker finds and raises issues, a Corrector makes the fixes, and a Viewer has read-only access to the record. Each role carries a defined set of responsibilities and permissions so that every action in the process has a clear owner.

Why should the checker not verify their own corrections?

Because verification is a control, and a control loses its value when the same person performs and confirms the same action. A corrector who can close their own items may, under deadline pressure or simple optimism, mark something resolved that was never properly fixed. Having a different person verify the correction is the cheapest, highest-value check in the whole process, and it is the core of separation of duties.

What is separation of duties in drawing QC?

Separation of duties means splitting the check, correct, and verify steps across different people so no single person can carry a defect through all three unchecked. The person who corrects a drawing should not be the person who verifies that correction. It produces both a stronger control — a second pair of eyes at the point a defect is closed — and a cleaner audit trail, because every step carries a different owner's name.

Can one person hold more than one QC role?

Yes, and on small teams it is common. One person might be both Manager and Project Lead, or a Project Lead might also check critical sheets personally. The line that must not be crossed is one person checking, correcting, and verifying the same item. Combining roles across different items is fine; collapsing the check-correct-verify chain into one person for a single item removes the control entirely.

Who signs off that a drawing set has passed QC?

Typically the Project Lead, who is accountable for the quality of a specific drawing set. They confirm that the right checks happened, that every open comment has been corrected and independently verified, and that the set is fit to issue. The Manager can usually do this too by permission, but the sign-off is an ownership decision that belongs with whoever is answerable for that project's quality.

Put the roles to work on your next set

A drawing QC process is only as strong as the separation between who corrects and who verifies. If your roles still live in people's heads rather than in the record, see how Archi Check enforces the five-role model and keeps every comment owned and verifiable: Try Archi Check free for 14 days.

Related guides

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

• Checker vs corrector vs approver
• The drawing QA/QC process in 4 stages
• How to set up a shop drawing review process
• What is drawing QA/QC?

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.