AI entries
What the model writes itself, what it never writes, how to tell its entries from yours, and what it cannot touch.
The model adds to the base by itself — at the moment it has found something out, not “some time later”. This happens at any stage where it works: in development and review, in an audit, in research, in “Ask” — when you have told it a fact about the project right in the conversation — and in passes after finished work.
What it writes
- A fact — a stable characteristic of the project or the environment that is not in the code; this also covers a decision taken in the course of work, together with its reason.
- A pitfall — a reproducible obstacle and the way around it that was found.
Where it writes
The model chooses each entry’s scope itself: project — if the knowledge will outlive the current task (environment, build, tool behaviour, legacy), task — if it is true only for that task (the author’s decisions on this task, the composition of its atoms, its branch and specification, anchors verified for it). A task’s entries are seen only by that task’s runs, and when the task is closed they go to the archive — after the pass after finished work has moved into the project whatever will outlive the task. When in doubt, the model writes to the task.
What it never writes
- Rules — they are set by a person.
- Code structure, paths, conventions — these are read from the repository and go stale faster than they come in handy.
- Git history and “who changed what”.
- Recipes for one-off fixes: the fix itself is already in the code, the reason in the commit.
- The momentary state of work — which atom is open, what is uncommitted. Not even in the task scope.
- What is already written down: instead of a second entry about the same thing, it updates the existing one. When updating its own entry, it keeps its flags: it does not clear the “show to the model upfront” you set, nor the “needs review” mark.
How to tell them apart
Every entry shows its author. The model’s entries carry the AI icon and the name of the stage that made them: develop, audit-analyst, knowledge.recall, knowledge.dream, ask. Each such entry also has a source — the task, stage and project it came from. The author filter (person or AI) shows the model’s entries as a feed: handy for looking through what it has learned once a week.
Everything the model did to the base — created, updated, marked or archived — is recorded in the audit log as a pipeline action, with the stage and the task.
What the model cannot do
The restrictions are enforced on the server, not in the prompt text — so the model cannot “talk them out of it”:
| Cannot | Why |
|---|---|
| Write to the organisation scope | Rules for the whole company are set by a person |
| Touch a permanent entry | That is exactly what the flag exists for |
| Rewrite your entry | It can only mark it “needs review” and explain what diverged |
| Archive your entry | Same thing: a mark, not an action |
| Write a secret | Such an entry is rejected with an explanation |
| Overwrite someone else’s edit | A change requires the version read before the edit |
| Write to another task’s scope or move an entry between scopes | A run sees and writes only its own task; moving from task to project is done by a person or by the pass after finished work |
The “permanent” flag
Set it on an entry the model must not revise under any circumstances: a key rule or fact all the work rests on. The AI will be able neither to change it nor to archive it. You will.
If the model wrote something superfluous
Open the entry and correct it, or move it to the archive with a reason — it will not disappear, but it will stop reaching runs. If such entries keep appearing, the base most likely lacks a rule that would explain the boundary to the model.