The automated count finds devices on some sheets and none on others

If automated counting returns sensible numbers on most sheets and nothing on a few, the model is not the variable — the sheets are. A drawing set is assembled from several consultants' files, produced on different days by different software, and often part-scanned. Detection is dependable on some of those substrates and impossible on others, so the count fails sheet by sheet rather than degrading smoothly across the job.

This is dangerous because the output looks credible. Totals arrive, found symbols are marked on the sheet, and nothing announces that level 3 came back empty. So the first job is not to fix anything. It is to find out which sheets are wrong and by how much, because the causes need three different responses and two of them are not code changes.

Build the per-sheet detection table before you touch a setting

One row per sheet, filled in for every sheet the condition was supposed to cover — including the ones that returned zero, which are the rows the tool will not volunteer. On an 80-sheet set this is about an hour of work, and it ends the argument about whether the tool is any good.

1. List every sheet in scope for the count, from the drawing register rather than from the tool's output. Sheets missing from the output are the finding, so a list built from the output cannot show them.
2. Record each sheet's origin: which consultant issued it, and whether it arrived as an issued PDF, a print-to-PDF or a scan. The transmittal usually tells you.
3. Try to select a room name or a note with the text cursor. Selectable text means vector geometry underneath; no selectable text means a raster image, and that single test predicts most of the result.
4. Record the detected count per sheet as the tool reports it.
5. Hand count one sample area per sheet — a single apartment, one 10 m by 10 m grid square, or one room type — and record both the hand count and the detected count for that same area.
6. Compute detected divided by hand-counted for the sample. Above about 0.97 the sheet is fine; 0.4 to 0.9 is partial detection; below 0.1 is a sheet the extractor never read at all. Those three bands are three different problems.
7. Sort the table by that ratio and look at what the bottom of the list has in common. It is almost always one consultant, one issue date, or one file origin.

Reading the table: pattern to cause

The pattern in the table names the cause faster than any inspection of the model does. Six patterns cover nearly everything.

One set, two substrates

The most common finding is that the set is not one thing. The architectural sheets arrive as clean vector exports, the services sheets come from a consultant who scans marked-up prints, and an addendum sheet was photographed on somebody's phone. What the extractor is reading changes completely between those cases, which is the subject of what a quantity extractor is actually reading when it opens your PDF — and the failure mode on scans is covered in extraction that works on issued sheets and fails on scans.

Symbol variants, overlap and legend drift

Where the substrate is fine and the sheet still comes back short, three drawing-side causes account for most of it.

• Consultant-specific variants. A duplex receptacle is drawn one way by one electrical engineer and another way by the next, and both are correct practice. A detector tuned on one job's symbols quietly under-reads the next job's, which is why an accuracy figure quoted without naming the drawing population means very little — see what takeoff accuracy claims are measuring.
• Overlap with linework. Symbols sitting on hatching, inside dimension strings, or under leader text lose the closed outline the detector matches on. The tell is that the miss rate rises with drawing density: sparse rooms count perfectly, plant rooms do not.
• Legend drift across disciplines. The same physical device appears in the electrical legend and the fire legend with different graphics, and only one of the two is in your symbol map. The fix is a per-job map maintained by a person, not a smarter model.
• Symbols that are text. Some consultants tag devices with a text label and no distinct glyph. That is a text-extraction problem wearing the costume of a symbol problem, and it wants a different tool — the ranking in which parts of a drawing set machines read reliably is the map to that.

The devices that were never on the plan

A sheet can be perfectly readable and still under-count, because the device is not drawn there. This is the group that survives every technical fix and lands in the estimate as a missing scope item.

• Riser diagrams and single-line schematics, which carry devices that appear on no floor plan at all.
• Keyed enlarged details, where a typical toilet or a typical patient room is drawn once and referenced from twenty locations.
• Equipment and device schedules, where a table row is the only record that six of something exist.
• Notes carrying multipliers — typical of 6, provide at each column, refer to detail — which are prose instructions to multiply, and no counter reads them as such.

A detector that finds nothing on a sheet is announcing a problem. A detector that finds 80 percent of a sheet is the expensive case, because 80 percent looks like a number you can price.

What to do with a sheet that will not count

1. Split the set rather than averaging it. Countable sheets go through automation; the rest are marked for assisted counting, and the split is recorded on the estimate. The rule for drawing that line is in assisted counting versus full automatic takeoff.
2. Ask for the vector files before doing anything clever. On a live bid this is a same-day request to the design team and it removes the problem entirely on the sheets it succeeds for.
3. Record a qualification for every sheet counted by hand or excluded, in the words the bid form will accept. An unrecorded assumption is what turns a takeoff gap into an argument after award.
4. Reconcile the count against a second source — the device schedule, the panel schedule, the spec's product list — before pricing. Two independent sources agreeing beats one source at higher confidence.
5. Carry the sheet-level result through to the export, so the quantity that lands on a cost code says how it was produced. Mapping takeoff quantities onto cost codes for export is where that provenance either survives or is lost.

One thing worth saying plainly: dedicated takeoff engines compete hard on symbol recognition, and several are good at it. We do not claim parity with a product whose whole roadmap is counting symbols. What is usually missing around those engines is everything else — the sheet inventory proving which sheets were covered, the exception report that flags a zero-detection sheet before it gets priced, and the mapping into the estimating and accounting systems.

The consequences run downstream in two directions. A count that is short on two sheets becomes a budget line nobody funded, which shows up later as a job budget that does not agree with the estimate that won it. And an unrecorded per-sheet difference is one of the quieter reasons two estimators return different quantities from one set, because each has silently made their own decision about the sheets that would not count.

The durable fix is a scheduled check, not a platform: inventory the sheets, run the count, flag any sheet below your ratio threshold, and email the estimator before work starts. That is the same exception-report shape that stops an expired insurance certificate being found after the sub is on site, and the kind of narrow build we scope under internal tools and ops. The rest of this silo sits under preconstruction, takeoff and estimating, within our construction and contracting work.

• takeoff
• symbol recognition
• drawing quality
• estimating