Knowledge base
A shared knowledge store for people and AI: working rules, project facts and environment pitfalls. It reaches the model at every stage.
The knowledge base is what your organisation knows about itself and its projects, in one place and in the same form for people and for the model. Working rules (“YAGNI, always”, “we answer in Russian”), facts about the project that cannot be read from the code, and environment pitfalls someone has already stepped into.
The model sees these entries at every stage of work: when formulating a task, during decomposition, analysis, development, review and conflict resolution, in an audit, in “Ask” and in deep research. It also adds to them — right in the course of work, when it has established a fact or found a way around an obstacle, and after finished work.
Why it is needed
The model does not remember yesterday. Every task starts from scratch: it reads the code again, finds out again that the tests do not run without the environment up, and proposes again an approach you rejected a month ago. The knowledge base is what outlives the end of a task.
It exists for three things:
- Your rules are followed without reminders. A rule that has been written down reaches every run — there is no need to repeat it in every task statement.
- Mistakes are not repeated. What you corrected once — rejected a formulation, sent back for rework, explained in a clarification — becomes an entry and keeps working on its own.
- Knowledge does not leave with people. The reason for a decision, an environment pitfall, a quirk of a legacy module live in the organisation, not in the head of whoever found it out.
What it is NOT
- Not repository documentation. The model reads the code structure, paths and conventions from the code itself — and reads the current ones, not a snapshot from half a year ago. The knowledge base is for what the code does not contain.
- Not a task statement. A task statement is about one specific piece of work. The knowledge base is about what holds for all work in this project or organisation.
- Not a secrets store. Entries go into the model’s prompt; tokens, passwords and keys do not belong here — there are repository credentials for them.
How it works
| What | Where to read |
|---|---|
| What an entry consists of and how to write a good one | Entry |
| Three entry types and what goes where | Types |
| Knowledge of the whole organisation or of one project | Scopes |
| How knowledge reaches the model and what it costs | How it reaches the model |
| What the AI writes and how to tell it apart | AI entries |
| Passes after finished work | Passes |
| There is no deletion — there is an archive | Archive |
| Who sees and changes what | Permissions |
| Ready-made recipes and typical mistakes | Recipes |
Where to find it
The “Knowledge base” section in the left-hand menu. It belongs to the organisation, not to a project: rules for all projects can be set up before the first development project exists.
Ask from a document or ticket
How to address the AI agent in Notion, a Google Doc, Confluence, Figma or a tracker: forms of address, where the answer arrives, what the bot does not do.
Entry
What a piece of knowledge consists of: title, one-line description, type, scope, body and two flags. How to write it so the model uses it.