Knowledge base

The knowledge base is the tool class that holds durable, readable knowledge: what a topic is for, how its work is done, and why choices were made.

Role in TFW

The knowledge base is the source of truth for explanations that people read more than once. This includes the topic’s purpose, processes, explanations of how systems work, decision write-ups, meeting records, and indexes of links.

It is not the source of truth for task status or files. Status belongs in task management. Files belong in document storage. A knowledge base page links to them.

One topic’s surface

The example topic Example Co Operations (topic code EXOP) has one knowledge base surface.

• Container. One space.
• Name and key. The space name is Example Co Operations. Where the product uses a short key, the key is EXOP. If the product assigned a different key, record it as an alias.
• Root page. The space opens on its purpose page.
• Structure. A shallow page tree under the purpose page, organized by subject. A common set of top-level pages is Processes, Decisions, Meetings, Plans, and Related Systems and Links. Page titles describe the content. They do not need the topic code as a prefix, because the space already identifies the topic.
• Permissions. The space is visible to the participants inside the topic’s access boundary, granted through the topic’s group.
• Maintainer. One named maintainer keeps the purpose page, the page tree, and the permissions correct.

The purpose page

Each space has exactly one purpose page at its root. It is the short record of what the space is for. People and AI agents read it first. It points to other records; it does not copy them.

A recommended outline:

1. Page status. The topic code, the topic name, the lifecycle status, the maintainer, and the date of the last review.
2. Purpose. What the topic covers and why the space exists, in a few sentences.
3. Scope and boundaries. What belongs in this space, and what does not belong here and where it goes instead.
4. How to use this space. The top-level pages, what each one holds, and the rules for new pages.
5. Links to other surfaces. The project, the shared drive, the chat channel, the automated channel, the email group, and the calendar, or a link to the topic profile that lists them.
6. Open gaps and next review. Known provisioning gaps, unverified statements, and the date of the next review.

If a fact on the purpose page is not verified, mark it as not verified. Do not fill a field with a likely guess.

Rules

• Each topic has one space. Do not create a second space for a subproject; use a page.
• Each space has exactly one purpose page, at the root.
• Keep the page tree shallow and organized by stable subject, not by a short-term task list.
• Put the conclusion, the status, and the links to evidence near the top of each page.
• Each important page names its owner, its sources, and the date it was last reviewed.
• Link to files, tasks, and threads. Do not paste large files or long chat transcripts.
• When a page is replaced, link to the replacement and archive the old page. Do not delete history without a reason.
• Do not store passwords or access tokens in pages.

Common mistakes

• No purpose page. Without it, readers guess the purpose of the space from its name.
• A purpose page that copies the task list. The purpose page describes the topic and links to the project. It does not track work.
• Status tracked in pages. A page that lists tasks and their state becomes out of date. Track work in task management.
• Deep page trees. Pages five levels down are rarely found.
• Pages that state a decision without a source. A decision page links to the record where the decision was made and names who made it.
• A second space for the same topic. This is a provisioning gap. Merge the pages and record the change.

Tools

• Confluence: How to set up and maintain one topic's knowledge base surface as a Confluence space with a purpose page as its homepage.

Other products in this class follow the same rules.