Your knowledge base, the organization's brain

Your knowledge base, the organization's brain

Every organization runs on knowledge that lives in someone's head: why the contract says what it says, which funder wants what format, how payroll actually gets done. That works until someone is on holiday, until someone leaves, or until you hire. Then it gets rebuilt from scratch, usually badly.
There is a newer reason, and it is the one that changed the stakes. People fix missing knowledge by asking the colleague next to them. An AI assistant can't. Everything your organization knows but hasn't written down is invisible to it. If it isn't written down, no AI can read it, not yours and not anyone else's.
You will be offered a "company brain" as a product this year. You probably don't need one. You need the tools you already use, connected, and two habits.

What the setup needs

Seven elements. Most organizations already have five of them and have never said out loud which is which, which is the actual problem.
  • A place for durable knowledge: how things work, what was decided, what the policy is. Your  knowledge base .
  • A place for work: tasks with an owner and a date. Your  project management tool  .
  • A place for files: contracts, designs, source documents. Your  cloud storage  .
  • A place for talk that expires: questions, nudges, informal thinking. Your  team chat  .
  • A place for who does what: roles, accountabilities, who to ask. Your  role management  .
  • An  AI assistant  connected to the four places above.
  • One role that sets the standards for all of it:  Collaboration Culture Builder  . It is the only central role in this pattern, and it owns the standards, not the content.

Two rules

Everything else is downstream of these.
The role that does the work owns the page. There is no librarian and no knowledge manager. The role that runs payroll owns the payroll pages. The role that handles contracts owns the contract pages. Write it into the accountability in those words: updating the relevant pages. A knowledge base with one owner rots, because one person cannot know when forty pages went out of date. One where forty roles each own two pages stays alive without anyone maintaining it.
Write down why, not just what. Most knowledge bases record the decision and lose the reasoning. Six months later nobody can tell whether a rule still applies or was a workaround for a problem that no longer exists, so it gets argued out again from zero. One sentence at the point of decision, why we chose this and what we rejected, is the highest-value line in your whole knowledge base. It is also the line an assistant needs in order to reason like your team instead of parroting it.

Where to start

Don't migrate anything. Pick the three questions your team asks most often, write those three pages, put them in your knowledge base, and connect your assistant to it. Then write a page only when a question comes up twice.

Your variation

Record what you chose differently and why, with a date for when to look at it again. If you based your version on this pattern, say so on the page, so the next person knows where it came from.

The rest of this pattern

  •  Where things live  : which of the four places each thing belongs in, and the rule that keeps chat from becoming a filing cabinet.
  •  Setting up your knowledge base  : structure, naming, and what to make public.
  •  Writing it down  : how to write pages people actually read, and how to write your own patterns.
  •  Keeping it alive  : ownership and review, kept light enough to survive.
  •  Connecting your AI  : what to connect, in what order, and a proportionate line on privacy.