Lifecycle

Harvester доставляет данные и чинит каждый источник по отдельности; Curation Pass доводит граф поверх всех источников разом. Это зеркало Harvester · Reconciliation: Reconciliation читает API источника и приводит снимок per-source в соответствие с ним; Curation Pass читает саму базу Knowledge Store и сводит то, что видно только при взгляде на все источники сразу. Граница ровно та же, что на границе с производителем: «точно внутри источника → Harvester, догадка между источниками → Knowledge Store».

Расписание — одно платформенное, не per-source: прогон идёт по всему графу целиком, дробить его по источникам незачем. Частоту задаёт → Admin · Knowledge Store. Под одним оркестратором — три шага по расписанию в v1 (retention v2 — четвёртым) плюс один по событию:

Детерминированный шаг, не догадка. Harvester при захвате оставляет явные ссылки заявками в entity_ref, когда целевой узел ещё не в базе (другой источник или forward внутри своего). Прогон проходит нерешённые заявки, ищет цель по натуральному идентификатору и, найдя, пишет ребро в entity_edge (origin=curation) и гасит заявку; цель не нашлась — заявка ждёт следующего прогона. Так граф eventually complete: связь появляется, как только оба её конца оказались в базе. Это отделяет детерминированную сборку явных связей от нечёткого сведения ниже.

Это deep entity resolution — то, что не поймал exact-match Harvester на загрузке. Внутри одного источника дубли схлопывает полный скан Reconciliation; между источниками точного ключа нет, и сведение становится догадкой — задача Curation Pass. Jira «Иван Петров» и Slack «ipetrov» — один человек; две страницы об одном релизе в разных пространствах — одна тема.

Несведённое прогон не выбрасывает: что нечётко связать не удалось, остаётся на ручной разбор в → Admin · Identity Mapping — так автоматика и ручной разбор работают по одной очереди.

Данные устаревают и не равны по достоверности: год назад закрытый тикет и вчерашний релиз, официальный регламент и реплика в чате — разный вес. Curation Pass ведёт ранжирующий entities.trust_score — без удаления, только понижение приоритета в выдаче. Базу задаёт авторитет источника, давность и спрос её модулируют: trust = вес источника, сниженный устареванием и невостребованностью.

Decay — не статус и не soft-delete: оси status и is_deleted ведёт загрузка, а trust_score — это непрерывный вес, который пересчитывает прогон. Пропажу записи из источника фиксирует Reconciliation, а не staleness.

Что хранить вечно, что архивировать, что удалять физически — завершающий шаг цепочки, отложенный в v2: в первой версии данные просто накапливаются (источник вычищает только то, что сам пометил удалённым, — через Reconciliation), а собственную политику хранения вводим позже. Политика зависит от типа сущности и требований клиента (нормативные сроки, объём, чувствительность), поэтому задаётся не в коде, а в → Admin · Knowledge Store рядом с расписанием прогона.

Этот шаг стоит вне цепочки расписания: его триггерит не таймер, а событие — смена модели эмбеддингов. Векторы, посчитанные старой моделью, несовместимы с новой: их близость в общем пространстве теряет смысл, и поиск ломается, пока база смешана. Поэтому при смене модели Curation Pass перегенерирует chunks.embedding и обновляет chunks.embedding_model — массовый прогон, который сам по себе — инференс AI.

Тонкость размерности: при равной размерности старые и новые эмбеддинги сосуществуют построчно, пока идёт прогон (различает embedding_model). Смена самой размерности N — не построчный refresh, а schema-операция: chunks.embedding типизирована размерностью (halfvec(N)) и двух N разом не держит, поэтому новый размер требует реиндекса колонки.

Отмена безопасна — своп единственная точка фиксации. Раз новое поколение собирается в отдельной колонке, а старый индекс авторитетен до свопа, прерывание прогона просто отбрасывает недостроенную колонку: смешанного построчного состояния, видимого поиску, не возникает, и платформа остаётся на прежней модели. Цена не в целостности, а в потраченном инференсе — поэтому в Admin отмена переэмбеддинга идёт через подтверждение, а перезапуск — повторной сменой модели.

Зеркало журнала прогонов Harvester (sync_runs) на стороне Knowledge Store: одна строка на прогон, видимость хода и итога. UI ничего не вычисляет — читает curation_runs и рисует прогресс, статус и статистику по шагам.

В один граф пишут две фоновые полосы: доставка — Harvester тянет источники, и доводка — Curation Pass наводит порядок в уже собранном графе. Правило одно: обычно они идут рядом, не мешая друг другу, и лишь на короткое разрушительное окно доводки синхронизация источника уступает ей дорогу.

UI. Кнопки просто показывают это состояние, ничего не вычисляя. Источник под прогоном — «Синхронизировать» неактивна; идёт разрушительное окно доводки — запуск помечен «в очереди · идёт доводка графа». Общий индикатор активности — на → Admin · Knowledge Store, когда экран выйдет из заглушки.

Резервное копирование идёт автоматически по расписанию, отдельно от доводки графа. Назначение (внешнее хранилище / S3), периодичность и retention самих бэкапов задаются в → Admin · Backups; оттуда же запускается восстановление. Одна база Postgres под всем модулем означает, что снимок целостен по построению: тело, векторы, граф и права попадают в бэкап одной согласованной точкой, без сборки из нескольких СУБД.

Реляционное тело, pgvector и граф живут в одном Postgres, поэтому проекции и ACL меняются транзакционно — без кросс-базовой синхронизации, без окна, где права и контент разошлись между СУБД. Source of truth — реляционное тело; векторы и рёбра суть его проекции.

Синхронную загрузку (одна транзакция, фиксированный порядок проекций) держит модель данных. Доводка же асинхронна: Curation Pass досводит cross-source рёбра и нечёткие связи отдельным прогоном, поверх уже консистентного тела. Поэтому граф eventually complete — ребро видно сразу, когда оба узла уже в базе; ссылка на ещё не пришедший узел (как и cross-source) досводится прогоном, — а реляционное тело верно всегда.