An independent magazine about AI at work in construction. Every story starts on a real job site, with the people who used the technology and the results they will answer for.
The Curb That Moved Between the Bid Set and the Permit Set | ConstructionMagazine.ai
The Curb That Moved Between the Bid Set and the Permit Set
An estimator fed two drawing sets to a chatbot, one file at a time, and found a changed curb the bid had missed. Catching the next one takes a register for every issued set and a person who decides what enters the price.
The bid was already on the street when the architect emailed a new set. The estimator, at one of the GCs we talked to, opened a chatbot, uploaded the old PDF and then the new one, and asked what had changed. It took several prompts before the model stopped describing the sheets it found interesting and answered the question. One of the changes was a curb. The bid did not include it.
A ten-day tender leaves no time to overlay every sheet by eye, so a change like that usually surfaces months later as a change order with the general contractor's name on it. The estimator had the right instinct. The tool was built for a different job, and the reasons it struggled explain what a tool built for this job has to do.
The curb moved between the two issued sets. AI-assisted illustration.
How a set changes between bid and permit
A bid set and a permit set are rarely the same document. Between them the design team answers plan-check comments, the civil engineer resolves a grading conflict, and a utility company moves a connection. Each of those lands on a sheet as a revision cloud with a delta mark, and the set goes back out with a new issue date. Sheets get renumbered when a detail is split in two. A curb that moves six inches to clear a new drainage inlet is exactly the kind of change that arrives this way: small on the page, easy to miss in a cloud among a dozen others, and expensive once the forms are set.
The bid letter is the record that ties a price to a set. Most estimators write the issue date and revision list of the drawings they priced into the letter, and most owners' contracts treat a later issue as a change to be priced separately. That habit is the whole defence. If the letter names the set, the curb is a change order the GC can carry back to the owner. If the letter is vague, or if the estimator priced the new set without knowing what moved, the cost sits with the GC. The compare is not a technical exercise. It decides who pays.
Why the chatbot talked about the wrong sheets
A drawing set is the wrong shape for a chat window. A civil set of a dozen sheets runs to several megabytes, and a commercial permit set runs far larger. Chat interfaces cap uploads well below that, which is why the estimator was feeding files one at a time. Once a file is in, each question starts the reading over. The model reads the whole document again for every prompt, spends most of its attention on the pages it parses most easily, and answers about those. Ask what changed and it will tell you what it noticed.
The harder problem is that the answer arrives polished. A fluent paragraph describing three changes reads as complete, and a reviewer with ten minutes will scan it, agree with it, and move on. The changes it missed are invisible by construction. Nothing on the page says what the model did not look at.
The upload limit is the practical version of the same problem. Chat products cap a single file at a few megabytes, and a civil set of ten or fifteen sheets already runs to that size. A commercial permit set with structural, mechanical, and electrical volumes is many times larger. Estimators who work this way end up splitting the set by hand, uploading one volume at a time, and losing the cross-references between sheets, which is where a moved curb shows up: on the civil plan, on the grading plan, and in a detail that references both.
Hold both sets still
The estimators who get reliable results from models on drawings do not ask the model to read the set. They split each issued set into single sheets, pull the text and vector layers out of each one, and build a register: sheet number, title, revision mark, and a one-line account of what the sheet shows. The model then works from the register and opens a sheet only when a question points at it. Practitioners who have measured the difference report accuracy in the high nineties against the low eighties for raw images, and a fraction of the processing cost, because each question touches a few thousand characters instead of a whole set.
The register also fixes a record-keeping habit that makes revision compares impossible in the first place. Most project folders hold ten versions of the same drawing named by date, or by underscore-final and underscore-final-final. Nobody can say which one the bid was priced from. A register per issued set makes the answer explicit: this takeoff was measured from this set, and a new issue means the takeoff is stale until someone says otherwise. Version control on a drawing set is not a software feature. It is a record of which piece of paper a number came from.
The GC in this story built the idea into its own tool. It pulls sheets from the structured drawing records in Procore, so the revision history it reads is the real history and not a folder listing. The model reads both versions of a changed sheet. Each finding is pinned to a location on the sheet, and the run is saved so the next review starts from it rather than from scratch.
Nothing in that design is exotic. It is the same discipline a document controller applies to a transmittal log, applied to the model's inputs. The register says what exists. The takeoff record says what was priced. The compare says what changed. The model's job narrows to reading two versions of one sheet and describing the difference in plain terms, pinned to a grid reference, which is a task it does well when the two sheets are the only thing in front of it.
Revision compare from two issued sets
1Split each issued set into single-sheet PDFs and extract the text and vector layers
→
2Build a sheet register for each set: number, title, revision mark, what is shown
→
3Record which set the current takeoff and bid number were priced from
→
4Compare the two registers: new sheets, dropped sheets, changed revision marks
→
5For each changed sheet, open only that pair and describe what moved, pinned to a location
→
6Count-type changes come from vector tags; length and area changes go to a person to measure
→
7A person decides whether each change enters the price and logs the run for the next review
What the compare can count and what a person must measure
There is a line inside a drawing that decides what a model can be trusted with. On one side are the objects a drafter tagged: light fittings, fixtures, doors, anything with a text label sitting in the vector layer. A model can count those with near-perfect accuracy, and the count can be audited because each tag has a location. On the other side are quantities a person reads off the drawing with a scale: the length of a cable tray run, the area of a slab, the dimension of a curb. Models are poor at those, and the vendors know it. The connectors that link chat models to plan-review software read the text layer and stop there. Across the model comparisons practitioners have published this year, scale and measurement is the weakest category for every model tested.
The curb in this story sits on the wrong side of that line. A model can flag that a curb line moved between two sheets, and that is worth a great deal on a ten-day tender. It cannot be trusted to say how far, or what the new dimension does to the price. That measurement stays with the estimator, which is where the GC's tool leaves it: the change is flagged and located, and a person opens the pair of sheets.
Other contractors have landed in the same place with vendor tools. Novo Construction, which built its own system of record rather than buy one, replaced Bluebeam overlays with Buildcheck's automated drawing diffs. Colin Stoner, Novo's chief information officer, told Construction Dive that overlaying hundreds of pages by hand made the reviewers go cross-eyed, and that his rule for the automated version is to trust it and then verify it. Buildcheck says it has more than 50 paying customers. That figure is the vendor's.
Buildcheck raised $5.9 million in December 2025 to build that product, according to Engineering News-Record, and the market it sells into is the review step this story is about: a design revision arrives and someone has to find every change before it costs money. Bluebeam, the plan-review tool most estimators already own, has its own overlay and compare features. Its newer connection to chat models reads a drawing's text layer and stops there, so a question about a length or an area on a scanned sheet gets no answer. The boundary is the same one the GC's tool respects.
What to record before the next set arrives
The estimator's compare would have gone faster with four records already in place. None of them needs software beyond a folder and a spreadsheet, and all of them make a model compare possible later.
Write the issue date and the revision of every sheet you priced into the bid letter, and keep the exact PDF you priced from under that name.
Keep one register per issued set: sheet number, title, revision mark, and one line on what the sheet shows.
When a new set arrives, list new sheets, dropped sheets, and changed revision marks before anyone opens a drawing.
Send count-type changes to the software and length and area changes to a person with a scale, and log who measured what.
Whether the curb belongs in the number is the estimator's call, as it always was. What changes is what the estimator knows when making it: which set the price came from, which sheets moved, and which of the changes the software counted rather than guessed.