obsidian-vault/personal/projects/personal-os/personal-os-work-graph-research-2026-10-04.md

# Personal OS: понимание большого потока работ

Дата: 2026-10-04. Статус: исследование и предложение архитектуры, до согласования реализации. Проверены официальные документы, статьи авторов и выбранные исходники GitHub. Репозитории не запускались. Частные данные не отправлялись исследуемым моделям; установки и расписания не создавались.

## 1. Решение и изменение приоритета

**Актуальная постановка и очередность:** [шесть уровней Personal OS](/Users/admin/Developer/personal-os/planning/personal-os-six-layer-analysis-2026-10-05.md). Сначала доказать покрытие выбранных проектов, затем сравнить готовые открытые механизмы извлечения/графа на общем корпусе. Личный доступ без изменения систем компании исключает корпоративное внедрение как первый этап. Ниже сохранено исходное исследование компонентов и контрактов.

Проблема состоит из пяти отдельных задач: полнота наблюдения; выделение объектов и событий; связывание объектов между источниками; восстановление текущей ситуации; приоритизация относительно роли, целей и доступного внимания. Один хороший классификатор не гарантирует остальные четыре результата.

LifeOS шире журнала агентских действий: TELOS описывает личные цели, Atlas — активы и наблюдения. Однако прочитанные контракты не доказывают восстановление обязательств, неявных инициатив и их приоритетов из большого корпоративного архива. Обзор LifeOS остаётся полезен для пользовательского слоя. [Atlas](https://github.com/danielmiessler/LifeOS/blob/5e2f2e8c0abde612da0e99c16c0d07d4ec21b88c/LifeOS/install/LIFEOS/DOCUMENTATION/Atlas/AtlasSystem.md).

**Условный вариант собственной реализации, если проверка продуктов выявит необходимость:** сохранить PostgreSQL как реестр доказательств и принятых состояний; построить проверяемый конвейер извлечения и связывания с заменяемыми моделями. Решение строить этот конвейер ещё не принято. Jev — кандидат для узких решений внутри конвейера. Graphiti — кандидат для сравнения временных связей. Glean — коммерческий образец организации корпоративного контекста; Numen — близкий открытый прототип, требующий существенной проверки.

## 2. Что есть у нас фактически

Агрегаты прочитаны из локальной PostgreSQL в транзакции READ ONLY 04.10.2026, 17:45 UTC. Это доступный локальный корпус, **не доказательство полноты Asana или всех источников**. Машинный срез: [corpus-inventory.json](/Users/admin/Developer/personal-os/planning/work-graph-research-2026-10-04/corpus-inventory.json).

| Показатель | Наблюдение | Следствие |
|---|---|---|
| Задачи | 79 507; 36 756 с `completed=false`; 446 разных `project_gid` | Это большой исторический корпус. Открытый статус не означает текущую работу пользователя. Одно поле проекта не отражает все memberships задачи. |
| Stories | 575 587 у 40 621 задачи, с 2011 по 2026 год | Здесь и обсуждения, и системные события. Отсутствие stories может означать отсутствие событий или пробел загрузки. |
| Явные связи | 50 161 mention; 2 468 subtask; 14 dependency + 5 dependent | Уже есть полезная структура. Упоминание нельзя превращать в зависимость; малое число dependencies требует аудита collector. |
| Подготовленность | `task_embeddings` пустая; 5 388 задач без notes | Предметный семантический индекс пока не доказан. Последний `fetched_at` задач — 03.10, что не удостоверяет полноту комментариев. |
| Другие источники | В `zoom-recordings` один manifest; в `~/context/mattermost-client` 101 JSON-файл | Это файловые наблюдения в двух конкретных каталогах, не количество всех встреч/сообщений. Нужна сверка с upstream и другими архивами. |

Текущий Zoom loader выделяет кандидатов по английским регулярным выражениям (`decision`, `commitment` и др.). Это допустимый начальный фильтр кандидатов, но его выход не заменяет полный корпус бесед: косвенная речь, отрицания и русские формулировки требуют другого анализа. См. [zoom-transcripts-load.js](/Users/admin/Developer/personal-os/scripts/zoom-transcripts-load.js).

`agent/work-profile.md` содержит узкий набор эпизодов, а `career-notes.md` помечает старые карьерные сведения как неподтверждённые. Следовательно, текущую роль и цели нельзя считать уже восстановленными. Нужны датированные факты о зонах ответственности и отдельные гипотезы. Миссия Personal OS сохраняется: самочувствие, внимание и границы рабочего дня ограничивают рабочую оптимизацию.

## 3. Существующие решения: что действительно подходит

### 3.1. Готовые системы

| Решение | Подтверждённая близость к задаче | Ограничение и вывод |
|---|---|---|
| **Glean** | Граф объединяет контент, людей и активность; идентичности, роли, команды и история участвуют в персонализации. | Наиболее близкий из изученных коммерческих классов. Закрытый алгоритм; соответствие нашим источникам, индивидуальному доступу и миссии не проверено. Рассматривать продукт при доступности, архитектуру использовать как ориентир. [Документация](https://docs.glean.com/security/knowledge-graph). |
| **Numen** | Открытый граф задач, PR, документов, людей и целей; urgency, briefing, MCP; Python/FastAPI, PostgreSQL, FalkorDB, Redis. | Beta; заявленные коннекторы Linear/GH/Slack/Jira/Notion/Docs не закрывают нашу тройку Asana/Zoom/Mattermost. Ниже есть конкретные ограничения кода. Источник идей и кандидат для ограниченного сравнения, не готовая замена. [Репозиторий](https://github.com/theBstar/numen). |
| **LifeOS / Letta / Khoj / Dify** | Личный контекст, агентная среда, поиск или сценарии соответственно. | Полезны после появления достоверного предметного слоя. Их прежний рейтинг отвечал на вопрос об оболочке, а не доказывал качество понимания работ. [Предыдущий обзор](/Users/admin/Developer/personal-os/planning/personal-os-ready-systems-and-skills-2026-10-04.md). |

Отсутствие найденного готового продукта, закрывающего все требования, не доказывает отсутствие такого продукта вообще. В исследованных реализациях нет подтверждённого сочетания наших источников, временных решений, произвольных объектов, роли пользователя и приёмки качества приоритетов.

### 3.2. Что обнаружено в настоящем коде Numen

Проверен commit `0b5ac5f1d64e69f1dd2a8d3c9fec69fa9f7cf2ba`; это статическое чтение выбранных модулей, не интеграционный тест.

| Модуль | Наблюдение | Почему существенно для нас |
|---|---|---|
| [link_suggester.py](https://github.com/theBstar/numen/blob/0b5ac5f1d64e69f1dd2a8d3c9fec69fa9f7cf2ba/src/llm/link_suggester.py) | Получает до 1 000 PR и до 1 000 задач; закрытые задачи исключаются. На пакет из 5 PR передаётся список задач. Предложения сохраняются pending, порог confidence — 0.4. | При нашем масштабе это ограничивает обнаружение связей с архивом и расходует контекст. Pending полезен; число confidence ещё надо калибровать. |
| [urgency.py](https://github.com/theBstar/numen/blob/0b5ac5f1d64e69f1dd2a8d3c9fec69fa9f7cf2ba/src/inference/urgency.py) | В формуле `compute_urgency` есть частота упоминаний и давность; аргумент `person_id` сохраняется в результате, но не участвует в вычислении факторов. | Отбор доступных человеку объектов есть в [scorer.py](https://github.com/theBstar/numen/blob/0b5ac5f1d64e69f1dd2a8d3c9fec69fa9f7cf2ba/src/inference/scorer.py), однако просмотренная формула не меняет важность одной задачи в зависимости от роли. Это не наш готовый ranker. |
| [resolution.py](https://github.com/theBstar/numen/blob/0b5ac5f1d64e69f1dd2a8d3c9fec69fa9f7cf2ba/src/graph/resolution.py) | Проверка равенства нормализованных имён вложена в условие их неравенства. Эта ветка недостижима. | Даже подходящая предметная модель не означает надёжную реализацию сопоставления. |

### 3.3. Граф и поиск

| Подход | Что переиспользовать | Что он не доказывает |
|---|---|---|
| **Graphiti** | Инкрементальное извлечение, сопоставление сущностей, временные связи, поиск. | Корректность идентичностей, отменённых решений и пользовательских приоритетов на нашем корпусе. Python и дополнительное graph storage увеличат стоимость эксплуатации. [GitHub](https://github.com/getzep/graphiti). |
| **Microsoft GraphRAG** | Построение сообществ и обзоров большого корпуса; полезно найти крупные направления, а не только ответ на уже заданный вопрос. | Сообщество не равно проекту. FastGraphRAG использует совместную встречаемость, поэтому его ребро не означает «блокирует» или «решено». [Dataflow](https://microsoft.github.io/graphrag/index/default_dataflow/), [методы](https://microsoft.github.io/graphrag/index/methods/). |
| **HippoRAG 2 / LightRAG** | Кандидаты для поиска связанных фрагментов через несколько переходов. | Retrieval benchmark не измеряет актуальность обязательств и качество личного плана. Personalized PageRank в HippoRAG персонализирован относительно запроса; это не модель карьерных приоритетов. [HippoRAG](https://github.com/OSU-NLP-Group/HippoRAG), [статья](https://arxiv.org/abs/2502.14802), [LightRAG](https://github.com/HKUDS/LightRAG). |

Graphiti просмотрен глубже: commit `5d47d4d0182aa6350edeb435b734837a88ed9738`. В [node_operations.py](https://github.com/getzep/graphiti/blob/5d47d4d0182aa6350edeb435b734837a88ed9738/graphiti_core/utils/maintenance/node_operations.py) есть ограниченный набор кандидатов (15, cosine threshold 0.6) и последующее разрешение через LLM. Это полезная декомпозиция. Схлопывание одинаково нормализованных имён внутри эпизода требует отдельной проверки на омонимах. В [edge_operations.py](https://github.com/getzep/graphiti/blob/5d47d4d0182aa6350edeb435b734837a88ed9738/graphiti_core/utils/maintenance/edge_operations.py) дубликаты и противоречия обрабатываются отдельно, поддерживаются временные интервалы; семантическое решение всё равно принимает модель. Наличие timestamp не гарантирует верность решения.

В просмотренном дереве Graphiti есть Neo4j/FalkorDB/Kuzu/Neptune drivers; PostgreSQL driver не обнаружен. Поэтому Graphiti — либо изолированный сравнительный стенд с перестраиваемым графом, либо источник адаптируемых контрактов. Второй независимый реестр принятой правды нам не нужен.

LazyGraphRAG полезен как идея переноса части затрат на момент запроса. Статья Microsoft описывает исследования и интеграции; это не достаточное основание обещать готовый открытый пакет для нашего внедрения. [Источник](https://www.microsoft.com/en-us/research/blog/lazygraphrag-setting-a-new-standard-for-quality-and-cost/).

### 3.4. Дешёвое извлечение, классификация и сопоставление

| Кандидат | Подходящая функция | Когда выбирать |
|---|---|---|
| **Jev / TypeSafe** | Выбор из заданных вариантов: тип сигнала, отношение пары объектов, подтверждение конкретного утверждения. | Проверить первым как API-кандидата для ограниченных решений. Нужны готовые кандидаты и вариант unknown. [Введение](https://typesafe.ai/blog/introducing-system-one-models-and-jev). |
| **GLiNER2** | Извлечение сущностей, классификация, структур и отношений по заданной схеме; потенциально локальное исполнение. | Сравнить с API на EN/RU и реальном оборудовании. Извлечение имени ещё не определяет идентичность человека между системами. [GitHub](https://github.com/fastino-ai/GLiNER2), [статья](https://arxiv.org/abs/2507.18546). |
| **SetFit** | Компактная классификация по размеченным примерам, включая multilingual encoders. | После стабилизации категорий и появления исправлений. Не решает открытие совершенно новых типов связей. [GitHub](https://github.com/huggingface/setfit). |
| **Splink** | Вероятностное сопоставление структурированных записей с предварительным отбором пар. | Для людей/организаций при наличии нескольких полей; не для вывода смысла всего обсуждения. [Документация](https://moj-analytical-services.github.io/splink/). |
| **BERTopic / Snorkel** | Обнаружение тем / получение слабых меток из нескольких правил. | Вспомогательные инструменты: поиск неразобранных направлений и bootstrap. Тематическая близость и слабая метка не становятся фактом. [BERTopic](https://github.com/MaartenGr/BERTopic), [Snorkel](https://github.com/snorkel-team/snorkel). |

Эти решения — альтернативы внутри этапов. Одновременная установка всех библиотек не предлагается.

## 4. Jev: конкретное место и экономика

Под `jev` здесь понимается найденный официальный TypeSafe Jev. На дату проверки модель `jev-1.13.0` стоит $0.042 за миллион входных токенов, выход не тарифицируется. Основной язык обучения английский; русский надо проверять отдельно. Для воспроизводимости фиксируется версия, а не `latest`. [Модель и цена](https://docs.typesafe.ai/models).

В официальном [entity alignment cookbook](https://docs.typesafe.ai/cookbooks/entity_alignment) уже есть подход «предварительно отобранная пара → разные / одинаковые / требуется проверка». Это ближе к нашей задаче, чем просьба одной модели построить весь граф. Но демонстрация на каталогах товаров не подтверждает качество на людях, задачах и косвенных договорённостях.

Jev не генерирует произвольные новые объекты/объяснения. Документация отдельно предупреждает о многошаговых рассуждениях, шумном большом контексте, порядке вариантов и вычислении дат/чисел. Поэтому IDs и календарные сравнения делает код; генеративная модель или extractor выделяет неизвестные объекты; Jev оценивает короткие кандидаты. [Ограничения](https://docs.typesafe.ai/model-jaggedness/jev-1.13).

**Пример стоимости, не измерение нашего корпуса:** 100 000 эпизодов × 1 500 входных токенов = 150 млн токенов, или $6.30 за один проход. Если дополнительно проверять 10 пар на эпизод по 600 токенов — ещё 600 млн, $25.20. Отдельно оплачиваются извлечение, embeddings, сложные случаи, повторы и хранение. Число stories не равно числу эпизодов и не даёт готовую смету. Реальная единица сравнения — стоимость 1 000 обработанных эпизодов **при одинаковой полноте и качестве**, плюс минуты проверки человеком.

Есть официальный [TypeSafe skill](https://github.com/typesafe-ai/skills/blob/65a39f393687675ce170e6094757de20370365b9/skills/typesafe-ai/SKILL.md). Прочитан как материал для разработки; не установлен и не применён как инструкция этой сессии. Его можно использовать после выбора модели, сохранив наши контракты unknown, provenance и локальной калибровки.

## 5. Предлагаемый data flow

```mermaid
flowchart TD
  S[Asana / Mattermost / Zoom / GitHub / файлы] --> R[Исходные записи, версии, покрытие]
  R --> D[IDs, ссылки, явные связи — код]
  R --> E[Полные треды и эпизоды → извлечение объектов и событий]
  D --> C[Кандидаты: точные ключи + текст + векторы + соседи]
  E --> C
  C --> J[Узкие решения: правила / Jev / локальная модель]
  J --> U[Неясные и существенные случаи → углублённый разбор]
  J --> P[Предложения связей с источниками]
  U --> P
  P --> V[Проверка контрактов и принятие]
  V --> G[PostgreSQL: версии объектов, утверждения, временные связи]
  G --> W[Направления работ, зависимости, текущая ситуация]
  R --> O[Периодическая проверка непокрытого архива]
  O --> C
  W --> K[Роль + цели + обязательства → приоритеты]
  K --> L[Planner: ёмкость дня, текущий план, ограничения]
  L --> UI[Обзор → действие / объяснение / исправление]
  UI --> F[Типизированная обратная связь]
  F --> V
  F --> EV[Retrospector: ошибки и качество policy]
  EV --> T[Офлайн-проверка новой версии]
  T --> V
```

### 5.1. Сбор и покрытие

Единица анализа — задача с историей, тред или эпизод встречи с соседним контекстом. Сохраняются исходные реплики, speaker/source IDs, время события и загрузки, версии, диапазоны текста/таймкоды. Сводка служит навигацией; вывод проверяется по исходным фрагментам.

Первый проход по **всему доступному архиву** строит недорогой индекс, явные связи и карту покрытия. Глубина разбора увеличивается для действующих работ, изменений и непонятных областей, но архив остаётся в поиске. Очередь backfill должна гарантировать продвижение по старым и малообсуждаемым данным; скорость и остаток показываются отдельно.

Полнота измеряется по источнику, проекту/каналу и периоду: ожидаемые и полученные объекты, pagination, права, пропуски, удалённые/изменённые записи. «Синхронизация успешна» не означает «вся история доступна». Пропущенное окно понижает уверенность соответствующей ситуации.

### 5.2. Обнаружение кандидатов без квадратичного перебора

79 507 задач дают примерно 3.16 млрд неупорядоченных пар. Проверять каждую моделью неразумно. Предлагается объединение точных IDs/URL/aliases, полнотекстового поиска, multilingual embeddings, участников/временных окон и соседей графа. Временная близость — добавочный сигнал, не условие: связь может проходить через годы.

Начальный бюджет — 10–30 кандидатов на объект, расширяемый при неопределённости. Он выбирается по Recall@K, а не удобству реализации. Пропущенную кандидатом связь не исправит самый сильный последующий классификатор. Для каждой пары сохраняется причина попадания в выборку.

Новые направления обнаруживаются также среди объектов без хороших кандидатов: кластеризация, общие результаты/артефакты/участники, генеративная гипотеза о workstream. Кластер может содержать несколько проектов; одна задача может принадлежать нескольким направлениям. Объекты с малым числом связей остаются видимыми.

### 5.3. Идентичность, отношение и событие — разные решения

`same_entity`, `part_of`, `blocks`, `implements`, `discusses`, `supersedes`, `contributes_to_goal` имеют разные критерии. Общая тема даёт максимум кандидатное `related_to`. `discusses` не доказывает участие в реализации. Объединение идентичностей требует более высокой точности, чем подсказка поиску.

Принятие одного `same_entity` может объединить много соседей; поэтому нельзя применять транзитивное слияние по цепочке слабых сходств. Merge/split обратимы, история исходных IDs сохраняется. Одинаковые имена без workspace/provider контекста не достаточны.

Событие хранит автора высказывания, адресата обязательства, модальность, отрицание/условие, время и подтверждающие фрагменты. «Можно сделать», «поручено», «сделано», «принято», «выпущено» не взаимозаменяемы. Позднее упоминание старого решения не отменяет более раннее по дате публикации новое решение: сравнивается смысл и время события.

### 5.4. Произвольные объекты и непрямые связи

База R2 уже предусматривает versioned types и typed assertions. Нужна реализация discovery, не бесконтрольное создание схемы моделью. Неизвестный объект получает стабильный internal ID и `type_candidate`; имя и предполагаемый тип могут уточняться без потери истории.

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

Последовательность проектов выражается typed relations `enables`, `follows`, `replaces`, `depends_on`, а не порядком дат. Для циклов показывается противоречие/цикл; нельзя молча обещать корректный critical path. Файлы и сессии приложений связываются через IDs, URL и артефакты; foreground time само по себе не определяет задачу.

## 6. Как получится приоритет именно для пользователя

Сначала строятся независимые оценки: **значимость результата, моя ответственность, срочность, доступное действие**. После этого planner учитывает ёмкость дня и устойчивость уже принятого плана. Один непрозрачный score 0–100 скрывает слишком много разных причин.

| Слой | Входы | Выход |
|---|---|---|
| Роль | Подтверждённые зоны ответственности, DRI/reviewer/координатор/консультант, период действия и источник | Почему эта работа относится к пользователю; неизвестность явна |
| Значимость | Связь с подтверждённой целью, последствия задержки, зависимые результаты и люди | Обоснование важности; отсутствие данных не превращается в ноль |
| Срочность и действие | Реальные дедлайны, обещания, ожидания других, готовность входов | Что требует действия сейчас и что действительно доступно |
| Планирование | Время, нагрузка, фокус, отдых, уже принятые обязательства | Небольшой набор действий; остальное остаётся доступным |
| Обратная связь | «Не моя роль», «не тот объект», «позже», «неверная связь», «неверный статус» | Исправление конкретного слоя; отложить не означает обесценить цель |

Пользователь не обязан быть assignee, чтобы review/координация были его работой. Старые карьерные записи не считаются действующей ролью автоматически. В начале предлагается черновик роли с доказательствами, пользователю остаётся исправить только неопределённые существенные пункты.

Hard constraints и даты вычисляет код. Модель сравнивает подходящие действия по явным критериям и сообщает контрсвидетельства. Результат сохраняется вместе с policy version и snapshot источников. Обучаемый ranker имеет смысл после накопления валидной обратной связи; лайки сводок недостаточны.

Количество сообщений, свежесть и центральность графа могут помочь поиску, но не служат самостоятельным доказательством важности. Для тестирования устойчивости дублируем сообщения о второстепенной задаче: её приоритет не должен расти. Значимость тихого обязательства проверяется отдельным тестом.

## 7. Контракты компонентов и изменения к R2

PostgreSQL остаётся canonical store; Node.js постепенно типизируется TypeScript. Полнотекстовый индекс — исходная база; `pgvector` проверяется как замена отсутствующего семантического поиска на том же корпусе. Python добавляется только изолированным batch worker для выбранной локальной модели/Graphiti, если сравнение оправдает зависимость. n8n/Node-RED могут оркестрировать этапы, но качество классификации и графа от них не появляется.

Существующие `entities`, `source_records/source_spans`, `assertions`, версии и feedback из [контракта R2](/Users/admin/Developer/personal-os/planning/personal-os-evidence-graph-design-2026-10-04.md) используются повторно. Дополнительные логические записи ниже — предложение, **не применённая миграция**:

| Запись | Обязательные поля / смысл |
|---|---|
| `coverage_partition` + `episode` | Источник, область, период, pagination/watermark, статус полноты; исходные record/span IDs, участники, время эпизода |
| `candidate_link` + `analysis_run` | Пара/тип, причины отбора, model/prompt/schema версии, варианты, uncertainty, стоимость, входные hashes, статус рассмотрения |
| `workstream_membership` | Workstream/entity IDs, роль объекта, поддерживающие assertions, период, proposed/accepted; многозначное членство |
| `role_assignment` + `priority_assessment` | Человек, scope/роль/цель/период; действие, компоненты важности, ограничения, evidence, policy/snapshot, dissent |
| `evaluation_case` + `review_outcome` | Stratum, независимый ожидаемый результат, split, решения проверяющих, ошибки по этапам, время проверки |

### Минимальные инструкции анализа

**Extractor.** Вход: эпизод с соседним контекстом. Выход: объекты и утверждения с точными span IDs, актором, временем и модальностью. Сохранять отрицание, условность и противоречащие фрагменты; незаявленный результат помечать unknown. Собственные названия направления — гипотеза.

**Resolver.** Вход: пара и ограниченные контекстные доказательства. Выход: same/different/unknown, либо конкретный тип отношения и evidence IDs. Раздельно оценить идентичность и связь. При несовместимых идентификаторах не объединять. Отсутствие найденного доказательства не равно доказательству отсутствия связи.

**Situation builder.** Вход: история подтверждений и опровержений по направлению. Выход: текущая ситуация, незакрытые обязательства, решения по отдельным измерениям, пробелы покрытия. Для изменения статуса указать событие и предыдущее состояние; пересказ не является новым событием.

**Priority proposer.** Вход: ситуация, подтверждённая роль/цели, ограничения и альтернативы. Выход: предлагаемый порядок, причины, доступное действие, что изменит порядок. Запрещено подменять результат интенсивностью обсуждения. Неизвестная ответственность выделяется отдельно.

**Retrospector.** Вход: предложения, фактические выборы и результаты, исправления. Выход: ошибки этапов и предлагаемое изменение policy с тестами. Пользовательское «позже» не размечается как ошибка важности; отказ из-за перегрузки не меняет карьерную цель. Новая policy сначала проходит replay, затем согласованное включение.

## 8. Приёмка: как не повторить выбор одного яркого случая

### Данные оценки

Начальный исследовательский набор: около 1 000 эпизодов, 300 размеченных пар и 30 историй изменения решений, плюс 20 пар реальных альтернатив для оценки приоритетов. Числа — стартовый бюджет, не статистическая гарантия. Они уточняются после распределения корпуса. Разметку объективных фактов готовит инженер по первичным источникам; модель может предложить метки, но не быть единственным судьёй. Пользователю предъявляются небольшие пакеты субъективных выборов, максимум пять за раз.

Выборка сочетает случайную пропорциональную часть и целевые редкие случаи. Страты: источники и языки; проекты и периоды; открытые/закрытые/давно неактивные работы; явные/косвенные связи; исполнение/ревью/координация; тихие/многообсуждаемые обязательства. Один знакомый эпизод может быть regression case, но не центром набора.

Разделение train/dev/test выполняется целыми тредами и задачами, с временным cutoff; отдельная проверка на ранее не встречавшемся проекте. Дубликаты и пересказы одной встречи не распределяются по разным split. Негативные пары включают похожие названия разных объектов и тематически близкие работы без причинной связи.

### Метрики и предлагаемые gates

| Уровень | Что измеряем | Начальный критерий перехода, не достигнутый результат |
|---|---|---|
| Покрытие и кандидаты | Полнота страниц/окон; Recall@K отдельно от последующей классификации | Весь заявленный пилотный scope загружен либо имеет явный gap; Recall@30 ≥95% на размеченных связях, включая отчёт по стратам |
| Идентичности и отношения | False merges; precision/recall по типу; калибровка вероятностей и доля abstain | Автослияние по семантике выключено до достаточной выборки; существенные ошибочные слияния — блокирующие. Для обычных принимаемых отношений precision ≥95%, критические — отдельная ручная приёмка |
| Ситуация и доказательства | Верный текущий статус; причинность; покрытие источниками | Все утверждения в выводе имеют проверяемые ссылки; обязательные сценарии отмен/противоречий проходят полностью; неподтверждённый outcome не принимается |
| Приоритеты | Попарное согласие пользователя, пропущенные обязательства, устойчивость к шуму, разнообразие представленных работ | Пилот лучше согласованной простой базы; ноль пропущенных критических обязательств в контрольных сценариях; повтор сообщений не меняет порядок без нового факта |
| Полезность и эксплуатация | Минуты review, стоимость/1 000 эпизодов, p95 задержки, replay, backlog | Пользовательский review укладывается в предложенный бюджет 10 минут/неделю; две недели shadow-пилота без необъяснимых смен плана, дубликатов и потери данных |

Порог ≥95% на малой выборке не подтверждает промышленную надёжность. Отчёт включает размер выборки, доверительные интервалы, худшие страты, ошибки высокой цены и долю неизвестных. Ноль ошибок на 300 парах не доказывает 99.9% качества. Если неопределённости слишком много для review-бюджета, автоматизацию не расширяем: улучшаем сбор/кандидатов или сужаем область принятия.

STaRK полезен как образец оценки поиска по тексту и связям; QMSum — как образец поиска нужных фрагментов встречи. Их готовые benchmarks не являются приёмкой наших приоритетов. [STaRK](https://github.com/snap-stanford/stark), [QMSum](https://github.com/Yale-LILY/QMSum).

### Сравниваемые варианты

Сначала одна общая база: явные IDs/связи + полнотекстовый/векторный отбор. На фиксированных кандидатах сравниваются Jev и доступный локальный extractor/classifier с одинаковой схемой; сложные случаи получают отдельный генеративный разбор. Graphiti сравнивается на временных историях как отдельный вариант, если простая база не проходит этот gate. GraphRAG/BERTopic проверяются на обнаружении направлений, только если остаётся измеренная проблема покрытия.

Так результат различает «не найден кандидат», «неверно понята пара» и «правильный граф, неверный приоритет». Сравнение разных полных стеков одним общим баллом скрывает причину ошибок.

## 9. Этапы проверки и условной реализации для согласования

Текущие поставки и gates определяет [разбор шести уровней](/Users/admin/Developer/personal-os/planning/personal-os-six-layer-analysis-2026-10-05.md). WG-0–WG-4 ниже остаются декомпозицией требований: готовые компоненты используются там, где проходят общий эталон; корпоративный shortlist не является условием начала.

| Этап | Ограниченный результат | Связь с существующим планом |
|---|---|---|
| **WG-0: корпус и критерии** | Coverage manifest всех источников; воспроизводимый sampler; размеченный набор; черновик роли с датами и источниками. Сегодня выполнен только агрегированный локальный срез. | Дополняет R0 до выбора оболочки и моделей. |
| **WG-1: базовый граф** | Полный недорогой индекс истории, явные IDs/связи, эпизоды, baseline кандидатов; измеренный Recall@K. | Проверяемый предметный срез R1/evidence core. |
| **WG-2: связывание и состояние** | Сравнение моделей, typed proposals, versioned decisions, обратимые merge/split, replay исправлений; отчёт качества и цены. | Обязательное доказательство semantic gate R2. |
| **WG-3: направления и приоритеты** | Workstreams, косвенные связи, role-relative объяснения и небольшой обзор действий; сравнение с простым baseline и выбором пользователя. | Условие использования графа planner/career, до полировки их отчётов. |
| **WG-4: shadow-пилот** | Инкрементальные обновления, backfill, ретроспекция ошибок, review-бюджет, rollback и приёмка двух недель. | Gates R3–R4; включение сценариев и расписаний отдельно согласуется. |

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

## 10. Просмотр и взаимодействие

Основной экран — до пяти направлений/действий с причинами «почему сейчас» и покрытием. Раскрытие направления показывает людей, артефакты, решения и зависимости в один-два перехода. Фильтры: время, тип связи, принятые/предложенные, неизвестные области. Полный граф доступен для исследования, но не является ежедневным рабочим экраном.

Исправление начинается с конкретного объекта/связи: «другой проект», «не моя ответственность», «решение отменено», «перенести». Оно адресует нужный слой, пересчитывает затронутые выводы и остаётся в истории. Career advisor и ретроспектор читают принятый snapshot и его gaps, а не повторно собирают всю правду из сырого архива каждый раз.

## 11. Статус исследования и воспроизводимость

Сделано: исследование первичных источников; чтение выбранных модулей Numen/Graphiti и официального TypeSafe skill; локальный агрегированный inventory; предложение конвейера, контрактов, приёмки и поправка очередности roadmap. [Проверенные версии и SHA256 прочитанных файлов](/Users/admin/Developer/personal-os/planning/work-graph-research-2026-10-04/source-manifest.json).

Не измерены: качество моделей на нашем корпусе, фактическая цена backfill, полнота всех upstream-источников, готовность Glean для нашего доступа, скорость локального inference. Предлагаемые технологии и пороги не объявляются уже выбранными или достигнутыми. Печатные схемы R2 пока не содержат это дополнение; данный текст — актуальное исследовательское уточнение для согласования.

Следующий ограниченный результат: **согласованный upstream/local manifest трёх Asana-проектов и исправленное сохранение всех memberships**, по новому разбору шести уровней.