Building Verification-First AI Takeoff: A Development Update

Teraquant's core platform — ingestion, drawing OCR, claim review, SOR matching, and export — is live in production. Tender Q&A and cross-drawing consistency checks also ship as separate project-level pages (not one-click actions from the drawing shell); they typically need prior document vectorization or entity-graph setup before they are useful. A platform being feature-complete and a platform being genuinely *accurate* are two different bars, and accuracy is the one that actually matters to a QS team relying on this for a tender submission. This update is about that second bar: what we tested, what we found, and what we fixed.

Testing against real answer keys, not synthetic benchmarks

Instead of grading ourselves on made-up test cases, we ran the full pipeline against real tender projects that already have a completed, human-priced BQ/SOR — the actual answer key. We rendered real drawing pages, let the AI extract quantities the same way it would for a live user, matched them against the SOR, and compared the computed totals to what a professional QS had already priced. That comparison is unforgiving in a useful way: it surfaces exactly where the pipeline is strong and where it isn't.

What we found and fixed

This process caught several real accuracy issues that were quietly capping performance in production — the kind of bugs that don't show up until you test against a real answer key. We fixed how AI-suggested SOR matches are ranked, made sure unit mismatches are flagged clearly before a human confirms a match, and repaired a spreadsheet-parsing bug that was silently garbling data for one particular BQ format. We also made sure every human correction is now preserved alongside the AI's original suggestion, which lets us actually track accuracy over time instead of guessing.

Choosing the right AI model for the job

We benchmarked two different AI providers for SOR text matching on real plumbing & drainage data. One was noticeably more accurate on harder cases; the other was dramatically faster and cheaper. Since a takeoff platform needs to run thousands of matches per project, we made the practical call: the faster, cheaper model stays the default for everyday matching, with the more accurate (but slower) option available whenever accuracy matters more than speed.

The hardest problem: real BQs are messier than they look

Once localization and counting were solid, a deeper problem surfaced: real bills of quantities often list several line items with an *identical* generic description — say, "150mm diameter pipe" appearing three times, once for removal works, once for above-ground new work, once for a gully connection — distinguishable only by which section of the BQ they sit under. Matching on description text alone genuinely can't tell these apart. We're now teaching the matching pipeline to use that section context, the same way a human QS reads it, and it's already showing a real improvement in match correctness.

Why we test this way

None of this would surface from a demo on clean, hand-picked data. Teraquant's whole premise is that AI proposes and a human verifies — and we hold our own testing to the same standard, checking every claim against a real answer, not a plausible-looking one. That's slower than shipping a confident-sounding demo. It's also the only way to build something a QS team can actually trust.

What's next

• Roll the section-context matching improvement out beyond this test into the general pipeline.
• Start building a growing dataset of real human corrections, logged automatically, to inform future model improvements.
• Keep testing every accuracy claim against real, priced tender projects — not synthetic benchmarks.