Spec text in. Trade scopes out.
The Scope Builder is the Trueleveler engine that 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.
Try it now
Scope Builder runs on your spec text and needs a free account (no card). It has no sample data yet, and the no-signup demo only levels bids.
Specs are a wall of text. Bids start as a scope.
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 day the spec lands. Not the day RFQs go out.
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.
- Initial spec receipt — the full project manual goes through, generating 18–28 trade scopes (typical mid-size CRE).
- Each addendum — delta-only scope update. If addendum #3 changes Div 21 fire protection, only that scope rewrites.
- Bid scoping meetings — estimator brings the trade scopes to the strategy meeting. PM reviews the assumed/qualified lines. Together they finalize what to bid out vs self-perform.
- Owner-side scope review — design teams and owner reps use the same engine to validate that the spec covers every trade discipline before bid release.
Spec text. That's it.
PDF or pasted text. The engine handles either. Optional context narrows the run if you only need certain trades.
Spec text (PDF or pasted)
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.
Trade hint
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.
Project type
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.
One scope per trade. Four buckets each.
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.
The first engine. Feeds the next four.
Scope Builder is the pre-award starting line. Its output is the canonical reference for everything that follows in the bid cycle.
- RFQ Generator — drafted scope feeds straight into RFQ generation. Every scope inclusion/exclusion becomes a structured RFQ section. The carries-data badge fires on this chain.
- Bid Leveling — the scope becomes the canonical reference for vendor-bid scope checks. Bid Leveling reads the scope's inclusions and verifies each vendor's coverage line-by-line.
- Doc Chat — pre-bid Q&A on the spec inherits the scope context. Subs ask "is the panel demo included?" and the answer cites the same scope line the RFQ uses.
- Bid Templates — bid form templates pull line structure from the scope's inclusion list so vendors price against the same breakdown the GC scoped.
Things everyone asks first.
Does it invent scope items not in the spec?
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.
What if the spec is unusually thin or non-standard?
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.
How does CSI MasterFormat division mapping handle 2016 vs older specs?
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.
Can I edit a generated scope before persisting it?
Yes. The composed scope renders in an editable view. Estimator adjusts any of the four buckets — rewrite a line, add a custom qualification, note directly on an inclusion that it's "owner-furnished" or "by others." Saved scope persists with the edits + a diff log showing what was changed from the engine's first draft.
What's the difference vs. Doc Chat?
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.
Drop a spec. See 22 trade scopes in 30 seconds.
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.
Try Free for 14 Days →