Identifies each distinct trade discipline in the supplied spec text and writes a procurement-ready scope. Grouped by trade with CSI MasterFormat division mapping. Inclusions, exclusions, assumptions, and qualifications are each grounded in the spec — no invented requirements. Persists each scope to the scopes table so the RFQ Generator can read it on the very next click.
A 400-page project manual contains every requirement, every product reference, every coordination note. None of it is structured by trade. The estimator has to read the whole thing, mentally split work by trade, and write a one-page scope narrative for every sub they want to bid the job. That's the work this engine does.
Scope Builder identifies each distinct trade discipline mentioned across the spec, then composes a procurement-ready scope per trade: what's included (cited from the spec), what's explicitly excluded (cited or absent), what's assumed (industry-standard fills), and what's qualified (caveats and clarifications). Each scope maps to its CSI MasterFormat division so it lines up with the project manual's organization.
The estimating team's first job after spec receipt is figuring out who to invite to bid. Trade scopes are how that happens. Run Scope Builder once at spec drop; rerun on each addendum.
PDF or pasted text. The engine handles either. Optional context narrows the run if you only need certain trades.
Full project manual is best. Partial specs work too (e.g., only the Div 26 electrical section) — the engine generates trade scopes from whatever it can read.
Restrict the run to a single trade if you only need to scope, say, mechanical. The engine ignores other divisions for this run but persists the rest of the index for later.
Healthcare, lab, K-12, residential, industrial. Project type tunes the assumed-lines library — a lab project gets different default exclusions than a mid-rise condo.
Sample output for an electrical trade scope, generated from a 14-floor commercial office spec:
Every inclusion / exclusion line is grounded in the spec by citation (section number + page). When a sub disputes a scope item at bid clarification, you reply with the spec reference, not a memory of where you saw it. Disputes that used to take three email rounds resolve in one.
Scope Builder is the pre-award starting line. Its output is the canonical reference for everything that follows in the bid cycle.
No. Every inclusion and exclusion line carries a spec citation (section + page). Assumed and qualified lines are explicitly labeled as such — the engine surfaces them to the estimator for human review before scope finalization. If a spec is silent on a point that matters (NEC clearances, standard manufacturer terms), the assumed line says exactly that.
Design-assist or design-build specs without the usual division structure still parse — the engine identifies trade discipline by content (electrical equipment, plumbing fixtures, structural members) rather than by section number. Output flags lower confidence on non-standard specs so the estimator knows to verify more carefully.
2016 MasterFormat is the default. Older Uniformat or 1995 MasterFormat specs auto-translate at parse time — old "Division 15 Mechanical" maps to current Divisions 22, 23. The mapping persists in the scope output so downstream RFQs use the modern division.
Yes. The composed scope renders in an editable view. Estimator adjusts any of the four buckets, can add custom qualifications, can mark an inclusion as "owner-furnished" or "by others." Saved scope persists with the edits + a diff log showing what was changed from the engine's first draft.
Doc Chat answers ad-hoc questions on a spec ("what's the fire-rating for the lobby?"). Scope Builder writes the full trade-level scope narrative in one shot. Doc Chat is exploration; Scope Builder is procurement-grade output ready for RFQ generation.
Bring a real project manual to a 15-minute call. We'll process it on screen and walk through the generated scopes trade-by-trade. You keep the output.
Start free — 14 days, no card →