One shared vocabulary from plan to estimate.
OpenBEAM is an open, machine-readable vocabulary for construction components — built as a structured join of the classification standards the industry already publishes, not another invented taxonomy. A baseboard should be one name, everywhere: on the drawing, in the takeoff, in the estimate, in the software.
Tag a plan — 60 seconds ↓ hello@openbeam.caEvery drawing set speaks its own dialect.
The same physical baseboard leaves the architect as a legend code, reaches the estimator as a guess, and reaches the trade as a phone call. Between each hop, data dies — and gets re-typed, re-guessed, re-priced.
A project-local code. Meaningless outside this drawing set.
Re-typed into a spreadsheet, meaning reconstructed by hand.
Priced from memory, confirmed by call-back. Third re-entry.
Not invented — joined.
OpenBEAM doesn't create a new classification of the built world. Each token is a structured join of real, published OmniClass tables (CSI / CSC): Table 23 says what the component is, Table 41 says what it's made of — the official spec calls materials "modifiers" on products — and Table 49 says how it's measured. Codes are cross-referenced at entry creation, never bulk-imported.
| OpenBEAM token | What — OmniClass 23 | Material — Table 41 | Properties — Table 49 |
|---|---|---|---|
| material.trim.baseboard | 23-15 17 11 17 11 Base and Accessories for Floor Coverings |
41-30 30 11 19 11 Softwood Timber 41-30 50 21 71 PVC-U |
49-71 19 13 Length · 49-71 19 21 Height 49-71 19 25 Thickness · 49-61 41 31 Style |
Worked example from a real 178-unit residential drawing set. Every code above appears verbatim in the published OmniClass tables — no code on this page is fabricated.
Early. Real. Open about both.
This is not a finished standard, and we won't pretend otherwise. It's a working vocabulary being grown sample-by-sample from real drawing sets, with its open questions in public view.
- 185 tokens in the working catalog (v2.9), grown from real multi-residential documents
- Every token follows one convention: family.context.specific
- Open decisions are tracked openly — e.g. should baseboard classify under Floor Base and Accessories or Wall Moldings? Both are defensible; a standing rule is still being debated.
- The catalog grows deterministically: a new component earns a token only when a real document demands it — no speculative taxonomy.
Click the plan. Build a machine-readable takeoff.
Eight components in this sample unit are waiting for a name. Click each glowing element, choose what it is, and watch the takeoff table build itself — every row carries a real OmniClass cross-reference. When you pick a material, the component takes that material's color: in OpenBEAM, material is a modifier, and here you can see it.
Takeoff — Sample Unit 1B
| Component | OpenBEAM token | What — OmniClass 23 | Material | Qty |
|---|---|---|---|---|
| — nothing tagged yet. Click a glowing component on the plan above — | ||||
Quantities describe this fictional sample unit only. OmniClass codes are real, verbatim from the published tables.
This standard needs more heads than ours.
We're looking for academic collaborators — construction engineering, BIM, information management — and industry people who've felt this problem in their hands. Classification rules, catalog governance, edge cases from real documents: the open questions are genuinely open, and co-authorship is on the table.