ConstructionIQ

Logo
Home Page
Negotiation
Risk Management

Inspiration

A 900-page tender document arrives. A procurement engineer spends three days reading clauses, calling vendors, and comparing quotes on a spreadsheet — hoping they didn't miss a certification requirement on page 647.

Generic AI chat tools have no persistent project memory. Enterprise platforms like Kaya AI's Amber are built for large contractors with full procurement teams. The gap we saw: no tool takes a single project's documents and runs the complete procurement decision loop from first read to signed purchase order. ConstructIQ is built to close that gap.

What it does

ConstructIQ is a 10-stage AI procurement intelligence system for construction projects. Upload your documents once; the system runs the full loop on demand:

Ingest → Extract → Discover → Evaluate → Comply → Risk → Recommend → Negotiate → Purchase Order → Track

Key behaviours:

Catches that Fe500 steel ≠ Fe500D steel (different IS 1786 grades) and flags it with a plain-English explanation — not a silent mismatch
Scores delay risk as $$S = 0.5 \cdot P_{lead} + 0.35 \cdot (1-R_{vendor}) + 0.15 \cdot D_{order}$$ — a formula you can read and verify, not a black-box prediction
Runs a multi-round Buyer ↔ Vendor negotiation where concessions are computed by $$P_{new} = P_{prev} - \delta \cdot f_{flex}$$ not improvised by the LLM
Generates a signed PO PDF on human approval and tracks delivery status through a forward-only state machine

Core design principle: every AI judgment is a transparent, inspectable calculation the LLM explains in plain English — never an unexplained opinion.

How we built it

                       Streamlit Dashboard
                                │ HTTP
                         FastAPI Backend
                    ┌───────────|──────────────────┐
               ChromaDB       SQLite        Claude Agent SDK
              (vectors)   (structured)   (8 procurement tools)
                                    │
           Document pipeline (PyMuPDF + pdfplumber + python-docx)

PDF parsing: PyMuPDF for body text, pdfplumber for BOQ tables — both are needed because one library mangles what the other handles well
Embeddings: sentence-transformers running locally (all-MiniLM-L6-v2) so the demo works fully offline — no API call to fail in front of judges
RAG: ChromaDB filtered by project_id; every retrieval returns a confidence score so low-quality matches are flagged, not silently trusted
Agent: 8 Claude tools chained autonomously; tool-call log is screen-shareable during Q&A to show the full reasoning chain
Negotiation: prices computed in Python, LLM only writes the message — the model narrates a calculation, it never freelances a number

Stack: Python 3.11 · FastAPI · SQLite · ChromaDB · Anthropic SDK · Tavily · ReportLab · Streamlit · Docker

Challenges we ran into

Scope under ambition. A 6-stage MVP became 10 stages, 5 document sources, a negotiation engine, and a tracking state machine within two days of planning. We maintained a hard CORE vs DEFERRED boundary in writing and re-read it before adding anything. Daily standup rule: "I started on a deferred item" is a blocker, not a status update.

Credible negotiation. Two free-roaming LLM personas agreed too quickly and couldn't survive a judge asking "is the vendor just saying yes to look good?" We removed the model from price calculation entirely — the Vendor agent's concession is a formula, the LLM only writes the in-character sentence around the result.

Table extraction. Construction tenders mix body text with Bill-of-Quantities tables. PyMuPDF alone garbles them; pdfplumber is slower but table-aware. Solution: PyMuPDF for text, pdfplumber targeted only at detected table pages. Tables serialised as Markdown strings so the LLM reads structure correctly.

Accomplishments that we're proud of

Every score is auditable — open the source, trace any output in under a minute
The compliance gap detection is domain-aware, not just keyword matching
The full 10-stage loop closes end-to-end: tender PDF in, PO PDF out
Demo runs fully offline — rehearsed once with wifi disabled to confirm

What we learned

RAG quality lives in the chunking strategy and chunk metadata, not the LLM
In agentic systems, let the LLM narrate computations — never compute inside the prompt
Scope discipline is a technical skill that requires the same deliberateness as writing code
Synthetic demo data is fine; disclosing it honestly is what makes it credible

What's next for ConstructIQ

Multi-source ingestion: WhatsApp export, bulk email, drawing descriptions via vision
Knowledge graph: connect Project → Material → Vendor → Region for multi-hop queries ("which projects are exposed if Vendor X fails?")
Portfolio view: cross-project risk dashboard for procurement directors
Real vendor data: GeM and CPWD e-procurement portal integrations

The risk weights {0.5, 0.35, 0.15} are a calibrated starting point. The production model trains on real delay outcomes:

$$\hat{S} = \mathbf{w}^{\top}\phi(\mathbf{x}), \quad \mathbf{w} = \arg\min_{\mathbf{w}} \sum_{i} \mathcal{L}(S_i, \hat{S}_i)$$

That dataset doesn't exist at hackathon scale — but it accumulates naturally once the product is in production use.