Setu | Devpost

Inspiration

We started by asking people who actually manage construction materials how they track them. The answer, over and over, was some version of: a spreadsheet, and then I call the vendor.

That's not a small gap. Construction is the second least-digitized major sector on earth (McKinsey). Large projects run 20% longer and up to 80% over budget. Roughly half of all purchase-order lines change after issuance and nobody finds out until the truck doesn't show up. Switchgear now averages 44-week lead times, and a two-week slip on a $50M project burns $50,000–$100,000 before anyone even looks up liquidated damages.

None of this is an information problem. The approval is sitting in a submittal PDF. The fabrication status is in someone's inbox. The need-by date is in the schedule. Every answer already exists , just scattered across a dozen formats owned by a dozen parties, and nobody has the hours to reconcile all of it, every day, on every package.

That's not a job for a chatbot. That's a job for a brain.

What it does

SETU answers the five questions every project team asks and nobody can answer today: what's approved, what's being fabricated, what's delayed, where is it now, and will it arrive when we need it.

It reads the submittal stamps, parses the vendor emails, chases the ones who don't reply, predicts each delivery date with an honest confidence level, and simulates how a late item ripples through the construction schedule.

The output isn't a chat reply. It's a risk-ranked list of every material, each one showing its likely arrival window, the delay it would cause in working days, the money at stake, and what to do about the traceable back to the exact page it came from.

How we built it

Reading. Throwing whole drawing sheets at a vision model failed immediately. So we rebuilt it as detect-then-read: classify each sheet, find the schedule tables and review stamps with small detectors, then let a fine-tuned model read only those cropped regions. Every extracted fact stores the page and box it came from. The research backed this — a Florence-2 fine-tuned on just 400 drawings beat GPT-4o and Claude at drawing extraction. Remembering. Every material becomes a node in a Neo4j graph [ a Material Passport ] linking its spec, submittals, vendor, PO, shipments, and the schedule activities that depend on it. Search is graph-constrained, so asking about AHU-3 can't return AHU-1's approval letter. Predicting. Most published delay models just classify late vs not late. That isn't actionable. We instead predict a delivery date range with a real confidence level "78% chance by March 14, 90% by March 27" using survival analysis, so purchase orders still in transit still teach the model something. Cascading. A late PO only matters through the work it blocks, so we simulate each arrival through the project schedule thousands of times. Output: "AHU-3 threatens Level-3 rough-in by 9 working days, 82% likely." Days and rupees , the only two languages an owner speaks. Acting. Agents email vendors, escalate to an automated phone call when ignored, match packing slips to POs, and rank recovery options. Everything consequential needs a human approval before it goes out.

Challenges we ran into

Our best result was a bug. The first delivery model looked fantastic. Then we realized we'd only trained on POs that had already arrived which are quietly dropping every one still in transit. Those are disproportionately the late ones. We'd built a model that learned materials arrive on time by deleting the evidence that they don't.

Our confidence numbers were wrong. The model claimed 90% confidence but was only right about 68% of the time. When your whole promise is "trust this number," that's fatal. Conformal prediction fixed it.

The vision model invented equipment. Reading full sheets produced clean, plausible, entirely fictional rows. A hallucinated AHU-4 isn't a cute bug — downstream, it becomes a purchase order.

Agents that lie politely. An early agent read a vendor's "we'll try to get back to you" and logged the part as finished. An agent that says "I don't know" is worth ten that guess.

Accomplishments that we're proud of

1)We resisted the chatbot. Every time wrapping a prompt would have been faster, we built the harder thing. 2)Delivery predictions that come with honest uncertainty instead of a fake-precise date. 3)Risk expressed in schedule days and rupees, not abstract scores. 4) A closed physical loop : most tools stop at the tracking portal; ours ends at the loading dock. 5) Every answer cites the document it came from, so nothing has to be taken on faith.

What we learned

Calibration beats accuracy. A well-calibrated 78% helps a project manager far more than a confident, precise, wrong date. Bad data hygiene flatters your metrics. Dropping "incomplete" records is the easiest way to build a model that lies to you. Small fine-tuned models beat frontier models on narrow visual tasks, at a fraction of the cost. The graph is the product. Models are replaceable; a structured record of every material is the durable asset. Domain knowledge was the real unlock. Knowing why a submittal gets stamped "Revise & Resubmit" mattered more than any architectural choice we made.

What's next for SETU

1) Real project data through Procore and Autodesk connectors , the architecture is deliberately source-agnostic. 2)Cold-start forecasts for new projects that borrow from every vendor SETU has seen before. 3)A vendor-facing portal, so status arrives before an agent has to ask. 4)Extending the simulation from schedule risk to cash-flow risk, where every day of delay carries interest.

The data exists. The delays are real. The industry is waiting. Ask us the five questions. SETU already knows the answers.