A risk register you can argue with.
You have the specifications, the project manual and a bid date. Blueprint reads those documents against each other and hands back a ranked list of the scope nobody has clearly taken: the conflicting requirement, the gap between two divisions, the sentence that leaves ownership unsaid. Every line names the rule that produced it and quotes the sentence it came from, with the document and the page, so you can open the PDF, land on the line, and decide the engine is wrong. A finding you cannot check is worth nothing on a bid day.
Current pilot focus: Division 08 ↔ Division 28 access-control scope.
Runs on your machine Every line cited to a page Rules published in full Same documents, same register
Four stages, and you own the last one.
Blueprint sits between the day the package drops and the day you submit. It does not price anything and it does not decide anything. It reads the documents against each other and gives you a shorter, sourced list of things to settle before the bid goes in.
-
Input: the specifications and the contract documents
You point Blueprint at the written package. It reads specification sections and the project manual, extracts the text with page provenance, and segments it by CSI MasterFormat section number, so a finding can name section 08 71 00 at page 5 rather than a file at a byte offset. Ingest is deterministic and offline: no model call, no network, no clock.
Not everything in a bid package is an input today. This is the honest list.
Document types and whether Blueprint reads them today. Document State Specification sections and the project manual Available Scope-ownership language: NIC, by others, furnished by, installed by, OFCI, CFCI, under separate contract, existing to remain, verify in field Available Document type detection, including addendum front matter Available Drawings and plan sheets Planned Addenda reconciled against the base documents Planned Door, hardware and equipment schedules as structured rows Planned Bill of materials as an input Planned An addendum is detected and read as one more document. It is not diffed against the base specification, so addendum reconciliation stays your job. A PDF with no text layer is refused by name rather than ingested as empty, and every unreadable file in the package is reported at once, so it costs one round trip and not one per file.
-
Cross-check: the documents against each other
The expensive problems are rarely inside one section. They sit between sections, between divisions, and between the people who wrote them. Blueprint runs published rules across the whole set of documents at once and looks for three things.
- Conflicting requirements. Two sections that cannot both be satisfied, or that assign the same work twice on different terms.
- Scope gaps. Work that every section assumes somebody else carries, which is the gap that shows up as a change order.
- Unclear responsibility. Language that names the work but never names the party, or that names a party the other division contradicts.
Division 08 says Division 28 owns it. Division 28 says Division 08 owns it. Blueprint flags the conflict before bid.
Every rule is written down and published. You can read the conditions, read the cited authority, and tell the engine it is wrong about your project, because the packs shipped today are written against California DSA reviewed K-12 work and every rule is project-overridable. Read the rules
-
Output: a ranked, traceable pre-bid risk register
One register, ordered so the top of the list is where your remaining hours go. Ranking is deterministic, and two runs never disagree about which of two equal items comes first. Each line carries its rule id, its severity, the specific opening or system it is about, the sentence that triggered it, the document and page that sentence came from, and one recommended pre-bid action.
A register that reads well and cannot be checked is a liability. So evidence is not optional on any line: a finding with no citation cannot be built at all. The engine also reports what its checks computed when they pass, because a pass with no numbers attached is indistinguishable from a check that never ran.
Same documents, same rule packs, same register, every time. The run carries a hash that identifies it, so a finding you showed the design team last week is the same finding when they ask you to run it again. How that is proved
-
Action: you decide what each line is worth
The register is an input to your judgement, not a replacement for it. Every line arrives with one recommended action, and you are free to take a different one. In practice a finding ends in one of these.
- Issue an RFI, quoting both sentences.
- Carry an allowance and say so in the bid.
- Qualify the bid and name the assumption.
- Exclude the scope explicitly.
- Request a clarification from the vendor or manufacturer.
- Verify responsibility with the other trade before submission.
- Confirm it against the drawings by hand.
- Take no action and price it knowingly.
That last one matters. A flag you read, understood and decided to carry is a priced risk. The same flag unread is an unpriced one. The point of the register is to move items from the second category to the first before the bid goes in, not to grow the list of things you must chase.
Thirteen fields, and none of them are decoration.
This is what one line of the register is made of. If you have ever been handed a list of "issues" with no source attached, this is the part that matters: each field exists so that you can check the claim, take it to somebody, or throw it out on a stated ground.
- rank
- Where it sits in the register, so the top of the list is where the remaining hours should go. Severity orders it first. The rule id is part of the ordering so that two items of equal weight always come back in the same order and the list does not reshuffle itself between runs.
- rule_id
pack_id
pack_version - Which published rule produced this, out of which pack, at which version. Rule ids are permanent and never renumbered, so a finding you argued about in March is still the same rule in October. You can look it up, read what it checks, and tell us it is wrong for your project. All four shipped packs are at version 0.1.0.
- severity
- BLOCKING, HIGH, MEDIUM or LOW. Blocking is reserved for the ones you cannot responsibly bid without an answer, such as a fail-secure device on a panic-protected egress opening, which is a life safety defect rather than a cost item.
- category
- What kind of problem it is: LIFE_SAFETY, SCOPE_GAP, QUANTITY, POWER, INFRASTRUCTURE, DOCUMENT_CONTRADICTION, FIELD_VERIFICATION or EXTRACTION_CONFIDENCE. You triage differently by kind. A scope gap goes to the project manager. A quantity question stays on your desk.
- target
- The specific thing this is about, named rather than described: an entity type, an entity id, and a human label such as "Opening D101, main entrance". A finding about "the access control system" is not actionable. A finding about D101 is.
- finding
- What is wrong, in one statement, written in an estimator's vocabulary rather than a rule engine's. This is the line you paste into an RFI.
- rationale
- Why it matters commercially, rather than a restatement of the condition that fired. It is written as if the reader is the engineer whose design you just contradicted, because sometimes they are.
- authority
- The code section, standard or manufacturer document the rule stands on. This is what turns a disagreement into a conversation about a citation rather than a conversation about who sounds more confident.
- evidence
- One or more citations, each naming a sheet, a document or a CSI section, with page, detail reference, schedule row, and the verbatim quote where the wording is the finding. Non-empty by constraint. A finding with no citation attached is not built and then rejected in review. It cannot come into existence at all.
- computed_values
- Where the finding came from a check that calculated something, the numbers it actually produced. This is what lets you check the arithmetic instead of accepting the verdict, and it is reported on a pass as well as on a failure.
- exposure_estimate
- The slot where commercial exposure will sit. The engine carries an order-of-magnitude band internally so the register has something to sort on beyond severity. No band is published to customers, because none has been calibrated against real project cost history yet, and a number nobody can defend under questioning is worse than no number. Every finding renders this as Commercial exposure: calibration pending
- recommended_pre_bid_action
- One thing to do, specific enough to do today. File an RFI quoting both sentences. Confirm which division carries it. Read the cited sections by hand before relying on this seam. You are free to do something else, and stage four above is the list of what else usually applies.
- confidence
- Zero to one, and never defaulted. Where a finding rests on two extracted statements it is the lower of the two, not an average and not a lift, because a formula that turns 0.8 and 0.8 into 0.96 produces a number nobody can defend in a room.
- review_required
- True where the documents do not settle the matter and the honest output is a flag rather than a verdict. A rule arguing from silence says so here, instead of arriving looking identical to a rule that read two contradictory sentences.
What runs, what is being validated, what is not written yet.
One table instead of a paragraph of qualifications. What we publish is measured. What isn't measured is labeled accordingly. Nothing here is a roadmap promise with a date on it; it is the state of the code as it stands.
| Capability | State |
|---|---|
| Deterministic rule evaluation, validators, risk register, report | Available |
| Specification and project-manual cross-check, Division 08 ↔ Division 28 seam | Pilot |
| Scope-ownership statements, SB-001 and SB-002 | Pilot |
| Division seam rules, SB-020 to SB-024 | Pilot |
| Access-control opening rules, AC-001, AC-010 to AC-014, AC-020 to AC-022, AC-030 | Pilot |
| Video-surveillance rules, VS-001 and VS-002, Experimental | In Development |
| Dual-vendor extraction agreement, code written and unit tested, reached by no command | In Development |
| Hosted web application, login, chat copilot, not deployed | In Development |
| Schedule-to-specification join, SB-010 to SB-019, ids reserved, no rules written | Planned |
| Addendum reconciliation, DC-020 to DC-029 | Planned |
| Cross-document contradiction, DC-001 to DC-019 | Planned |
| Plan and drawing extraction, no module exists | Planned |
| Bill of materials as an input | Planned |
Whole-system validators
Six checks in the access-control pack look at the system rather than one sentence, and each reports the numbers it computed either way: the required current against the available current, the openings counted against the panel, the measured run length against the copper limit. A validator that never ran reports nothing rather than reporting a pass, because those two must never look the same.
| Id | Title | Scope | Severity |
|---|---|---|---|
| V-001 | Access power supply capacity | idf | High |
| V-002 | Voltage consistency per opening | opening | Blocking |
| V-003 | Controller opening capacity | idf | High |
| V-004 | Cable distance from serving IDF | opening | High |
| V-005 | Standby battery runtime | idf | Medium |
| V-006 | Egress locking compliance | opening | Blocking |
It is not a takeoff engine and it is not an estimating system. It does not count devices off a drawing, it does not produce your quantities, and there is no unit cost, no labor rate, no extended total and no quotation anywhere in the output. It is a second pass over the seams between the documents, run by something that does not get tired at 11pm on the night before a bid.
Find it while it's still an RFI.
Open a real register, click a finding, and read the rule, the evidence and the page it came from. Nothing to install and nothing to upload.