It does not do takeoff.
It does not count devices off a drawing, because it does not read drawings. It does not produce your quantities. If you are looking for something that replaces the count, this is not it and will not become it.
Blueprint Risk Engine / limitations
Expect both false positives and false negatives. This page is the list of what the engine gets wrong, what it has never read, and what its numbers are not.
There is no accuracy figure on this page because there is no accuracy figure. What is here instead is the exact shape of the gap, the measurement that would close it, and the method intended to produce that measurement.
This engine has never been measured against real outcomes. There is no benchmark dataset, no precision figure, no recall figure, and no accuracy claim anywhere on this site. Nothing on this page, and nothing in any output it describes, may be read as evidence that the engine produces correct output. It may be wrong, and how often it is wrong is currently unknown and unmeasured.
The measurement that would matter is precision and recall of pre-bid flags against the change orders a project actually issued. That measurement does not exist yet. Until it does, read this page as a description of a design, not as a claim about results.
Required by project amendment A-003. This notice is permanent and cannot be dismissed.
Expect both false positives and false negatives.
That sentence is the honest summary of what this tool is, and it is at the top rather than in a footnote because it is the thing that decides whether the tool is any use to you.
A false positive is a flag on a line where nothing is actually wrong. The rule fired, the citation is real, the sentence it quoted says what it says, and there is still no problem. You open the page, read the line, and close it. That costs you a minute and it costs the tool credibility, which is the more expensive of the two.
A false negative is the gap the engine walked straight past. It is worse and it is quieter. A short register looks like a clean package, and the two are not the same thing. There is a known example already recorded rather than hidden: the scope detector matches marker phrases such as NIC, by others, furnished by, installed by, OFCI and CFCI, and on the first real project manual it was run against it missed a page that assigned owner-furnished scope in ordinary English with none of those words in it. That page was the residual catch-all, which is the most expensive form of the thing it was built to catch.
That gap was left open on purpose. Widening the pattern to catch phrases like "responsible for" would fire on a large fraction of any specification's body text, and a rule that fires too broadly is worse than an absent rule because it trains you to ignore the output. The gap is held open, recorded, and guarded by a test that fails if anyone closes it quietly.
This framing is borrowed openly from how static analysis tools document themselves. A security scanner has the same structural problem: it fires on code that is fine and stays silent on code that is not, and the only usable posture is to say so at the top and let the reader decide what the review is worth. Nothing about construction documents makes that problem easier.
There is one measurement that would settle whether this engine is worth anything, and it does not exist.
That measurement is precision and recall of pre-bid flags against the change orders a project actually issued, plus lead time: how far ahead of the event the flag was raised. Precision is what fraction of the flags mattered. Recall is what fraction of the things that mattered got flagged. Lead time is whether knowing would have helped.
Nothing else substitutes for it. Not a passing test suite, not a deterministic replay, not a well-cited register. Those make the output auditable. They say nothing about whether the things it flags are the things that become change orders.
Published here before there are results, because a methodology published after the numbers is a methodology chosen to fit them.
No package satisfying all three sourcing criteria has been found in public sources. The failure has a clean shape: both halves exist, and not in the same project. The districts that publish full bid documents online have tended to be running Division 27 work. The districts that ran Division 28 projects hold their bid documents in a business office for in-person review.
So the honest status is not "the benchmark is in progress." It is that the dataset does not exist yet, the scoring code named in the project's own contract document has not been written, and the results file does not exist. When it does, it goes on this site with the misses in it.
A methodology published before the results is a commitment. Published after, it is a defense.
Several things a reader would reasonably assume are in the box are not. This table is taken from the project's own architecture notes, which were checked against the code on 9 August 2026 rather than read off module names.
| Capability | Status | What that means in practice |
|---|---|---|
| Drawing sheets | not built | Plan extraction does not exist. There is no rasterization, no scale determination from a scale bar or title block, no tiled extraction and no review payload. The module named for it in the project contract is not in the repository. Every spatial model the engine has ever run on was authored by hand. |
| Structured claim extraction | built, wired to no command | The one sanctioned model call for reading specification text is written and tested. No command reaches it, and the ingest path never populates the claims field. It is code that has never run on a real package. |
| Two-vendor agreement | built, wired to no command | The mechanism that reads the same content with two vendors and emits no value where they disagree is written and tested. Nothing outside its own test calls it, and the rule id that would carry a disagreement into the register is defined by no rule pack. |
| Addendum reconciliation | not built | There is no addendum parser and no diff against the base documents. The delta record is modelled and validated and nothing produces one. An addendum in the package is read as one more document, not as a modification to the others. |
| Contradiction detection | not built | No rule of that family exists in any pack, and no module compares claims across documents. Quantity mismatch, product mismatch and conflicting responsibility assignment between two documents are not detected today. |
| Schedule to specification joins | allocated, ships no rule | The rule block for "a device appears in a drawing schedule and every specification reference assigns it elsewhere, or nowhere" is reserved and empty. The schedule-row record is modelled; nothing populates it; no pack defines those ids. This was described in the project contract as the highest-value check in its phase, and it does not run. |
| Scanned documents | refused | A PDF with no text layer is refused by name rather than silently ingested as empty. Route it through OCR and re-run. The refusal reports every unreadable file at once, so it costs one round trip and not one per file. |
| A package's own equipment schedule | refused on purpose | Ingestion refuses any path under a schedule folder. A published equipment schedule is benchmark truth for that package, and a system that reads the answer key cannot be scored against it. There is no flag to override this; moving the file is the override, and it leaves a trace. |
| PDF text and CSI segmentation | built | Reads a package of text-layer PDFs, segments by CSI MasterFormat section numbering, and carries document, page and coordinate provenance on every element. No model call anywhere in it. |
| Scope marker detection | built, with a measured recall gap | Regex over marker phrases, not a model. The gap described at the top of this page is this component. It has been measured against one real project manual and the result was recorded rather than assumed. |
| Division 08 to 28 seam analysis | built, partially fed | Reads two kinds of evidence: located scope statements and structured claims. Only the first is populated on a package the tool can currently produce, so half of the seam analysis has nothing to read. |
That last row is the one worth sitting with. The Division 08 to Division 28 boundary is the highest-value scope gap in this domain and it is what the engine is aimed at, and today it runs on one of its two evidence sources.
Every item in the register carries an exposure band. Here is exactly what that band is.
It is an uncalibrated structural placeholder. Every band in every rule pack the project ships is marked as not calibrated, and that is not a hedge, it is a field in the data. None of them is derived from cost history. They exist so the ranking has a second key to sort on after severity, and that is the entire job they do.
Every rendering marks it. The uncalibrated marking is required on each place a band is printed, so a placeholder can never appear in the same typeface as a derived figure. A placeholder set in the same type as a real number is a confident output, and a confident output where the honest answer is a flag is the specific failure this project treats as unacceptable.
It is an order-of-magnitude planning figure. It is not a quotation, not an offer, not a price, and not derived from a takeoff. It is there to help you decide which three of thirty flags to chase this afternoon.
The deliverable carries no pricing at all. No unit costs, no labor rates, no extended totals. The bill of materials carries quantities and device identities and nothing with a currency on it, and that is enforced in the software rather than left to whoever writes the report.
No exposure figure appears anywhere on this website, for the same reason. Publishing a placeholder band next to a product claim would be using a number as evidence when the number is admitted to be a placeholder.
Not "has not got to yet." These are things the design refuses, and they will still be refused when the rest of it is finished.
It does not count devices off a drawing, because it does not read drawings. It does not produce your quantities. If you are looking for something that replaces the count, this is not it and will not become it.
The bill of materials it emits is supporting evidence for the register, not a purchase list. Every line names the rule that put it there so you can check it. Contracting against a number this tool produced, without checking it, is using it for something it was not built for.
It does not decide what to bid, what to carry, or what to walk away from. It performs one specific review that gets skipped under deadline, which is the cross-check between documents, and it hands you a list of questions. A person answers them.
A short register means the rules that exist did not fire on the documents that were read. Given the table above, that covers a lot of ground the engine never went near. Read a short register as "these rules found nothing", never as "this package is clean."
The system is built to make that distinction where it can. A derived rule run against a package with no documents loaded raises an error rather than reporting zero findings, because zero findings and a clean package look identical in a report and are not the same thing. A validator run with no spatial model reports nothing rather than reporting a pass, because a validator that passed having examined nothing is indistinguishable from one that looked.
Where two independent readers disagree on a field, no value is emitted. Not a value with a warning next to it. There is deliberately no tiebreak, because a tiebreak reduces the flag count without reducing the ambiguity, and a shorter list reads as good news about the documents when it is only a change in how the software behaves.
If you're going to have to go through and do the takeoff to verify what the AI spat out, what's even the point of using AI?
The objection is correct about the thing it is aimed at. If a tool produces a count and you have to redo the count to trust it, you did the work twice and paid for software. Nobody should buy that.
It does not land on this tool for one reason, and the reason is a fact about what the output is, not an argument about model quality.
The output is not a quantity you check against your own quantity. It is a list of places in the documents where two sentences do not line up, each one naming the document, the page and the sentence. There is no number to verify because the engine is forbidden from producing one: the model is allowed to locate a sentence, transcribe it verbatim, classify it and match it, and it is never allowed to compute a count, pick a part number, produce a score, or rule on compliance. Every number in the output is computed by ordinary code from written rules.
What you do with a flag is not a takeoff. You open the cited page, read the sentence, and decide one of three things: it is a real gap and it becomes a pre-bid RFI, it is a real gap you will not get answered and it becomes a line on your qualifications and assumptions, or it is nothing and you close it. That last case is the false positive, and it is the cost.
The cost is one open-the-page-and-read-it per flagged line, and it is paid by the estimator, in the week they have the least time. There is no version of this where the flag arrives pre-verified.
How much time that is depends entirely on how many lines come back, and that is the number nobody has. The only run anyone can point to is the repository's own hand-authored twelve-opening fixture, which produces a seven-line register with three items carrying an entity flagged for review. That is a synthetic fixture built to exercise the rules, not a real bid package, and quoting it as an expected workload would be dishonest. On a real package, the register length is unmeasured, which means the review cost is unmeasured too.
So the trade is not "software instead of review." It is: a fixed reading cost per flag, against the cross-check between documents that gets skipped first when the deadline compresses, because it is the slowest part and it usually finds nothing. If your process already runs that cross-check every time and finishes it, this tool has less to offer you than it does to someone whose process does not.
A pre-bid RFI is free. The same question asked after award is a negotiation.
The honest limit on this answer: it assumes the flags are worth reading, and that is exactly what has not been measured. If precision turns out to be poor, the reading cost per useful finding goes up and the objection starts landing. That number is the benchmark, and the benchmark does not exist.
The AI can't tell you what's not there.
True of a model reading one document. A model asked "is anything missing from this specification" has nothing to compare it against and will produce a plausible answer either way.
That is not how absence is found here. It is found by comparing two documents in code and naming both. The mechanism, rather than the conclusion:
The limit on this, stated with the mechanism rather than after it: this comparison reads two kinds of evidence, located scope statements and structured claims, and only the first is populated on any package the tool can currently produce. So the seam analysis runs today at half its designed evidence. That is the same row as in the table above, and it is the single largest gap between what this section describes and what runs.