Checker vs Corrector vs Approver: Defining Roles in Drawing Review

Short answer: In drawing review the checker, corrector, and approver are three distinct roles. The checker finds and raises issues without fixing them, the corrector makes the actual change to the drawing, and the approver verifies the fix and signs off to close it. The point of keeping them separate is independence: whoever made the fix should not be the one who confirms it is right. Archi Check encodes this directly in its roles and its Check → Correct → Verify → Close loop, so every comment has an owner at each stage and a verifier who is not the author.

Most drawing review breaks down not because people lack skill but because the roles blur. The person who spots a clash also fixes it, then tells themselves it is fine, and the review ends there. On a small job that may be survivable. On a real project, with hundreds of sheets and several disciplines, that blur is where errors slip through to construction — not because nobody looked, but because the same pair of eyes did all three jobs and could not see its own mistake.

This guide separates the three roles that drawing review keeps conflating. It defines what each one is responsible for, explains the independence principle that makes the separation matter, and walks through the handoffs between them. The aim is a model you can apply whether you run a two-person studio or a large multidisciplinary practice.

The three roles, defined

The confusion usually starts with language. "Reviewer," "checker," and "approver" get used interchangeably, and "correction" is treated as something that happens invisibly between the two. Pulling the verbs apart helps: someone finds, someone fixes, and someone confirms. Those are three different actions, with three different mindsets, and on a well-run project they belong to three different people.

The checker finds and raises

The checker reads the drawing critically and records what is wrong, missing, or unclear. Their job is to surface issues, not to resolve them. A good checker is deliberately adversarial toward the drawing: they assume there is a problem and go looking for it, checking dimensions against the brief, references against the sheet list, and one discipline's drawing against another's. Crucially, the checker does not edit the drawing. The moment a checker starts fixing things, two things go wrong — the record of what was found gets lost in the act of fixing it, and the checker stops checking and starts designing, which is a different job with a different bias.

The corrector makes the fix

The corrector takes a raised issue and changes the drawing to resolve it. This is usually the original author of the drawing or another member of the production team, because fixing a drawing requires the authoring tools and the design knowledge to make the change correctly. The corrector's responsibility is narrow and specific: resolve the issue as raised, and record what was done. They are not the judge of whether the issue was valid — if they disagree, that is a conversation to have in the comment thread, not a reason to silently ignore the markup. And they are not the person who decides the fix is complete; that decision belongs to someone else.

The approver verifies and closes

The approver confirms that the correction actually resolves the issue, then closes it. This is the verification step, and it is the one most often skipped. The approver — often a project lead, senior checker, or discipline lead — looks at the corrected drawing and asks a single question: does this fix the issue that was raised, without introducing a new one? If yes, the item closes with a record of who verified it and when. If no, it goes back. The approver is not re-doing the checker's work and not doing the corrector's work; they are the gate that decides an item is genuinely resolved rather than merely touched.

Why conflating the roles breaks QC

When one person plays two or three of these roles at once, specific failure modes appear, and they are predictable enough to name.

The first is the self-verification trap. When the person who made a fix also confirms it, they are checking their own work, and people are demonstrably bad at finding their own errors. The same mental model that produced the mistake is the one now asked to catch it. This is not a comment on anyone's competence — it is a known limit of human attention, and it is exactly why proofreaders do not proofread their own copy and surgeons do not assist on their own operations. A correction verified by its author is, in quality terms, an unverified correction.

The second is the lost-issue problem. When the checker fixes as they go, there is no durable record of what was found. The drawing changes, but the issue was never written down as a discrete item with a status, so nobody can later ask "was that clash ever resolved?" The fix and the finding collapse into a single invisible event. Months later, when a defect surfaces on site, there is no trail showing whether it was caught and missed, caught and mis-fixed, or never caught at all.

The third is the accountability gap. If a checker also approves, the question "who signed this off?" has a circular answer — the same person who might have made the error also blessed it. When responsibility cannot be attributed cleanly, it cannot be questioned cleanly either, and the review loses its value as a record. The roles exist partly so that, if something goes wrong, the project can reconstruct exactly who decided what.

The independence principle

The thread running through all three failure modes is independence. The single most important rule in drawing review is this: the person who makes a fix should not be the person who verifies it. Everything else in this article is a consequence of that rule.

Independence does not require a large team. In a two-person studio, the principle still holds — if I draw a sheet and you check it, then I fix what you found and you verify the fix, we have preserved independence with two people by swapping roles per item. What independence forbids is the closed loop where one person finds, fixes, and signs off with no second set of eyes at the verification gate. The number of people can be small; the number of independent viewpoints at the verify step must be at least one that is not the corrector.

There is a softer version of the principle worth naming too: independence of mindset. A checker who has just spent an hour fixing a drawing carries the author's bias into the next check — they see what they meant to draw, not what is on the sheet. Keeping the finding role separate from the fixing role keeps the checker's eye cold. This is why even a single competent person, wearing different hats at different times, benefits from making the roles explicit rather than letting them merge.

Checker vs corrector vs approver: a comparison

The clearest way to hold the three roles apart is to lay them side by side. The columns are not a hierarchy — a senior person may act as checker on one item and approver on another — but on any single item they should be three distinct hats, and ideally two or three distinct people.

If your practice formalises who holds these roles, it is worth reading alongside the fuller picture of the wider team — see who does what in drawing QC, which sets these three within the full set of project roles.

How the handoffs work

Roles only mean something when the work moves cleanly between them. Each transition is a handoff, and each handoff is where an item can either progress or stall. There are three of them.

Checker to corrector: the raised issue

The checker hands the corrector a raised issue. For the handoff to work, the issue has to be specific enough to act on: what is wrong, where it is on the sheet, and ideally why it matters. "Check this" is not a handoff; "the door swing on grid C/4 clashes with the radiator shown on the M&E layout" is. A well-formed issue tells the corrector exactly what to resolve and gives the approver, later, a clear test for whether it was resolved.

Corrector to approver: the completed fix

The corrector hands the approver a completed fix, along with a note of what was changed. This handoff fails most often when the corrector marks something done without saying what they did, leaving the approver to reverse-engineer the change. A good handoff says "moved the radiator 300mm and revised the door to open out," so the approver can verify against a stated change rather than hunting for it. The corrector does not close the item — they signal it is ready for verification.

Approver to closed: the verified item

The approver either closes the item or returns it. Closing means the verification record is written: who confirmed it, against what, and when. Returning means the item goes back to the corrector with a reason, and the loop runs again. This is the gate that gives the whole system its integrity — an item is not done because someone touched it, it is done because someone independent confirmed it. Nothing leaves the loop without passing through this gate.

A worked example

To make the roles concrete, here is a single coordination issue moving through all three, the way it would on a real set.

• Check. A checker, reviewing the architectural floor plan against the structural layout, finds that a non-loadbearing partition on the architectural drawing sits where the structural drawing shows a column. They raise a comment on the sheet: "Partition on grid B/2 conflicts with structural column 400×400; coordinate." They do not move anything.
• Correct. The comment is assigned to the architectural author. They confirm the column is fixed, adjust the partition to wrap the column, and update the door position that the partition shift affected. They record what they changed and mark the item ready for verification — but do not close it.
• Verify. The project lead opens the corrected sheet and checks the stated change: the partition now clears the column, the door still meets the corridor width, and no new clash was introduced. They confirm it resolves the original comment.
• Close. The lead closes the item. The record now shows the issue, who raised it, who fixed it and how, and who verified and closed it, with dates. If the same area is queried on site later, the whole history is there.

Notice that no single person did all four steps, and the verifier was not the corrector. That is the independence principle in practice. If the author had simply moved the partition and ticked the comment off, the door-width side effect might never have been caught — and there would be no record that anyone had checked.

Where Archi Check fits

Archi Check is purpose-built QC software for architectural drawing sets, and the separation this article describes is built into how it works rather than left to discipline. Its roles map directly onto the three actions: a Checker raises comments, a Corrector is assigned to them and makes the fix, and a Project Lead verifies and closes — with a full permission matrix behind it, plus Manager and Viewer roles, so people only do the part of the loop they own.

The reason it holds the line is the core loop. Every markup in Archi Check becomes a tracked comment that moves through Check → Correct → Verify → Close, and a comment cannot close itself. It is raised by the checker, assigned and resolved by the corrector, and then verified and closed by someone else — the loop is built so the person who fixed an item is not the person who signs it off. Each transition is recorded, so the audit trail shows who found the issue, who corrected it, and who verified it, with dates against each stage. That is the accountability gap closed by construction, not by good intentions.

Because the data lives in your own project folders rather than a vendor cloud, the audit trail belongs to you and sits beside the drawings it describes. You work across two screens — the comment register and roles on one monitor, the full-size drawing markup on the other — so the checker can raise an issue against the sheet while the register tracks ownership and status alongside it. Archi Check runs on Windows today, with macOS coming soon, and there is a 14-day free trial.

FAQ

What is the difference between a checker and a corrector?

A checker finds and raises issues on a drawing without fixing them — their job is to surface what is wrong, missing, or unclear and record it as a discrete item. A corrector takes a raised issue and changes the drawing to resolve it, usually the drawing's author or someone on the production team. Keeping them separate means the record of what was found is preserved, and the checker keeps an independent, adversarial eye rather than slipping into authoring.

Can the same person be the checker and the approver?

On a single item, it is better that they are not, but the firmer rule concerns the corrector. The person who makes a fix should never be the one who verifies and closes it, because people are poor at finding their own errors. A checker who did not make the fix can act as approver. The hard line is that verification must be independent of the correction — whoever fixed the item cannot be the one who signs it off.

What does the approver actually do in drawing review?

The approver verifies that a correction resolves the issue that was raised, without introducing a new one, and then closes the item with a record of who verified it and when. They are not re-running the checker's review or re-doing the corrector's edit; they are the gate that decides an item is genuinely resolved rather than merely touched. This verification step is the one most often skipped, and skipping it is where unverified fixes reach construction.

Why does separating the roles matter on a small team?

Independence is about viewpoints, not headcount. Even on a two-person team you can preserve it by swapping roles per item — one person draws and fixes, the other checks and verifies. What the principle forbids is the closed loop where one person finds, fixes, and signs off with no second set of eyes at the verify gate. Making the roles explicit also keeps each person's mindset clean, so a checker is not carrying the author's bias into the next review.

How does Archi Check enforce the separation between roles?

Archi Check assigns distinct roles — Checker, Corrector, and Project Lead, within a fuller permission matrix — and runs every markup through a Check → Correct → Verify → Close loop where a comment cannot close itself. An item is raised by a checker, assigned and resolved by a corrector, then verified and closed by someone else. Each stage is recorded, so the audit trail shows who found, who fixed, and who verified each issue, with the verification step held independent of the correction by design.

Keep the three roles honest

Defining the checker, corrector, and approver is the easy part; keeping them separate under deadline pressure is the hard part, and it is where most QC quietly fails. If you want the separation enforced by the tool rather than by memory, see how Archi Check tracks every comment through Check → Correct → Verify → Close: Try Archi Check free for 14 days.

Related guides

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

• Who does what in drawing QC
• The drawing QA/QC process in 4 stages
• How to set up a shop drawing review process
• Defect tracking on 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.