Checking Every Set Against Code Before It Leaves the Studio

Start with the problem. What was quality control on a drawing set actually costing the studio before you automated any of it?

Every set we issue is three documents that must agree: the drawings, the specifications, and the schedules, all measured against the building code for that jurisdiction. In practice they drift. A finish gets changed on a plan but not in the spec, a door disappears from a schedule, a corridor loses the clearance an accessibility clause requires. On a small team, that reconciliation lands on a senior architect in the final days before a deadline, when attention is thinnest. What we miss surfaces later as a request for information, a plan-review comment, or rework in the field, and each carries a cost we rarely recover on a fixed fee. Industry reviews attribute a large share of expensive errors, commonly cited around seventy percent, to coordination gaps between disciplines rather than to design mistakes. For a studio our size the exposure is not only the change order. It is the hour a principal spends re-checking a set instead of designing, and the credibility we stake with a client and a plans examiner every time we stamp a drawing.

Tools that check drawings against code have been promised for years. Why is this viable now and not five years ago?

Two capabilities matured at roughly the same time. The first is that vision models can now read a real drawing sheet: the plan geometry, the annotations, the schedules, the title block, not just a tidy BIM database. Older compliance checkers were rule engines that demanded perfectly structured models, so they broke on the mixed PDF and model sets most firms actually issue. The second is retrieval. Instead of asking a model to recall the code from memory, which is where these systems used to invent requirements, we retrieve the specific code text and the project's own specification and require the tool to cite the clause it is applying. That grounding is the difference between a plausible guess and a checkable finding. The regulatory context has moved as well. Florida's 2025 legislation authorizes private providers to use software-based plan review, and Singapore's CORENET has run automated code checking for years while still routing complex projects to human examiners. None of this makes the tool an authority. It makes it a credible first pass, which five years ago it was not.

Walk me through how a set actually moves through the check. What happens, in order?

A set goes in as we issue it: the drawings, the specification, and the schedules, with the jurisdiction and code edition identified up front, because a requirement can change from one edition to the next. The system extracts the content first, reading annotations, dimensions, and schedule tables from the sheets. Then it retrieves the clauses that apply to this building's occupancy and construction type, and pulls the relevant sections of our own spec. From there it runs a library of cross-checks. Some are code checks: egress widths, corridor and door clearances for accessibility, fire-rating call-outs, plumbing-fixture counts. Others are internal consistency checks: a material named in the spec that never appears on a drawing, a door or fixture shown on a plan but missing from its schedule, a finish that two sheets describe differently. The output is not a verdict. It is a ranked list of flags, each tied to a specific sheet location and the clause or spec section behind it, sorted so the highest-consequence items sit at the top. An architect then opens each flag and decides what it is.

Drawing sets and client specifications are sensitive. How do you handle confidentiality and the data itself?

The drawings and the specification are the client's intellectual property, and the design is often unpublished, so this was a procurement decision before it was a technology one. We required that our project data not be used to train anyone's model, that it stay isolated to our tenant, and that it be retained only as long as we need it and then deleted. Access is scoped by project, so a team member sees the sets they are working on, not the whole studio's book of work. The building codes themselves are public, but the pairing of a specific client's drawings with a specific site is not, and that pairing is what we protect. One practical point firms overlook: professional-liability carriers are starting to ask how AI is used in the workflow, and undisclosed use that changes your risk profile can complicate coverage. We treat disclosure, to clients and to our insurer, as part of the governance, not an afterthought.

Who is accountable for what the set says, and how do you keep the tool's mistakes out of a stamped drawing?

The accountability does not move. A licensed architect stamps the set, and that responsibility is non-delegable: it cannot be assigned to software. So the tool is built to propose, never to approve. It surfaces candidate issues; a licensed architect reviews each one and decides whether it is a real conflict, an acceptable condition, or a false alarm. False positives are expected, and we would rather the system be slightly over-sensitive than quietly miss something. To trust it at all, we validated it the way you would validate any control: we ran it against past sets where we already knew what the problems had been, measured how many it caught and how much noise it generated, and only then let it into live work. Two habits keep its mistakes out of a stamped drawing. First, every flag carries its citation, so the reviewer checks the clause rather than the model's assertion. Second, nothing the tool produces edits a drawing on its own; it produces a review list, and a person makes the change. The reviewer's judgment is the product.

How did the studio adopt this? What did staff make of it, and what went wrong first?

There was healthy skepticism, most of it from the people whose judgment the tool was supposedly assisting, which is the right instinct. The first version was too noisy. It flagged trivial inconsistencies alongside real ones, and a reviewer who wades through forty low-value alerts to find three that matter will stop reading. So the early work was not adding checks but suppressing the ones that did not earn attention, and ranking the rest by consequence. We also made a sequencing mistake. We first ran the check only at the end, as a final gate before issue, which meant findings arrived when there was no time to do anything but the urgent fixes. Moving it earlier, so a set gets checked as it develops, turned it from an audit into a working tool. On training, we were explicit that this reduces the drudgery of reconciliation, not the responsibility for the design. We taught people to read the citation and disposition each flag rather than trust or dismiss the tool wholesale. Newer staff took to it fastest, and a few senior architects became its strongest advocates once it caught something they respected.

What has it actually produced that you can measure, and how honestly can you attribute it?

The clearest number is time. Reconciling drawings, specs, and schedules by hand was consuming a large block of senior hours, and in our own accounting we estimate the check returns on the order of two hundred and forty hours a year per professional, time that goes back into design and client work. I would frame that honestly: it is our internal estimate, not an audited figure, and it varies with how complex the project is. The outcome I value more is consistency. Before, whether a set got a thorough code-and-spec review depended on who was free and how tight the deadline was. Now every set the studio issues gets the same baseline check, which is the real change for a small firm. We also see fewer code conflicts reaching permit review or the field, though that one resists precise measurement, because you cannot cleanly count the errors you prevented. What I can say is that our plan-review comments trend down and our teams are surprised late less often. The gain is not that the studio moves faster. It is that it misses less.

What would you say to a peer who distrusts these tools, or a client who is nervous about AI touching their drawings?

They are right to be cautious, and the profession is. The American Institute of Architects found in 2025 that only about eight percent of firms had put AI into practice, and inaccuracy was the top concern, cited by roughly ninety-four percent of them. That skepticism is appropriate, because the tool is wrong sometimes. It can misread a poorly scanned sheet, apply the wrong code edition if the inputs are sloppy, or flag conditions that are perfectly acceptable. Those failure modes are exactly why it holds no authority in our process. To a nervous client I say something simple: no decision about your building is made by software. A licensed architect reviews every finding and stamps the set, and their liability is unchanged. What the tool does is make that review more complete and more consistent, not make the architect less involved. On limits, I am candid about where it is weakest. Novel conditions, ambiguous local amendments to the base code, and performance-based compliance paths still require judgment the system does not have. It is not a substitute for expertise.

Give me a specific moment where it mattered.

On a commercial fit-out, late in the set, a millwork revision narrowed one side of a corridor. It was a small change on a single plan, the kind that looks harmless in isolation. But that corridor was part of an accessible route, and the reduced dimension no longer met the clearance the accessibility provisions require. The specification still described the original condition, so the plan now disagreed with it. The check flagged the conflict, tied it to the specific clause and the sheet where the change lived, and ranked it near the top because it touched code and safety, not just consistency. A senior architect confirmed it in a few minutes and we corrected the plan before the set went out. On its own that is one catch, and I offer it as representative rather than as a headline. But trace it forward: unresolved, it becomes a plan-review rejection at best and, at worst, a built condition that fails inspection and has to be torn out. The value of the tool is that it made a quiet, easy-to-miss change loud at the moment it could still be fixed cheaply.

Looking ahead, what does this change about the practice of architecture, or about the client relationship?

I do not think this automates architecture. It automates the checkable, rule-bound layer that sits underneath the design, so that a professional's judgment goes to the parts of the work that actually require it. For a studio our size that is a meaningful equalizer. We can now offer a level of quality assurance that used to require the headcount of a much larger firm, and offer it on every project rather than the ones that happen to have slack in the schedule. The client relationship shifts in a quiet but real way: fewer late surprises, a documented and repeatable review behind every set, and a clearer answer when a plans examiner asks how we checked our work. I also expect the ground to keep moving. As more jurisdictions accept software-assisted plan review, fluency with these tools stops being an advantage and becomes an expectation. What does not change is where responsibility sits. The stamp is still a human act, and the judgment behind it is still ours. The bar that rises is thoroughness, and I am comfortable being held to it.