# Organisation, project, task

> Knowledge of the whole organisation, one project or one task: what goes where, who sees it, and what happens to a task’s entries when it closes.

Every entry has one scope: **the whole organisation**, **one development project** (or a [space](/en/docs/quickstart/space) — it is a scope just like a project) or **one task** within a project.

## What goes where

**Organisation** — what is true everywhere, in any project:

- working rules (“YAGNI, always”, “comments in Russian”);
- company-level decisions written down as rules (“we publish upstream only through a PR”);
- links to shared resources.

**Project** — what is true only here and will outlive any task:

- facts about a specific codebase and its environment;
- this project’s build and test pitfalls;
- decisions taken in this project.

**Space** — the same for a department without code: the rule “We answer a customer within one working day” goes into the support space, the fact “The current price list is in the Sales/Price lists folder” into the sales space, the pitfall “The 2024 procurement regulation is outdated — use the 2026 edition” into the legal space. Such entries should not go into the organisation: a support rule would get in the way in every development project.

**Task** — what is true while one task is open:

- the author’s decisions on this task, given in clarifications and at gates;
- the composition and contracts of its atoms, its branch and specification;
- anchors, counters and profiles verified for its artifacts.

A task’s entries are written **only by the model** — in the course of working on it. A person does not choose this scope in the editor: their knowledge is either about the project or about the organisation.

In doubt between organisation and project — put it in the project. Writing knowledge into the organisation means showing it to every run of every project: a rule true for one project will get in the way in the others. The model, in doubt between project and task, writes to the task: a [pass](/en/docs/knowledge/passes) will lift what is valuable from there, whereas anything superfluous in the project will not go away by itself.

## How the model sees it

A run of task `T` in project `P` in organisation `O` receives:

- all active entries of organisation `O`;
- all active entries of project `P`;
- all active entries of task `T` — and not a single entry of any other task.

Other projects are never visible — neither in the index nor on request. Other tasks neither. A run outside a task (an audit, “Ask”) gets no task entries at all.

## What happens to a task’s entries

When a task ends — merged, rejected or stopped — the [pass after finished work](/en/docs/knowledge/passes) reads its entries along with the rest of the material and **moves into the project** whatever will outlive the task. After the pass, the whole task scope goes to the [archive](/en/docs/knowledge/archive) in one action with the reason “task completed”: in the list such entries are visible on the “Archive” tab, and in the [audit log](/en/docs/audit-log) as a single event with a list of names.

A task entry you have marked **permanent** stays active: this flag is your decision to keep it. If the knowledge is needed for good, it is better to **move it to the project**: open the entry, choose the project in the “Scope” field and save.

## How people see it

A member sees the entries of the scopes their [read permission](/en/docs/knowledge/permissions) reaches: a grant on a project gives that project’s entries (together with the entries of its tasks) and the organisation’s entries; a grant on the organisation gives everything.

In the list, the scope is shown by an icon on each entry; a task entry also carries a **“task #N”** mark that leads to the task itself. The **“Task knowledge”** filter shows only such entries — both on the “Active” tab and in the archive.

_Illustration: A task entry: the “task #N” mark next to the project and the “Task knowledge” filter above the list._

## Who can write where

| Who | Organisation | Project | Task |
| --- | --- | --- | --- |
| A person with change permission on the organisation | yes | yes | no — but can move a task entry to a project |
| A person with change permission on a project | no | only this project | no — but can move a task entry to a project |
| AI | **no, never** | only its own project | only its own task |

Organisation-wide entries are entirely human territory: these are the rules the whole company works by, and the model does not set them. The task scope is the model’s territory: it holds what the model found out in the course of one piece of work. Moving an entry between scopes is done by a person, and from task to project also by the pass after finished work; the model itself does not change an entry’s scope in the course of a task.