How to Build an AI Construction Project Knowledge Base

A construction project knowledge base is how you stop re-explaining your project to Claude every single chat. In a recent video I walked through the exact structure I use on every job: a project context folder, a CLAUDE.md routing file, and markdown mirrors of the drawings, contract and specs. This is for PMs, estimators and anyone running Claude or Cowork across a live project who wants faster, cheaper, more accurate answers instead of re-uploading PDFs.

Key takeaways

• A knowledge base is a folder structure plus a set of markdown mirrors, not a new piece of software. The 0. AI Context folder is what makes Claude fast and cheap to run on a project.
• Converting a document to markdown before Claude reads it cuts token use by roughly 10 to 20 times against reading the original PDF, based on my own testing.
• CLAUDE.md is the routing map, project.md is the summary, and per-document markdown files carry the detail. Claude reads each once and reuses it for every task after.
• Split your information into three buckets: project context (this job only), business context (shared across every job), and procedural context (how you do the work, built into your skills).
• Only static information belongs in the AI context folder. Live registers like RFIs and variations stay in the working folder and get read fresh each time.

What is an AI construction project knowledge base?

An AI construction project knowledge base is a structured folder of your project’s documents, converted into a format Claude can read cheaply and reuse across every chat, rather than re-uploading files or re-explaining the job from scratch each time you open a new conversation. As I put it in the video: “A construction project knowledge base is a way to set up your project and business information so AI always has access to it.”

Most of what a project manager actually does day to day is a data transformation exercise. You take unstructured information (what happened on site) and move it into a structured template (the daily diary, the RFI, the monthly report). Current AI models are more than capable of doing that transformation. What they need is the structure to store and categorise the information first, and that is the whole point of the knowledge base.

The folder structure itself is nothing exotic. It is the same SharePoint or Google Drive structure most of you already run: contract, drawings, specifications, subcontract documents, RFI register, variation register. What changes is one addition, a 0. AI Context folder that holds markdown mirrors of the documents everyone keeps asking about. This sits underneath the broader idea in Claude for construction: the knowledge base is the input side of that pattern, the skill and the template are the output side. It is also the foundation the rest of AI for construction workflows sits on, drawings, RFIs, procurement and controls all read from the same folder once it exists.

Why convert drawings, contracts and specs to markdown first?

Converting a document to markdown before Claude reads it cuts token use by roughly 10 to 20 times against reading the original file, because Claude is a text-in, text-out model. Every time it opens a PDF, a spreadsheet or an image, it has to convert that file to text first, and it pays that conversion cost again on every single chat unless you have already done it once and saved the result.

So instead of asking Claude to open the contract PDF every time someone asks about liquidated damages, you convert the contract to a markdown mirror once, store it in the AI context folder, and every future question reads the mirror. On the sample project I use for testing, asking a plain question against the markdown mirror ran on Haiku, the cheapest model, and answered faster than the same question against the raw PDF.

That gap is not a rounding error. On a related video I go through the same principle for whole knowledge bases: spend roughly 30 minutes setting up the project knowledge base at the start of a job, and most of the criticism I hear about AI in construction (I’d put it at around 90% of it) traces back to poor context and poor instruction, not the model itself.

Drawings need their own pass and behave differently to contracts and specs, because they are visual documents, not narrative text. AI for reading construction drawings covers that version of the problem in more depth. In this workflow, a drawing analyzer skill splits the set into individual sheets and writes a text and database representation of what’s on each one, so a question like “what is the depth of this slab” reads one line item instead of a 15 megabyte PDF.

How do you set up the CLAUDE.md and project.md files?

You set this up once per project, at the start, using two workflows: a project indexer that writes your CLAUDE.md and project.md, and a drawing analyzer pass for the drawing set. After that, Claude reads the routing file automatically every time you open a chat in that project folder, so nobody has to paste context in or out again.

Here’s the sequence I run on every new job:

1. Open Cowork, Claude Code or a similar agent inside the project folder, so it can read and write there directly instead of files being uploaded one at a time.
2. Run a project indexer workflow. It writes the 0. AI Context folder, a CLAUDE.md routing file, and a project.md summary of the job.
3. Run a drawing analyzer pass over the drawing set. It splits the set into individual sheets and writes a markdown and database representation of each one.
4. Claude reads CLAUDE.md at the start of every prompt in that project. That file points to project.md, which points to the next layer down (a specification index, a drawing register), so only the relevant piece loads instead of one enormous file.
5. Re-run the indexer whenever a key document changes, or on a schedule, so the mirrors stay current rather than quietly going stale.

The project indexer and drawing analyzer skills, along with the rest of the library, are part of what members build out and customise inside the ContractorOS community if you’d rather start from a built version than write your own from scratch.

What’s the difference between project, business and procedural context?

Project context is information specific to one job, business context is information shared across every job, and procedural context is how you actually do the work. Keeping these three separate is what stops the knowledge base turning into one unmanageable pile of documents.

Context type	What it holds	Example
Project context	Specific to this one job	Contract, drawings, scope of works, RFI and variation registers
Business context	Shared across every job	Historic cost library, subcontractor directory, standard contract positions, lessons learned
Procedural context	How you do the work	The skill itself, with electrical, mechanical and civil examples nested inside it

Project context mostly lives in the project folder Claude has direct access to. Business context usually lives outside that folder, in a tool like Airtable or Supabase, so you connect it with an MCP connector rather than a markdown mirror, because it is shared across jobs and updated independently of any one project. Procedural context lives inside the skill itself. If you’re running a procurement packaging skill, the electrical and mechanical examples sit nested inside that skill’s own instructions, not loaded into every chat, because a skill only pulls in what it needs when it’s actually called.

Why does a smaller context window actually work better?

Context rot is the drop in accuracy that happens when a model is handed more information than it needs in one go, even if the raw context window has room to spare. A model like Opus 4.8 advertises a context window in the hundreds of thousands to a million tokens, but that number describes the ceiling, not the sweet spot.

The same model answers noticeably better with 50,000 tokens of tightly relevant context than it does once you fill the window toward 200,000 tokens of loosely relevant documents. Part of that is a “lost in the middle” problem, where information buried in the centre of a long context gets missed even though it was technically provided. I’ve seen this on long, complicated jobs myself: once a chat’s context climbs up toward 200,000 tokens, the quality of the answers visibly starts to degrade, even though the window still has room left on paper.

That’s the real argument for the layered CLAUDE.md to project.md to index structure, rather than one giant file with everything in it. You’re not just saving tokens for the sake of a smaller bill. You’re keeping the model working inside the range where it’s actually accurate, and letting it progressively load only the layer a given question needs.

Common mistakes to watch for

• Putting live registers in the AI context folder. RFI, variation and correspondence registers change constantly. Only static, unchanging information belongs in the markdown mirrors; anything still being edited should be read fresh from the working folder each time.
• Treating structured data like narrative text. A cost library or a supplier list belongs in a proper database (Airtable, Supabase, even a well-structured spreadsheet), not a markdown mirror written for prose documents like specs and contracts.
• Leaning on an MCP connector for lookups you run constantly. MCP calls are slower and burn more tokens than reading a local file. For a task you repeat often, wrap it in a sub-agent with a direct API call instead.
• Assuming a bigger context window means you can skip the structure. Context rot is real. A model handed 200,000 tokens of unsorted documents performs worse than the same model reading a five-line CLAUDE.md that points it to the one file it actually needs.
• Never refreshing the index. A knowledge base that’s months stale is worse than no knowledge base, because Claude will answer confidently from an out-of-date file rather than telling you it doesn’t know.
• Building it once and never feeding it back. Run the indexer at the start of a project, and run something similar at the end, capturing actual costs, lessons learned and the variations you hit per trade, so the next project’s business context starts ahead of where this one did.

Watch the full video above for the walkthrough, including the Cowork setup and the project indexer running live on a sample project.