An architect I talked to recently described the moment she dreads most. Not the design. Not the client review. The issuance. The set goes out the door, stamped and complete, and for the next few months it comes back to her one RFI at a time. A door schedule that calls for a fire rating the wall type on the plan can’t carry. A finish in the spec that the room the drawing points to was never sized for. A detail referenced on sheet A-501 that doesn’t exist. Each one is a small thing. Each one was sitting in the file she released, and neither she nor anyone on her team could see it, because seeing it would have meant holding four hundred pages in their head at once and checking every one against every other.
She caught what she could. The rest surfaced later, in the field, as questions from a contractor who found the contradiction the hard way. That’s the part that stuck with me.
I have been thinking about that conversation because it names something the industry has quietly accepted as the cost of doing business. The average commercial project generates close to 800 requests for information, and a large share of them exist for one reason: the drawings, the specs, and the schedules that make up a construction document set are supposed to agree, and they don’t. The Navigant Construction Forum studied more than 1,300 projects and put the average cost of resolving a single RFI at about $1,080, roughly eight hours of somebody’s time per question. Do that eight hundred times and the arithmetic gets serious. What almost nobody says out loud is that most of those questions aren’t really questions. They’re the design catching up to itself, months after it should have.
What a set actually is
The reason this problem’s been so stubborn is that everyone, including the software built to help, has misread what a drawing set is.
A plan set looks like a document. It opens in the same viewer as a lease agreement. It is bound, paginated, and read front to back. So the tools we built to manage it treat it like a document: a place to store pages, mark them up, and route them for signatures. Storage and workflow. Neither one knows what’s on the page.
But a set isn’t a document. It’s a database that happens to be printed. The floor plan is one table. The door schedule is another. The wall-type legend is a third, the finish schedule a fourth, the specification book a fifth. Every one of them describes the same building from a different angle, and they are joined by keys the way any relational database is joined by keys. A door tag on the plan is a foreign key into the door schedule. A wall-type callout points into the assembly legend. A room number ties the plan to the finish schedule to the mechanical loads. The meaning of the set doesn’t live inside any single sheet. It lives in whether those joins hold. That’s the whole thing.
When they don’t hold, you get exactly the thing the architect dreads. A door tagged on the plan that the schedule rates for the wrong fire class. A room the finish schedule furnishes that the plan drew too small. A detail callout with no detail on the other end. These aren’t exotic failures. They’re the normal state of a real set under deadline, because the sheets are drawn by different people, at different times, and reconciled by hand, late, if at all.
Validation the reader can’t do
Once you see the set as a database, the interesting question changes. It stops being “how do we store this” and becomes “why can’t we query it before we ship it.” Good question.
A database has a concept the drawing set has always lacked: the constraint you check before you commit. You don’t let a record save if its foreign key points at nothing. You don’t let two rows claim the same primary key. The machine won’t allow it. The whole point of structure is that the machine catches the contradiction the instant you create it, not two months after you’ve built on top of it.
A drawing set has never had that, and not for lack of care. The architect can’t run the query because the set isn’t queryable. It’s ink on four hundred pages. Checking whether every door tag resolves to a real schedule row, whether every finish has a room that can hold it, whether every detail callout lands on an actual detail, would mean a person cross-referencing thousands of relationships by eye, on a deadline, and getting all of them right. Nobody can do that. So the constraints go unchecked until the contractor checks them for you, one RFI at a time, after issuance, when every fix is a change order instead of an edit. By then it’s late.
The thing that makes this fixable now is that the set was always structured. The structure was just locked in a format only a trained human could read.
The same reading, a different reader
This is the part that connects to what we have been building for years, and it is why the architect’s problem and the estimator’s problem are the same problem wearing different clothes.
An estimator reads a set to produce a quantity: how many fixtures, how many linear feet, how much drywall. To do that, they have to first turn the flat pages into a model of a real building, tracing a circuit from the plan to the panel schedule to the riser, holding the whole set together well enough that the count is right. The reading is the hard part. The counting comes after.
An architect validating a set before issuance is doing the same reading, and then asking a different question of it. Not “how many,” but “do these agree.” Does the door on the plan match the door in the schedule. Does the wall type on this sheet carry the rating the life-safety plan assumes. Does the finish the spec calls for fit the room the drawing points to. Those are join checks against the same graph the estimator traverses. A system that can read a set into a connected model, the plans and the schedules and the specs as one structure instead of a stack of images, can answer both questions from the same understanding. The takeoff and the design check are two reports off one query engine.
That’s the whole idea, and it took us a while to say it this plainly. We started with takeoff because that is where the pain was loudest and the money moved fastest. But the capability we had to build to do takeoff well, reading a drawing set into the structured, connected thing it always was, turns out to be the capability that lets an architect see the mismatch at draft time instead of at RFI. Same model. Same graph. The estimator asks it to count. The architect asks it to check. That’s the only difference. Neither could do their real job until the reading was done, and the reading is the part software could never do until now.
Draft time, not RFI time
The shift I care about is where in time the error gets caught.
Today the design set is validated by the people downstream of it. The contractor’s estimator finds the contradiction while bidding. The field super finds it during install. The owner finds it in the change-order log. Every one of those is a discovery made after issuance, which is the most expensive possible moment to discover anything, because the whole point of issuance is that everyone downstream now trusts the set enough to build on it. A construction workflow compounds forward and doesn’t reverse. An error in the set propagates through the bid, the contract, the buyout, the schedule, and the crew before it surfaces, and pulling it back costs money in every direction it traveled.
Move the same check upstream, to the architect, before the stamp, and the contradiction is a five-minute edit instead of a $1,080 RFI and the delay behind it. Nothing about the design got harder. The reader just got better. The set was always a database. We just finally have something that can read it as one, and hand the architect the query she could never run by hand: show me every place these pages disagree, while I can still fix it with a keystroke.
I don’t want to oversell where this sits. Reading each kind of sheet well is solved. Making the checks continuous and complete across an arbitrary set, on every project, is the work we’re driving toward, and I’d rather say that than pretend the whole thing’s finished. But the direction is not in doubt. The building industry has spent a century treating its most important dataset as a stack of paper because that was the only form its readers could use. It was never paper. It’s a database in disguise, waiting for a reader that could finally query it. The architect who dreads issuance has been doing that query by hand, imperfectly, for her entire career. She shouldn’t have to anymore.
Deepti Yenireddy is the founder and CEO of Boon AI.
