What AI Takeoff Tools Cannot Do Without Human Review

Division 8 estimating (doors, frames, hardware, glazing) now runs through AI takeoff tools that extract door schedules and hardware sets faster than any manual process could. What these tools cannot do is resolve the judgment calls buried inside the documents themselves: contradictory specs, undefined finishes, contested conventions, and cross-division scope questions that require a trained estimator to adjudicate, not extract.

That distinction matters because Division 8 is not a small corner of a commercial bid. A single mid-rise building can carry 180 to 400 individual door openings across three to five floors, and each opening comes attached to a fire rating, a frame type, a hardware set, and ADA requirements that all have to agree with each other. A single hardware set can run 15 or more line items. Multiplying that across 300 doors pushes the gap between a careful takeoff and a sloppy one into six figures before anyone breaks ground. Custom frames, specialty glazing, and electrified hardware often carry lead times of 8 to 14 weeks, so a missed item discovered after award isn't just a cost problem, it's a schedule problem. Estimators historically had to read the floor plan, the door schedule, the hardware schedule, and the Division 8 spec section all at once, cross-checking finishes and ratings and notes against each other, because doing them one at a time is exactly where errors start. Division 8 also touches Division 5 for frames in metal stud walls, Division 26 for electrified hardware power, and Divisions 27 and 28 for communications and access control, so a coordination miss in any one of those becomes a scope miss in the bid.

That's the complexity AI takeoff tools are now operating inside. Tools that handle it well are doing something genuinely hard, and that's why the point where they stop being reliable deserves precision.

What AI takeoff tools do well in Division 8

The strongest platforms on the market extract door schedules, hardware sets, and floor plan data at the same time, map each opening to its hardware set, and hand back a structured takeoff without an estimator re-typing anything. On clean, vector-based PDF blueprints, some platforms report accuracy in the 95 to 99% range on clean inputs, and independent testing has placed platforms within a narrow margin of ground-truth quantities on well-formed document sets.

Several purpose-built products illustrate the range of what's now automated. Some tools locate doors directly on the floor plan, tag them by configuration, and reconcile that against the published door schedule, which lets an estimator swap a component (a different closer, a different lockset) and see the cost impact in minutes rather than re-running a manual count. Others use an AI-powered first pass to return footprint, area, linear, and count quantities, including door counts, and then rely on a second, more traditional takeoff pass to refine handing and hardware detail (right-hand versus left-hand swings, frame counts, locks, hinges) before the estimator reviews it. Still others automate the counting of doors, windows, and wall symbols across a floor plan set, freeing an estimator's attention for pricing and scope decisions instead of manual counting. A newer category of tools built specifically for door and hardware distributors carries a job from takeoff through estimating and submittals into purchase orders, and some platforms now trace every extracted row back to its exact source page and table, so the estimator can verify the number against the original document rather than trusting a black box.

What all of these share is that they solve for volume. Reconciling 300 openings against a hardware schedule by hand used to eat a full day. Now it doesn't. But extraction accuracy and judgment accuracy are not the same metric, and that difference is where the real risk in Division 8 estimating lives.

Where accuracy numbers stop telling the whole story

The 95 to 99% accuracy figure comes with a condition attached to it that vendors don't always lead with: it applies to clean, vector-based PDFs. Complex commercial document sets with dense annotation, hand markups, or scanned raster pages still produce error rates in the 8 to 12% range on some platforms, and that gap hasn't closed just because the marketing has gotten more confident. Other vendors report accuracy in the mid-80s to low-90s on simple building geometry, with explicitly worse performance once the building gets multiple levels and more complex floor plans.

None of those numbers, even the good ones, measure what actually causes rework on a Division 8 bid. They measure quantity extraction from well-formed documents. They do not measure whether the tool can interpret ambiguous spec language, catch a fire-rating conflict between two sections, or notice that a finish code is missing. Separately, research into AI hallucination rates has found error rates ranging from roughly 1% on simple summarization tasks up to 19% on long, multi-turn conversations, which is a wide enough range that "the model is usually right" stops being a useful reassurance. A hallucination rate that's tolerable in a creative writing tool is not tolerable in a technical takeoff. The cost of a wrong answer isn't symmetrical: a missed hardware line on an exterior door isn't a stylistic quibble, it's a change order.

The honest framing, and it's one the better practitioners in this trade already operate by, is that AI has been estimated to automate close to half of construction tasks broadly. The other half still needs a human who understands the trade. That's not a knock on the technology; it's a description of where the boundary currently sits, and pretending otherwise is how six-figure gaps happen quietly, without anyone noticing until the openings are already on order. It's a description of where the boundary currently sits, and pretending otherwise is how six-figure gaps happen quietly, without anyone noticing until the openings are already on order.

Spec conflicts that no extraction engine can resolve on its own

A spec conflict is a contradiction between two documents, or between two sections of the same spec, that leaves the actual requirement genuinely unclear. A scope gap is different: it's work that sits in the project set but belongs to no trade. Both appear constantly in Division 8 documents, and neither one is something an extraction engine can settle on its own.

The trade's own conventions acknowledge this. Discrepancies or conflicting items create ambiguity that belongs with the architect before bidding, not quietly resolved by whoever's doing the takeoff.

A published fire station specification makes the problem concrete. Its hardware schedule lists five columns with no column headers at all, which is a fairly typical live-document format in this trade. Four doors in that schedule are assigned to two hardware sets simultaneously. Nine more doors are assigned to a set explicitly captioned "NOT IN USE." Read that caption literally, and those nine openings carry no hardware. The door list is the authoritative source, and those same nine openings carry 63 separate line items. An AI tool extracting that document will faithfully reproduce the contradiction exactly as written, because there's nothing in the document telling it which reading is correct. It has no way to know, and no mechanism for finding out.

Late addenda make this worse, not better. A spec section revised 48 hours before bid day means every trade touching that section needs re-checking, and an AI tool that already processed the earlier version has no way of knowing anything changed unless a person tells it to look again. Adjudicating the contradiction, writing down the assumption, and deciding what to carry, qualify, or send back as an RFI is estimator work. It cannot be handed to the extraction layer, because the extraction layer has no basis for choosing.

Finish codes, blank lines, and the prices an estimator has to invent

Blank finish codes are one of the quieter ways a Division 8 bid goes wrong. On that same fire station specification, 233 line items make up the published hardware schedule, and 83 of them carry no finish designation at all, including every gasketing line, every threshold, every door sweep, and every silencer. A typical hardware set averages something like 5.8 line items, ranging from as few as two on a roof hatch to 14 or more on a card-access exterior door, and one set number on a door schedule is standing in for all of them.

Even where a finish is stated, the codes themselves aren't standardized in a way that removes ambiguity. US32D is the traditional designation for a particular finish, and 630 is the BHMA numeric code for that same finish, so the two can appear interchangeably in a spec without anyone flagging that they mean the same thing. Finish codes that appear without a corresponding key leave the estimator without a defined reference in the document. Some lines carry a different kind of ambiguity: on that same fire station set, ten of 34 live hardware sets hand at least one line item off to another trade marked simply "OT," and a tool that doesn't recognize that shorthand will leave the estimator carrying scope that was never theirs to price.

Every blank finish line is a price the estimator has to invent from scratch, and the invented number is invisible in the output, because the spreadsheet stays internally consistent whether the price is right or wrong. That invention matters more now than it used to. Aluminum mill shapes rose substantially and steel mill products rose about 17% over calendar 2025, the steepest climb since 2022, against a broader nonresidential input index that rose only slightly. A blank finish on a high-traffic exterior door, in that kind of market, is not a rounding error. It's a decision the estimator has to make deliberately, price at current market, and document, because the tool can flag the blank but it cannot fill it.

The quantity-per-opening convention that the trade hasn't settled

Even the basic unit of measure in a hardware schedule is contested. Should the quantity listed against a hardware set represent the quantity per opening, or the total quantity across every opening that uses that set? The trade has not settled this, and public disagreement between practitioners who work in it every day makes that plain.

One detailer raised the issue in 2025, noting that the estimating platform in use at the time submits total quantity across all openings rather than quantity per door, which he described as difficult for customers and architects to review, since they then have to do math themselves to figure out the correct quantity per door. A code authority at a major hardware manufacturer responded on the other side of the debate, stating that, absent some change, the hardware set should show quantity per opening. Meanwhile, the fire station specification referenced earlier states its own quantities are for each pair of doors or for each single door, which is yet a third framing. Three credible sources in the same trade, three different defaults.

Get this backwards on a 40-set project, and every downstream number in the bid is wrong by a multiple, not by a rounding amount, and nothing in the output will look broken because the math stays internally consistent either way. An AI tool applies whichever convention its own logic assumes. It has no way to flag that the convention itself is contested, and no way to ask the estimator which basis actually governs the project in front of it. Knowing the convention, checking which one the tool applied, and reconciling before the number goes into the bid is, again, work that belongs to the person, not the software.

Owner-standard specifications and the institutional jobs that require authorship, not extraction

Three published specifications, set side by side, show just how differently this trade's documents can be built. The fire station spec runs 40 headers, 34 live hardware sets, and 233 line items, with finishes stated on about 64% of the lines, doors already assigned to sets, and errors already baked into that structure. A university spec at a different institution runs 23 sets with no finishes anywhere, zero traditional codes and zero BHMA numerics, every hinge line reading only "3 Hinge As Required MK," six proximity reader lines whose model numbers are available only by phone call, and eight power supply lines that specify neither amperage nor voltage. Roughly 23% of that document's line items, 43 out of 186, carry nothing an estimator can price directly. A third institution's spec has no hardware sets at all: it's organized as 13 pages of component tables by category, and the estimator has to match usage to a row and repeat that process nine separate times for every single opening in the building.

Two of those three documents don't hand the estimator a hardware schedule to extract. They hand over an owner's standard, and the estimator has to build the schedule from raw component-level inputs. That's authorship, not extraction: it requires knowing the owner's standards, the building's security requirements, and the applicable codes well enough to assemble something usable from parts.

That dependency is structural: a door hardware specification can only be complete after building plans have sufficiently settled, because even a minor adjustment to an opening can change what hardware is actually appropriate for it. That's a design-phase dependency, and it's a human judgment loop from end to end, not a document extraction problem. An AI tool that treats every spec section as something to be extracted will produce output that's either incomplete or meaningless the moment it hits an owner-standard document like these. The estimator has to recognize which kind of document is in front of them before the tool becomes useful.

Visual and spatial judgment that current AI handles unreliably

Current AI models still don't interpret visual or spatial information reliably on their own, and industry reporting on this is fairly consistent: whatever usefulness these models show on visual tasks depends on scaffolding built around them, translating images into structured text, running vision pipelines, applying rule-based constraints, and keeping a human in the loop to catch what the pipeline gets wrong. As of 2025, these systems function closer to co-pilots than autonomous operators, and the phrase "autonomous takeoff" overstates what's actually shipping today.

In Division 8 specifically, that appears in a handful of recurring, expensive ways. Handing calls, meaning which direction a door swings, get read off plan symbols, and a misread handing on an exterior card-access door doesn't just throw off a count, it can mean the hardware ordered is physically incompatible with the opening. Revision clouds and addenda markups on a drawing set require a person to notice that a condition changed before anyone re-runs the extraction. Doors that appear on the floor plan but never appear on the schedule need a human decision: count it and flag the gap, or assume the absence was intentional and move on, and those two choices produce very different bids. Paired openings, borrowed lights, and sidelights change frame pricing meaningfully, and they're often not tagged distinctly enough on a raster-scanned drawing set for a tool to separate them cleanly.

The scaffolding these tools need in order to work reliably is, itself, a form of human judgment. The estimator setting up the review conditions correctly is already doing the real work, before the output even reaches their desk.

Access control logic and electrified hardware scope that requires cross-division knowledge

Electrified hardware is one of the easiest categories to under-carry on a fast-moving bid, and it's also one of the most consequential to get wrong. Card readers, electric strikes, magnetic locks, power transfers, and request-to-exit devices each require power coordination with Division 26 and access control coordination with Division 27 or 28, and most hardware schedules do not spell out that coordination.

Go back to the university spec with six proximity reader lines listed as available only by phone call. That means an estimator has to make an actual phone call, get the model number, cross-check it against the access control spec, and only then price it, none of which exists anywhere in the written document. The same spec's eight power supply lines, with neither amperage nor voltage specified, leave the estimator to work out what the hardware actually draws before they can even begin pricing the electrical rough-in coordination it requires.

An AI tool can flag that electrified hardware shows up somewhere in a set. It cannot know if the power supply belongs in Division 8 scope or Division 26 scope, if the reader is owner-furnished and contractor-installed, or if a line item that looks complete is actually missing the one detail that makes it priceable. That determination sits at the intersection of four divisions and a fair amount of institutional knowledge about how access control systems actually get specified and installed. No extraction tool, however good its accuracy on clean PDFs, was ever built to make that cross-division judgment on its own.