About the Project

SiteSage AI is a construction procurement intelligence copilot for project managers. It helps teams identify material delays, vendor reliability risks, purchase order follow-ups, and schedule-impacting bottlenecks from uploaded procurement documents and structured project data.

The idea is simple: construction delays often begin in procurement, but the warning signs are scattered across purchase orders, contracts, spreadsheets, and vendor communication. SiteSage AI brings those signals into one local dashboard so teams can ask questions, get cited answers, and act early.

Inspiration

We built SiteSage AI because procurement problems are often visible long before they become site delays, but only if someone can connect the dots. In real construction workflows, a project manager may have to search across dozens of documents to answer questions like:

  • Which deliveries are at risk this month?
  • Which vendors are high risk?
  • What purchase orders need follow-up?
  • What materials may affect the project schedule?

We wanted to create a copilot that feels useful to an actual construction team, not just a generic chatbot. That is why the project focuses on procurement-specific language such as PO numbers, ROJ dates, critical materials, project phase, and vendor reliability.

What We Learned

This project taught us how to combine retrieval, machine learning, and business rules into a single practical workflow.

We learned that:

  • Good AI demos are usually about workflow, not just model quality.
  • Cited answers build trust much faster than uncited responses.
  • Even a lightweight local model can be useful when the app is grounded in project documents.
  • Small, interpretable risk signals are often more useful than a black-box score.
  • Domain-specific UX matters. A construction procurement dashboard feels very different from a general-purpose chatbot.

We also learned how to design for failure. If the local LLM is unavailable, the app still returns grounded, cited extractive answers from uploaded documents.

How We Built It

We built SiteSage AI as a local-first Streamlit application with a Python backend.

1. Document ingestion and retrieval

Users can upload procurement documents such as PDFs, TXT files, CSVs, Markdown files, and Excel sheets. The app extracts text, chunks it, stores it in SQLite, and indexes it for search. Retrieved chunks are then attached to answers as citations.

2. RAG-based question answering

The assistant answers only when the uploaded documents contain relevant evidence. If the documents do not support the question, the app says it does not have enough information. This keeps the experience grounded and avoids unsupported guesses.

3. Delay risk prediction

We trained a lightweight scikit-learn model on synthetic procurement history to estimate delivery delay risk and expected delay days. In simplified form, the risk score behaves like:

$$ \text{Risk Score} = f(\text{criticality}, \text{lead time}, \text{on-time rate}, \text{communication score}, \text{quality issues}) $$

The model then estimates an expected ROJ date:

$$ \text{Expected ROJ Date} = \text{Promised Delivery Date} + \text{Expected Delay Days} $$

4. Vendor reliability scoring

We also score vendors using delivery performance, communication, and quality signals. This makes it easy to identify suppliers that need escalation before they affect the schedule.

5. Alerts and dashboard

Finally, the app turns risk into action. It generates alerts for delivery risk, vendor risk, follow-up actions, and schedule impact, and presents them in a clean Streamlit dashboard.

Challenges We Faced

The main challenge was keeping the prototype useful while staying lightweight enough to run locally on a hackathon laptop.

Some specific challenges were:

  • Making answers grounded in document evidence instead of generic text.
  • Designing a fallback when the local LLM is not available.
  • Choosing a retrieval approach that is fast, deterministic, and easy to demo.
  • Creating synthetic procurement data that still feels realistic enough for a construction use case.
  • Balancing technical depth with a dashboard that judges can understand quickly.

Another challenge was keeping the product focused. It would have been easy to build a generic document chatbot, but the stronger project is a procurement copilot with delay prediction, vendor scoring, and alerts.

Share this project:

Updates

Submission history