A takeoff condition is a measurement rule, not a highlighted area

A takeoff condition is the reusable measurement rule an estimator sets up once and applies across a drawing set. It names what is being measured, how it is measured — count, length, area or volume — at what scale, in what unit, with what waste and deduction rules, and which cost item the resulting quantity feeds. The coloured overlay on the sheet is the result of applying the condition to geometry. It is not the condition.

The distinction sounds academic until quantity extraction enters the conversation. A system that reports it found 214 duplex receptacles has produced geometry and a count. A condition produces a number with a unit, a stated boundary, an adjustment and a destination. Everything between those two positions is the work, and it is where automated takeoff either becomes useful or becomes a second thing to check.

The record behind the colour

One condition, written out as the record it is. This is the shape any tool — or any automation — has to produce before its output can be used downstream without an estimator re-deriving it.

Only the second and third rows are about geometry. The other six are judgement, and they are the reason a condition set is worth more to a contractor than the marked-up drawings it produced.

The four measurement types, and the derived ones people forget

• Count. Discrete items, unit EA — devices, fixtures, doors. The only type where the geometry alone nearly tells you the answer.
• Linear. Length along a path — wall, pipe run, kerb. Carries a start-and-stop rule: does the run continue through a doorway, and does it stop at the face or the centreline of the intersecting wall?
• Area. Plan or elevation area, with deduction thresholds. The threshold is a policy, not a measurement, and it belongs on the condition.
• Volume. Area multiplied by a depth the drawing usually does not show, so the depth is a condition field sourced from the specification.
• Derived. Linear multiplied by a height to give board area; a count of fittings inferred from segments in a linear run. These are the ones extraction gets wrong most often, because the multiplier is carried by the condition and exists nowhere on the sheet.

What an automated takeoff has to output to be usable

There are 5 steps between a drawing file and a quantity an estimator will price. Symbol recognition is the first, and sometimes the second.

1. Find the geometry, with a scale reference attached to the sheet it came from rather than assumed globally.
2. Classify it against a named condition, not just a symbol shape — 3 different devices can share one symbol across disciplines.
3. Apply the unit conversion, waste factor and deduction rule the condition carries.
4. Map the result to a cost item or assembly, so the quantity lands in the estimate without being re-typed.
5. Emit a citation — sheet number and region — so the estimator can click a number and see what produced it. Without step 5 the reviewer has to re-measure to disagree, and will simply re-measure everything.

Finding the symbols is the part of the takeoff a machine is good at. Deciding what the symbols mean, and what the number is for, is the part that pays.

This shapes how we scope estimating work. The extraction step is worth automating where the drawings support it; the condition definitions stay with the estimator, and the system carries them as data rather than re-deriving them per job. That split — a deterministic structure with judgement supplied by a person at named points — is the same pattern we argue for in AI agents in production and the one we build to in AI agents and automation engagements.

Where the condition record travels next

A condition is the join between the drawing and the money, so its fields turn up in three later arguments. The cost item link is only useful if the rate on the other side carries its own context, which is what a unit cost library needs before it can price a second job covers. Scope that cannot be measured yet does not become a condition at all — it becomes an allowance line with an owner and a reconciliation date. And the scale reference field is the one a whole cluster of quantity errors traces back to, which is why lengths that are all wrong by the same percentage is a calibration problem rather than a measuring problem.

Downstream of the estimate, conditions decide whether comparison is even possible: two subcontractors pricing the same trade against different inclusion boundaries produce numbers that cannot be lined up, which is the normalisation problem a bid tab has to solve. The rest of this silo sits under preconstruction, takeoff and estimating, and the systems we build around it are described in our construction and contracting work.

• takeoff
• estimating
• quantity extraction
• preconstruction