PlanB

PlanB
Working Example
Worked Example
The Problem
The Gap
The Solution

Inspiration

We started by reading what the Government of India's own project monitor says about construction. The numbers stopped us cold: as of MoSPI's March 2024 flash report, 779 of 1,873 monitored central-sector projects were officially delayed, with an average slippage of ~3 years and ₹5.55 lakh crore in cumulative cost overruns. Behind almost every one sits the same unglamorous failure — a material that didn't arrive when the schedule assumed it would.

Then we noticed something strange. The entire industry, including its best platforms, is racing to detect delays — trackers, dashboards, lead-time engines. Kaya itself has proven detection works (90% lead-time accuracy). But the moment a dashboard turns red, the software stops. Four people assemble a war room, dig through POs and schedules, ring vendors, and rebuild the plan by hand — for 3–5 days, per incident, hundreds of times per project.

Every AI in construction tells you you're late. Nobody has built the AI that gets you back on schedule. That's PlanB.

What it does

When a delay signal arrives (vendor email, fab update, shipping ping), PlanB runs five stages:

Signal — document intelligence parses the delay out of unstructured comms
Triage — maps the PO line → BOQ item → CPM schedule activity, computes float, and answers the question nobody automates: does this delay even matter? The exposure is simply

$$ \text{Exposure} = \max(0,\ d_{delay} - f_{float}) \times C_{day} $$

Generate — costed options across the only three levers a project has: expedite (split shipments, alternate freight), substitute (RAG over the project's own specs + vendor catalogues finds a code-compliant equivalent and auto-drafts the substitution RFI with a compliance matrix), and re-sequence (consume float elsewhere so crews stay productive)
Decide — a human picks from a Pareto menu ("₹4.2 lakh, saves 15 days, needs engineer approval")
Execute — agents email the vendor, file the RFI, place a voice call to the supplier's dispatch desk to lock the revised slot, and write the change back to the schedule

In our worked scenario — a 21-day switchgear slip on a 40 MW data centre — PlanB cuts a ₹3.4 crore exposure to under ₹0.3 crore in one afternoon.

How we built it (Stage 1) and what we learned

We spent this stage doing the unglamorous groundwork: studying MoSPI datasets, reading how expediting and substitution actually happen on Indian sites, and pressure-testing why this layer doesn't exist. The answer taught us the core insight — POs, BOQs and schedules live in different systems with no shared IDs, so the PO↔schedule mapping was never automatable until LLMs. That mapping is our quiet superpower.

Challenges

The hard problems ahead are honest ones: reliable line-item matching across messy real documents, keeping substitution suggestions strictly code-compliant (the RFI always routes to a human engineer), and making the voice agent robust. Our design principle throughout: PlanB proposes and executes; people approve. Nothing that commits money or scope moves without a named human's sign-off.

What's next

Stage 2: one delay scenario, end-to-end and real, real PO PDF, real exported schedule, live voice call, automated write-back. Narrow, deep, and demonstrably not a chatbot wrapper.