The Workshop Diary is an ongoing series about how tools really come to be, in my own and clients’ projects, from idea through error to iteration.

The same phenomenon repeats from one organisation to the next: there are plenty of documents, but the knowledge is lost. Official instructions, informal notes, training material, old versions of the same thing, decisions buried in email, all in different places, in different formats. Nobody is quite sure which is the latest and which still applies. When someone asks “how do we do this nowadays?”, the answer is too often “ask Juho”, and if Juho is on holiday, the knowledge is effectively gone.

It isn’t only a problem for small associations. The same happens in SMEs and large organisations alike. Documentation piles up over the years, but no one has had time to make sense of it, and a search box doesn’t help if you don’t know which word to look for.

This diary is about a tool I built for this problem as part of the work I do in the voluntary rescue service: a general solution that different associations can use within the SAR framework. Its core idea transfers directly to any organisation drowning in its own documents.

When documentation has no process

In SAR work, documentation lives on two levels. There is the wider operational whole with its own instructions and standards, and there is each association’s own documentation: training materials, exercise notes, local practices. Both vary, both are managed haphazardly, and processes and practices are missing here and there. One association does a thing one way, another does it differently, and the “official” instruction may be two years old.

Familiar? This is exactly how it is in SMEs where the quality manual is on one drive, the real ways of working on another, and the actual knowledge of why something is done a certain way lives in the heads of a few veterans.

I wanted a tool that would answer two questions an ordinary folder search cannot: “how has this practice evolved over time?” and “am I really working according to the latest information?”, and do it from both official and informal documents, because the truth often lives right between them.

Why RAG rather than a search box

An ordinary search looks for words. If you search for “change in the search pattern” and the document doesn’t say exactly that, you find nothing, even if the document is about precisely that in different words. A person doesn’t remember which term a three-year-old memo was written with.

The answer is RAG, retrieval-augmented generation. The idea has two parts: first, based on meaning, it retrieves the pieces of documents that actually relate to your question, and then a language model composes an answer from them that refers to its sources. It is not a chatbot that makes things up. It is a search engine that understands what you mean, and justifies its answer with the real documents.

This is exactly what suits document chaos: you don’t need the right search word, you need the right question.

Obsidian vault: knowledge stays as text and in your own hands

I built the knowledge store in an Obsidian vault. The choice is not cosmetic. Obsidian stores everything as ordinary markdown text in a local folder, not a database, not the cloud, not a closed format. That means three things that are decisive for this project: the knowledge is readable without special software, it is portable (a folder is a folder), and it is in your own hands. If the tool ever changes, the knowledge is not held hostage.

Obsidian’s other strength is linking: documents can refer to one another, forming a network. This later became the backbone of the whole tool.

Vectors and search: meaning, not words

For meaning-based search to work, documents have to be turned into vectors, numbers that describe the meaning of the text so that pieces meaning the same thing sit close to one another regardless of word choice. This is the heart of RAG, and it is done with a local embedding model: the text is split into suitably sized pieces, each piece is vectorised, and the question is vectorised the same way. The search is then simply “which pieces are closest to this question”.

Sounds straightforward. The size of the split turned out to be one of the hardest decisions, more on that shortly.

AI as cross-referencer: the Jarvis legacy

This is where the tool turned from a search engine into a memory. Once the pieces were vectors, I set the AI to read through them and populate the vault with cross-references: it recognises that this exercise memo deals with the same practice as that official instruction, and links them together. Gradually a scattered pile of documents grows into a network where the different versions, dates and perspectives of the same topic are connected.

Anyone who has followed the “second brain” world recognises the principle: this rests on the same idea as those famous Obsidian + AI “Jarvis” projects, where a searchable, self-linking knowledge store is built from personal memory. The difference is in the purpose, here we are not organising one person’s notes but an organisation’s shared knowledge, and security is part of the design from the start.

Where I stumbled

Three things taught humility.

The size of the split. Pieces too large brought irrelevant material into the search; too small cut a thought off midway and the AI answered on half the information. The right size was found only by experimenting, and it depended on the document type, a tight instruction and a rambling memo need different handling.

Justification made mandatory. The first version gave fluent answers that sounded right. But without a source reference a fluent answer is dangerous: you don’t know whether the model read it from a document or invented it. I forced every answer to refer to the document it came from. If there is no source, there is no answer.

Weighting official against informal. The truth often lives in informal documents. That is where it is told how a thing is really done. But when they conflict, the latest official instruction has to win. The tool had to tell these apart and tell the user which is which. This was not a technical problem but a knowledge-management one, and precisely what was missing at the start.

Local AI is not merely a technical choice. It is a decision about whose server your organisation’s knowledge rests on.

Why local: the data stays inside the house

This is the crux of it. RAG and the language model can be run in the cloud or on your own machine. When they run locally, the organisation’s documents never leave the house, not the text, not the attachments, not even the search queries go to an outside server. The whole knowledge store, the vectors and the models run on your own hardware.

For sensitive information the difference is significant. In SAR work, documents can concern locations, procedures and situations not meant for outsiders. Personal data is always off-limits. It does not belong in a store like this at all, and is excluded already at the mapping stage. In a company the same applies to contracts, pricing and customers. When the information never leaves the machine, the attack surface for a leak shrinks dramatically: no third party on whose server the data accumulates, no uncertainty about where queries are stored, no dependence on an outside service’s security level.

The price is computing power. A local model demands more of the hardware than a cloud service opened in a browser, a decent machine, preferably with a graphics card. That is a real cost, and not one to downplay. Power can also be bought as a service, and for many organisations that is the most sensible solution, but then responsibility for security shifts to the provider, and you get a grip on it only through contractual means. That is a story of its own, and I’ll write about it in the next part of the series.

The result: searchable, traceable, up to date

The finished tool does what was impossible at the start. You can ask “how has this practice changed over the last three years”, and get an answer that gathers together the official instructions and the informal memos, arranges them into a timeline and refers to every source. You can make sure you are working according to the latest information without leafing through ten folders. A scattered pile of documents became a memory you can ask, and one that can justify its answers.

And it doesn’t forget when the veteran goes on holiday.

The same chaos, the same solution, in SMEs

I built this as part of the work I do in the voluntary rescue service, but the whole time I had in mind how recognisable the problem is. The same document chaos plagues SMEs just as much: a quality system nobody can find; a way of working that lives in three people’s memories; decisions buried in email. And the same model, a local RAG that keeps the knowledge inside the house, is within their reach without having to hand the data to anyone. The tools are open, the hardware is affordable, and the knowledge stays your own.

It doesn’t require an IT department. It requires one machine, a little patience with the splitting, and the decision that your own knowledge stays in your own hands.

Next part: when it is worth buying computing power from the cloud, and what happens to security responsibility when you do. Contractual mechanics, the DPA and NIS2’s supply-chain responsibility enter the picture.