Design intent is what estimators price when the drawings stop talking

Design intent is the project the drawings are trying to become, not only what is currently inked. GC estimators, chief estimators, and precon leads reconstruct that intent under bid pressure whether the set is missing sheets or "100% complete" and still silent on interfaces, means, and ownership.

This piece is for teams that already know how to take quantities. The question is narrower: when drawings are incomplete, or complete but still ambiguous, how do you reconstruct what the design team meant, and why does junior judgment diverge from senior judgment on the same set? For the related skill of reading between the drawings, start there. For the broader case that estimating is risk management, not cost calculation, start there. Here the focus is design intent as an inference problem, and how to keep that inference reviewable.

Incomplete is obvious; complete-but-ambiguous is the trap

Missing sheets, single-line MEP, unfinished connections, and "typical" details that never get typical: those are the incomplete cases everyone recognizes. At 30%, 50%, and 75% design, AACE-style estimate classification (for example RP 18R-97) treats maturity of deliverables as the driver of accuracy, not the sophistication of the takeoff tool. You are quantifying implied assemblies and holding design contingency for evolution, not pretending the model is finished.

The harder case is a full Construction Document set that still forces inference. Specs conflict with details. Trade packages leave a parapet, embed, or in-wall backing unowned. Division 01 language sounds mandatory and operationally vague. A note says "coordinate in field." The designer intended a buildable assembly; the documents never named who prices the gap. Completeness of page count is not completeness of commitment.

On a hard-bid warehouse, that ambiguity often hides in shell interfaces and performance specs. On a CMAR healthcare or education job at GMP, the same ambiguity shows up earlier, while design is still moving, and the estimator is already inside the design conversation. Delivery method changes when you can ask; it does not remove the need to infer.

What juniors infer vs what seniors infer

Put a junior and a senior on the same bid set and the Layer 1 read can look similar. Both can see what is drawn, what is specified, and what is silent. The split is Layer 2: what the project will actually require.

Junior pattern (sheet-first). If it is not shown, it may not be in. If two trades are silent, hope the low bidder owns it. If the detail is "similar," copy the last job. If time is short, bury a cushion in the unit rate and move on. The sheet is the authority because the sheet is what they were trained to audit.

Senior pattern (build-first). Ask how the assembly goes together, who touches it in sequence, and what the designer usually means when they draw this typology. Price the support that is never detailed because the wall cannot stand without it. Flag the exclusion that is really a scope transfer. Treat a suspiciously clean sub number as a design-intent miss, not a market win. Related: spotting scope gaps before you carry and reviewing exclusions and qualifications.

Neither pattern is moral character. Juniors are doing what the documents reward under audit: stay close to ink. Seniors are doing what the field will enforce: stay close to constructability, trade practice, and late RFI history. The firm loses when Layer 1 volume crowds out Layer 2 hours, so the only people who can infer well never get enough time to teach it.

Inference patterns worth naming out loud

Design-intent work is not a vibe. It clusters:

1. Implied assembly. The detail stops before the support, termination, or secondary framing the assembly needs.
2. Interface orphan. Two packages each assume the other owns flashing, firestopping, embeds, or housekeeping pads.
3. Spec vs drawing conflict. One document is older, or written for a prior scheme, and nobody reconciled them before bid day.
4. Performance without prescription. The outcome is specified; the means and the trade boundary are not.
5. Typology memory. Seniors recognize "this designer / this building type always means X"; juniors only see this PDF.
6. Late-only clarification. The RFI answer will arrive after the price is locked, so the bid must carry a provisional position anyway.

Write those patterns into the estimate basis. A number without a named pattern is not reviewable in final bid QA. See the final bid review playbook.

A short checklist for documenting assumptions

Use this before you bury risk in a unit rate or a blanket contingency:

1. State the intent in one sentence. "We are pricing a continuous air/vapor barrier at the parapet even though the wall section stops short."
2. Point at the source. Sheet, detail, spec section, addendum, or "not shown; inferred from adjacent typical."
3. Name the pattern. Implied assembly, interface orphan, conflict, performance gap, typology memory, or late clarification.
4. Separate contingency types. Design contingency for incomplete design evolution; construction contingency for execution risk. Do not blur them into one opaque pad.
5. Assign an owner. Who must confirm before award: designer RFI, sub clarification, chief estimator carry decision.
6. Set the decision deadline. What happens if the answer arrives after submission: hold, qualify, or carry with a named allowance.
7. Keep it attached to the estimate. Assumptions that live only in a hallway conversation do not survive buyout.

This is how you turn senior judgment into something a junior can execute next week without pretending they already have twenty years of pattern memory. It is also how scope generation stays honest when the package moves.

What this means for the work

Design intent is not a document-completeness KPI. It is the continuous job of reconstructing commitments from drawings, specs, addenda, company standards, and how buildings actually go together. Incomplete sets force that work early. Complete sets still force it at the interfaces. Junior estimators fill gaps from the sheet; seniors fill gaps from the build. The system worth building is one where Layer 1 reading and cross-check do not consume the hours seniors need for Layer 2, and where every inference stays linked to a source so a reviewer can challenge it before the number ships.

If your team still rebuilds that understanding from a blank spreadsheet on every pursuit, you are paying the tax described in why every construction estimate still starts too close to zero.

Where Piper fits

Design-intent work fails when the reading and cross-check never finish, so the only people who can infer well spend bid week on assembly instead of judgment.

Piper is the AI operating system for preconstruction. It reads the bid set against your company's scope standards, surfaces gaps and silent items with the clause or drawing behind them, and carries that same understanding of the project into scope, leveling, and final review, so an inference made at 50% documents is still visible when the addendum arrives that tests it. The estimator stays in control of status and adjustments. The goal is not to invent design intent for you. It is to finish Layer 1 structure fast enough that Layer 2 inference stays human, reviewable, and attached to the estimate.

Sources

• AACE International, Recommended Practice 18R-97, Cost Estimate Classification System