Inspiration

We didn't start with construction. We started with a question: where in the physical economy is an enormous amount of money being lost to problems that math could actually solve? We kept circling back to construction — one of the largest industries on earth and one of the least digitized, where an estimated three‑quarters of the infrastructure the world will need by 2050 hasn't been built yet.

Then we found the number that wouldn't let us go. A power transformer — the kind every data center, hospital, and factory depends on — now takes around 128 weeks to arrive. More than half of the data centers planned in the US for 2026 are expected to slip or be cancelled for lack of electrical gear, and a single day of delay on a large build can burn on the order of \$237,000.

And yet, when we looked at how the industry actually tracks these make‑or‑break deliveries, it came down to one ritual we saw everywhere: a site manager on the phone asking a vendor "where's my switchgear?", hanging up, and writing a single date on a schedule — a date everyone already knows is fiction. The world's most expensive projects are run on a phone call and a guess.

That was the spark. Every tool on the market answers "what's the status?" Nobody could answer the two questions that actually change a decision: what is the probability this arrives on time, and what does it cost us if it doesn't? We set out to build exactly that, and we called it Foresite.

What it does

Foresite reads the messy documents a project actually runs on, turns each critical material's delivery into a full probability distribution instead of a single promised date, maps that risk onto the schedule's critical path, and tells the team — in days and in rupees — the cheapest way to buy the schedule back.

How we built it

Foresite is a three‑layer engine.

  • Ingest — an LLM reads purchase orders, submittals, fabricator schedules and vendor emails into a living material graph, attaching a confidence score to every field it extracts.
  • Predict — a competing‑risks survival model produces an arrival distribution for each material, and those distributions propagate through the project's CPM schedule via Monte Carlo simulation.
  • Act — an agent proposes interventions from a constrained, real‑world library, picks the one with the best expected value, and drafts the vendor email for a human to approve.

We model arrival with survival analysis, where the survival function

$$S(t) = P(T > t)$$

gives the probability a material still hasn't arrived by time $t$, so the probability it makes its Required‑On‑Job date is simply

$$P\big(T \le t_{\text{ROJ}}\big) = 1 - S\big(t_{\text{ROJ}}\big).$$

The agent then recommends the action $a^{\star}$ that maximizes expected value:

$$a^{\star} = \arg\max_{a}\;\Big(\;\mathbb{E}\big[\text{delay cost avoided}\mid a\big] \;-\; \text{cost}(a)\;\Big).$$

Because we had no proprietary industry dataset, we built our own discrete‑event simulator of the vendor → fabrication → factory‑acceptance‑test → shipping → site pipeline, encoding documented delay archetypes and calibrating it to published lead‑time benchmarks — then trained and, crucially, validated the model's calibration on held‑out runs. Running beneath all three layers is an integrity layer: a linguistic hedging classifier that catches vendors softening bad news ("targeting end of month…"), and a vision model that, at the delivery gate, reads the equipment's nameplate and reconciles the physical unit against the order — catching wrong parts and substitution before they ever reach installation.

Challenges we ran into

The first was intellectual honesty. If you generate synthetic data and then "predict" it, you're only recovering your own assumptions. We attacked this by grounding the simulator in cited real‑world benchmarks and by judging ourselves on calibration on held‑out data, not on fitting our own noise — turning our biggest vulnerability into the result we're proudest of.

The second was harder to admit: our first instinct was to build a better tracker — which is exactly what everyone, including very good companies, already builds. We had to throw that away, find the real wedge (probability + cost of failure + the decision), and be disciplined enough to position Foresite as something that extends the tools teams already trust rather than competing with them.

The third was scope. Two of us, a few weeks. It was tempting to simulate a whole project shallowly; instead we chose one high‑stakes electrical‑room sub‑network and did it with genuine mathematical rigor. Depth over breadth.

The last was the quiet one: building something that survives expert scrutiny. The people who understand this problem best would be reading our work, so every number had to be defensible and every recommended action had to be something a real procurement team could execute this week. That constraint made the product sharper.

Accomplishments that we're proud of

  • We turned our biggest weakness into our strongest result: instead of hiding that we train on synthetic data, we hold ourselves to a calibration standard — a reliability curve on held‑out runs — so that when Foresite says "63%," it means 63%.
  • We found the one idea that separates a dashboard from a decision tool — float — and built the critical‑path cascade that turns a raw probability into an answer measured in days and rupees.
  • As a two‑person team, we designed a genuinely probabilistic engine end to end — document intelligence, a survival model, a Monte‑Carlo schedule cascade, and an agent that prices and drafts the fix — instead of wrapping a chatbot around a prompt.
  • We gave the system a conscience: an integrity layer that treats vendors and documents as adversarial, catching hedged language and physical substitution — a dimension we haven't seen anyone else attempt.
  • And we're proud that we resisted the easy version: we scoped tightly, stayed honest about what we could prove, and positioned Foresite to extend the industry's best tools rather than pretend to replace them.

What we learned

The most important thing we learned is that a date is a lie, and a distribution is the truth. Real delays aren't gentle bell curves — a failed factory test is a discrete three‑to‑six‑week jump, a re‑submittal loop adds weeks, a congested port adds a long tail. The right forecast is multimodal, and admitting that changed everything.

We learned the lesson that turned our idea from a dashboard into a decision tool: float. A transformer that's 12 days late might cost the project only 4 days if it has slack, while a 5‑day slip on the critical path costs all 5. Knowing which is which is the entire game — so we push each distribution through the schedule to get the number executives actually care about, $P(\text{energization on time})$, and the marginal cost of every at‑risk item.

And we learned something less technical but just as important: in the field, an AI that is always confident is worse than one that knows when it doesn't know. Trust is the product. Calibration matters more than any headline accuracy claim.

What's next for Foresite

  • Real data. The architecture is built to retrain directly on a contractor's own project history; our immediate next step is a pilot on a live project's document set, replacing our simulator's priors with ground truth.
  • From one room to the whole portfolio. The same engine scales from a single electrical room to every long‑lead material on every job, and then to a cross‑project view for owners running many sites at once — each new project sharpening every future forecast in a data flywheel.
  • Live integrations. Primavera P6, Procore, and ERP connectors, so Foresite reads schedules and POs where they already live instead of from uploaded files.
  • Closing the loop at the source. A vendor‑side portal so fabricators post milestones directly, and hands‑free receiving on Meta smart glasses so a gate crew can reconcile a delivery without ever putting down their tools — our bridge to physical AI on the jobsite.
  • Earlier and deeper. Bid‑time risk pricing — using accumulated distributions to quantify schedule risk before a PO is ever cut — and richer modeling of correlated, systemic shocks like a port strike or tariff that hits many materials at once.

The north star stays the same: replace the guess with a distribution, and the phone call with a decision — for every project where a late part means disaster.

Built With

Share this project:

Updates

Submission history