# A company knowledge base that answers questions, and the answer it must never give A company knowledge base that answers questions has to keep each project apart, because the costly failure is an answer that blends two of them. Have it read the cheapest source first and show where each answer came from. A thin answer costs a second question; a blended one costs whatever gets done on the strength of it. Date: 2026-10-06 Reading time: 5 min Author: OCTYN No. 07 Somewhere in the shared drive is the document that settles the question, and somewhere in the chat history is a later message that half contradicts it. The person asking does not know which one is current. The person who would know is on leave this week, so the request that reaches whoever runs operations is a reasonable one: put everything in one place and let people ask it things. What gets built first is usually a search over everything. Connect the drive, the chat export and the notes, index all of it, and put a model on top that writes a reply from whatever the search brings back (the glossary has the general pattern under [retrieval augmented generation](/glossary/retrieval-augmented-generation)). On the first afternoon it does well, mostly because the first afternoon's questions are ones somebody already knew the answer to. Then, say, somebody asks how renewals work for one particular client. The reply gives the notice period from one client's contract and the payment terms from another's, in a tidy paragraph with no visible seam. Each half is true of somebody. Put together, they describe an arrangement that exists nowhere, and the reply carries no sign of it, since the model was handed both documents and asked for one answer. ## A thin answer costs less than a blended one Three things can go wrong with a knowledge base like this, and they are priced very differently. OCTYN worked out the order on its own planning system, Brain, and the [case study](/casestudies/octyn-brain) lists them from the cheapest up. A miss costs little. The system stops reading too early, the answer comes back thin, and the person asks again with a pointer to the right project. Annoying, but recoverable, and Brain is deliberately biased towards it for that reason. A blend costs a great deal: two projects merged into one answer and delivered fluently. The example in the case study is a deploy step, where a confident reply merges how two different projects deploy, and the mistake stays invisible until somebody carries it out. The third, and the one that grows as the system remembers more, is the stale recall. A fact that was true in July and comes back in September with no sense of its age is worse than no memory at all. That order should decide how the thing is built. If a miss costs little and a blend costs a great deal, the system ought to stop early and say less, leaving the person asking to push for more. A search over everything pulls the other way, since its whole job is to return whatever might be relevant. Compared with a [hallucination](/glossary/hallucination), a blend is harder to catch. A made up fact can at least be looked for and found missing. Every sentence in a blended answer has a real document behind it, and the error is in the joining. ## Reading one project at a time When OCTYN audited its own workspace on 24 July 2026, it found 20 plus repositories, about 34,853 files, and 141 notes across 15 subprojects. Every morning the context for all of that had to be rebuilt, down to what had been decided about a project and why a decision that now looked strange was made in the first place. Nobody holds that in their head, and a system that tries to hold all of it at once is no more use. So Brain does not search everything. Its planner reads the cheapest source first and stops once it has enough to answer. It is also explicit that it never mixes context between projects. Under it sits a tiered context model, five tiers deep on the internal map as captured on 14 September 2026, with each tier a wider and more expensive read than the one before, so stopping early is the default. The business side of OCTYN runs as a separate workspace on the same memory, and it may read the product side when a question needs it, but it is not allowed to blur the two into one answer. None of this is clever. The defence against a blend is structural: separate workspaces, and a rule against mixing them that is written down. There was still no automated detection of a blend on 14 September 2026. When one happens, the person who asked catches it, because they know which two projects got merged. In a services company the projects are usually clients, and the person asking is often the one who knows them least, someone new or someone covering for a colleague. That person will not spot a blend. A knowledge base built for them has to keep each client apart before it does anything else. OCTYN's own version of this is written up as the [Company Brain](/systems/company-brain). ## Show where every answer came from Brain's memory now keeps whatever it recalls traceable back to where it came from, and in that choice traceability counted for more than recall quality. The stale recall is why. A fact with its source and its date attached tells the reader it is from July. The same fact without them just sounds current. A source also makes a blend visible to readers who would otherwise miss it. Two documents from two different clients sitting under one answer is a seam anybody can see, even in their first week. Brain can afford its mistakes for one more reason. It plans and it learns, and it never builds or deploys anything, so the worst outcome of a wrong answer is a wrong answer. A knowledge base that can also update the record or send the reply has a much worse worst case, and everything above matters more for it. ## The test set that should have come first The case study is plain about the gap. There is no fixed test set for context selection, so as of 14 September 2026 nobody could state what share of answers pulled the right project's material. The claim that Brain never mixes two projects rests on nobody having noticed it happen. The first thing OCTYN would do differently is build that test set before anything else. It is a fixed list of questions with known right answers, run again whenever retrieval changes, and a company can write one before a single document is indexed. Put in pairs of questions about two clients whose files look alike, since the pairs are where a blend turns up. Put in a few where the right answer is that the client has nothing on file. If the first version then answers with a little less than people hoped, they will ask a second time. Of the three ways to be wrong, that is the one worth choosing. ## Related **Systems this bears on** - [Company Brain](https://octyn.co/systems/company-brain) **Case studies cited** - [Brain](https://octyn.co/casestudies/octyn-brain) **Terms used here** - [Retrieval augmented generation](https://octyn.co/glossary/retrieval-augmented-generation) - [Hallucination](https://octyn.co/glossary/hallucination) **Read next** - [Why a CRM does not fix client context, even when everyone fills it in](https://octyn.co/blog/why-a-crm-does-not-fix-client-context-even-when-everyone-fills-it-in) - [How to stop rebuilding client context before every call](https://octyn.co/blog/how-to-stop-rebuilding-client-context-before-every-call) - [How to scope an AI project so it ships: write down what it will never do](https://octyn.co/blog/how-to-scope-an-ai-project-so-it-ships-write-down-what-it-will-never-do) - [What should a founder automate first? Start with the catching up](https://octyn.co/blog/what-should-a-founder-automate-first) More on client context: [Client context](https://octyn.co/blog/topic/client-context) Canonical: https://octyn.co/blog/a-company-knowledge-base-that-answers-questions-and-the-answer-it-must-never-giv