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 — 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 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 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 in one action with the reason “task completed”: in the list such entries are visible on the “Archive” tab, and in the 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 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.
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.