Knowledge Hub — Bollinger Grohmann

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, drawings, and specifications, scattered across offices and file systems. Three previous attempts at internal knowledge systems had stalled, each between 6 and 18 months in. Pattern: tooling shipped, adoption never crossed 15%.

The real problem wasn't "we need a chatbot." It was that nobody could find the document they already knew existed.

The constraint that shaped everything: nothing leaves

The main requirement was not a feature. It was a boundary: GDPR compliance and full data sovereignty. Thirty years of structural engineering IP (client projects, calculations, specifications) could not leave infrastructure the firm controlled. No sending the corpus to a SaaS search vendor. No shipping documents to third-party AI APIs. Everything on the firm's own servers, full stop.

That constraint eliminated the entire buy-vs-build shortcut. The off-the-shelf enterprise search products all assume your documents can live in their cloud. They couldn't. So the system was custom-built from the ground up. Ingestion, search, and UI, running entirely within the firm's own environment.

For any firm whose documents are the business (engineering, legal, advisory), this is the requirement that disqualifies most of the market. It is also entirely buildable. This system is the proof.

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 and built the platform end to end (the document-ingestion pipeline, the semantic search layer built on Elastic ELSER, and the React UI), deployed across 19 global offices, achieving 62% firm-wide adoption.

What I built

An enterprise document-intelligence and semantic search platform. Three moving parts:

1. Ingestion. Automated processing of project archives, technical drawings, specifications, and reports across nine countries. OCR (Tesseract / unstructured) for scanned and image-based documents, ML-based layout parsing, language detection, and structured metadata and standards extraction (DIN codes, project taxonomy, document type).
2. Search. Semantic search over the processed corpus using Elastic ELSER, layered with faceted and lexical filtering. Backed by Elasticsearch and Azure Cognitive Search, with MongoDB for document metadata. Tuned against an internal evaluation set of reference queries.
3. UI. A React interface embedded where the work already happened, with click-through to the source document. No separate destination to remember. Find the thing, open the thing.

Stack: Python, Node, Elasticsearch, Elastic ELSER, Azure Cognitive Search, MongoDB, Azure, React. Auth through the firm's existing SSO. Deployed via CI to Azure App Service. Solo build. I architected, built, and shipped it.

Every layer runs on infrastructure the firm controls. No document, embedding, or query leaves their environment. The GDPR requirement wasn't bolted on, it was the architecture's first input.

The deliberate non-decision: no generated answers

The obvious "v2" was a generative answer layer: ask a question in natural language, get a written answer. I scoped it and chose not to ship it.

In a structural engineering firm, a confidently-worded but wrong answer about a load case or a code clause is a liability, not a convenience. The cost of a hallucinated structural recommendation outweighs the convenience of a typed answer. So the shipped system retrieves and surfaces the source. It points you at the authoritative document and lets the engineer read it, rather than synthesising an answer that has to be second-guessed.

That was a product judgment, not a technical limitation. Generation was the planned next phase, gated behind the trust the search layer had to earn first.

The data-sovereignty boundary reinforced the same call: a generative layer either runs a model inside the firm's environment or sends content to an external API. The second was off the table by requirement. Retrieval-first was both the safer product and the compliant one.

What was actually hard

Not the search. The ingestion.

Thirty years of documents in multiple languages, half of them scanned PDFs and drawings with no extractable text, inconsistent naming, and domain-specific structure (a structural spec is not a contract is not a calculation sheet). Getting clean, searchable, correctly-tagged content out of that mess, across nine countries, was the bulk of the engineering. Search quality is a function of ingestion quality. The retrieval layer is only as good as what you feed it.

The second hard part was adoption, which is a design problem, not a deployment problem. Three prior attempts had died at 15%. The thing that worked: embedding search where people already were, ruthless attention to result relevance, and onboarding built around how engineers actually look for things.

Why the three previous attempts failed (and this one didn't)

Worth being specific, because this pattern repeats in every firm I talk to:

1. They started with the interface, not the corpus. A wiki or a chatbot is an interface decision. If the underlying documents are unfindable, mis-tagged, or unreadable by the system, the interface doesn't matter. All three prior attempts inherited the mess instead of fixing it.
2. They asked people to change where they work. A separate portal, a separate login, a separate habit. Engineers under deadline do not build new habits for marginal benefit. The Hub went where the work already was.
3. They shipped once and stopped. Relevance tuning is not a launch task, it is an operating rhythm. The Hub was tuned continuously against an internal evaluation set of real reference queries. When engineers searched and failed, that failure became next week's tuning input.

None of this is exotic. It is product discipline applied to an internal tool. Which is precisely what internal tools almost never get.

Numbers

What the team can now do without me

The internal platform team owns the system. They can:

• Add new document sources via a documented ingestion contract
• Re-run extraction and re-index as the corpus grows
• Tune semantic relevance and facets per document type
• Ship new UI surfaces against the same search API
• Build the generative answer layer on top, when the firm decides the trust is there

A Confluence space documents every architectural decision and the runbook for the next failure mode.

What I'd do differently

Invest in ingestion quality even earlier. Every hour spent on clean extraction and accurate metadata paid for itself ten times over in search relevance. The instinct is to rush to the search box. The leverage is upstream.

(I dig into the adoption side of this in my essay: Why AI Pilots in AEC Die in Month Two).

Stack: Python · Node · Elasticsearch · Elastic ELSER · Azure Cognitive Search · MongoDB · Azure · React. Engagement type: embedded full-stack lead, solo build. Duration: ~3 years across two phases.

Related: the adoption playbook here was learned the hard way at Hayball, building a design technology function inside a 200-person Australian practice.

(Need a system like this for your firm? Start with a Pilot: a working slice on one workflow, in production, in 4–6 weeks.)