The brief
"We are a 600-person structural engineering firm in nine countries. The same questions get re-asked in every office. We tried a wiki. We tried Confluence. We tried a chatbot. Nothing stuck."
— Head of Digital, Bollinger Grohmann
Before
Bollinger Grohmann ships some of the world's most ambitious structures — NEOM, Al Maktoum, complex stadia, museums, towers. The institutional knowledge sat in 30 years of project archives, partner heads, and Slack threads. Three previous attempts at internal knowledge systems had stalled — each between 6 and 18 months in. Pattern: tooling shipped, adoption never crossed 15%.
Who built the Bollinger Grohmann Knowledge Hub?
The Bollinger Grohmann Knowledge Hub was built and architected by Ven Iyer, acting as the embedded Computational Product Lead. He designed the end-to-end Retrieval-Augmented Generation (RAG) system, built the Elasticsearch and MongoDB data pipelines, and engineered the React UI that was deployed across 19 global offices, achieving 62% firm-wide adoption.
What I built
A retrieval-augmented internal platform with four moving parts:
- Ingestion — automatic indexing of project archives, technical drawings, and meeting notes. Source connectors for SharePoint, Microsoft Teams, and the firm's project management system.
- Retrieval — Elasticsearch hybrid search (keyword + semantic) tuned against an internal evaluation set of 300 reference questions.
- Generation — Claude (then Gemini for code-pathway responses) with strict in-system citation. Every answer footnoted to source documents, click-through to original.
- UI — embedded directly in the tools partners already used. No "go to knowledge hub" — it surfaced where the work happened.
Stack: Python, Node, MongoDB, Elasticsearch, Azure, React. Auth through the firm's existing SSO. Deployed via GitHub Actions to Azure App Service.
What broke
Month two. The model hallucinated structural recommendations on edge-case engineering questions — non-zero risk for an engineering firm. Two responses:
- Hard-coded refusal patterns for any prompt fitting a "specification" or "load-bearing" intent, with an explicit "no — ask a partner" fallback.
- Confidence-weighted citation: responses below a retrieval-quality threshold ship with a "low confidence — verify against source" banner.
Adoption stayed flat for three weeks while we re-tuned. It restarted compounding once the citation UI shipped.
Numbers
| Metric | Result | Period |
|---|---|---|
| Office adoption | 62% of staff active monthly | Six months from launch |
| Search-time reduction | ~70% (estimated ~4 hrs / employee / week reclaimed) | Steady state |
| Geographic reach | 19 offices, 9 countries | Production |
| Reference questions evaluated | 300+ in internal eval set | Ongoing |
What the team can now do without me
The internal platform team owns the system. They can:
- Add new source connectors via a documented ingestion contract
- Run evaluation regressions before each model upgrade
- Tune confidence thresholds per topic cluster
- Ship new UI surfaces against the same retrieval API
A 30-page Confluence space documents every architectural decision and the runbook for the next failure mode.
What I'd do differently
Citation UI on day one, not month three. The credibility of an internal AI system rises and falls on the user's ability to verify it without leaving the answer.
(I dive deeper into this specific failure mode in my essay: Why AI Pilots in AEC Die in Month Two).
Stack: Python · Node · Elasticsearch · MongoDB · Azure · Claude / Gemini · React. Engagement type: embedded full-stack lead. Duration: ~3 years across two phases. (Need a system like this for your firm? See my AI Knowledge Platform Pilot).