Blueprint Risk Engine

A pre-bid risk engine for electronic physical security construction. It reads a public works bid package and emits a ranked, cited list of the things that will generate an RFI, a change order, or a field failure.

Every line carries the rule that caught it and the page it came from. Nothing on this page is a benchmark result, because there is not one yet. What is unproven is listed at the bottom in the same detail as what is built.

01The product

A register of the things that become change orders, before the bid closes

Input. A public works bid package. Drawings, specification sections, addenda, equipment schedules.

Output. A Bid Risk Register: a ranked list of the things in this package that will generate an RFI, a change order, or a field failure. Each item carries the rule that caught it, the document citation, the plain English rationale, the code or manufacturer authority behind it, and a recommended pre-bid action. A bill of materials is produced as supporting evidence, not as the headline.

The claim is predictive and auditable, not generative. This is not an attempt to automate a design engineer. It automates the review a senior estimator does not have time to perform in the week before a bid is due.

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

02One finding

What a single line of output actually looks like

Demonstration. The item below came out of a real engine run, against the repository's golden fixture: an invented package for a fictional district. The district, the manual, the pages and the sentence are all fabricated for testing. It is here to show the shape and the provenance of a finding. It is not evidence that the engine is right, and no accuracy claim is being made anywhere on this page.

SB-002 MEDIUM SCOPE GAP scope_boundary 0.1.0

Target: BY_OTHERS scope statement on page 8 of the project manual

Finding: A scope marker on page 8 of the project manual moves work to another party and names Division 28 as that party, which is this contractor's own scope.
Evidence: project manual, section 28 13 00, page 8 "Rough-in at the exterior openings is by others, by Division 28."
Authority: CSI MasterFormat Division 08 and Division 28 boundary; AIA A201 General Conditions 3.2 on the contractor's review of the contract documents.
Rationale: A marker that names a division is a different finding from one that names nobody, and it points at us. "By others" reads as somebody else's problem right up until the sentence continues "by Division 28", at which point the work is electronic safety and security, and the estimator reading the Division 8 section is the person who has to carry it. The common failure is symmetrical and expensive: the door hardware supplier reads the same sentence, agrees the work is Division 28, and neither party prices the rough-in.
Pre-bid action: Confirm this work is carried in the base bid rather than assumed to sit with the Division 8 hardware supplier, and price it if it is not.
Confidence: 0.87 extraction confidence, above the review threshold, so this item is not flagged for manual confirmation.

Rule trace for this target

Applied: SB-002, scope marker assigns the work to Division 28. Won the conflict group scope_statement_disposition.
Suppressed: SB-001, scope marker moves work to another party without naming the work. Lost the same conflict group, because SB-002 names the party and reporting both against one sentence would put the same money in the register twice.

A suppressed rule is not an error. It is the record of which rule won on a given target, so a reviewer who expected a different outcome can read the rule that displaced it instead of guessing. That run produced four items from documents alone, with no floor plan supplied, and it replays byte for byte from the same inputs, config hash and seed.

Each register item also carries an exposure band. Bands are order-of-magnitude planning figures rather than quotations, and every band shipped today is marked in the deliverable as an uncalibrated placeholder, because none of them is yet derived from cost history. No figures appear on this page for that reason.

03The argument

Why an output like that survives a design review

Four constraints are written into the project's contract document as prime directives. They are the reason the output has the shape it does, and each one is enforced in code rather than intended in prose.

Directive 2.1

Language models extract and classify. Code decides and computes.

A model may extract, classify, locate, transcribe and match. A model may never compute a quantity, assign a part number, produce a risk score, or decide that something is compliant. No model client may be reached from the engine, the validators, the scoring or the risk modules, and an architecture test asserts that in both directions. "The AI said so" does not survive the conversation with the engineer whose design you just contradicted. A named rule with a code citation does.

Directive 2.2

Every output line carries provenance.

Rule id, source document with page or sheet, and the specific target it applies to. A line without provenance is treated as a defect, not as a formatting preference. Citations in the chat lane are looked up by code from the record, not composed by the model that wrote the sentence around them.

Directive 2.4

Uncertainty is surfaced, never smoothed.

Every extracted entity carries a confidence and a review flag. Where the documents do not determine something, the engine emits a flag rather than a guess. Withholding a locking device on an aluminum storefront because stile depth is not stated anywhere in the package is the correct answer, and it is worth more to an estimator than a confident selection. Guessing is a change order.

Directive 2.5

Runs replay byte for byte.

The same inputs, config hash and seed produce byte identical output. Model calls are cached by content hash. Golden tests compare whole reports character for character, so a change in a rendered sentence fails the build rather than drifting quietly. A run that cannot be replayed cannot be benchmarked, and a run that cannot be benchmarked cannot be defended.

04The seam

Division 8 against Division 28, the highest value gap in this domain

Door hardware is specified in Division 8 by the architect. Access control is specified in Division 28. Electric strikes, electrified locksets and latch retraction devices sit exactly on that seam, and each package routinely assumes the other side covers it.

For any given opening there are four outcomes: the locking device is specified in Division 28, in Division 8, in both with conflicting requirements, or in neither. Both and neither are where the money is. Both means a duplicate buy or an argument at submittal. Neither means somebody eats it.

The failure is symmetrical, which is what makes it expensive. A sentence reads "by others, by Division 28". The security contractor reads it as somebody else's scope. The door hardware supplier reads the same sentence, agrees that the work is Division 28, and neither party prices the rough-in. That sentence is the finding shown above, and the rule that catches it is SB-002.

What ships today reads one located scope statement at a time: it finds the markers, resolves which of them names a party, and converts each into a register item with its page and its verbatim sentence. The full analysis, which joins every opening in the plan against every specification reference to it, now ships as five rules covering the states that seam can be in: both divisions specifying it and disagreeing, both carrying it and agreeing, each handing it to the other, neither speaking after both sections were read, and the seam being undeterminable at all. It has never run against a real bid package, because that needs plan extraction, which is not built.

05On green tests

A green test suite is not evidence, and this project has the receipts

One recent session's audit found seven defects in code that reported itself as working. Each was verified independently and proven by mutation, meaning the test was deliberately changed to a version that should have failed, and it did not. Three of them are worth stating plainly.

The architecture test that enforces directive 2.1 did not enforce it. Importing the engine straight into the model authored package left all thirty tests green. Twelve import forms evaded the detector, and the detector's own tests were exercising a hand copied duplicate of it rather than the detector itself.
The guard that keeps pricing out of client facing output was bypassable. A currency symbol followed by a zero width character renders as an ordinary price and passed. So did two Unicode characters that are formally named as dashes.
Several tests could not fail. Three retrieval selectors could be deleted outright with the suite still green. Two guards were mathematical tautologies.

Every one of those passed its own tests before mutation was applied to them. That is the reason nothing here is offered as proof that the engine is accurate. A passing suite establishes that the code does what its tests describe. It establishes nothing about whether the findings are the ones that become change orders, and that is a different measurement entirely.

06What is built

State of the build

These are run results from the working branch, not estimates. Each was reproduced immediately before this page was written.

1128tests passing, with 6 skipped and 1 expected failure held open

36source modules, clean under strict static type checking

3shipped rule packs, versioned and hashed into every run

256viewer tests passing, plus 35 architecture tests

Components, and an honest state for each.
Component	State	What it is
Deterministic engine	built	Rule evaluation with conflict groups and a full rule trace, validators that print their computed values on pass as well as on fail, the ranked risk register, the bill of materials, markdown and JSON reports, and a command line interface. Golden tests compare output byte for byte.
Document ingestion	built	Turns a package directory into a document model deterministically, segmented by CSI MasterFormat section numbering, with document, page and coordinate provenance on every element.
Claim extraction	built	A model reads a section and emits structured claims: subject, predicate, object, section, page, confidence. It structures and it does not conclude.
Scope boundary detection	built	Locates the markers where margin disappears, including "NIC", "by others", "furnished by" and "installed by", and converts each located statement into a register item through the SB rule family.
Grounded chat	built, unmerged	Answers questions about one loaded package out of that package's own artifacts. Deterministic retrieval, citations looked up by code, a coverage footer stating what was searched, a transcript, a review queue, and a disclosure gate before anything leaves the machine.
Plan viewer	built	Renders engine output and nothing else. Coverage geometry and every other number are computed in the engine and serialized, and the browser draws precomputed values only.
Plan extraction	not built	Specified: rasterize the real sheet, tile with overlap, extract openings and equipment with confidence, and halt with a blocking flag when scale cannot be determined rather than assuming it. Nothing draws a plan; the engine only reads one.
Benchmark	not built	The phase that would make an accuracy claim possible. It has no dataset. See below.

07Not proven

What this cannot defend yet

This section is not a footnote and it is not an apology. In this category of product it is the most useful thing a reader can be given, because everything else on a page like this looks the same whether the engine is right or wrong.

There is no accuracy claim, because there is no benchmark.

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. Until it does, nothing here supports a statement about how often the engine is right, and no such statement is made.

The blocker is records access, not research.

The benchmark needs a bid package whose documents are public and whose later additive change order is traceable to a defect in those documents. Both halves exist and so far never in the same project: the districts that publish complete bid documents ran projects in a different division, and the districts that ran the relevant projects hold their documents in a business office for in-person review.

Exposure bands are structural placeholders.

Every band shipped today was chosen so the ranking key has something to sort on, and none is derived from cost history. Rather than print a placeholder in the same typeface as a real figure, each band carries a calibration flag and every rendering marks it as uncalibrated.

The viewer is a demonstration, not evidence.

It was built ahead of the benchmark deliberately, against the project's own stated anti-pattern, and the amendment authorising that says so in writing: it will look equally convincing whether the engine is right or wrong, and nothing in the viewer may be read as evidence that the engine works.

There is a known detection gap, held open on purpose.

The ingest acceptance lane ran against a real project manual and passed every assertion but one. The one it failed is a genuine gap: owner-furnished scope stated in ordinary English, carrying none of the marker phrases the detector looks for. Rather than widen a pattern until the page passes, it is recorded as a backlog item and pinned as a strict expected failure, so that if the detector is ever widened to catch it the suite fails as an unexpected pass and whoever widened it has to come back and record that the gap closed.

Six tests are skipped, and a skip is not a pass.

The suite reports 1128 passing and 6 skipped. The skips are the chat acceptance lane, which needs a real ingested package present locally and recorded model responses to replay. Recording those means sending a real bid package to a model vendor, which leaves the machine, so it waits on a deliberate decision rather than being quietly worked around. Each skipped test names what is left unverified without it, and none of them is counted as green.

What it can defend today.

Every output line carries a rule id and a document citation. Runs replay deterministically. The system refuses rather than guessing when the documents do not determine something. What it cannot defend yet is that the things it flags are the things that actually become change orders.

08See it

Two things you can open right now

/viewer/ The register and plan viewer Running on fixture data, with layer toggles, device markers and the rule trace on click. Read the constraint above before reading anything into it. /status/ The build tracker Verified run results, the defects found and fixed in the most recent session, and what is currently blocked and why.