AI for MEP Estimating Teams Inside CM Firms — Three Capabilities That Actually Save Hours

If you run MEP estimating inside a construction manager, you already know where your week goes. A pre-bid Monday opens with a 1,200-page spec book and the question "what's actually in here that touches mechanical, electrical, plumbing, fire protection scope?" By Tuesday afternoon you've been through it once with a highlighter, and you're not sure you didn't miss something — because in a 1,200-page document, you can't be. On Wednesday three sub bids land that ostensibly cover the same MEP scope, and the rest of the day disappears into a side-by-side that the subs have made deliberately uncomparable. If the project is healthcare, Thursday is FGI Guidelines stacked against ASHRAE 170 stacked against your state's Department of Health amendments, three documents that change independently and that the spec selectively references.

None of this work is the work you went to school for. The judgment work — what the project actually needs, where the spec is reaching, where the subs are gapping, what the local AHJ is actually going to enforce — is the work. Everything before it is volume that has to get processed before judgment can apply. AI is finally good at this kind of volume processing, on one condition: the AI has to be the kind that cites its source or refuses rather than the kind that confidently fills in plausible-sounding answers.

That distinction is structural. A generic chat AI handed a 1,200-page PDF will produce a clean-looking summary of MEP scope items in three minutes. It will also invent some of them. The output gives you no signal about which is which. You can't act on it. The estimator who spent two days with a highlighter still has to spend two days with a highlighter.

The architecture that fixes this — multi-mind verification, primary-source citations or refuse to claim, refuse-sets defined and visible, working practitioners as the final gate — is what The Hive is built around. The full architecture is here. The rest of this piece is what that architecture looks like when it lands on three specific MEP estimating tasks.

1. Spec Book MEP-Scope Scanner

The task: read a project specification book — typically 800 to 1,400 pages — and identify every section that affects mechanical, electrical, plumbing, or fire protection scope. The pain isn't divisions 22, 23, 26, 27, 28 — those are obviously yours. The pain is the MEP requirement buried in Division 01 General Requirements (commissioning scope, owner-furnished equipment installation responsibilities, sustainability targets that flow to MEP selection), Division 03 (slab penetrations and embeds for plumbing and fire protection), Division 09 (ceiling system compatibility with MEP coordination), and project-specific sections that override standard requirements without flagging it. Miss any of these in your bid and you've eaten the change order or you've eaten the loss.

The Hive's Spec Book MEP-Scope Scanner is built around four outputs, each citing primary source:

• MEP-scope sections. Every section that affects MEP scope, with division, section number, page range, quoted excerpt, and the specific reason it affects MEP. Not paraphrased — quoted.
• Owner-specific overrides. Items that override standard scope: epidemic preparedness, isolation suite cascades, vibration overlays, redundancy multipliers, post-disaster resilience, infection-control overlays, energy-target overlays. Each entry cites the page-and-paragraph and identifies what standard scope it overrides.
• Cross-reference contradictions. Sections that conflict with each other, with cited drawings, or with cited standards. Both sides of the contradiction are required to be cited primary-source — no inferred conflicts, no "looks like" reasoning.
• MEP scope summary. A one-page narrative the estimator can paste into the bid as a starting point, generated from claims that passed verification. Every claim cites its source.

There is a fifth output that matters more than the other four for trustworthiness: the refuse list. Pages the tool couldn't read because of scan quality. Sections it couldn't classify with confidence. Claims it would have made but couldn't cite to source. Refuse is first-class output, not an error state. An estimator reading the refuse list knows exactly what wasn't covered, which is the only honest way to use the rest of the report.

Design target: a scan that takes the estimator from "what's actually in this spec book" to a structured report with citations in roughly 8 minutes for a 1,000-page book, vs the 1–2 days it takes with a highlighter. The full architecture is documented at the Spec Book Scanner architecture page. Current state: free public preview live at /tools/spec-book-mep-scanner/ — paste-text input, two-pass cite-or-refuse, no signup required. v0 accepts up to 30,000 characters of pasted spec text (~20 pages); full PDF processing is v1.

2. Sub-Bid Scope-Gap Detector

The task: an MEP scope on a mid-size bid comes back with three or four sub bids, each one purportedly covering the same scope. In practice each sub has written the scope, exclusions, and qualifications in their own language. One excludes core drilling. One includes the temporary power required during construction but excludes the temporary heat for cold-weather pours. One qualifies their pricing on a specific manufacturer that the spec calls out as basis-of-design but the addenda then list as one of three acceptable manufacturers. The estimator's job is to surface every gap, every exclusion, every qualification, decide what each one is worth, and level the bids onto a comparable basis.

Manual sub-bid leveling on a complex MEP scope is the kind of work that takes 60 to 90 minutes per bid pair and that produces errors precisely because the language is intentionally non-parallel. The sub who excludes the unusual item buried in a 14-page qualifications attachment is the sub who wins on price and then submits the change order in week three.

The Sub-Bid Scope-Gap Detector is built around the same cite-or-refuse architecture. Inputs: two or more MEP sub bids as PDFs. Outputs:

• Side-by-side scope comparison. Each line of scope, each bid, the language each sub used.
• Exclusions in each bid. Quoted, cited to the page of the bid document.
• Qualifications in each bid. Quoted, cited.
• Scope-gap flags. Items one bid covers that another doesn't, surfaced explicitly.
• Refuse list. Items the tool wasn't confident enough about to claim were gaps — refused rather than guessed.

What the tool deliberately does not do: estimate the dollar value of each gap. Dollar estimation requires regional unit-pricing data we don't have and that varies by trade contractor mix in ways the tool can't verify. The architecture refuses to claim what it can't ground. The estimator still applies judgment to the dollar impact — but the gap surfacing, which is the volume work, is done. The architecture for this tool is documented here. Current state: architecture published, build pending Spec Book Scanner free-tier launch.

3. Healthcare MEP Code-Cross-Reference Engine

The third task is more specialized but more painful per occurrence. A healthcare project bid in the Mid-Atlantic typically references three independent regulatory documents for MEP space requirements: the FGI Guidelines for Design and Construction of Hospitals (current edition), ASHRAE 170 (current addenda), and the state Department of Health's adoption-and-amendment of FGI. Pennsylvania adopts FGI with a specific amendment set. Maryland adopts FGI with a different amendment set. New Jersey administers facility design review through a different process entirely. Delaware and Virginia each have their own approach. The three documents — FGI, ASHRAE 170, and the state amendments — change on independent revision cycles and selectively cross-reference each other.

For an isolation suite, an operating room, a procedure room, an imaging suite, or any of the dozens of space types that have stacked MEP requirements, the estimator's question is: what does the AHJ that will actually review this project's permit drawings require for this specific space, in this specific jurisdiction, today? Answering that question manually requires pulling all three documents, finding the relevant section in each, identifying which one governs where they disagree, and tracking which amendments are active.

The Healthcare MEP Code-Cross-Reference Engine is the most ambitious of the three capabilities and the one with the longest build path. Inputs: project location (state, county/jurisdiction), facility type, and the space types being designed. Outputs: stacked applicable requirements for that specific project's MEP scope, with citations to FGI section, ASHRAE 170 paragraph, and the state amendment provision. Where the three disagree, the tool surfaces the disagreement and identifies the controlling document for that jurisdiction — citing the relevant adoption-and-amendment provision. Where the tool cannot reconcile, it refuses and surfaces the unresolved conflict for the estimator's judgment.

The reason this capability matters disproportionately: getting a healthcare MEP requirement wrong in a bid is not just a change order. It can be a delay in the certificate of occupancy, which on a hospital is a delay in opening, which is a number that gets very large very fast. The current state of this tool: in design. Building the underlying state-amendments library takes longer than the other two tools combined. The supporting essays in The Hive's writing archive cover the regulatory landscape — see the CON vs licensure distinction, the Maryland Certificate of Need piece, the New Jersey CON piece — and there are state-by-state references for the Mid-Atlantic regulatory stack in the writing index. The tool layer comes next.

What these tools deliberately don't do

The shape of an honest AI tool is partly the shape of what it refuses. The three capabilities above share a refuse list:

• They don't generate dollar estimates. Dollar estimation requires regional pricing data that varies by trade contractor and that the tools can't verify. The estimator owns the dollar judgment.
• They don't substitute version-stale model knowledge for what's actually in the document being scanned. The Spec Book Scanner reads this spec, not the model's training on similar specs.
• They don't paraphrase the spec into the user's preferred wording. Quotes are quotes. Paraphrasing is where fabrication enters.
• They don't make claims they can't cite. A claim without a source citation isn't an output — it's an error.
• They don't store uploaded PDFs beyond the session. Output is offered for download; uploaded content is purged within 24 hours. No model training on uploaded content.

None of these refuses are a degraded fallback. They're the architectural commitment that lets the rest of the output be trustworthy. A tool that "does everything" does nothing trustworthy. A tool that refuses the cases it shouldn't try is the only kind that works for estimating work where being wrong has consequences.

What this looks like in practice for an MEP estimating team

If the three capabilities above are working — Spec Book Scanner free public preview live, Sub-Bid Scope-Gap Detector free tier live, Healthcare Code-Cross-Reference Engine for the Mid-Atlantic in production — the workflow for an estimating team inside a CM firm changes specifically on the volume tasks:

• Monday morning pre-bid: drag-and-drop the spec book. Walk away. Come back to a structured report with cited quotes, owner overrides flagged, and a one-page scope summary that the estimator marks up rather than drafts from scratch.
• Wednesday sub-bid leveling: drag-and-drop three sub bids. Side-by-side comparison with exclusions and qualifications surfaced. Estimator applies dollar judgment to the gaps instead of finding them manually.
• Healthcare project pre-design: input the project's jurisdiction, facility type, and space types. Get the stacked FGI / ASHRAE 170 / state-amendment requirements with the controlling document identified per requirement.

The judgment work — what to do with the surfaced findings, how to price the gaps, what to RFI, what to assume and proceed on — stays where it should: with the estimator. The volume work shrinks. That's the point.

Where the work is, today

The architectures for all three tools are public and documented in The Hive's writing archive. The Spec Book Scanner is the first to a free public preview; sub-bid leveling and healthcare code cross-reference follow. The MEPCalc Pro tier (currently invitation-only beta) is where these tools become unlimited-use production tools inside a firm's estimating workflow, with custom owner-overlay rule sets and project-history retention under explicit opt-in.

For MEP estimating teams inside CM firms in the Mid-Atlantic who want to discuss what an honest AI build looks like for their specific workflow — what's buildable, what isn't, what should be refused — there's a written engagement page at /builder-circle.html and direct contact at via LinkedIn. Two paragraphs is enough.