Why a Single Accuracy Number Is the Wrong Goal
We recently set out to answer a direct question: how do we make AI-driven quantity takeoff extremely accurate? We treated it like a real research problem — surveying published work on vision-model counting, retrieval-augmented matching, and construction-document AI, then testing candidate fixes against real drawings and real, already-priced tender documents. The honest answer we landed on isn't the one we went looking for, and it's more useful than the one we wanted.
There is no single number
Every credible source we looked at — published research and the practice of other construction-AI companies alike — converges on the same point: nobody ships an autonomous accuracy percentage. The serious products ship confidence-scored review. That's not a marketing hedge; it reflects something real about the problem. A drawing that's a clean, vector-drawn CAD export behaves completely differently from a photocopied, scanned sheet. A bill of quantities with clear, unique line-item descriptions behaves completely differently from one where three different items are all labeled identically and only distinguishable by which section of the document they sit in — which, it turns out, happens constantly in real tender documents.
The hard part of takeoff automation isn't getting an AI to produce a number — it's producing a number a quantity surveyor can check in seconds.
What we actually tested
Rather than tune prompts and hope, we picked two concrete, literature-backed hypotheses and tested each one against real project data with a real answer key.
The first hypothesis: since construction tender drawings in Hong Kong and Macau are almost always vector-drawn CAD exports rather than scans, a repeated symbol on the page — a manhole, a valve — should in principle be recoverable as an exact count from the PDF's own vector geometry, rather than asked of a vision model as a guess. We built a prototype and confirmed the geometry is genuinely there — tens of thousands of real vector elements on a single sheet. But naively grouping that geometry into "symbols" failed in two opposite, instructive ways: group by proximity, and continuous walls and hatching chain almost the entire page into one giant blob; don't group at all, and you're left counting fragments of text and hatch patterns instead of whole symbols. Getting this right needs a smarter approach — matching against a template taken from the drawing's own legend, the way established takeoff tools in this space actually do it — which we've scoped but not yet built.
The second hypothesis: the reason a bill of quantities has multiple line items with identical wording is that they belong to different sections — different scopes of work — and a matching system that only looks at the item's own text, without that surrounding context, can't reliably tell them apart. We tested this directly on a real bill with a confirmed case of exactly this ambiguity — the same generic pipe description used three times for three different scopes of work, at three different quantities. Matching on the text alone got it right essentially never. Giving the matching system the same section context a human reviewer would naturally read cut that failure rate by roughly two-thirds. That fix is now live.
What this means in practice
We're not going to claim a headline accuracy percentage, because the honest evidence doesn't support one — it varies by drawing type, by how the tender document is structured, and by how much of the drawing is genuinely machine-readable geometry versus a scan. What we will say plainly: some parts of this problem are already solvable close to exactly, some are meaningfully improvable with the right architecture, and some genuinely require a person's judgement — recognizing a provisional sum, or an item governed by a written specification rather than anything drawable. Our job is building a system that tells you, honestly, which of those three buckets a given number falls into.
- Quantities are derived from evidence you can click through to on the actual drawing — never presented as a total with no source.
- Every figure carries an honest confidence signal, and disagreement between independent checks is surfaced to you, not silently averaged away.
- The system gets measurably better every time a reviewer corrects it — that correction is never thrown away.
That's a less dramatic promise than "extremely accurate AI." It's also one we can actually stand behind, because we tested it the same way we're asking you to trust it: against the real answer, not a convenient one.
Related articles
Phase 28 — Coverage Ladder 5/21 Held; Count CP Still 3/63, Not 80/80
Phase 28 is the execute-close of the same qty_3d coverage + S33 count-CP families: inner COVERAGE_LADDER_PASS, five training_data graphs kept (S33, N23, Kwai On, S27, N22), fabricatedGeometry false. Extra S33 plan pages 12/14/16/19 raised world elements to 41 on the same slug — not a sixth coverage credit. Count CP stayed evaluated at 3/63 on S33 BQ sheet E (detection 5/63; N=63 held; reasonCode null). Frozen loop RSI_PLATEAU. Live 圖則.pdf is a residual, not a coverage credit. Not Peak P&D 3D 80/80. Not corpus 80–90%.
14 min readPhase 27 — Coverage Ladder 5/21; Count CP 3/63, Still Not 80/80
Phase 27 is the execute-close of the coverage-ladder 3→5 + S33 count-CP pack: COVERAGE_LADDER_PASS, five training_data graphs (S33, N23, and Kwai On preserved; S27 and N22 new), fabricatedGeometry false. Count CP is evaluated at 3/63 on S33 BQ sheet E — unblocked, not IDENTITY_ONLY_NO_GT, and not an accuracy win. S27 geometric takeoff was empty (NO_PLAN_POLYLINES); fittings-only still qualified. Live 圖則.pdf is a residual, not a coverage credit. Not Peak P&D 3D 80/80. Not corpus 80–90%.
12 min read