Project knowledge piles up in many places: standards and guidelines, component libraries, script snippets, meeting notes, decisions from past mandates. Anyone running several projects in parallel as a one-person company knows the problem. The knowledge exists, but it is not at hand in the moment you need it.
I solved this with a persistent knowledge archive that I connected to a language model. In this article I describe the setup, the workflow and my honest assessment after several weeks of practice in infrastructure BIM.
The idea: a brain between me and every source
The model is the LLM wiki pattern by Andrej Karpathy. The core idea: instead of handing a model fresh documents for every question, you maintain a curated archive of markdown files. This archive is the shared knowledge base. The model reads from it, writes syntheses back, and keeps the archive current together with you.
I call this archive my brain. Technically it is an Obsidian vault, a folder of linked markdown files. Obsidian works well because the content stays plain text. No proprietary format that an agent cannot read.
The schema: one file that sets the rules
In the root of the vault sits a file called CLAUDE.md. It is the master schema. Every agent that opens the vault reads this file first and learns how the vault is structured and which conventions we work by.
The schema is co-evolutionary. When a convention does not hold up in daily use, I adjust it in this file, and the agent follows the new rule next time. That shifts maintenance away from rigid rules towards conventions that grow with real usage.
The structure: PARA as order
The vault follows the PARA method, a division into four areas:
- Projects: active projects with a concrete outcome
- Areas: ongoing areas of responsibility
- Resources: knowledge, tool references, concepts
- Archive: completed content
On top of that come a folder for people, a folder for immutable original sources, and a meta folder with an index and a log. Every file carries YAML frontmatter with title, type, tags and status. Links use double square brackets, the standard format in Obsidian. The result is a graph of connected notes rather than a loose collection of folders.
One rule matters to me here: no orphan pages. Every note needs at least one inbound and one outbound link. That keeps the knowledge connected and findable.
Vault architecture
Four layers, from the schema down to the sources
Schema layer
CLAUDE.md as the master schema. Defines structure and conventions. Read first.
Knowledge layer (PARA)
Curated markdown: projects, areas, resources, people.
Source layer
Original sources, untouched. Read only.
Meta layer
Index and log. Links to every layer.
Every page: at least one inbound and one outbound link. No orphan notes.
bimatic.chThe connection: MCP as a bridge
For a language model to actually read and write the vault, not just in theory, it needs an interface. That interface is the Model Context Protocol (MCP). An MCP server provides the model with tools, for example to list files, read a note or write a new page.
I run two MCP servers in parallel:
- A filesystem-based server for routine operations such as reading and writing. It works whether or not Obsidian is running.
- A second server through Obsidian's local REST programming interface (API). It comes into play when I need live features such as the built-in search.
In addition I use a command-line tool that allows a fast full-text search across the entire vault. With a large archive that is faster than a recursive search through all files.
The MCP bridge
How Claude reads and writes the vault directly
No copy-pasting of content. The agent reaches the knowledge directly, inside the workflow.
bimatic.chThe workflow: three recurring operations
In practice almost all work on the vault follows three patterns, again inspired by Karpathy.
Three recurring operations
The working loop around the vault
Ingest
Drop a source, discuss the key points, write a summary, link the pages.
Answer
Read the index, pick the relevant pages, synthesise an answer with sources and file it back.
Maintain
Find and clean up contradictions, stale claims and orphan pages.
The first pattern is ingesting a new source. I drop in a document, for example a guideline or a meeting record. Claude reads the source, we discuss the key points, and Claude writes a summary to the right place. The second step matters: a new source usually touches several existing pages. Claude updates those pages and links them. That way the knowledge stays connected instead of isolated.
The second pattern is answering a question. Claude reads the index first, decides which pages are relevant, and synthesises an answer with references to the underlying notes. Valuable answers I write back as a new page. A good synthesis should not get lost in the chat history.
The third pattern is maintenance. At regular intervals I check the vault for contradictions, stale claims, orphan pages and missing cross-references. This step is easy to underestimate. It decides whether the archive stays reliable over time.
In daily BIM practice
In concrete terms, the system helps me in several situations. When I need to retrace a decision from an earlier project phase, I find it through the linked notes rather than by searching my inbox. When I need a specific classification rule for a point cloud evaluation, it sits in the vault as a concept page rather than only in my memory. And when I solve a recurring automation problem, for example a detail in a Dynamo script, I record the solution as a resource page and find it again on the next project.
The value appears where knowledge repeats across several mandates. Exactly where scattered storage costs the most.
An honest assessment
The system has clear strengths. The knowledge sits in one place, in an open format, and an agent can retrieve it inside the workflow without me copying content. The answers are traceable because they point to concrete notes.
The limits are just as clear. The archive is only as good as its upkeep. Without conventions and without regular clean-up it runs wild. The work does not disappear, it shifts from searching to structuring. Anyone who does not bring this discipline gains little. And the model stays fallible: it can link notes incorrectly or summarise a statement too confidently. The critical eye remains my job.
For a larger team, the question of shared upkeep and access rights would come on top. For my one-person company, that is not an obstacle but an advantage: a single person sets the conventions, and the archive stays consistent.
Conclusion
A knowledge vault connected to a language model does not replace expertise. It replaces searching. For everyday work in infrastructure BIM it is a reliable memory that forgets nothing and quotes on demand. The price is discipline in upkeep. Anyone willing to pay that price gets a tool that becomes more useful with every project.
Bimatic GmbH supports you with BIM automation and digital workflows in infrastructure. From the base to automation.