# Архивариус

> Что делает архивариус MMW после каждой записи — связи графа, отметки устаревания и уточнения — и чего он никогда не делает.

Архивариус — фоновый процесс MMW, который после каждого `remember` смотрит, как новая запись соотносится с недавними, и наводит порядок: связывает, отмечает устаревшее, понижает уверенность. Он ничего не удаляет.

Из этой страницы вы узнаете:

1. что архивариус делает с новой записью и с соседними;
2. какие данные он передаёт модели;
3. как он работает в организациях и где не запускается.

Пример на всю страницу: месяц назад агент сохранил «staging выкатывается вручную через scp», а сегодня — «staging выкатывается через systemd-юнит `app-staging`».

## Как это работает

```text
  remember(новая запись)
        │  запись сохранена, ответ агенту уже ушёл
        ▼
  архивариус (в фоне)
        │  берёт до 5 самых свежих записей той же области и проекта,
        │  которые может читать автор новой записи
        ▼
  модель GigaChat оценивает: CREATE / MERGE / INVALIDATE + связи
        ▼
  обновления: связи графа, статус stale, уверенность, fact_key
```

Анализ идёт асинхронно: `remember` отвечает сразу, а связи и отметки появляются чуть позже. Если модель недоступна, архивариус пропускает запись — она сохранена как обычно, просто без обогащения.

## Что он делает

| Решение модели | Что меняется |
| --- | --- |
| **CREATE** — новый факт | Только связи и, если нужно, служебный `fact_key` у новой записи. |
| **MERGE** — новая запись уточняет или дополняет старую | Уверенность старой записи понижается до 0,4 (если была выше). |
| **INVALIDATE** — новая запись опровергает старую | Старая запись получает статус `stale`, её уверенность понижается до 0,1. |

Дополнительно:

- **Связи графа.** Архивариус строит связи `relates_to` (связано), `fixes_issue` (исправляет проблему) и `supersedes` (заменяет) с весом. Они видны в `graph_relations` результатов `search` и на карте связей в кабинете.
- **Служебный fact_key.** Если вы не задали `fact_key`, архивариус присваивает ключ вида `archivist:полка:кратко`. Заданный вами ключ он не меняет.
- **Только среди кандидатов.** Изменять он может лишь те записи, которые сам получил на сравнение. Если модель укажет другую запись, решение отбрасывается.

В нашем примере архивариус, скорее всего, решит INVALIDATE: запись про `scp` станет `stale` с уверенностью 0,1, а новая получит связь `supersedes` к ней. В поиске агент увидит обе — и поймёт, какая актуальна.

## Чего он никогда не делает

- **Не удаляет.** Опровергнутая запись остаётся видимой и находится поиском. Удаляет только `forget`, вызванный вами или вашим агентом.
- **Не меняет текст** ни новой, ни старой записи.
- **Не повышает уверенность** — только понижает.
- **Не выходит за пределы** проекта и рабочей области новой записи.

Отметка архивариуса — оценка модели, а не правило. Она может ошибаться. Если запись помечена `stale` напрасно, сохраните факт заново: новая запись снова будет `unverified`. Строгие правила — конфликт по `fact_key` и сравнение хешей источника — работают независимо от архивариуса.

## Какие данные уходят модели

Модели передаются текст новой записи и начало (до 140 символов) каждой из записей-кандидатов вместе с их ID. Секреты к этому моменту уже заменены заглушками — [Memory Guard](/memory/memory-guard/) срабатывает до сохранения. Ответ модели тоже проходит вычистку секретов, прежде чем попасть в `fact_key`.

## В организациях

Архивариус соблюдает те же правила видимости, что и поиск: кандидатов он выбирает только из записей, которые может читать **автор новой записи**. Черновик коллеги («только автор») или запись чужого отдела не попадут ни в сравнение, ни в связи, ни в отметки. См. [Видимость](/organizations/visibility/).

## Где он не запускается

Для записей, сделанных через подключение ChatGPT (коннектор по OAuth, бета), `remember` — чисто добавляющая операция: архивариус не запускается, и текст записи модели не передаётся. При сохранении такие записи не анализируются.

## Что дальше