Объектная модель базы знаний (CoreStream)
Бизнес-объекты ITECH по CoreStream (A1–A11): что является объектом, его фазы и связи. Основа структуры KB и тегов. Данные — в Grace, здесь — контекст. Полка определится позже.

Объектная основа базы знаний
База знаний ITECH строится от бизнес-объектов, а не от папок отделов. Методика — CoreStream: бизнес = взаимодействующие объекты (A1–A11), процессы = действия, меняющие их состояния.
Зачем так
Данные в Grace — это зёрна (конкретные записи: контрагенты, проекты, заказы). Сами по себе они не дают понимания. Объектная модель — это контекст, который придаёт зёрнам смысл: что это за объект, какие у него фазы жизни, с чем связан. Из контекста разворачиваются и процесс (что с объектом делают), и метрики (сколько длится, сколько стоит).
Поэтому: Grace держит данные, BookStack фиксирует контекст, агент соединяет их.
Две оси
О чём знание → бизнес-объект (становится книгой KB).
Как знание живёт → жизненный цикл объекта «Знания» (A11): сбор → интеграция → применение → оценка → обновление → архивация. Это операционная модель KB и шкала зрелости.
Карта объектов → книги
Контур (полка)
Книги
Объект CoreStream
СМК / ISO
БЗ-1, БЗ-2
A2 Бизнес-система
Инженерный
БЗ-3, БЗ-4
A3 Продукт
Производственный
БЗ-5, БЗ-6
A8 Товар
Коммерческий
БЗ-7, БЗ-8, БЗ-9, БЗ-11
A7 Потребитель (компания)
(сквозная)
БЗ-10 Прецеденты проектов
Здание (объектный контур)
Книга = проекция объекта. Главы = фазы его жизненного цикла. Страница = один канонический документ. Теги 
объект-cs: (тип объекта) и 
фаза: (фаза ЖЦ) связывают страницу с моделью и с данными Grace.
Подробные разборы объектов — соседние страницы этой книги.

Потребитель: компания, объект, представитель
В слове «потребитель» слиплись три разные сущности — их нельзя смешивать.
Что
Роль в модели
Данные Grace
Компания
объект A7 Потребитель — свой цикл продаж
accounts
Объект
отдельный объект — место, где стоит оборудование
properties
Представитель
часть A7 (контактное лицо, интерфейс)
contacts
Покупатель — это компания. С ней отношения, она платит, проходит цикл: потенциальный → холодный → тёплый → горячий → покупатель → спящий. Объект — это место потребления оборудования, отдельный объект. Представитель — интерфейс к компании, не самостоятельный объект.
Связывает их Проект — это связь, а не объект: 
projects.account_id (компания) + 
projects.property_id (здание). Прямой связи «здание → компания» нет. Поэтому одно здание ↔ много компаний (проектировщик, генподрядчик, заказчик — вокруг одного объекта через разные проекты).
⚠️ Компания, которой продаём, часто посредник (генподрядчик), а не конечный выгодоприобретатель. Поэтому роль покупателя (генподрядчик / заказчик / проектировщик / системный интегратор) — ключевой атрибут A7: она говорит, где компания стоит в цепочке относительно здания.
Фазы жизненного цикла A7 (Потребитель)
Фаза
Что это
Состояние в Grace
A7.1 Идентификация
поиск клиента, ввод ИНН, квалификация
тип «Потенциальный»
A7.2 Привлечение
контакт → проект → заявка на расчёт → КП → переговоры
Холодный → Тёплый → Горячий; статусы сделки
A7.3 Обслуживание
договор → реализация → закрытие
«Покупатель»
A7.4 Оценка удовлетворённости
фиксация удовлетворённости
(в Grace в разработке)
A7.5 Удержание
повторные продажи, мониторинг активности
против «Спящий»
A7.6 Претензии / вывод
рекламации, гарантия
риск «Потерянный»
Ключевое: сделка / проект — не отдельный объект, а фазы A7.2–A7.3 жизненного цикла потребителя. История сделок, скрипты, клиентская база — всё это знание об одном объекте A7 в разных фазах.
Пробелы в данных (теплота клиента, удовлетворённость, роль покупателя — не синхронизированы в аналитический слой) — реестр на обогащение 
sync_agent и для агента аудита данных.

Продукт (A3) и Товар (A8)
Два разных объекта, которые легко спутать.
A3 Продукт
A8 Товар
Суть
что мы умеем делать — тип, конструкция
что делаем сейчас по заказу — экземпляр
Это
рецепт / чертёж / спецификация типа
конкретный шкаф под заказ
Данные Grace
nomenclatures, 
calc_nomenclatures (корпус, IP, ток, время сборки), прайсы, типовые решения
orders, 
order_items, фактический BOM, ОТК, отгрузка
Цена
плановая (прайс бренда)
фактическая себестоимость (закупка)
Контур (полка)
Инженерный
Производственный
Пример, чтобы щёлкнуло
A3 = «Шкаф ВРУ, корпус IEK 2000×800, Icu 25 кА, такая-то компоновка» — это тип / конструкция, описана один раз, переиспользуется в сотнях заказов. Знание инженера.
A8 = «Заказ №17795: 3 таких шкафа, запущены 12.07, прошли ОТК, отгружены 20.07» — это конкретные экземпляры на производстве.
Один и тот же «шкаф», но A3 — это его проект/спецификация (знание, стабильное), A8 — его физическое воплощение под заказ (производство, разовое).
Почему это важно отдельно для нас
Разрыв «плановая цена (A3) vs фактическая себестоимость (A8)» = корень ERP-боли ценообразования. Расчёт (
calculations) — мост: берёт каталог A3 и считает спецификацию конкретного A8.
Что из этого в книги
Инженерный (A3): БЗ-3 «Продукты и конфигурации» (каталог типовых решений, применяемость компонентов), БЗ-4 «Нормативная база».
Производственный (A8): БЗ-5 «Технологические стандарты» (техкарты сборки, нормативы времени), БЗ-6 «База дефектов и решений» (несоответствия ОТК на конкретных изделиях).
Верхний разрез учёта
Шире: Изделия (своё производство — основной A8), Товары (перепродажа — чужой A8), Услуги. Деление по напряжению: НН (до 1 кВ — щиты/НКУ) и СН (6–35 кВ — КРУ/ячейки).

Карточка объекта: A7 Потребитель (детально)
Домен / источник данных: Grace CRM/ERP. OpenSearch (89): 
itech_accounts (ядро), 
itech_projects (сделка = фаза ЖЦ), 
itech_contacts, 
itech_orders (стык с A8). Регламент: 
manager_crm_workflow.md (= 
rules_1.md, утв. 24.06.2024). Словарь: 
grace_concept_dictionary.md.
Бизнес-объект CoreStream: A7 Потребитель («Продвижение и продажи»).
Экземпляр объекта = один 
account в роли Покупателя (
type_id=1). ⚠️ Тот же 
account в роли поставщика — это объект A6 (двойная роль, см. §4).
Дата / автор: 2026-06-19, сессия моделирования KB. Заземлено на структуру индексов от 04.05.2026.
Принцип: данные Grace = зёрна (экземпляры). Эта карточка = контекст, из которого разворачиваются процесс (методы) и метрики (corestream-metrics). Фиксируется в BookStack (книга A7 на полке «Коммерческий»), питает агентов через Onyx-теги.
1. Атрибуты (только подтверждённые реальными полями)
Категория
Атрибут
Поле-источник
Тип
Замечание
Идентификаторы
ID контрагента
itech_accounts.id
int
PK
Идентификаторы
ИНН
itech_accounts.inn
keyword
юрлицо
Идентификаторы
Наименование
itech_accounts.name
text
ru_standard
Состояния
Тип контрагента
account_types / 
type_id
keyword
Покупатель=1 (роль в цепочке, НЕ теплота)
Состояния
Надёжность
reliability
keyword
категория
Состояния
Теплота клиента
—
enum
⚠️ Потенциальный/Холодный/Тёплый/Горячий/Покупатель/Спящий/Потерянный/Нулевой — НЕ синкнуто (см. §5)
Количественные
Кол-во сделок
project_count
int
Количественные
Кол-во заказов
order_count
int
Количественные
Выручка, млн
revenue_mln
float
Количественные
Оплачено / Долг, млн
paid_mln / 
debt_mln
float
дебиторка
Качественные
Отраслевые сектора
sectors
keyword
Качественные
Роль покупателя
—
enum
Генподрядчик/ЭМК/Проектировщик/Системный интегратор/Заказчик — словарь 
accounts/get/roles; ⚠️ в индексе явного поля нет
Временные
Создан
created_at
date
маркер фазы A7.1
Временные
Последний заказ
last_order_at
date
маркер активности (→ Спящий)
Внешние (связи-ссылки): 
manager_id, 
owned_by_id, 
assistant_user_id → A5 Сотрудник.
2. Жизненный цикл — 6 фаз (A7.1 → A7.6)
Состояние A7 двухуровневое: теплота (уровень контрагента, ⚠️ не синкнута) и статус сделки 
itech_projects.project_status (уровень сделки, синкнут). Сделка = фаза ЖЦ потребителя, не отдельный объект.
#
Фаза (A7.x)
Состояния объекта
Событие перехода дальше
Подтверждено полем
1
A7.1 Идентификация
Потенциальный (ИНН + роль)
внесены контактные данные
created_at; теплота ⚠️ нет поля; 
itech_contacts появляются
2
A7.2 Привлечение
Холодный→Тёплый→Горячий; сделка: Заявка на расчёт→Расчёт выполнен→Отправлено КП→Согласование договора
счёт переведён «в работу»
itech_projects.project_status, 
probability_percent, 
amount, 
forecast_date; 
itech_calculations.kp_exposed_at
3
A7.3 Обслуживание
Покупатель; сделка: Реализация→Закрытие
сделка закрыта / отгрузка
itech_orders.is_shipped, 
shipping_date_fact, 
project_status
4
A7.4 Оценка удовлетворённости
(удовлетворённость)
—
⚠️ нет поля (в Grace «в разработке»)
5
A7.5 Удержание
повторные продажи; риск Спящий
новая сделка / уход в Спящий
last_order_at, 
order_count; переход в Спящий ⚠️ не датирован
6
A7.6 Претензии / вывод
рекламация; Потерянный / Нулевой потенциал
закрытие отношений
itech_projects.refusal_reason; типы Потерянный/Нулевой — ⚠️ ручные, не синкнуты
Исключения: отказ по сделке (
refusal_reason, заполнен ~8%), Потерянный/Нулевой потенциал (менеджер вручную).
Спонтанные переходы: → Спящий автоматически при отсутствии активности > 3 мес (таймаут от 
last_order_at).
3. Методы (процессы объекта)
Вид
Метод
Код CoreStream
След в данных
Конструктор
Создание контрагента (внести ИНН, роль)
A7.1
insert 
itech_accounts + 
created_at
Адаптация
Квалификация, создание сделки, заявка на расчёт, КП
A7.2
itech_projects, 
itech_calculations.kp_exposed_at
Использование
Договор, реализация, заказы
A7.3
itech_orders (стык A8)
Валидация
Оценка удовлетворённости
A7.4
⚠️ нет следа
Воспроизводство
Повторные продажи, мониторинг активности
A7.5
itech_comments, напоминания; 
last_order_at
Деструктор
Рекламации, перевод в Потерянный/Нулевой
A7.6
refusal_reason; смена типа вручную
Методы данных (бизнес-правила): теплота проставляется CRM автоматически по событиям (но не синкается в OpenSearch); вероятность и плановая дата обновляются менеджером 25-го числа каждого месяца (регламент) → свежесть 
probability_percent/
forecast_date привязана к этой дате.
4. Связи
С объектом
Тип
Характер
Поле/механизм
Атрибуты связи
A5 Сотрудник (менеджер)
ассоциация
двусторонняя асимм.
manager_id, 
owned_by_id
ответственность
A8 Товар (заказ)
ассоциация
двусторонняя
itech_orders.account_id, 
project_id
сумма, отгрузка
Контактное лицо
агрегация
—
itech_contacts.accounts (nested)
должность, приоритет
Объект (здание)
ассоциация через Проект
—
itech_projects.property_id → 
itech_properties
⚠️ соседний самостоятельный объект (объектный контур), НЕ атрибут A7. Один объект ↔ много компаний
A2 Бизнес-система (договор)
связь-договор
—
договор = ассоциация A7↔A2
цена, сроки, оплата
A6 Поставщик (тот же account)
обобщение/полиморфизм
—
account_types=[1,2]
один субъект — два объекта по роли
Проект (
itech_projects) — это не объект, а интегрирующая связь (центральный узел функц. схемы): несёт фазы A7.2–A7.3 и соединяет A7 (компания) ↔ Объект (здание) ↔ A8 (заказ). Прямого ребра «Объект → Компания» нет — только через Проект. Поэтому «потребитель» = компания (свой ЖЦ продаж), а здание = место потребления (отдельный объект). Карта объектов → 
00_object_map.md.
5. Пробелы (не подтверждено данными — вход для Quality-агента / вопрос владельцу)
Теплота клиента не синкнута (Потенциальный→…→Спящий нет в 
itech_accounts) → воронку по теплоте из OpenSearch не построить; живёт только в Grace MySQL. Кандидат №1 на добавление в sync_agent.
Переходы теплоты не датированы → cycle time «сколько шёл от Холодного до Покупателя» не посчитать (нет таймстемпов фаз A7.1→A7.3 на уровне контрагента).
A7.4 удовлетворённость — поля нет (Grace «в разработке»).
Роль покупателя (Генподрядчик/ЭМК/…) — в индексе явного поля нет, только 
sectors.
status_updated_at в 
itech_projects = text и пуст ~53% → датировка переходов фаз сделки слабая.
refusal_reason заполнен ~8% → причины ухода (A7.6) почти не аналитируемы.
→ Эти пробелы — реестр для аудита и чистки данных и список на обогащение синхронизации (sync_agent).

Карточка объекта: A3 Продукт (детально)
Домен / источник данных: Grace. OpenSearch (89): 
itech_nomenclatures (мастер-каталог), 
itech_calc_nomenclatures (расчётная номенклатура — изделия со спецификой), 
brands_price_lists (прайсы вендоров). Словарь: концепт-словарь Grace §10.
Бизнес-объект CoreStream: A3 Продукт — конструкция / каталог, «что мы умеем делать» (тип, а не экземпляр).
Экземпляр объекта = одна позиция номенклатуры / изделие как ТИП (шкаф определённой конструкции или компонент с артикулом и характеристиками).
1. Атрибуты (по реальным полям)
Категория
Атрибут
Поле-источник
Замечание
Идентификаторы
ID
nomenclatures.id / 
calc_nomenclatures.id
Идентификаторы
Артикул
article
⚠️ внутренний артикул ITECH ≠ вендорскому
Идентификаторы
Наименование
name
Состояния
—
—
⚠️ статуса ЖЦ продукта НЕТ (каталог = плоский текущий срез)
Количественные
Цена (плановая)
calc_nomenclatures.price
прайс бренда
Количественные
Габариты корпуса
body_width/height/depth
Количественные
Icu, номин. ток
icu, 
rated_in
электрич. характеристики
Количественные
Модулей, масса
module_count, 
weight
Количественные
Время сборки / ТО / АСУ
assembly_time, 
service_time, 
asu_time
технологические нормативы продукта
Качественные
Бренд
brand
Качественные
Тип / бренд корпуса, IP
body_type, 
body_brand, 
body_ip
Качественные
Ценовая группа, ед. изм.
price_group, 
unit
Временные
Создан
nomenclatures.created_at
Внешние (связи): 
brand → Бренд / Вендор (A6 Производитель НКУ); применяется в BOM → A8 Товар.
2. Жизненный цикл — 6 фаз (A3.1 → A3.6)
#
Фаза
Состояние
Событие перехода
Подтверждено
1
A3.1 Разработка нового продукта
конструкция / спецификация изделия
запуск в производство
⚠️ не датируется
2
A3.2 Масштабирование и запуск
позиция в каталоге
⚠️ нет статуса
3
A3.3 Сопровождение производства и продаж
активная позиция
косвенно — через применение в заказах
4
A3.4 Анализ производительности продукта
⚠️ нет полей
5
A3.5 Совершенствование
версии конструкции
⚠️ нет версионирования
6
A3.6 Вывод из производства
снят с производства
—
⚠️ нет поля «снят / устарел»
Главный вывод: продукт-как-объект в данных почти не имеет жизненного цикла — есть только текущий каталог (срез на сейчас). Когда позиция введена, версионируется, снимается — не отслеживается.
3. Методы
Вид
Метод
Код
След в данных
Конструктор
Ввод позиции в каталог
A3.1
insert 
nomenclatures
Использование
Применение в расчёте / BOM
A3.3
bom_components.article
Мутатор
Обновление прайса
A3.3
brands_price_lists (файл прайса)
Деструктор
Снятие с производства
A3.6
⚠️ нет следа
4. Связи
С объектом
Тип
Поле/механизм
Замечание
Бренд / Вендор (A6 Производитель НКУ)
ассоциация
brand; регистрация объекта → защищённая цена
плановая цена
A8 Товар
ассоциация (применение)
article в 
bom_components
где / сколько применён
Компоненты (проектный BOM)
композиция
изделие ◆ компоненты
⚠️ проектный BOM ≠ фактическому
5. Пробелы
Нет ЖЦ / статуса продукта (введён / версия / снят) — только текущий каталог.
Внутренний артикул ITECH ≠ вендорскому → нужен маппинг (корень разрыва цен).
Проектный BOM (конструкция изделия) почти не доехал (~9%); 
itech_bom_components = фактический BOM расчёта, а не дизайн-спецификация.
Плановая цена живёт в файлах прайсов; связь «артикул ↔ цена» не прямая.

Карточка объекта: A8 Товар (детально)
Домен / источник данных: Grace. OpenSearch (89): 
itech_orders (шапка заказа), 
itech_order_items (позиции), 
itech_bom_components (фактический BOM), 
itech_calculations (расчёт / КП → спецификация).
Бизнес-объект CoreStream: A8 Товар — конкретный ЭКЗЕМПЛЯР, «что делаем сейчас по заказу» (в отличие от A3 — конструкции).
Экземпляр объекта = позиция заказа (конкретное изделие в производстве); заказ — агрегат позиций.
1. Атрибуты (по реальным полям)
Категория
Атрибут
Поле-источник
Замечание
Идентификаторы
Номер заказа, позиция
orders.order_number, 
order_items.id
Идентификаторы
Артикул
order_items.article
→ A3 Продукт
Состояния
Статус заказа / производства
status_id, 
status_production_id
производственные состояния — ЕСТЬ
Состояния
Отгружен
is_shipped
флаг финальной фазы
Количественные
Кол-во, цена, сумма
quantity, 
price, 
amount, 
amount_wo_vat
Количественные
Плановая себестоимость
purchase_plan
план
Количественные
Прибыль, часы
profit_amount, 
hours_plan, 
hours_estimation
Количественные
Итог / себест. заказа
orders.total_cost, 
general_purchase
агрегат
Качественные
Тип счёта, тип продукта
bill_type, 
product_type_name
Качественные
Гарантийный / внутр. / перепаковка / приоритет
is_guarantee, 
is_inner, 
is_repack, 
is_priority
Временные
Создан, запуск
created_at, 
run_date
маркеры A8.1
Временные
Отгрузка план / факт / договор
shipping_date_plan / 
_fact / 
_by_contract
A8.6
Внешние (связи): 
account_id → A7 Потребитель; 
project_id → Проект (фаза A7); 
manager_id → A5; 
article → A3 Продукт.
2. Жизненный цикл — 6 фаз (A8.1 → A8.6)
#
Фаза
Состояние
Событие перехода
Подтверждено
1
A8.1 Формирование произв. программы
заказ создан, в плане
запуск
run_date, 
in_plan, 
status_production_id
2
A8.2 Подготовка производства
BOM, закупка
старт цикла
bom_components, 
purchase_items
3
A8.3 Выполнение произв. цикла
в производстве
передача на ОТК
status_production_id
4
A8.4 Контроль качества (ОТК)
на контроле
принято / возврат
⚠️ 
status_production_id частично; типы несоответствий — в комментариях, не структурно
5
A8.5 Обработка несоответствий
возврат / перепаковка
устранено
is_repack (только флаг) ⚠️
6
A8.6 Обработка готовой / отгрузка
отгружен
—
is_shipped, 
shipping_date_fact, 
shipped_year
3. Методы
Вид
Метод
Код
След в данных
Конструктор
Создание заказа
A8.1
insert 
orders + 
run_date
Адаптация
Подготовка, BOM, закупка
A8.2
bom_components, 
purchase_items
Использование
Производственный цикл
A8.3
status_production_id
Валидация
Контроль ОТК
A8.4
чек-лист в CRM ⚠️ слабо в данных
Воспроизводство
Обработка несоответствий
A8.5
is_repack
Деструктор
Отгрузка / передача
A8.6
is_shipped, 
shipping_date_fact
4. Связи
С объектом
Тип
Поле/механизм
Атрибуты связи
A7 Потребитель
ассоциация
orders.account_id
сумма
Проект (связь, фаза A7)
ассоциация
orders.project_id
A3 Продукт
ассоциация (что производим)
article → 
nomenclatures
Позиции / BOM
композиция
заказ ◆ позиции ◆ компоненты
кол-во, стоимость
A10 Капитал
ассоциация
expected_payments.order_id
оплата / долг
A5 Сотрудник
ассоциация
manager_id
5. Пробелы
ОТК (A8.4) и брак (A8.5) слабо структурированы — типы несоответствий в комментариях и флагах (
is_repack), не отдельными полями.
Фактическая себестоимость по компоненту: 
bom_components.cost (план?) vs фактическая закупка (
purchase_items.received_quantity) — разрыв план/факт = та же ERP-боль ценообразования.
status_production_id — числовой код без расшифровки переходов в индексе.

Три потока и объектная модель
Базу знаний мы строим от бизнес-объектов (см. «Объектная основа»). Поверх объектов лежит вторая линза — три потока процессов: основной, управленческий, обеспечивающий. Важно: потоки и объектная модель не конкурируют — поток классифицирует методы объектов по их роли.
Объект и поток — две линзы на одно
Объект — что это: спина модели (атрибуты, фазы жизненного цикла, методы).
Поток — роль методов объекта в бизнесе: создаём ценность / управляем / обеспечиваем.
Ключ: поток — это классификация методов по роли. Один и тот же объект разными фазами может попадать в разные потоки. Поэтому потоки не ломают объектную модель — они её группируют сверху.
Карта: поток → объекты → контуры
Поток
Роль
Объекты
Контуры (полки)
Основной
прямо ведут к продукту и клиенту
A7 Потребитель · A3 Продукт · A8 Товар · Здание
Коммерческий · Инженерный · Производственный · Объекты
Управленческий
задают цели, планируют, контролируют
A2 Бизнес-система · A1 Группы влияния · A10 Капитал (фаза планирования)
СМК/ISO · Стратегия и планирование
Обеспечивающий
дают ресурсы и ведут учёт
A5 Трудовые ресурсы · A4 Активы · A6/A9 Снабжение и логистика · A10 Капитал (фаза учёта)
HR · АХО · Снабжение · Бухгалтерия
Пример: финансы делятся по фазам, а не на два объекта
Финансовый блок естественно делится на Стратегию/планирование и Бухгалтерию. В объектной модели это не два объекта — это один объект A10 Капитал, разрезанный по фазам жизненного цикла:
ранние фазы (бюджет, инвестиции, финансовая стратегия) → управленческий поток;
операционные фазы (учёт, платежи, отчётность) → обеспечивающий поток.
Объект один; поток определяется тем, какую фазу/метод мы рассматриваем. Теги 
объект-cs: a10 и 
фаза: держат это связно: две полки — но обе проекция A10 в разных фазах.
Не путать два «управления»
Управленческий поток — управление бизнесом (стратегия, финплан, цели): объекты A2/A10/A1, контурные полки.
Управление знаниями — управление самой базой знаний (объект A11: как ведём BookStack). Это мета-слой, отдельная полка.
Вывод
Три потока — это верхняя группировка над контурными полками, а не новая ось разбиения. Она даёт законное место управленческому контуру (стратегия, СМК, финпланирование) и обеспечивающему (HR, АХО, снабжение, бухгалтерия), оставляя спиной по-прежнему объекты.

Зачем нужны контурные книги
Контурная книга (БЗ-1…11) — это дом контекста-знания по одному бизнес-объекту (например, БЗ-7 — об объекте A7 Потребитель). Зачем они нужны.
Пять целей
Дать агенту и человеку контекст для чтения данных. Данные Grace сами по себе — зёрна без смысла. Книга объясняет, что такое объект, его жизненный цикл, как читать его данные и по каким правилам. Тогда ответы AI обоснованы, а не выдуманы.
Превратить опыт «в головах» в актив. Прецеденты, скрипты, стандарты, выводы сейчас разрознены или у людей в голове. Книга фиксирует их как устойчивый, находимый ресурс.
Связать данные ↔ процесс ↔ метрики через объект. Объект → его фазы → его метрики (эконометрика). Книга — спина, которая соединяет контекст (BookStack), данные (Grace) и метрики через теги.
Дать единицу зрелости. Каждый блок знаний (БЗ) — самостоятельный актив; его зрелость измеряется моделью зрелости. Книга — то, что оцениваем и растим: от «в головах» до «живой контекст AI-агента».
Питать ассистентов Onyx. Полка = document set, книга = ограниченный контекст знания → ассистент достаёт точный контекст под вопрос, а не «всё подряд».
Граница
Книга держит знание (контекст, правила, опыт), а не данные (экземпляры). Данные — всегда в Grace/OpenSearch. Книга = «как понимать и читать данные» + переиспользуемый опыт. Поэтому книга не дублирует CRM/ERP, а делает её осмысленной для людей и AI.