Case study / 23 Jun 2026

How I would build a knowledge base for a construction firm

I have not run a construction firm. I keep coming back to the industry because it has a knowledge problem so well known it has a name. Every project relearns what the last one already knew. Here is how I would approach it, using the method I set out for a company and have now sketched for freight and energy field service.

Construction might be the clearest case of all, because the knowledge is not just scattered. It is actively destroyed at the end of every job.

The knowledge dies at handover

A construction project generates an enormous amount of hard-won knowledge, and then the team disbands and most of it evaporates.

The detail that leaked, and the one that finally worked.
The subcontractor who was excellent and the one who blew the programme.
The clash that should have been caught in design and was found on site.
The question that came up, the answer that was given, and whether it was right.
The estimate that was wrong, and by how much, and why.

This is the lessons-learned problem, and the industry has tried to solve it with closeout reports nobody reads for years. So the next project, often with half the same people, makes a version of the same mistake. The knowledge existed. It just was not in a form anyone could reach when it mattered.

The raw pile

The material is voluminous and, for once, mostly already digital. The trouble is that it is organised by project, so knowledge cannot travel from one job to the next.

Drawings and the revisions between them.
The RFI log. Every question asked of the design team and the answer given.
Change orders and variations, with the reasons behind them.
Site diaries, progress photos and inspection records.
Subcontractor records. Who did what, on time or not, to what standard.
Closeout and as-built documents, where the gap between designed and built is recorded.

The first move is to stop treating each project as a sealed box, and pull the knowledge out of all of them into one pile a model can read across.

What the model compiles from it

Have a model compile that pile across projects, and you get a wiki organised by knowledge rather than by job.

An article per detail or system. How this waterproofing junction has been built across projects, and which versions leaked.
An article per subcontractor. Their record across every job, not just the one a project manager happens to remember.
An article per recurring problem. The clash, the sequencing mistake, the long-lead item that always slips.
A lessons layer. What each project learned, written so the next project can read it before it starts, linked to the drawings and RFIs that prove it.

The thing being built here is institutional memory. Right now a construction firm's memory is its longest-serving people, and it walks out the gate when they retire. Compiled, it becomes something the firm owns.

The questions it can suddenly answer

With the wiki compiled across projects, the firm can ask the questions that institutional memory was supposed to answer and never quite did.

"How have we detailed this junction before, and did any version fail."
"What is this subcontractor's actual record across our last ten jobs."
"What usually goes wrong on a project of this type, and where did the last one slip."
"We are about to make this call. Have we made it before, and how did it turn out."

The linting pass has a specific job here too. A model reading across projects can flag where the as-built diverged from the specification, where an RFI was raised and never resolved, and where the same defect appears on more than one job. Those are exactly the patterns a firm needs to see and almost never assembles by hand.

What stays human

A wiki like this informs the decision. It does not make it. The judgement that matters on a site stays with the people who carry the risk.

The model surfaces how the detail failed last time. The engineer still decides how to build it this time.
The model shows the subcontractor's record. A person still chooses who to engage, and why.
The model drafts the answer to an RFI from precedent. The designer still owns the response that goes out.

The grind of remembering moves to the machine. The accountability stays exactly where it has to, with the people who sign the drawings and stand on the site.

Prompt you can use

I run a construction firm and our hard-won knowledge dies at the end of each project, so every new job relearns what the last one knew. Help me plan a knowledge base a model can compile and maintain across projects.

Work through it one step at a time:
1. Ask me what records we hold per project: drawings and revisions, RFI logs, change orders, site diaries and photos, inspection records, subcontractor records, closeout and as-builts.
2. Propose how to organise a wiki that cuts across projects: per detail or system, per subcontractor, per recurring problem, plus a lessons-learned layer.
3. For one detail I name, show me what its article would contain and which projects and documents it would draw on.
4. List the questions this base should answer before we start a new job or make a repeat decision.
5. Tell me which calls must stay with the engineer or site manager, and where a wrong automated answer would be expensive or unsafe.

Start by asking me what we build and where each project's knowledge ends up today.

The rule

A construction firm's memory should not be the same thing as its longest-serving employees. Right now it usually is, and it leaves when they do.

Pull the knowledge out of every project into one pile. Let a model compile it into the details, trades and lessons that should outlive any single job. Keep every site decision with the people who carry the risk. Stop paying for the same mistake twice.