Building a reusable condition library for sitework bids

How to design takeoff conditions you can reuse across projects: naming, units, attributes, color conventions and keeping the library from sprawling.

5 min read

Key takeaways

  • A condition is a named measurement type with a unit and attributes.
  • Standard naming makes quantities comparable across projects.
  • Encode depth and size bands in the condition, not in notes.
  • Prune the library; unused conditions cause mis-assignment.

A condition is the unit of organization in a takeoff: a named thing you measure, with a unit, a color and a set of attributes. Get the condition library right and every project starts half-built, exports cleanly, and produces numbers that can be compared to the last job.

Anatomy of a good condition

PropertyExample
NameStorm — 12" RCP — 8-14' depth
TypeLinear
UnitLF
ColorStorm blue
AttributesSize, material, depth band, surface
Scope groupStorm drainage

Naming conventions that scale

Use a consistent order — scope, then item, then qualifier — so conditions sort into usable groups and a reviewer can scan the list.

  • Scope prefix first: Storm, Sanitary, Water, Paving, Earthwork, Erosion.
  • Then the item and size: 12" RCP, B6.12 curb, 4" walk.
  • Then the qualifier that splits pricing: depth band, surface, phase.
  • Avoid project-specific names like "north lot curb" — they do not reuse.

Color conventions

Colors are for review, not decoration. Assign one hue family per scope and vary shade by size or depth. A reviewer glancing at a marked-up sheet should be able to tell storm from sanitary from water without reading a single label.

Keep colors consistent across every project. Muscle memory in review is a real accuracy gain, and it disappears the moment blue means storm on one job and water on the next.

What belongs in the condition vs the note

  1. Anything that changes the unit price belongs in the condition name or attributes.
  2. Anything a supplier needs to quote belongs in an attribute.
  3. Anything unique to one measurement — an odd assumption, a plan discrepancy — belongs in a note on that measurement.
  4. If you find yourself repeating a note across projects, it should be a condition attribute.

Keeping the library healthy

  • Start small: fifteen well-named conditions beat two hundred half-used ones.
  • Add a condition when a real project needs it, not speculatively.
  • Retire duplicates — two conditions for the same item guarantee split quantities.
  • Review the library quarterly against the scopes you actually bid.
  • Keep depth and size bands aligned with how your crews and suppliers price.

The payoff shows up in the second year: quantities from this bid are directly comparable to the same condition on last year's bid, so historical unit costs become usable data rather than anecdotes. That comparability is only possible because the condition names never drifted.

Doing this work in TakeoffAI? Conditions.

Ready to run your next takeoff?

Create an account and turn your first plan set into measured quantities today.