Blueprint Risk Engine

The estimator's problem

A senior estimator bidding public work has days, sometimes hours, to review a package that runs to hundreds of pages across drawings, specifications, addenda, and schedules. The money is not lost in the obvious line items. It is lost in the seams: a device count on a drawing that contradicts the equipment schedule, a specification section that quietly assigns conduit to the wrong trade, an addendum that changes a submittal deadline nobody re-read.

Each of those becomes an RFI at best and a change order fight at worst. The review that would catch them is well understood — it simply does not fit in the bid window.

The architectural decision that defines it

The tempting build here is a large language model that reads the package and describes what it sees. I rejected that as the core mechanism. Estimating is an adversarial commercial context — a flag that cannot be traced to a named rule and a page citation is worthless the moment a general contractor pushes back on it.

So the engine is built as rule packs over structured extraction. Every finding names the rule that produced it and cites the document and location it came from. The system is allowed to be wrong; it is not allowed to be unaccountable. That single constraint drove the schemas, the test benches, and the phase order of the entire build.

How I ran the project on myself

I wrote the specification as a binding contract before any code existed — five phases, numbered gates, and an explicit rule that a later phase does not begin because an earlier one felt easy. It includes prime directives that override any request that conflicts with them, and a standing instruction to surface a bad assumption immediately rather than inherit it into the schemas.

• No feature exists before the phase that calls for it — no web interface, no database, no configuration system added speculatively.
• Small commits, one logical unit each. Tests green before every commit.
• Where a design decision carries a genuine tradeoff, both options and a recommendation get stated — no silent picking.
• The specification is explicitly a working document, amendable when reality contradicts it.

This is the same governance I would put on a delivery team, applied to a project where I am the only participant. It is the most honest test of whether a process is real or theatre: it survives when nobody is watching, or it does not.

Current status

In active development against the phased plan. The validation approach is deliberately unforgiving: run the engine against bid packages where the real change orders are publicly known, and measure whether it flagged the issues that actually became change orders. Anything that does not move precision or recall against that benchmark is, by the project's own definition, plumbing.