SupplyBrain

Inspiration

Construction is one of the largest industries in the world — and one of the least digitized. A project manager tracking dozens of active material orders has no single source of truth. Purchase orders live in one system, vendor emails in an inbox, shipping updates in another spreadsheet. Nobody can answer "what's at risk right now" without manually cross-referencing five disconnected systems — and by the time a delay is discovered, it's already cascaded into a missed schedule and a blown budget.

We asked: what if a construction project's supply chain had an actual brain — something that reads every document, tracks every material's real status, predicts delays before they happen, and takes the first step toward fixing them automatically?

What it does

SupplyBrain is an AI-powered cognition layer for construction material logistics, built around four pillars:

Document Intelligence — ingests real construction documents (POs, invoices, shipping updates, delay notification emails), extracts structured data via LLM, and embeds full document text for semantic search.
Unified Material Timeline — every material item is tracked through its full lifecycle (Ordered → Approved → Fabricating → Shipped → Delivered), queryable in plain English: "where is the rebar for Site 3?"
Delay Forecasting — a trained Gradient Boosting Regressor scores every material item's delay risk using vendor reliability, category, and days remaining until the required-on-job date. On our live seeded data, it correctly flagged a real at-risk shipment at a 99.9% risk score with a 21.5-day predicted delay — driven by the vendor's 65% historical on-time rate and a tight delivery window.
Agentic Escalation — this is what separates SupplyBrain from a dashboard. When risk crosses a threshold, the system automatically drafts a vendor follow-up email referencing the exact PO number, and a PM escalation summary explaining the business impact — ready for one-click approval, not just a red flag.

How we built it

Backend: Python + FastAPI, with a modular services/routers architecture
Database: Neon serverless Postgres with the pgvector extension for embedding storage and semantic similarity search
AI: Google Gemini (gemini-3.1-flash-lite for reasoning, structured extraction, and RAG chat; gemini-embedding-001 for document embeddings)
ML: scikit-learn Gradient Boosting model, trained on synthetic historical delay data modeling vendor reliability, category, and timeline pressure
Frontend: React + TypeScript, designed with Google Stitch and built with Google AI Studio, calling our backend via a documented REST API
Deployment: Backend live on Render, connected to Neon Postgres in production, with environment-based configuration for local vs. live parity

We seeded the system with realistic data across three construction projects (a downtown office tower, an industrial warehouse, and a luxury apartment complex), six vendors, and a dozen real material orders — then verified every layer end-to-end against the live deployed backend, not just locally.

Challenges we ran into

Provider migration under time pressure: we started on OpenAI for embeddings and chat, hit an API quota wall mid-build, and migrated the entire LLM/embedding layer to Google Gemini — including handling a dimensionality mismatch between OpenAI's and Gemini's embedding models to keep our pgvector schema intact without a risky last-minute migration.
Serverless Postgres quirks: Neon's connection pooler required disabling asyncpg's prepared-statement caching to avoid intermittent query failures — the kind of bug that passes on the first few calls and fails unpredictably afterward if left unfixed.
Deployment platform pivot: we moved from Google Cloud Run to Render mid-build due to billing constraints, which meant re-verifying every endpoint against a new live URL and discovering that database re-seeds regenerate all record IDs — a real lesson in why we always test against the live deployment, not just local success.
A raw SQL parameter-binding bug in our semantic search query silently broke our RAG chat endpoint in production while working fine locally — caught only by reading the actual server logs and tracing the exact SQL error, not by trusting a passing local test suite.

Accomplishments that we're proud of

A fully working, live, end-to-end system — not a mockup. Every layer (document ingestion, risk prediction, agentic drafting, semantic chat) is verified against real deployed infrastructure with real generated data, including genuinely varied ML risk scores and LLM-drafted vendor communications that read like something a human procurement analyst would actually send.

What we learned

That the gap between "looks like it works" and "actually works in production" is enormous — and closing it (fixing silent fallbacks, verifying against live URLs instead of localhost, reading actual server logs instead of guessing) mattered more to the final quality of this project than any single feature we built.

What's next for SupplyBrain

Live document ingestion pipeline (pull directly from vendor email inboxes and procurement systems instead of manual upload)
Expanded agentic actions: automatic substitute-vendor sourcing, calendar/scheduling integration for PM alerts
Integration path into Kaya AI's Amber agent ecosystem for shared project context across supply chain, procurement, and last-mile delivery