Blueprint Risk Engine

Pre-bid review pass

The scope nobody priced is still sitting in the documents. Find it before the bid goes in.

A pre-bid review pass for electronic physical security work. It reads the bid documents and reports the places where two of them do not agree, and the places where nobody is assigned the work. Every line names the rule that caught it, the document, and the page.

See it run Read what it cannot do
  • No form, no login, no email. The viewer is the running application on fixture data. Open it and click a line.
  • Every limit, in one place. What it misses, what it does not read, and why there is no accuracy figure on this site.
Demonstration fixture Hand-authored test model. Not a real building, not a real project, not a customer.
Floor plan of the demonstration fixture: a twelve room school wing with fourteen openings, three cameras and two wiring closets. Opening D108 is highlighted. Main Lobby Corridor Classroom Classroom Classroom Classroom Admin Multipurpose Storage IDF 1 IDF 2 Vestibule D108
controlled opening uncontrolled D108, flagged below
Rule
AC-010
Target
Opening D108
Authority
NFPA 101 7.2.1.5
Cited
sheet A-601, door schedule row 8

The full finding, with the extracted facts and the rule trace, is further down this page.

Standing notice: not yet benchmarked

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.

01One line of output

This is the whole product: one line, and everything behind it

Not a dashboard, and not a screenshot of one. Below is a single line of engine output, rendered as text, with every part of it labelled. The reason for showing it first is that it is the only thing worth judging. An estimator reading a public forum thread about these tools put the buying criterion better than any vendor has: It's been important to me for the agents to demonstrate provenance and have a clear audit process. How and why and what and where they acted. That is the entire specification for the block below.

This came out of the demonstration fixture, not a real project. Opening D108 is one of the twelve controlled openings, out of fourteen in total, in a hand-authored test model that ships with the repository, built to exercise the rules. There is no such building and no such door schedule. Every value below, including the sheet reference and the schedule row, is read out of that fixture rather than composed for this page, and the rule text, the authority and the trace are what the engine actually emitted when run against it. It is here to show the shape and the provenance of a finding. It is not evidence that the finding is correct, and no accuracy claim is made anywhere on this page.

AC-010 LOCKING DEVICE PASS 1 ac_k12_base 0.1.0

Egress opening with existing panic hardware resolves to electric latch retraction

Rule
AC-010, from the pack ac_k12_base at version 0.1.0. The id is permanent and is never renumbered. Two runs a month apart are comparable because the rule that fired is named in both. The full text of this rule, and of the other eighteen, is published at /rules/.
Target
Opening D108. Read from the door schedule at 0.93 extraction confidence.
  • frame material HOLLOW_METAL
  • stile depth not stated
  • egress path yes
  • existing hardware PANIC_DEVICE, CLOSER
These are the extracted facts the rule tested, printed so you can check them against the schedule yourself. The 0.93 is a confidence on this one reading. It is not an accuracy figure and there is no accuracy figure. "Not stated" is recorded as its own value rather than defaulted, because a missing dimension and a small dimension are different problems.
Rationale
Where egress depends on a panic device, the latch must remain free at all times, so the locking function has to act on the panic device rather than on the frame. An electric strike releases the frame keeper and leaves the panic latch under electrical control, which is why a strike is not an acceptable substitute on this opening. This text is stored in the rule and printed in the deliverable. It is written for the engineer whose design it just contradicted, because sometimes that is who reads it. It is not generated per finding, so it cannot drift between one run and the next.
Authority
NFPA 101 Life Safety Code 7.2.1.5 Door Leaf Operation; CBC 1010.2 Door Operations. Code interpretation varies by jurisdiction, so every rule cites the section it leans on and stays overridable on a project. If your authority having jurisdiction reads it differently, you now know exactly which sentence to argue with.
Cited
sheet A-601, door schedule row 8 The single row this opening and every fact above was read from.
Sheet and row, not "the drawings". You can open A-601, find row 8, and either confirm the reading or throw the line out. A line without this is treated as a defect in the software rather than as a formatting preference. Where a finding comes from a sentence rather than a schedule row, that sentence is carried verbatim instead of paraphrased.
Effect
Electric latch retraction, quantified per leaf, and the derived attribute requires_sequenced_supply set for later rules to read. Every quantity here is computed by ordinary code from the written rule. No model computes a count, picks a part number, produces a score, or rules on compliance. That boundary is enforced by a test rather than by intention.
Rule trace for this opening
  • Applied: AC-010, egress opening carrying existing panic hardware. Won the conflict group locking_device.
  • Suppressed: AC-011, standard controlled opening on hollow metal resolves to a Grade 1 strike. Lost the same conflict group to AC-010.
  • Suppressed: AC-012, opening adjacent to instruction or administration resolves to a quiet strike. Lost the same conflict group to AC-010.

The suppressed rules are the part most people do not expect. They are not an error log. They are the record of which rule won on this opening, so a reviewer who expected a Grade 1 strike can read the rule that displaced it instead of guessing why the software went quiet. On this opening the answer is legible in one line: free egress outranks acoustic comfort, and the rule that says so cites the code section it is standing on.

A pre-bid RFI is free. The same question asked after award is a negotiation.

02What it is

It reads the documents against each other and reports where they do not line up

Assume you have never heard of this. Here is the mechanism, in the order it happens.

In. A bid package for electronic physical security work. Specification sections, drawing schedules, addenda. Out. A ranked list of the things in that package that will generate an RFI, a change order, or a field failure, each one carrying the rule that caught it, the document and page it came from, the rationale, the authority, and a recommended action you can take before the bid closes.

It is not reading for comprehension. It is reading for disagreement. A document is segmented by CSI MasterFormat section, every located sentence keeps its document, page and coordinates, and then ordinary code compares what one document says against what another does not. The finding is always a relationship between two named places, which is why it can be printed with citations on both sides of it.

The seam it is built for

Door hardware is specified in Division 08 by the architect. Access control is specified in Division 28. Electric strikes, electrified locksets and latch retraction devices sit exactly on that line, and each package routinely assumes the other side covers it. That seam is the highest-value scope gap in this domain, and it is the thing this engine was built around.

For any one opening, on its locking device, its power and its rough-in, there are five states, and four of them cost money:

  • Both divisions carry it. A duplicate buy, or an argument at submittal.
  • Both carry it and require different things. An argument on the day the opening is hung, with two specifications that both say they are right.
  • Each division hands it to the other. The seam failure caught in the act. A sentence reads "by others, by Division 28", the security contractor reads it as somebody else's scope, the hardware supplier reads the same sentence and agrees it is Division 28, and neither party prices the rough-in.
  • Neither division specifies it. Nobody priced it, so after award somebody eats it.
  • The documents do not settle it. Reported as a flag that means look here, deliberately kept as a separate finding from "nobody is assigned", because collapsing the two is what makes an estimator stop believing a register.

The output is not an estimate and it is not a takeoff. It is the list of questions to ask while asking is still free, which is the raw material for your qualifications and assumptions, your inclusions and exclusions, and the alternate adds you decide to carry.

What runs today, stated before you ask

Verified against the code rather than taken from a module name.

runs today Document ingest. Reads a package of PDFs, segments by CSI section, and locates the markers where margin disappears: NIC, by others, furnished by, installed by, OFCI, CFCI. It has a measured recall gap, recorded rather than assumed.
runs today The deterministic engine. Rule loading and evaluation with conflict groups, six validators that print their computed values, the ranked register, the bill of materials, and the report. Runs replay byte for byte from the same inputs.
half fed The Division 08 and Division 28 seam analysis. Written and tested. It 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 it runs at half its designed evidence today.
not built Reading the plan sheets. Specified and not built. Nothing in the system draws or reads a drawing. Spatial models are hand authored today.
not built The benchmark. The only thing that would let anyone claim this engine is accurate. It has no dataset.

The longer version of all of this, written for people who read bid packages for a living and have no reason to care how software is built, is at /how-it-works/, and the same system drawn as five diagrams is at /diagrams/.

03The objections

The objections, answered

These are the three things estimators actually say about tools in this category. They are quoted rather than paraphrased, because a paraphrase is how a vendor makes an objection easier to answer than it was.

Said out loud, repeatedly
"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?"

Correct about the thing it is aimed at. It does not land here, for one specific reason.

If a tool hands you 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.

This is not takeoff. It does not produce a quantity you contract against, and there is no number to check against your own number. What it produces is the list of questions to ask before the bid: a place in the documents where two sentences do not line up, naming both documents, both pages, and both sentences. That feeds your qualifications and assumptions, and it feeds bid leveling when you are reading three subcontractor proposals that each carry a different half of the same seam.

The review still costs you time, and it is your time. One open-the-page-and-read-it per flagged line, paid by the estimator, in the week they have the least of it. There is no version of this where the flag arrives pre-verified. Some of those lines will be nothing, you will close them, and that minute is gone. How many lines come back on a real package is unmeasured, so the total cost is unmeasured too, and quoting the fixture's register length as an expected workload would be dishonest.

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 long form is at /limitations/.

Said out loud, repeatedly
"The AI can't tell you what's not there. And no one is going to let you change order them because the AI didn't pick this up due to how it was labeled."

True of a model reading one document. That is not how absence is found here.

A model asked "is anything missing from this specification" has nothing to compare against and will produce a plausible answer either way. So it is never asked that. Absence is found by cross-referencing what one document says against what another does not, and the finding names both documents.

For one opening, code assembles what the Division 08 sections say about its locking device, its power and its rough-in, and separately what the Division 28 sections say about the same three. Each entry carries the document, the section and the page it came from. Then code compares the two sets. Nothing asks a model whether they agree. A "neither division specifies this" finding cites the Division 08 section that was read and the Division 28 section that was read, which is a claim you can put in front of the person who wrote one of them.

What it cannot do, said plainly: it cannot find what no document mentions at all. If the package contains neither a Division 08 nor a Division 28 section covering the work, the engine emits nothing rather than reporting that neither division covers it, because an absence claim with nothing on both sides of it carries no provenance and is not evidence. There is also a recorded case of it missing owner-furnished scope written in ordinary English with none of the marker phrases in it. That gap is held open on purpose and guarded by a test that fails if anyone closes it quietly.

On the second half of the objection: nobody should expect a tool to win a change order argument, and this one is not built to. It is built to move the question to before the bid, where it is an RFI and it is free. The long form is at /limitations/.

The question everyone asks second
"What happens to my drawings?"

Pages of your package are sent to model vendors to be read, you are told which ones before it happens, and none of it is committed anywhere.

Reading a document means transmitting it. Before the first outbound call for a package, the vendors, the model identifiers and the file list are shown and consent is recorded, and consent is asked again when the file set changes. There is deliberately no flag to suppress that prompt, because suppressing it is the first thing anyone scripts. Source bid documents, drawings and client material are never committed to the repository, and each package's own model cache lives outside it. The full statement, including what is retained and for how long, is at /security/.

04Not this

What it does not do

Short, because the list is short and none of it is hedged.

It is not benchmarked.

No precision figure, no recall figure, no accuracy claim, and no dataset that would produce one. Whether the things it flags are the things that actually become change orders is unmeasured.

It does not do takeoff and it does not price work.

No quantity you contract against, no unit costs, no labor rates, no totals, nothing a reader could mistake for an offer.

It does not read plan sheets.

Extraction from drawings is specified and not built. What runs today works from documents.

An empty result is not a clearance.

A short register means the rules that exist did not fire on the documents that were read. It does not mean the package is clean.

It does not replace an estimator.

It does not decide what to bid, what to carry, or what to walk away from. It performs the one cross-check between documents that gets skipped when the deadline compresses.

Expect both false positives and false negatives. The complete list, including the sources of each and the one detection gap that is recorded and deliberately left open, is at /limitations/. It is longer than this page and it is the one a skeptic should read.

05The rules

The rules are published, so you can judge the checks without trusting the vendor

There is no way to verify an accuracy claim from the outside, and no reason you should try. What you can verify from the outside is the mechanism. Every rule the engine runs is published in full: the rule id, what it checks, the code section or manufacturer document it leans on, and the rationale that prints in the deliverable, reproduced character for character from the pack file.

Nineteen rules across four packs, and six whole-system validators that return their computed values rather than a boolean. Read them the way you would read another estimator's checklist. Some will be things you already do, some will be things you do not, and a few you will disagree with. All three are useful answers, and none of them requires taking anyone's word for anything.

Every rule ships with a test proving it fires and a near-miss test proving it does not, where the near miss differs in exactly the one attribute the rule turns on. A rule that fires too broadly is worse than an absent rule, because it trains you to skip the section, and a register nobody reads is worth less than no register since it also consumed the week before the bid.

/rules/ All nineteen rules and six validators Rule id, what it checks, the authority, and the rationale, in the words the pack file uses. Including the blocks that are allocated and still empty. /viewer/ The register and plan viewer The running application on fixture data, with the rule trace on click. No form, no login, no email. Read the standing notice before reading anything into it.
06Who built this

Who built this

My name is Muhammad Sizar. I built Blueprint Risk Engine. There is one person on this project and it is me.

That is worth stating plainly for two reasons. The first is that you are entitled to know who is asking to read your bid package, and a company name with no person behind it is not an answer to that question. The second is that it tells you what you are buying and what you are not. There is no sales team to get past and no support queue to escalate through. If a rule fires wrongly on your package, the person who wrote that rule is the person who reads your message.

It also tells you the honest limits. One person means a narrow domain, a small number of rules, and a benchmark that does not exist yet, all of which is stated on this site rather than discovered later. Everything I can defend today is on this page, and everything I cannot is at /limitations/.

There is no contact form on this site yet, and no address published here. That is deliberate rather than an oversight: the tool is not ready to be run against a stranger's bid package on request, so asking for one would waste your time. When it is, this line will say so.

See it run Read the rules
  • No form, no login, no email. The running application, on fixture data.
  • All nineteen, published. Judge the checks without taking my word for any of them.