# 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](/en/docs/knowledge/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](/en/docs/knowledge/scopes) 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](/en/docs/knowledge/passes) 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](/en/docs/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.