Personal notes, a team wiki and a knowledge base for AI differ in who reads them: your future self, your colleagues, a model. All three have to answer what to keep, how to organize it, how it gets found and who maintains it. Research on personal collections finds that most 'finding' is re-finding things you have already seen; research on enterprise wikis finds that once the person who tidied or wrote the content leaves, it starts to decay.
Getting team documents to look alike and make sense takes two templates and one principle. The principle is fewer but fresh: Google's documentation guide says a small set of fresh, accurate docs beats a large pile in disrepair, and if something exists elsewhere, link to it. The how-to template runs prerequisites, steps, how to confirm it worked, and whom to ask when it fails; in one study, installation instructions rewritten to a template scored better on eight of ten aspects readers rated. Architecture decision records (ADRs) note why a decision was made; when one is reversed, you don't delete it, you mark it superseded and link to the new decision. Research also finds ADRs are often tried and dropped, and that the "considered options" section is the most problematic, often missing or misplaced, so keep the template short and keep that section.
A common team-wiki argument is whether to organize by department or by task. The research is more cautious than you might expect: employees who know the org chart were actually faster on an intranet organized by department, and label quality mattered far more than the organizing scheme. A safer approach: give the main structure a scheme where every page has an owner, then add a few task-based entry pages that hold only links, and title pages with the words readers will search for. Before organizing, use card sorting to learn how readers think; afterwards, use tree testing to check whether they can find things.
Documentation going out of date is normal, and it throws no errors: eight in ten of GitHub's most popular projects have at some point left references in their docs to code that had been deleted. There are four ways to maintain docs: give every page a responsible role, set verification expiry, change the docs in the same change as the process, and fix pages when they're used. Each one fails in its own way: the owner leaves, expiry notices get treated as spam, the rule exists but nobody follows it, and articles nobody uses never get checked. The deletion principle: delete what's certainly wrong first, and archive what's correct but rarely used. By the end you'll be able to draw up a maintenance table for your team: document type, responsible role, review cycle, and deletion conditions.
When colleagues can't find something, it usually isn't missing: of 50 zero-result queries at one university library, only one in ten was for something it didn't have. Sort the gaps in three to six months of search logs into can't be found, doesn't exist and different words, and fix titles and synonyms first; AGENTS.md files for AI need the same care, since one evaluation found they didn't raise success rates overall while raising costs by about a fifth.
Research on rotting team wikis keeps finding three things: gaps and outdated pages are complained about more often than wrong ones; the people who write have no time or have left; and managers want something different from the people who actually write. Not every wiki rots: wikis hold up better when the writers are also the readers, or when the documents solve a clear problem. Diátaxis sorts documents into four kinds (tutorials, how-to guides, reference and explanation), and two questions tell you which kind a document should be, so you can see which kind your team is missing.