Объектная модель базы знаний (CoreStream)

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

Объектная основа базы знаний

База знаний ITECH строится от бизнес-объектов, а не от папок отделов. Методика — CoreStream: бизнес = взаимодействующие объекты (A1–A11), процессы = действия, меняющие их состояния.

Зачем так

Данные в Grace — это зёрна (конкретные записи: контрагенты, проекты, заказы). Сами по себе они не дают понимания. Объектная модель — это контекст, который придаёт зёрнам смысл: что это за объект, какие у него фазы жизни, с чем связан. Из контекста разворачиваются и процесс (что с объектом делают), и метрики (сколько длится, сколько стоит).

Поэтому: Grace держит данные, BookStack фиксирует контекст, агент соединяет их.

Две оси

  1. О чём знание → бизнес-объект (становится книгой KB).
  2. Как знание живёт → жизненный цикл объекта «Знания» (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 — это его проект/спецификация (знание, стабильное), A8 — его физическое воплощение под заказ (производство, разовое).

Почему это важно отдельно для нас

Разрыв «плановая цена (A3) vs фактическая себестоимость (A8)» = корень ERP-боли ценообразования. Расчёт (calculations) — мост: берёт каталог A3 и считает спецификацию конкретного A8.

Что из этого в книги

Верхний разрез учёта

Шире: Изделия (своё производство — основной A8), Товары (перепродажа — чужой A8), Услуги. Деление по напряжению: НН (до 1 кВ — щиты/НКУ) и СН (6–35 кВ — КРУ/ячейки).

Карточка объекта: A7 Потребитель (детально)

Принцип: данные 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-агента / вопрос владельцу)

→ Эти пробелы — реестр для аудита и чистки данных и список на обогащение синхронизации (sync_agent).

Карточка объекта: 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. Пробелы

Карточка объекта: A8 Товар (детально)

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. Пробелы

Три потока и объектная модель

Базу знаний мы строим от бизнес-объектов (см. «Объектная основа»). Поверх объектов лежит вторая линза — три потока процессов: основной, управленческий, обеспечивающий. Важно: потоки и объектная модель не конкурируют — поток классифицирует методы объектов по их роли.

Объект и поток — две линзы на одно

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

Карта: поток → объекты → контуры

Поток Роль Объекты Контуры (полки)
Основной прямо ведут к продукту и клиенту A7 Потребитель · A3 Продукт · A8 Товар · Здание Коммерческий · Инженерный · Производственный · Объекты
Управленческий задают цели, планируют, контролируют A2 Бизнес-система · A1 Группы влияния · A10 Капитал (фаза планирования) СМК/ISO · Стратегия и планирование
Обеспечивающий дают ресурсы и ведут учёт A5 Трудовые ресурсы · A4 Активы · A6/A9 Снабжение и логистика · A10 Капитал (фаза учёта) HR · АХО · Снабжение · Бухгалтерия

Пример: финансы делятся по фазам, а не на два объекта

Финансовый блок естественно делится на Стратегию/планирование и Бухгалтерию. В объектной модели это не два объекта — это один объект A10 Капитал, разрезанный по фазам жизненного цикла:

Объект один; поток определяется тем, какую фазу/метод мы рассматриваем. Теги объект-cs: a10 и фаза: держат это связно: две полки — но обе проекция A10 в разных фазах.

Не путать два «управления»

Вывод

Три потока — это верхняя группировка над контурными полками, а не новая ось разбиения. Она даёт законное место управленческому контуру (стратегия, СМК, финпланирование) и обеспечивающему (HR, АХО, снабжение, бухгалтерия), оставляя спиной по-прежнему объекты.

Зачем нужны контурные книги

Контурная книга (БЗ-1…11) — это дом контекста-знания по одному бизнес-объекту (например, БЗ-7 — об объекте A7 Потребитель). Зачем они нужны.

Пять целей

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

Граница

Книга держит знание (контекст, правила, опыт), а не данные (экземпляры). Данные — всегда в Grace/OpenSearch. Книга = «как понимать и читать данные» + переиспользуемый опыт. Поэтому книга не дублирует CRM/ERP, а делает её осмысленной для людей и AI.