Building the Construction Price Graph
Omnicost is building a graph of catalog items, supplier SKUs, decompositions, regions, and price observations for construction intelligence.
What is the construction price graph?
A connected layer of cost data that links price observations to supplier SKUs, canonical items, regions, units, and budget lines — far more powerful than a flat price list.
Why build a graph instead of a price list?
Most estimating still runs on flat price lists: a spreadsheet row, a line in an old price book, a quote pasted from an email. Flat lists can't answer the questions that actually drive margin — which of forty "ready-mix concrete" entries are the same product, whether last month's price still holds, or which budget rows are exposed if steel moves 8%.
A graph models the relationships, not just the values. The nodes are the real cost concepts in construction:
- Price observations — a number with its full context: provider, URL, currency, unit, region, timestamp, trust score.
- Supplier SKUs — a vendor's specific listing for a product.
- Canonical items — the deduplicated concept many SKUs map to (one "electric winch, 100A" instead of a dozen vendor names).
- Categories, regions, and units — the dimensions you benchmark along.
- Decompositions — BC3/FIEBDC-3 recipe trees that break an item into material, labour, and machinery per unit.
- Budget lines — where all of this gets used: a priced row in a real estimate.
The edges — this SKU maps to that canonical item, this item appears in that decomposition, this observation came from that region — are where the intelligence lives.
What questions does it answer?
Once the relationships exist, practical questions become queries instead of research projects:
- What is the current median price for this item, and how many vendors back it?
- Which suppliers moved recently, and by how much?
- Which budget rows depend on a category that just shifted?
- Which decompositions consume this material?
- Where do we lack regional coverage, so an estimate there is really a guess?
Why does it make AI estimating safer?
An estimating agent should never invent a price from text alone. The graph gives it something to retrieve against: it can pull related items, inspect units, compare observations across vendors, and explain whether an answer came from live data, an imported catalog, or a fallback assumption. That provenance is the difference between a number a contractor can defend and one they have to walk back. When the graph has no good evidence for a line, the honest output is "needs review," not a confident guess.
Where does it pay off?
- Procurement gets benchmarking: is this quote high for the region, and who else carries the item?
- Estimating gets faster line-item pricing — a median and a vendor count instead of a lone figure.
- Product teams get an API and MCP layer other tools and agents can query directly.
What is the compounding effect?
The long-term opportunity is a network effect in construction cost intelligence. Every new source improves coverage. Every mapped SKU improves future matching, because the next ambiguous row has more neighbours to compare against. Every budget that gets built and corrected becomes feedback that sharpens the next estimate. A flat price list decays the moment you save it; a graph that keeps reconciling new evidence gets more useful over time.
Start building your own price graph
Every new source and mapped SKU strengthens the network — making future estimates faster, more accurate, and more defensible.
See how the construction price graph powers faster, more defensible estimates — try it with your own data today.
Ready to price with live market data?
Try the free estimator (no signup) or create an account for BC3 budgets, catalog, and agents.