BuildUP

• 

  Architecture

• 

Inspiration

Construction projects don't fail on the job site — they fail three weeks earlier, in a shipping container stuck at a port, or in a purchase order that quietly ordered 7 fewer steel beams than the drawings required. By the time anyone notices, it's already a schedule delay and a change order fight.

We kept coming back to one observation: every construction project generates a mountain of data — purchase orders, vendor emails, schedules, drawings, site photos — but almost none of it talks to each other. A project manager might know the drawings require 125 beams. Procurement might know only 118 were ordered. Nobody connects those two facts until the crew shows up short.

We didn't want to build another chatbot that answers "where's my steel?" after the fact. We wanted something that tells you before it becomes a problem — and then helps you fix it. That's BuildUP: an AI system that predicts delays, explains the cause, quantifies the downstream impact, and recommends (or drafts) the fix, with a human approving the final call.

What it does

BuildUP ingests the messy, disconnected inputs of a construction project — purchase orders, vendor emails, schedules, drawings, and site photos — and turns them into a single reasoning layer over the project: Cross-checks drawings against procurement to catch quantity mismatches (e.g. "Procurement is short by 7 beams") before they become site shortages. Predicts shipment delays using supplier performance, weather, and historical lead times, with a probability and expected delay, not just a static ETA. Traces cascading impact through a dependency graph, so a late HVAC shipment automatically shows you the delayed ceiling work, delayed painting, and the dollar cost of the resulting schedule slip. Reads site photos to compare what's actually been delivered and installed against what the schedule expects. Recommends mitigations — like switching suppliers — with the cost/benefit math done for you, and drafts the resulting purchase order for approval. Answers plain-language questions like "Which shipments threaten next week's schedule?" or "Why is Tower A delayed?" by reasoning over the connected project data, not just searching documents.

How we built it

The architecture is organized in layers, moving from raw data to autonomous action:

Data processing layer — OCR and document parsing for purchase orders and vendor emails, drawing/spec extraction, and vision models for site photos. Construction knowledge graph — instead of a flat vector store, we modeled the project as a graph of relationships: buildings → floors → materials → suppliers → purchase orders → shipments. This is what lets the system reason about dependencies rather than just retrieve similar text. Intelligence layer — a delay-prediction model (gradient-boosted trees) that combines supplier history, weather, and lead-time data, plus a retrieval-augmented generation layer grounded in project-specific documents. Multi-agent orchestration — rather than one monolithic assistant, we split responsibilities across specialized agents (procurement, logistics, scheduling, vision, cost) that each contribute findings, which an executive agent synthesizes into a single recommendation. Interface layer — a dashboard with a project risk heatmap, a natural-language chat interface, and an automation layer that drafts the next action (an email, a revised PO, an updated schedule) for human approval.

Challenges we ran into

Making the knowledge graph actually useful, not just impressive. It's easy to build a graph that looks good in a diagram and adds nothing in practice. We had to be disciplined about only modeling relationships the reasoning layer would actually query — dependencies, lead times, and ownership — rather than every entity we could think of. Turning predictions into trustworthy recommendations. A delay probability is only useful if a project manager can see why the model believes it. We spent real effort on explanations, not just numbers, so "82% probability of delay" comes with the supplier, weather, and historical factors that produced it. Keeping "agentic" from meaning "unaccountable." It was tempting to let the system auto-send emails and auto-approve POs. We deliberately drew the line at drafting the action and requiring human sign-off, which turned out to be as much a design challenge as a technical one. Reconciling messy, inconsistent source data. Vendor emails, PDFs, and schedules rarely agree on formatting, units, or naming conventions for the same material — a lot of the unglamorous work was normalization, not modeling.

What we learned

A knowledge graph earns its complexity the moment you need cascading impact analysis — vector search alone can't tell you that a late HVAC shipment delays painting three steps downstream. Multi-agent decomposition makes debugging and explaining the system easier — when the cost agent's number looks wrong, we know exactly where to look, and we can show the user which agent said what. The most valuable AI output in this domain isn't the answer — it's the reasoning trail behind the answer. Project managers don't just want to be told what to do; they want to see enough of the "why" to trust and override it if needed.

What's next for BuildUP

Expanding the delay-prediction model with real port congestion and customs data feeds. Adding a digital twin view so every material's lifecycle — ordered, fabricated, shipped, delivered, installed — is visible at a glance. Piloting the human-approval workflow with an actual project team to tune where automation should (and shouldn't) act on its own.

Built With

• knowledgegraph
• multi-agent
• rag
• time-series-forecasting
• vision-language-models