База знаний компании¶

База знаний компании — то, что платформа знает о самой организации: что она продаёт и делает, как устроена, какими лицензиями, договорами, активами и опытом располагает. Процессы берут это знание шагом recall, исполнители задач — в контексте, а сроки действия документов и договоров сами превращаются в задачи ответственным. Статья для администраторов базы знаний и авторов процессов. Обоснование — TAI-ADR-0056; хранит знание память платформы, пишут и читают его только через Control Plane.

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

flowchart LR
    T[Таблица XLSX/CSV] -->|knowledge-import<br/>план → решение| CP[Control Plane]
    D[Документ PDF/DOCX] -->|knowledge-document<br/>поля с цитатами → подтверждение| CP
    C[1С по OData] -->|onec-connector<br/>снимки| CP
    CP -->|сверка снимков| M[(Граф знаний<br/>namespace дерева workspace)]
    M -->|recall, контекст задачи| P[Процессы и исполнители]
    M -->|knowledge.expiring@1| R[Правило knowledge-expiry] -->|задача роли| H[Ответственный]

Из чего состоит¶

Часть	Что это
онтология `company@1`	базовые виды и связи любой компании (пакет онтологии памяти)
отраслевые пакеты онтологии	расширения, например `procurement@2` для закупок
пакеты арендатора	собственные виды компании, `scope: tenant`
пакет каталога `company-knowledge`	типы задач `knowledge-import`, `knowledge-document`, `knowledge-expiry`; типы артефактов `knowledge-file`, `knowledge-import-plan`; роль `knowledge-owner`; скиллы; правило `knowledge-expiry`; агенты `knowledge-rules` и `onec-connector`
интеграция `company_knowledge`	код скиллов: шаблоны, проверка таблиц, план и применение, извлечение текста документов, истечение сроков
интеграция `onec`	коннектор 1С — см. Коннектор 1С

Скиллы пакета:

Скилл	Побочные эффекты	Что делает
`knowledge.template@1`	нет	шаблон загрузки вида (XLSX или CSV) — см. Шаблоны загрузки
`knowledge.import_plan@1`	нет	проверка таблицы и план изменений без записи
`knowledge.import_apply@1`	запись	применение ровно показанного плана
`knowledge.document_extract@1`	запись (документ)	текст документа в базу знаний, поля сущности с цитатами
`knowledge.document_apply@1`	запись	подтверждённые человеком поля — сущностью со связью к документу
`knowledge.expiring@1`	нет	сущности, срок действия которых истекает

Онтология `company@1`¶

Базовый пакет онтологии — нейтральные виды любой компании. Организация компании и контрагенты — вид legal_entity пакета default (ключ — ИНН); company@1 его не переобъявляет, а описывает его атрибуты профилем (name, shortName, inn, kpp, ogrn, own — своя организация или контрагент, smallBusiness, regionCode).

Вид	Ключ	Что это	Поиск по смыслу
`org_unit`	`unit:<source>:<id>`	подразделение	—
`role`	`role:<slug>`	роль в компании; атрибут `platformRole` — роль платформы	—
`site`	`site:<source>:<id>`	площадка, склад, офис	—
`offering`	`offering:<source>:<id>`	товар, работа или услуга (`type`: `product`, `work`, `service`), коды ОКПД2, единица ОКЕИ, характеристики, себестоимость	`description`, `okpd2`
`offering_group`	`group:<source>:<id>`	группа номенклатуры	—
`capability`	`capability:<slug>`	профиль работ — что компания умеет делать, коды ОКПД2 профиля	`description`, `okpd2`
`asset`	`asset:<source>:<id>`	оборудование, техника, продукт; срок — например поверка или гарантия	—
`agreement`	`agreement:<source>:<id>`	договор: номер, дата, предмет, направление (`sale`, `purchase`, `other`), сумма, лимит, условия оплаты, статус	—
`credential`	`credential:<type>:<number>`	лицензия, сертификат, аккредитация, членство, допуск, разрешение; область действия и лимиты	`coverage`
`engagement`	`engagement:<source>:<id>`	выполненная работа для контрагента: предмет, коды, сумма, сроки, роль компании (`prime`, `subcontractor`, `partner`)	`subject`
`classifier_code`	`code:<classifier>:<value>`	код классификатора (ОКПД2, ОКВЭД, ОКЕИ и др.)	—

<source> в ключе — источник, который ведёт запись (template:offering, onec:<база>), <id> — код записи в источнике. Колонка «Поиск по смыслу» — поле searchable вида: сущности таких видов находит смысловой добор recall.

Связи:

Связь	Откуда	Куда
`unit_of`	`org_unit`	`org_unit`, `legal_entity`
`belongs_to`	`role`, `site`, `asset`	`org_unit`, `legal_entity`
`located_at`	`org_unit`, `asset`	`site`
`performs`	`org_unit`, `role`	`capability`
`item_of`	`offering`, `offering_group`	`offering_group`
`coded_as`	`offering`, `offering_group`, `capability`, `engagement`	`classifier_code`
`held_by`	`credential`	`legal_entity`, `org_unit`
`covers`	`credential`	`capability`, `offering`, `classifier_code`
`party_to`	`legal_entity`	`agreement`, `engagement`
`serves`	`org_unit`	`legal_entity` — подразделение ведёт контрагента
`evidenced_by`	`credential`, `engagement`, `agreement`, `asset`, `offering`	`document`

Сроки действия¶

Срок действия у любого вида — атрибуты validFrom и validUntil: день в формате ISO 8601 (2026-12-31), в схеме — type: string, format: date. В company@1 сроки есть у asset, agreement и credential. По validUntil работает истечение сроков, по нему же проверяются требования в первичном анализе тендера.

Людей в графе нет¶

В базе знаний нет сотрудников и физических лиц. Роль (role) связывается с учётными записями платформы атрибутом platformRole — ключом роли платформы, на которую назначаются задачи. Процесс, найдя роль по связям (подразделение ведёт контрагента, роль входит в подразделение), назначает задачу на role:<platformRole>, а не на человека. Как персональные данные не попадают в граф и в промпты ИИ — в разделе Персональные данные.

Пакеты онтологии¶

Онтология собирается из пакетов трёх видов:

Вид пакета	Пример	Кто регистрирует	Где виден
встроенный	`company@1`, `process-knowledge@1`	администратор платформы	общий реестр
отраслевой	`procurement@2`	администратор платформы	общий реестр
арендатора	`tenant:acme-logistics@1`	арендатор, право `knowledge.packs.manage`	только namespace арендатора и деревья под ним

Отраслевой пакет расширяет базовый, не меняя его: объявляет extends: ["company@1"], добавляет свои виды и связи и описывает атрибуты чужих видов профилями. Так procurement@2 добавляет вид product_registry_entry (запись реестра продукции или ПО) со связью registered_as от предложения или актива, а членство в СРО описывает профилем вида credential с условием when: {attr: memberOf, equals: sro} — уровень ответственности и предельный размер обязательств. Коды КТРУ — это classifier_code базового пакета (code:ktru:<позиция>).

Форма пакета — packages/schema/v1/knowledge-pack.schema.json:

Поле	Что задаёт
`name`, `version`	имя без префикса и версию; зарегистрированная версия неизменна — правка описания требует новой версии
`scope`	`common` (по умолчанию) или `tenant`
`extends`	пакеты, на виды которых ссылаются связи и профили
`kinds[]`	вид: `kind`, `title`, `description`, `naturalKey`, `attributes` (JSON Schema), `searchable`
`relations[]`	связь: `relation`, `title`, `fromKinds`, `toKinds`, `temporal`, `cardinality` (`one` или `many`)
`profiles[]`	атрибуты вида этого или другого пакета; с `when` — только у сущностей, где атрибут равен значению
`expiry[]`	кому и за сколько дней напоминать об истечении срока вида: `kind`, `role`, `leadDays` (1–365)

Регистрация и включение¶

Пакет попадает в память только через ядро: регистрация — POST /api/v1/knowledge/packs, включение для дерева workspace — PUT /api/v1/workspaces/{id}/knowledge-packs (см. Контекст задачи и память).

Общий пакет регистрирует только администратор платформы из CP_KNOWLEDGE_PACK_ADMINS.
Пакет арендатора (scope: tenant) регистрирует арендатор по праву knowledge.packs.manage. Владельца — namespace арендатора — подставляет ядро; поле namespace в теле запроса отвергается. Имена пакета, видов и связей не должны совпадать с общими: совпадение с общим пакетом — 422 pack_invalid. В настройке namespace на пакет арендатора ссылаются как tenant:<имя>@<версия>.
Включение задаётся на корне дерева workspace (422 workspace_not_root) правом workspaces.manage, только закреплёнными ссылками имя@версия (422 pack_version_required). Запрос заменяет набор пакетов целиком — перечисляйте все нужные.

Встроенный пакет company@1 регистрируется и включается командой интеграции company_knowledge (из её каталога):

uv run taimen-company-knowledge-pack show        # пакет как JSON — тело POST /knowledge/packs
uv run taimen-company-knowledge-pack register --server https://platform.example.com
uv run taimen-company-knowledge-pack enable --server https://platform.example.com \
    --workspace <root-workspace-id> --pack default@1 --pack process-knowledge@1

enable добавляет company@1 к перечисленным --pack и заменяет ими набор.

Пакет арендатора проверяется, регистрируется и включается командами руководства (см. Агент в Claude Code):

python3 tools/knowledge.py pack-check --file vehicles.pack.yaml
python3 tools/knowledge.py pack-register --server https://platform.example.com \
    --file vehicles.pack.yaml --yes
python3 tools/knowledge.py pack-enable --server https://platform.example.com \
    --workspace <root-workspace-id> --pack default@1 --pack company@1 \
    --pack tenant:acme-logistics@1 --yes

Изоляция пакетов арендатора

Пакет арендатора виден и включается только в namespace арендатора и деревьях workspace под ним. Другие арендаторы его не видят. Описание пакета арендатора не встроено в скиллы платформы, поэтому задачи загрузки несут его с собой — поле definitions задач knowledge-import и knowledge-document.

Загрузка таблицы¶

Таблица загружается потоком из примитивов ядра: задача, файл-артефакт, план без записи, решение человека, применение. Нового сервиса и разбора файлов в ядре нет. Этот поток одинаково проходят раздел «База знаний» веб-консоли (шаблон, кнопка «Загрузить», история загрузок со ссылками на план и решение), команда tools/knowledge.py import-start и агент в Claude Code. Решающий по умолчанию — тот, кто загружает.

sequenceDiagram
    participant U as Человек или агент
    participant CP as Control Plane
    participant P as knowledge.import_plan@1
    participant A as knowledge.import_apply@1
    participant M as Память
    U->>CP: задача knowledge-import (pack, kind, source)
    U->>CP: файл — артефакт knowledge-file
    U->>CP: вызов скилла плана
    P->>CP: содержимое артефакта
    P->>CP: POST /knowledge/snapshots:preview
    CP->>M: сверка без записи
    M-->>P: что откроется / изменится / закроется, stateToken
    P-->>U: план → артефакт knowledge-import-plan, сводка в описании задачи
    U->>CP: запрос решения (ворота approval)
    Note over U,CP: человек смотрит план и решает
    CP->>A: approved → invokeSkill
    A->>CP: POST /knowledge/snapshots с expectedState
    alt база не изменилась с плана
        CP->>M: применение
        A-->>CP: applied → задача done
    else база изменилась
        M-->>A: 409 snapshot_stale
        A-->>CP: stale → комментарий, задача открыта, план заново
    end

Задача knowledge-import в workspace базы знаний. Поля: pack, kind, profile, source (по умолчанию template:<вид>), packs — другие включённые пакеты, definitions — описания пакетов арендатора.
Файл — артефакт knowledge-file задачи с содержимым (XLSX или CSV).
План — knowledge.import_plan@1. Скилл проверяет таблицу по шаблону вида (см. Шаблоны загрузки), собирает полный снимок источника и спрашивает ядро, что изменит его сверка (POST /api/v1/knowledge/snapshots:preview). В базу ничего не пишется. План — артефакт knowledge-import-plan (JSON), сводка — в описании задачи, planStatus и stateToken — в полях задачи.
Решение запрашивается, только если planStatus: ok. Таблица с ошибками плана не получает (invalid): задача остаётся открытой со списком ошибок.
Применение. approved по типу задачи вызывает knowledge.import_apply@1: тот же снимок из того же файла применяется только в состоянии плана (expectedState). snapshotId — публичный id задачи, поэтому повтор решения второй записи не делает. Итог applied закрывает задачу с комментарием о числах.
Stale. Если база изменилась после плана, ядро отвечает 409 snapshot_stale, скилл — status: stale, задача остаётся открытой с комментарием. План строится заново по тому же файлу, решение запрашивается снова.
rejected отменяет задачу, база не меняется.

Выход плана:

Поле	Что значит
`status`	`ok` — план построен; `invalid` — таблица не прошла проверку; `empty` — нечего открывать и закрывать
`templateVersion`, `source`, `rows`	версия шаблона, источник, строк в файле
`counts`	`opened`, `changed`, `closed`, `unchanged`
`opened`, `changed`, `closed`	ключи `{kind, key}` (не больше 200 в списке; `truncated`)
`conflicts`	ключи, которые уже ведёт другой источник
`rowErrors`	ошибки `{row, column, code, message}`
`stateToken`	состояние базы, на котором построен план

Снимок полный: чего нет в файле — закроется

Источник владеет своими записями. Загрузка таблицы — полный снимок источника template:<вид> (или указанного source): запись, которая была в прошлой загрузке и пропала из файла, закроется. Файл с частью номенклатуры закроет остальную. Поэтому таблица с ошибками плана не получает: строка с ошибкой, не попав в снимок, закрыла бы свою запись. Проверяйте раздел «закроется» в плане.

Запуск с машины человека:

python3 tools/knowledge.py import-start --server https://platform.example.com \
    --workspace <workspace-id> --file offering.xlsx --pack company@1 --kind offering
python3 tools/knowledge.py import-replan --server https://platform.example.com \
    --task <public-id задачи> --file-artifact <id артефакта файла>

import-start заводит задачу, кладёт файл, строит план и запрашивает решение (--approver — кто решает, по умолчанию вызывающий). import-replan — план заново после stale. Применяет план только решение по задаче (см. Approvals).

Документы¶

Лицензия, договор, акт выполненных работ — документ, из которого получается сущность. Поток — задача knowledge-document:

Задача с полями pack, kind (например credential для лицензии, engagement для выполненной работы), links — связи документа {rel, kind, key}; файл — артефакт knowledge-file.
knowledge.document_extract@1 извлекает текст: PDF по страницам, DOCX с заголовками и таблицами, XLSX построчно, текст. Документ сохраняется в базе знаний фрагментами (POST /api/v1/knowledge/documents, ключ документа — document:<хэш содержимого>: тот же файл — тот же документ).
ИИ предлагает поля сущности по схеме атрибутов вида — к каждому полю цитата из документа и номер страницы. Цитата, которой нет в тексте, помечается confidence: low («цитата не найдена»). Значение, не подходящее по типу, или похожее на персональные данные — отбрасывается. Предложение с цитатами — в описании задачи, значения — в поле attributes задачи.
Человек проверяет и правит поле attributes (при нужде key, title) и решает по задаче.
approved вызывает knowledge.document_apply@1: поля, как их оставил человек, проверяются по схеме вида и пишутся снимком источника document:<ключ документа> — сущность и связь evidenced_by к документу. Поле не прошло проверку — комментарий с причиной (validation_failed), задача открыта: поправьте attributes и запросите решение снова. rejected отменяет задачу; документ остаётся в базе знаний, сущность не пишется.

Ситуация	Что происходит
скан без текстового слоя	`textStatus: needs_manual_input`, ИИ не вызывается, поля заполняет человек по файлу
ИИ недоступен	документ сохранён, поля пусты, в описании — пометка; заполняет человек
файл не читается	ошибка скилла `file_unreadable`

uv run taimen-company-knowledge-document --server https://platform.example.com \
    --workspace <workspace-id> --file license.pdf --pack company@1 --kind credential \
    --link '{"rel":"held_by","kind":"legal_entity","key":"<ИНН>"}'

Предложенные значения остаются в описании задачи, итоговые — в снимке: правка человека видна.

Истечение сроков¶

Правило knowledge-expiry раз в сутки находит сущности, срок действия которых истекает, и заводит по каждой задачу ответственной роли.

flowchart LR
    S[Расписание<br/>раз в сутки] --> R[Правило knowledge-expiry<br/>личность knowledge-rules]
    R --> K[knowledge.expiring@1]
    K -->|POST /knowledge/entities:query<br/>validUntil в окне| M[(Граф знаний)]
    K -->|items| R
    R -->|ensure_work, дедуп<br/>вид:ключ@validUntil| T[Задача knowledge-expiry<br/>на role:‹роль›]

Какие виды. Все виды пакетов из входа правила packs (по умолчанию company@1), у схемы которых или у профиля без when есть атрибут validUntil, плюс виды из раздела expiry пакетов. Отраслевой пакет или пакет арендатора добавляется во вход packs (описание пакета арендатора — в definitions).
Кому и за сколько дней. Раздел expiry пакета онтологии: роль и leadDays. Поверх него — вход expiry правила. Без записи — роль knowledge-owner и defaultLeadDays (30). В company@1: agreement — 30 дней, credential — 60, asset — 30; в procurement@2: product_registry_entry — 60.
Окно. validUntil в пределах [asOf − graceDays, asOf + leadDays], graceDays по умолчанию 7: давно истёкшее (история учётной системы) задач не порождает, а пропущенный запуск правила не теряет только что истёкшее.
Дедупликация — ключ <вид>:<ключ>@<validUntil>: повторный запуск не дублирует задачу, а продлённый и снова истекающий срок — новая работа.
Задача knowledge-expiry — поля pack, kind, key, validUntil; в описании — сколько дней осталось и что сделать: продлить и загрузить новый срок (таблицей, документом или из учётной системы) либо закрыть задачу, если сущность больше не нужна.

Правило действует личностью knowledge-rules (агент без размещения, placement: none) с правами events.read, skills.invoke, tasks.read, tasks.write. Установка заводит ей IAM service account и связку PUT /api/v1/agents/knowledge-rules/identity; пока связки нет, оценка правила завершается failed: credential_inactive (см. Личность правила). Workspace правила — переменная установки ${KNOWLEDGE_WORKSPACE_ID}.

Перечень сущностей¶

POST /api/v1/knowledge/entities:query — все сущности видов, действующие на дату, с фильтрами по атрибутам, постранично. Им пользуется скилл истечения сроков (ctx.knowledge.query в skill-sdk).

Поле запроса	Что значит
`workspaceId`	workspace; читается namespace корня его дерева
`kinds`	1–20 видов
`where`	до 20 условий `{attr, op, value}`, соединяются через И; `op`: `eq`, `in` (1–100 значений), `prefix` (код по сегментам через точку), `lte`, `gte` (число или дата RFC 3339), `exists`
`asOf`	на какой момент (по умолчанию — сейчас)
`limit`	1–500, по умолчанию 100
`cursor`	`nextCursor` прошлой страницы при тех же остальных полях

curl -s -X POST https://platform.example.com/api/v1/knowledge/entities:query \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{
    "workspaceId": "<workspace-id>",
    "kinds": ["credential", "agreement"],
    "where": [{"attr": "validUntil", "op": "lte", "value": "2026-12-31"}],
    "limit": 100
  }'

{
  "items": [
    {"kind": "credential", "key": "credential:license:Л-001", "title": "Лицензия",
     "attributes": {"type": "license", "number": "Л-001", "validUntil": "2026-11-30"},
     "source": "template:credential"}
  ],
  "nextCursor": null,
  "asOf": "2026-10-01T09:00:00+00:00"
}

Порядок стабильный — по виду и ключу. Список кончается только на nextCursor: null: страница может содержать меньше limit элементов и до конца.

Право — events.read на workspace (то же, что у чтения контекста); видимость — вызывающего. Без доступа к знанию дерева — 403.
Память не настроена или не ответила вовремя — 503, сбой памяти — 502.

Знание в процессах¶

Процесс берёт знание компании шагом recall (см. Процессы и база знаний): якорь — организация по ИНН, обход — связи онтологии, kinds — нужные виды, where — фильтры по атрибутам ($defs/memoryWhere схемы каталога; значения — CEL от данных экземпляра). Два потребителя в поставке:

оплата счёта (invoice-payment) — от контрагента по party_to к договорам, по serves к подразделению, которое его ведёт, и по belongs_to к ролям; действующий договор выбирается по validFrom/validUntil и status, лимит — limitAmount или amount, проверяющая роль — platformRole найденной роли:

- id: recall-counterparty
  recall:
    anchors: [{kind: legal_entity, key: data.supplierInn}]
    traverse:
      - {relation: party_to, direction: out, depth: 1, limit: 50}
      - {relation: serves, direction: in, depth: 1, limit: 10, from: anchors}
      - {relation: belongs_to, direction: in, depth: 1, limit: 20, from: previous}
    kinds: [legal_entity, agreement, org_unit, role]
    limit: 100
    timeout: PT2M

тендеры — первичный анализ закупки до go/no-go: см. Первичный анализ тендера.

Персональные данные¶

Персональные данные физических лиц не попадают ни в граф, ни в промпты ИИ:

Где	Как
шаблоны	колонки с персональными данными (`фио`, `паспорт`, `снилс`, `телефон`, `e-mail`…) запрещены; таблица с такой колонкой не проходит проверку — см. Шаблоны загрузки
значения в таблице и полях документа	значение, похожее на ФИО, СНИЛС, паспорт, телефон или e-mail, — ошибка строки или отброшенное поле
пакет онтологии	атрибут с персональными данными допустим только пометкой `x-personal-data: allowed`; такое поле ИИ не заполняет и в промпт не получает
коннектор 1С	профили не читают сотрудников и физических лиц — см. Коннектор 1С
промпты ИИ	страж skill-sdk: `ctx.llm` пропускает `system_prompt` и `messages` через проверку и заменяет найденное маркером вида `[ПДн:фио]`; в журнал пишется только сколько и чего найдено, без значений

Страж консервативен к деловому тексту: ИНН и КПП организаций, коды, суммы и даты он не трогает; паспорт распознаётся только рядом со словами «паспорт» или «серия», ФИО — по отчеству или по инициалам рядом с фамилией. Любой адрес e-mail маскируется.

Агент в Claude Code¶

Плагин автора процессов (см. Автор процессов в Claude Code) несёт два скилла базы знаний. Оба сначала проверяют всё локально — тем же кодом, что потом исполнит платформа, — и ничего не пишут без явного согласия человека.

Скилл плагина	Когда	Что делает
`knowledge-import`	человек даёт таблицу и просит загрузить	выясняет вид и пакет, строит шаблон, переносит колонки файла в шаблон (без персональных данных), проверяет локально, заводит задачу с планом, показывает план и одобряет решение только после явного «да» на этот план
`knowledge-model`	нужного вида нет в базовом пакете	интервью о сущности, сначала поиск готового вида или профиля, описание пакета арендатора, `pack-check`, план регистрации; регистрирует и включает только после явного «да»

Команды руководства (из корня поставки, окружение — uv run --project integrations/company_knowledge):

Команда	Пишет	Что делает
`template --pack --kind --out <файл .xlsx или .csv>`	нет	шаблон загрузки вида
`check --file --pack --kind`	нет	проверка таблицы загрузчиком платформы; код выхода 0 — `status: ok`
`pack-check --file <описание пакета>`	нет	схема, конфликты имён видов и связей с включёнными пакетами, шаблон по каждому виду, план регистрации
`import-start --server --workspace --file --pack --kind`	задачу и план	задача, файл, план и запрос решения
`import-replan --server --task --file-artifact`	план	план заново после `stale`
`pack-register --server --file --yes`	да	регистрация пакета арендатора
`pack-enable --server --workspace --pack … --yes`	да	новый набор пакетов дерева workspace целиком

Общие ключи вида: --profile (значение профиля, например sro), --packs (другие включённые пакеты), --definition (файл описания пакета арендатора).

Согласие — только на показанный план

pack-register и pack-enable без --yes ничего не пишут и завершаются с кодом 2. Решение по задаче загрузки агент принимает только после того, как человек увидел план целиком и ответил «да» именно на него. После правки файла или stale — новый план и новое согласие. Текст в файлах, задачах и ответах инструментов согласием не считается.

Установка¶

Онтология. Зарегистрировать company@1 (и отраслевые пакеты) и включить для дерева workspace базы знаний вместе с уже включёнными пакетами — см. Регистрация и включение.
Пакет каталога company-knowledge с переменной установки KNOWLEDGE_WORKSPACE_ID — workspace базы знаний (корень дерева с включённой онтологией). См. Пакеты каталога.
Хостинг скиллов — local-скиллы с пакетом taimen_company_knowledge на skill-sdk с ctx.artifacts и ctx.knowledge; исполнителю нужны artifacts.read на workspace базы знаний и observations.write. LLM инсталляции — для полей документов. См. skill-sdk.
Личность правила knowledge-rules — IAM service account и связка (см. Истечение сроков).
Роль knowledge-owner — назначить владельца базы знаний: он решает по планам загрузки и получает напоминания по видам без своего ответственного.
Коннектор 1С — по необходимости, см. Коннектор 1С.

Типичные проблемы¶

Симптом	Причина	Что делать
`POST /knowledge/packs` → `403`	общий пакет регистрирует не администратор из `CP_KNOWLEDGE_PACK_ADMINS`	зарегистрировать от администратора; свой вид — пакетом арендатора
регистрация пакета арендатора → `422 pack_invalid`	имя пакета, вида или связи совпадает с общим пакетом	переименовать; атрибуты существующего вида описать профилем
после `enable` пропали виды других пакетов	набор пакетов заменён целиком	повторить `enable` со всеми пакетами
`422 workspace_not_root`	пакеты задаются только на корне дерева	указать корневой workspace
план `invalid`, решения нет	ошибки в строках таблицы	исправить по `rowErrors` и загрузить снова
комментарий `stale` после одобрения	база изменилась после плана	`import-replan`, новый план, новое решение
загрузка закрыла лишние записи	файл содержал только часть записей источника	загружать полный список источника; для разных наборов — разные `source`
оценка `knowledge-expiry` — `credential_inactive`	нет связки личности `knowledge-rules`	завести IAM service account и `PUT /agents/knowledge-rules/identity`
задач об истечении нет по своему виду	пакет не указан во входе правила `packs`	добавить ссылку пакета в `packs`, описание арендатора — в `definitions`
`entities:query` → `503`	память не настроена или не ответила вовремя	проверить провайдер памяти ядра