Знания как код: как устроить корпоративную память до внедрения AI

14 августа 2026 · 5 минут чтения

Четыре правила моей рабочей модели корпоративной памяти: один SSOT, источник отдельно от утверждения, ссылка вместо пересказа и проверяемый путь от вывода к свидетельствам.

Допустим, клиент пишет менеджеру: «Бюджет согласован». Менеджер пересказывает это в рабочем чате, руководитель переносит фразу в презентацию, а сводка, собранная AI, сообщает: «Бюджет подтверждён». Через неделю уже непонятно, что именно произошло: клиент высказал намерение, подписал заказ или действительно перечислил деньги.

Проблема существует и без AI: команда уже может принимать решения по устаревшим пересказам. AI добавляет ещё одного читателя тех же материалов. Поэтому начинать нужно не с задачи «загрузить всё в AI», а с договорённости о том, где хранится актуальное знание и как оно связано с источниками.

1. SSOT: у существенного утверждения один канонический владелец

В этой статье первый принцип — single source of truth, или SSOT. Для каждого существенного утверждения в заданной области команда выбирает канонического владельца: запись или систему, которую обновляют первой. Остальные документы и сообщения ссылаются на неё.

SSOT не означает один файл или одну систему для всей компании. У кода может быть свой репозиторий, у платежей — бухгалтерская система, у статуса клиента — CRM или карточка проекта. Важно, чтобы в пределах одного вопроса не было нескольких равноправных «последних версий».

Источников при этом может быть много. Письма, договоры и выгрузки подтверждают разные стороны факта, но актуальным утверждением владеет одно выбранное место.

Система контроля версий записывает изменения файлов и позволяет возвращаться к прежним версиям. Я переношу этот принцип на знания: команда меняет каноническую запись, а в обсуждениях ссылается на неё вместо создания новой копии.

2. Источник, утверждение и вывод — разные вещи

Вернёмся к сообщению клиента. Оно доказывает, что клиент написал: «Бюджет согласован». Но само по себе оно не доказывает наличие денег, подписанного заказа или полномочий отправителя.

В этой модели полезно разделять три уровня:

Источник → каноническое утверждение → вывод или решение.

• Источник: исходное сообщение клиента.
• Каноническое утверждение: клиент сообщил о согласовании бюджета; полномочия отправителя и принятый в проекте критерий согласования пока не проверены.
• Решение: не начинать работу до выполнения заранее установленного критерия — например, получения подписанного заказа. Поступление денег — отдельное утверждение со своим свидетельством.

В этой модели у одного утверждения может быть несколько свидетельств, а один источник может поддерживать несколько выводов. Каждый вывод или решение должен вести обратно к материалам, на которых он основан. W3C PROV описывает происхождение данных через сущности, действия и агентов; разделение уровней выше — моя рабочая нотация, а не отраслевой стандарт.

3. Мессенджер — транспорт, а не хранилище

Обсуждать в чате удобно. Искать там последнее действующее решение через месяц — нет.

В предлагаемой практике решение, договорённость или инструкция из переписки переносится в каноническое место. После этого в чат отправляется ссылка: «Текущий статус и основания зафиксированы здесь». Когда ситуация меняется, команда обновляет ту же запись, а старые сообщения остаются историей разговора, а не конкурирующей версией правды.

Текущий статус после этого ищут в одной записи, а чат сохраняет историю обсуждения.

4. Связывайте вывод со свидетельствами

Проверяемый ответ или отчёт показывает не только результат, но и границы знания — независимо от того, подготовил его человек или AI:

Клиент написал, что бюджет согласован — это подтверждённый факт коммуникации. Полномочия отправителя и принятый в проекте критерий согласования пока не проверены. Подписанный заказ не найден, поэтому по правилу проекта работу не начинаем. Поступление денег — отдельное утверждение; в этом примере оно не проверялось.

В таком ответе отдельно названы наблюдение, неизвестное, критерий проверки и принятое по правилу проекта решение. Уверенный тон не заменяет свидетельств.

Полный реестр правил

Эти четыре принципа — авторская рабочая модель. Остальные правила уточняют версии, типы ссылок, структуру записей, индексы и ограничения доступа.

Полный реестр из 12 правил, мнемо-номера и рабочая нотация живут в GitHub. Четырём принципам статьи соответствуют KAC-01 и KAC-07, KAC-02 и KAC-03, KAC-06, KAC-11. Это авторская рабочая система, а не заявка на отраслевой стандарт; стабильные номера нужны, чтобы команда могла ссылаться на конкретное правило.

С чего начать в одном проекте

Не нужно сначала строить AI-поиск, векторную базу или корпоративный граф знаний. Проведите один небольшой эксперимент:

1. Выберите один вид знаний, который регулярно теряется или расходится в копиях: например, решения команды или статус обязательств клиента.
2. Назначьте для него одно каноническое место и человека, который следит за актуальностью.
3. Фиксируйте там текущий ответ, дату и ссылки на свидетельства.
4. Когда вопрос возникает в чате или письме, обновляйте запись и отвечайте ссылкой на неё.
5. Проверьте, может ли новый участник команды или AI назвать текущий статус и показать основания, не перечитывая всю переписку.

Для эксперимента достаточно записи без специальной системы:

• Текущий статус: клиент сообщил о согласовании бюджета.
• Область: проект X.
• Каноническое место: карточка проекта.
• На дату: 14 августа 2026 года.
• Свидетельство: исходное сообщение клиента.
• Неизвестно: полномочия отправителя и выполнение принятого в проекте критерия согласования.
• Критерий начала работ: получен подписанный заказ.
• Ответственный за актуальность: менеджер проекта.

Если это не получается, не добавляйте новые инструменты. Сначала найдите разрыв: не выбран SSOT, запись устарела, свидетельства потеряны или ссылка ведёт на очередную копию.

Результат эксперимента наблюдаем: новый участник команды находит текущий статус и основания без перечитывания чата. Для AI критерий тот же.

Источники

Это не систематический обзор практик управления знаниями. W3C PROV служит основанием для описания происхождения данных, а Pro Git — для истории изменений; четыре правила статьи являются моей рабочей моделью.

• W3C PROV Primer — модель происхождения данных через сущности, действия и агентов.
• Pro Git: About Version Control — базовая модель версий и истории изменений.
• Knowledge as Code — канонический двуязычный реестр правил и нотации.

Автор: Данил Письменный · Дата: 14 августа 2026