Defect Tracking on Drawings: From Markup to Closed-Out

Short answer: Defect tracking on drawings is the practice of recording every issue found during review as a discrete, owned item and following it through to a verified close. A tracked defect needs five things: a location, an owner, a status, a date, and a recorded resolution. The lifecycle runs from raised, to assigned, to corrected, to verified, to closed — and nothing should close until someone other than the person who fixed it confirms the fix. Archi Check turns every markup into exactly this kind of tracked comment, so issues move through Check → Correct → Verify → Close instead of getting lost on a printout.

Almost every team that reviews drawings is good at finding problems. The hard part is not spotting a clash, a missing dimension, or a wrong detail reference — it is making sure that the problem, once spotted, actually gets fixed and stays fixed. That second half is where most quality processes quietly leak. An issue is raised, marked up, and then it depends on memory, goodwill, and the next person remembering to look.

The symptom is familiar: a markup with no owner, no status, and no verification. A cloud and a note on a PDF tell you something was wrong on that revision. They do not tell you who is fixing it, whether it has been fixed, or whether anyone checked. This guide is about closing that gap — what a properly tracked defect contains, the lifecycle it moves through, why a register beats sticky notes and loose PDFs, and how verification stops closed issues from reopening.

Why issues get raised but lost

The reason defects slip is almost never that nobody cared. It is that the act of marking up a drawing and the act of tracking the issue are two different things, and most workflows only do the first. You circle the problem, you write a note, and the note becomes the entire record. When that note lives on a printout in a pile, or in one of fourteen PDF versions in a shared folder, it has no independent existence. It cannot be counted, assigned, or reported on.

This produces a specific failure mode. A reviewer marks twenty issues on a set. Some get fixed obviously and visibly. A handful are ambiguous — was that comment addressed, or just acknowledged? One or two were on a sheet that got superseded, and nobody carried them forward. By the time the set is issued, the team genuinely does not know whether all twenty are closed, because the only record of them is scattered ink that was never reconciled against the corrected drawings.

The deeper problem is ownership. A markup is a statement about the drawing; a tracked defect is a statement about a person's outstanding work. Until an issue has an owner and a status, it belongs to everyone and therefore no one. The fix for lost issues is not more diligence at the markup stage — it is giving every issue a life of its own that persists across revisions, separate from any single sheet.

What a properly tracked defect contains

A markup says "this is wrong, here." A tracked defect says considerably more, and the extra information is what makes it impossible to lose. Five attributes do the heavy lifting. Strip any one of them out and the issue becomes harder to close cleanly.

The two fields people most often omit are owner and resolution. A defect with no owner drifts; a defect that closes with no recorded resolution cannot be defended later when someone asks why it was marked done. Together these five fields turn a markup into something you can count, sort, assign, and audit — the difference between a pile of comments and a register.

Severity and category, where they help

Beyond the core five, two optional fields earn their place on larger sets. A severity flag separates the issues that must be resolved before issue from the cosmetic ones that can wait, so a reviewer is not forced to treat a missing fire-rating note and a misaligned text label as equals. A category — coordination, dimension, annotation, code, detail reference — lets you see patterns across a set, such as the same discipline producing the same class of error repeatedly. Neither is essential to closing a single issue, but both make a register more useful as a management tool.

The defect lifecycle, stage by stage

A tracked issue is not a binary open-or-closed flag. It moves through a small number of states, and the value of tracking comes from knowing which state every issue is in at any moment. The lifecycle below is deliberately short — five states is enough to be honest without becoming bureaucratic.

Raised

Someone finds a problem and records it as a discrete item with a location and a description. At this point the issue exists independently of the markup that prompted it. The crucial discipline here is that raising an issue is a deliberate act of creating a record, not just drawing a cloud and moving on.

Assigned

The issue is given an owner — the person responsible for the next action. Assignment is what converts an observation into accountable work. An issue with no owner is the single most common way defects get lost, because no individual has a reason to act on it.

Corrected

The owner makes the change and marks the issue as corrected. This is the stage people mistake for "done," and the mistake is costly. Corrected means the fix has been attempted, not that it is right. The issue is not closed — it is now waiting for someone to confirm the correction actually resolved the problem.

Verified

A second person — ideally not the one who made the fix — checks that the correction is real and complete. Verification is the stage that separates a tracking system from a to-do list. Without it, "corrected" and "closed" collapse into the same step, and that is exactly where reopened issues come from.

Closed

The issue is closed, with a recorded resolution and the name of whoever verified it. A closed issue is not deleted; it stays in the register as part of the audit trail, so that if it ever resurfaces you can see what was done, when, and by whom. Closing is the only stage that should be irreversible, and it should only happen after verification.

The single most important rule in this lifecycle is that corrected and closed are not the same state. The gap between them — verification — is small in effort and enormous in consequence, because it is the only thing standing between a fix that was checked and a fix that was merely claimed.

Why a register beats sticky notes and loose PDFs

The instinct to track defects on the drawings themselves is sound — the issue belongs to a place on a sheet, so marking it there makes sense. The problem is that the drawing is the wrong place to store the issue's status. Drawings get superseded; statuses need to persist. A register solves this by giving every issue a home that survives revisions, while still pointing back to its location on the sheet.

Consider what each approach can and cannot do.

• Sticky notes and printout markups. Fast to create and physically tied to the sheet, but they have no owner field, no status, and no existence once the printout is filed. You cannot count them, sort them, or report on them, and they vanish when the sheet is reprinted.
• Comments on loose PDFs. Better, because they are digital and located on the drawing, but the status still lives in the comment text. When a new PDF is issued, the comments either get flattened, copied imperfectly, or left behind on the old version, and reconciling two versions by eye is exactly the step that drops issues.
• A spreadsheet alongside the drawings. Now you have owners and statuses, but the issue and its location have been divorced — the row says "door schedule, north wing" and you are hunting for which sheet and which door. The link between the record and the place is manual and fragile.
• A register bound to the drawings. Each issue is a row with all five fields and a pin on the actual sheet. The status persists across revisions, the location is one click away, and the whole set can be filtered to "everything still open on this package." This is what tracking is supposed to feel like.

The register is not a heavier version of a markup. It is a different object: a list of accountable work items, each anchored to a place on a drawing, that you can manage as a body of work rather than rediscover sheet by sheet. For how this fits the wider quality process, see the drawing QA/QC process in 4 stages.

How verification prevents reopened issues

The most expensive defects are the ones that get closed and then come back. A reopened issue is worse than one that was never closed, because it carried a false signal of completeness — the set was issued, the work proceeded, and only later did it emerge that a "fixed" item was never actually fixed. Verification exists to make that scenario rare.

The mechanism is simple separation of duties. The person who makes a correction is, understandably, the worst-placed person to judge whether it is complete — they already believe it is done, which is why they marked it corrected. A second reviewer brings fresh eyes and, critically, the original issue description to check against. The question they answer is narrow: does the corrected drawing actually resolve the issue as it was raised? Not "does this look fine," but "was the specific thing that was wrong made right."

This is also where a good register pays for itself. Because the original issue, its location, and its description are all preserved, the verifier is checking the fix against the exact problem rather than a vague memory of it. And because verification is its own status, the register can always tell you the most dangerous category of issue: the ones marked corrected but not yet verified. Those are the items that look done and are not, and a tracking system that surfaces them is doing its core job. The roles involved — who raises, who corrects, who verifies — are worth defining explicitly; see who does what in drawing QC.

A worked example

To make the lifecycle concrete, here is a single defect moving through tracking from start to finish, the way it should look in a register.

• Raised. During checking of sheet A-203 rev C, the checker finds the stair handrail height annotated at 850mm where the code minimum is 900mm. They raise an issue, pinned to the handrail detail, category "code," severity "must-fix."
• Assigned. The issue is assigned to the architect who authored the detail. It now appears in their list of open items, dated and owned.
• Corrected. The architect updates the annotation to 900mm on rev D and marks the issue corrected, noting the change. The status moves from open to corrected — but not closed.
• Verified. The checker, not the author, opens the issue, sees the original description, and confirms on rev D that the handrail now reads 900mm and the detail is consistent with the section. They mark it verified.
• Closed. The issue closes with a recorded resolution ("annotation corrected to 900mm, rev D, verified against section") and stays in the register as a permanent record.

At no point was this issue dependent on someone remembering it. It had an owner from the moment it was assigned, a status that anyone could read, and a close that a second person stood behind. If it ever resurfaces — say the detail is reused on another project — the full history is there. That is the difference defect tracking makes: not that fewer problems are found, but that every problem found is accounted for.

Where Archi Check fits

Defect tracking is the heart of what Archi Check does. It is purpose-built QC software for architectural drawing sets, and its entire model is that a markup should never be just a markup. Every markup you place — a pin, a cloud, an arrow, a stamp — becomes a tracked comment with an owner and a status, so the act of marking up a drawing and the act of tracking the issue are the same act, not two that have to be reconciled later.

Each tracked comment carries the five fields this guide is built around: its location (sheet, revision, and the point on the drawing), an owner, a status, the dates of each change, and a recorded resolution. The status moves through Check → Correct → Verify → Close, and the lifecycle is enforced rather than suggested — nothing closes without verification, so an issue cannot quietly jump from "corrected" to "done." A second person confirms the fix against the original issue before it closes, which is precisely the step that stops reopened issues.

Around that loop sits the practical workflow. A two-screen layout keeps the register and workspace on one monitor while you mark up the full-size drawing on the other, so the list of open items is always beside the sheet you are checking. Every change is written to a complete audit trail, and because Archi Check keeps your QC data in your own project folders rather than a vendor cloud, that audit trail belongs to you and your client, not a third party. Archi Check runs on Windows today, with macOS coming soon, and there is a 14-day free trial.

FAQ

What is defect tracking on drawings?

Defect tracking on drawings is the practice of recording every issue found during review as a discrete, owned item and following it through to a verified close. Each tracked defect carries a location, an owner, a status, a date, and a resolution, and moves through a lifecycle — raised, assigned, corrected, verified, closed — so that no issue depends on someone remembering it.

What should a tracked drawing issue contain?

At minimum, five fields: a location (the sheet, revision, and point on the drawing), an owner (the person responsible for the next action), a status (where it sits in its lifecycle), a date (when it was raised and when each status changed), and a resolution (what was done and who verified it). Severity and category are useful additions on larger sets but are not essential to closing a single issue.

Why do issues marked on drawings get lost?

Because marking up a drawing and tracking the issue are two different things, and most workflows only do the first. A cloud and a note on a PDF record that something was wrong, but they carry no owner and no status, so the issue has no independent existence. When the sheet is superseded or filed, the only record of the issue goes with it, and nobody can say whether it was ever closed.

What is the difference between corrected and closed?

Corrected means the owner has attempted the fix; closed means a second person has verified that the fix actually resolves the original issue and recorded the resolution. Collapsing the two into one step is the main source of reopened issues, because a fix that was claimed but never checked looks identical to one that was checked. Verification is the gap between them.

Why is verification a separate step in defect tracking?

Because the person who made a correction already believes it is complete, which makes them the worst-placed person to judge it. A separate verifier brings fresh eyes and checks the corrected drawing against the original issue description. Keeping verification as its own status also lets the register surface the most dangerous category of issue — those marked corrected but not yet verified — which look done but are not.

Track every issue to a verified close

Defects only stay fixed when each one is owned, tracked, and verified rather than left as ink on a printout. If your issues still live as loose markups and half-remembered notes, see how Archi Check turns every markup into a tracked comment 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:

• Snag list vs punch list
• The drawing QA/QC process in 4 stages
• How to redline a drawing the right way
• Who does what in drawing 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.