ТЗ: Knowledge Exploration — исследование предметной области и навигация по знаниям Temporality

#1. Цель

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

Система должна решать задачу не только поиска конкретного знания, но и последовательного исследования области, в которой это знание предположительно находится.

#1.1. Проблема

В процессе эксплуатации Temporality накапливаются утверждения с различными состояниями жизненного цикла: proposed, confirmed, challenged, corrected, superseded, invalidated (последние три — терминальные), а также флаг at_risk для знаний, зависящих от выбывших.

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

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

#1.2. Основная идея

Создать единый исследовательский слой поверх существующей модели знаний Temporality.

Слой предоставляет операции ориентации, поиска, исследования связей, проверки происхождения, сравнения версий и формирования исследовательского досье.

Один и тот же слой должен использоваться:

• агентами через доступный им механизм инструментов ядра (kernel tools, как knowledge_lookup и skill_search); MCP в Temporality подключает внешние серверы и для внутренних инструментов не используется;
• пользовательским интерфейсом Temporality;
• другими внутренними компонентами, которым необходимо исследовать предметную область.

Knowledge Exploration не является отдельной системой хранения памяти, самостоятельной онтологической базой или заменой существующего механизма формирования знаний.

#2. Основные принципы

#2.1. Существующая модель знаний остаётся источником истины

Перед реализацией необходимо изучить актуальный код Temporality и использовать существующие модели, репозитории, сервисы, проекции, идентификаторы и правила доступа.

Запрещается создавать параллельную модель знаний с независимым жизненным циклом или дублировать существующие механизмы только ради реализации исследовательского API.

Event stream остаётся источником истины. Состояния, связи, поисковые индексы, тематические группировки и исследовательские представления являются производными данными.

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

#2.2. Исследование не равно извлечению подсказок

Инструмент должен помогать агенту самостоятельно выбирать направление исследования на основании полученных результатов.

Исследование не конкурирует и не заменяет priming — автоматический отбор подсказек до задачи (docs/plan-priming-relevance.md): priming выбирает ограниченный набор cue для текущего решения, а exploration даёт агенту управляемые операции навигации по всей видимой базе. Дозагрузка конкретного знания по идентификатору уже доступна агенту инструментом knowledge_lookup.

В отличие от обычного поиска, результат может содержать:

• тематические области;
• альтернативные понятия и формулировки;
• связанные утверждения;
• подтверждения и противоречия;
• историю изменения знания;
• источники и контекст происхождения;
• пробелы и неопределённости;
• возможные следующие направления исследования.

При этом инструмент не должен автоматически возвращать всю обнаруженную информацию в контекст агента. Агент получает компактную сводку и при необходимости углубляет исследование.

#2.3. Семантическая близость не означает истинность

Необходимо различать следующие типы отношений:

1. Явные отношения — зафиксированы в существующей модели или подтверждены соответствующими событиями.
2. Выведенные отношения — получены детерминированными правилами на основании доступных данных.
3. Кандидаты на связь — обнаружены по сходству формулировок, контексту, совместному использованию или другим эвристикам.

Для каждого отношения должны быть доступны его тип, основание и происхождение, если они известны.

Кандидат на связь не должен отображаться как установленный факт, подтверждение или причинно-следственная зависимость.

#2.4. Жизненный цикл не равен достоверности

Состояние утверждения, его истинность, применимость, актуальность и качество доказательств — разные характеристики.

Нельзя использовать единый непрозрачный рейтинг, который смешивает:

• состояние жизненного цикла;
• временную актуальность;
• соответствие текущей задаче;
• количество и независимость подтверждений;
• наличие противоречий;
• частоту использования;
• семантическую близость.

Каждая характеристика должна интерпретироваться отдельно.

#2.5. Исследование должно быть ограниченным и воспроизводимым

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

Должна быть возможность понять, почему конкретное знание попало в результат, какие данные использовались и какие ограничения применялись.

#3. Предварительный аудит существующей реализации

До изменения кода необходимо провести анализ актуальной версии репозитория Temporality. Первичный аудит выполнен 2026-10-16 по main; при заметном дрейфе реализации его следует повторить.

Определить:

1. Как устроены модели знаний, их идентификаторы и состояния жизненного цикла.
2. Как представлены предложенные, подтверждённые, оспоренные, устаревшие, заменённые и инвалидированные знания.
3. Как устроены временные ограничения, включая существующую битемпоральную модель.
4. Какие отношения между знаниями уже существуют и как они хранятся.
5. Какие события позволяют восстановить происхождение и историю утверждения.
6. Какие данные связывают знания с организациями, подразделениями, проектами, задачами, агентами и запусками.
7. Какие механизмы полнотекстового и семантического поиска уже реализованы.
8. Какие проекции, индексы и фоновые процессы уже существуют.
9. Как реализованы авторизация, наследование доступа и ограничения области видимости.
10. Как агенты получают доступ к инструментам, MCP и существующим сервисам Temporality.

По результатам аудита составлена таблица:

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

Не выполнять массовую миграцию знаний и не менять семантику их жизненного цикла без отдельного обоснования.

#4. Функциональные требования

#4.1. Операция orient — ориентация в предметной области

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

Входные данные:

• вопрос или описание задачи на естественном языке;
• необязательный контекст организации и проекта;
• необязательные временные ограничения;
• необязательные ограничения по типам и состояниям знаний;
• лимит числа тематических областей и результатов.

Результат должен содержать:

1. Список релевантных тематических областей или групп знаний.
2. Основные понятия и альтернативные формулировки.
3. Наиболее релевантные утверждения с устойчивыми идентификаторами.
4. Связанные проекты, контексты и события, если доступно.
5. Обнаруженные противоречия и неоднозначности.
6. Предположительные направления дальнейшего исследования.
7. Объяснение, почему каждая область или группа релевантна запросу.

Если система не располагает готовой классификацией областей, допускается формирование временных тематических групп на основании доступных данных. Первое приближение уже есть в модели: каждое знание несёт topics и entities — их агрегация по видимой базе является готовой основой карты областей.

Такие группы не должны автоматически становиться постоянной онтологией или записываться в память как подтверждённые знания.

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

#4.2. Операция search — семантический поиск

Назначение: находить знания по приблизительному смыслу, даже если формулировка запроса отличается от исходного утверждения.

Поиск должен учитывать доступные механизмы:

• полнотекстового поиска;
• семантического сходства;
• альтернативных терминов и формулировок;
• контекстных связей;
• временной применимости;
• области действия знания;
• состояния жизненного цикла.

Использовать только те источники и механизмы, которые реально доступны в существующей архитектуре. При необходимости добавить недостающие возможности, не создавая без обоснования параллельный поисковый контур.

Текущая базовая линия — IDF-взвешенный матч параметра q с нормализацией лексики (регистр, пунктуация, словоформы русского и английского, идентификаторы; короткие токены вида go, jwt, v2 значимы и не должны отбрасываться). Те же требования к признакам сформулированы для priming в docs/plan-priming-relevance.md — извлечение признаков должно быть общим для обоих контуров, а не дублироваться.

Фильтры по организации, проекту, времени и состоянию должны ограничивать множество допустимых результатов, а не только влиять на сортировку.

Результат каждого совпадения должен включать:

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

Необходимо разделять оценку релевантности запросу и оценку качества доказательств.

#4.3. Операция expand — исследование связей

Назначение: исследовать окружение выбранного знания или понятия.

Поддерживаемые направления обхода должны определяться существующей моделью. При наличии соответствующих данных необходимо поддержать:

• подтверждающие и опровергающие утверждения;
• уточнения и альтернативные версии;
• связи замены и инвалидирования;
• исходные события и источники;
• контекст создания и использования;
• связанные проекты и задачи;
• знания, применявшиеся совместно;
• семантически близкие утверждения.

Словарь явных отношений сегодня: supports, contradicts, derived_from, depends_on, supersedes, related_to (события knowledge.linked) плюс типизированная замена replacement_id у corrected/superseded. Обход expand обобщает существующее одношаговое расширение отбора подсказок, добавив ограничение глубины и дедупликацию посещённых объектов.

Параметры:

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

Требования:

1. Не возвращать полный граф без ограничений.
2. Учитывать приоритет и релевантность связей относительно исходного вопроса.
3. Удалять дубликаты результатов.
4. Предотвращать повторный обход уже исследованных объектов.
5. Различать явные и предположительные отношения.
6. Возвращать основание каждой связи.
7. Обеспечивать переход от результата к исходному объекту.

При отсутствии явных связей допускается возвращать кандидатов на связь, если это поддерживается доступными данными. Их статус и основание должны быть явно обозначены.

#4.4. Операция trace — происхождение и история знания

Назначение: восстановить историю утверждения и объяснить, на каких событиях основано его текущее состояние.

Операция должна возвращать доступную информацию о:

• создании знания;
• последующих переходах жизненного цикла;
• подтверждениях и оспариваниях;
• изменениях и замене;
• инвалидации и устаревании;
• использовании в задачах и агентных запусках;
• связанных источниках и свидетельствах;
• изменении временной применимости.

Использовать реальные события и отношения существующей модели. Не выводить происхождение только из текущего состояния записи.

История переходов уже хранится в проекции (History) и журнале событий; цепочка активации доступна эндпоинтом GET /v1/observations/knowledge/chain. Операция trace строится поверх этих данных без новых сущностей.

Необходимо различать:

• время возникновения события;
• время действия знания (битемпоральный срез as_of);
• время регистрации события в системе (known_at).

При реконструкции истории нельзя терять последовательность событий или подменять историческое состояние текущим.

Если часть происхождения недоступна, результат должен явно сообщать об этом. Запрещается выдумывать автора, причину, свидетельство или причинно-следственную связь.

#4.5. Операция compare — сопоставление версий и противоречий

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

Для сопоставления необходимо учитывать, если эти данные доступны:

• содержание утверждений;
• тип и характер противоречия;
• время действия;
• время регистрации;
• область применимости;
• организационный и проектный контекст;
• состояния жизненного цикла;
• основания и источники;
• связи замены, уточнения и инвалидирования.

Результат должен содержать:

1. Список сравниваемых утверждений.
2. Основания, по которым они считаются противоречащими друг другу.
3. Существенные различия контекста и временной применимости.
4. Доступные свидетельства и ограничения каждого утверждения.
5. Неразрешённые противоречия.
6. Сведения о том, достаточно ли данных для обоснованного вывода.

Нельзя автоматически объявлять последнее по времени утверждение истинным только потому, что оно новее.

Нельзя автоматически считать два утверждения противоречащими друг другу, если они относятся к разным версиям системы, организациям, проектам или периодам.

Инструмент не должен самостоятельно изменять состояние знаний, подтверждать утверждения или инвалидировать их. Такие действия остаются в существующих механизмах управления жизненным циклом.

#4.6. Операция synthesize — исследовательское досье

Назначение: сформировать компактный, проверяемый результат исследования для дальнейшего выполнения задачи.

Входные данные:

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

Результат должен включать следующие разделы:

Установленные сведения

• релевантные утверждения и их состояния;
• доступные основания и источники;
• ограничения применимости.

Спорные вопросы

• противоречащие версии;
• неопределённости;
• недостаточно подтверждённые утверждения.

Временной контекст

• существенные изменения;
• устаревшие решения;
• сведения о замене или инвалидации.

Пробелы

• какие данные не найдены;
• какие отношения не удалось установить;
• каких свидетельств не хватает;
• какие проверки могут разрешить неопределённость.

Рекомендуемые следующие действия

• какие понятия исследовать дальше;
• какие связи раскрыть;
• какие первоисточники проверить;
• какие вопросы задать пользователю или другим агентам.

Каждый существенный вывод должен иметь ссылки на исходные утверждения и события, на которых он основан.

Синтез не должен превращать предположения в факты. Необходимо явно обозначать выводы, которые являются интерпретацией, а не прямым содержанием источника.

Операция не должна автоматически создавать постоянные знания в Temporality. Сохранение результатов исследования как устойчивого знания выполняется только через существующий процесс формирования и подтверждения знаний.

#5. Контекст и модель доступа

Исследование должно учитывать существующую организационную модель Temporality.

Поддерживаемые измерения контекста, если они предусмотрены моделью:

• компания;
• организационный узел;
• подразделение и команда;
• проект;
• задача;
• агент и его запуск;
• временной интервал;
• область применимости знания.

Необходимо различать:

• место формирования знания;
• место его применения;
• область, в которой оно действительно применимо.

Контекст задачи не должен автоматически превращать найденное знание в знание соответствующего проекта или организации.

#5.1. Обязательные правила доступа

1. Авторизация выполняется до формирования результатов исследования.
2. Все поисковые и графовые операции соблюдают существующие правила видимости и наследования доступа.
3. Ограничения применяются также к связанным объектам, событиям, источникам, названиям проектов и метаданным.
4. Запрещено раскрывать через агрегаты, количество результатов, названия кластеров или объяснения связей сведения о недоступных объектах.
5. Запрещено использовать результаты из недоступных областей для формирования видимых пользователю объяснений или синтеза.
6. Повторное использование кешированных результатов допускается только при корректном учёте области доступа и временного контекста.

Если связь ведёт к недоступному объекту, инструмент не должен раскрывать его содержимое или чувствительные метаданные.

#6. Интерфейс инструмента для агентов

Предпочтительный способ предоставления функциональности — существующая система инструментов ядра Temporality (kernel tools), по образцу knowledge_lookup, skill_search и artifact_search: единый обработчик RunTool с проектной авторизацией. Вынесение в MCP не требуется: MCP в Temporality подключает внешние серверы, а не внутренние инструменты.

На первом этапе рекомендуется реализовать один составной инструмент knowledge_explore с ограниченным набором операций:

• orient;
• search;
• expand;
• trace;
• compare;
• synthesize.

Это логические режимы одного инструмента. Делить их на самостоятельные MCP-инструменты следует только в случае, если этого требуют текущая архитектура, ограничения схем или результаты испытаний.

#6.1. Общие параметры

В зависимости от операции могут использоваться:

• operation — операция исследования;
• question — исходный вопрос или описание задачи;
• context — доступный контекст организации, проекта и задачи;
• targets — идентификаторы объектов исследования;
• filters — временные, контекстные и статусные ограничения;
• relations — интересующие типы связей;
• max_depth — ограничение глубины исследования;
• max_items — максимальное количество результатов;
• max_tokens — ограничение объёма возвращаемого содержимого, если оно поддерживается текущей инфраструктурой.

Конкретная JSON-схема должна быть согласована с существующим форматом инструментов Temporality. Перечисленные поля являются проектными требованиями, а не утверждением о наличии таких параметров в текущем коде.

#6.2. Общий формат результата

Результат каждой операции должен быть структурированным и машиночитаемым.

Предпочтительная логическая структура:

• operation — выполненная операция;
• results — найденные объекты;
• relations — выявленные связи;
• explanations — основания релевантности и связей;
• conflicts — обнаруженные противоречия;
• gaps — выявленные пробелы;
• next_actions — рекомендуемые следующие операции;
• limits — применённые ограничения;
• completeness — сведения о полноте исследования;
• errors — ошибки и ограничения, если имеются.

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

#6.3. Ссылки на исходные данные

Каждый результат должен содержать устойчивые идентификаторы исходных объектов. Для происхождения и истории должны использоваться идентификаторы соответствующих событий, если они доступны.

Необходимо обеспечить возможность повторно запросить найденное знание или событие без повторного семантического поиска.

Не использовать только текстовые цитаты как идентификаторы источников.

#6.4. Ошибки и неполные результаты

Инструмент должен различать:

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

Достижение лимита не должно интерпретироваться как доказательство того, что других результатов не существует.

#7. Стратегия исследования агентом

Инструмент должен поддерживать итеративную работу, но не навязывать агенту обязательный полный цикл для каждой задачи.

Пример сценария:

1. Агент получает задачу и выполняет orient.
2. Выбирает одну или несколько релевантных областей.
3. Выполняет search для поиска конкретных утверждений.
4. Выполняет expand для исследования важных связей.
5. Использует trace для проверки происхождения критичных утверждений.
6. При обнаружении конфликтов выполняет compare.
7. Формирует synthesize для получения компактного контекста.

Агент может пропускать операции, если они не нужны, и возвращаться к предыдущим направлениям исследования.

#7.1. Критерии остановки

Агенту необходимо предоставлять основания для остановки исследования:

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

Инструмент может рекомендовать остановку, но не должен выдавать ограниченный поиск за исчерпывающий.

#7.2. Бюджет и защита от бесконечного обхода

Обязательно предусмотреть:

• ограничение глубины;
• ограничение количества возвращаемых объектов;
• дедупликацию;
• защиту от циклического обхода;
• ограничение размера результата;
• контроль числа и стоимости поисковых операций;
• повторное использование результатов предыдущих шагов в пределах безопасного контекста.

Параметры лимитов должны быть настраиваемыми. Их начальные значения определить по результатам испытаний, а не выбирать произвольно без измерений.

#8. Семантическая навигация и кандидаты на связи

Необходимо предусмотреть возможность поиска связей, которые ещё не зафиксированы явно в модели знаний.

Источниками кандидатов могут быть доступные формулировки утверждений, контекст их создания и применения, общие события и существующие связи. Использование конкретного метода определяется результатами аудита и имеющейся инфраструктурой.

Для каждого кандидата по возможности возвращать:

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

Необходимо различать семантическое сходство, тематическую близость, совместное использование, противоречие, подтверждение и причинно-следственную связь. Одно не должно автоматически подменять другое.

#8.1. Временный характер исследовательских связей

Кандидаты, сформированные исключительно для текущего исследования, не должны автоматически становиться постоянными отношениями между знаниями.

На первом этапе допускается формировать такие связи в рамках вычисления результата операции, не сохраняя их как факты.

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

Автоматическое подтверждение кандидатов запрещено.

#9. Пользовательский интерфейс

В рамках данной задачи API и агентный инструмент являются первоочередным результатом. При этом контракты должны позволять использовать тот же исследовательский слой в пользовательском интерфейсе.

Если в текущем интерфейсе Temporality есть возможность реализовать исследовательскую навигацию без создания отдельной подсистемы, предусмотреть три взаимосвязанных представления.

#9.1. Карта областей знаний

Отображает тематические области и позволяет перейти от общей темы к конкретным утверждениям.

Отправная точка уже есть во вкладке «Знания»: группировка по topics[0]/entities[0]. Карта областей обобщает её до агрегата по всей видимой базе с распределением по состояниям и учётом прав доступа.

Для каждой области можно показывать:

• количество доступных знаний;
• распределение по состояниям жизненного цикла;
• активность за период;
• количество неразрешённых противоречий;
• наличие устаревших или заменённых знаний.

Тематическая группировка должна быть навигационным представлением, а не жёсткой классификацией, в которой каждый объект может принадлежать только одной теме.

Агрегаты должны вычисляться с учётом прав доступа.

#9.2. Локальный граф связей

Показывает выбранное знание и релевантное окружение, а не весь граф системы.

Пользователь должен иметь возможность:

• раскрывать соседние объекты;
• выбирать типы отношений;
• ограничивать глубину;
• видеть основания связей;
• отличать явные отношения от кандидатов;
• переходить к карточкам знаний и первоисточникам.

#9.3. Временная история

Показывает историю выбранного утверждения и доступные сведения о его применимости во времени.

Необходимо сохранять различие между временем регистрации события и периодом действия знания.

#9.4. Единый контекст исследования

При переключении между картой, графом и временной историей необходимо сохранять:

• исходный вопрос;
• выбранную область;
• текущие фильтры;
• временные ограничения;
• выбранные объекты;
• текущую глубину исследования.

Не следует реализовывать все три представления как обязательное условие готовности первого API. UI должен использовать общий контракт, а не дублировать исследовательскую логику.

#10. Архитектурные требования

#10.1. Минимальное вмешательство

Использовать существующие сервисы, модели, репозитории и механизмы доступа.

Новые сервисы, таблицы, индексы и фоновые процессы вводить только при доказанной необходимости.

Не внедрять отдельную графовую базу, полноценную OWL-онтологию или новую систему памяти только ради построения исследовательского интерфейса.

#10.2. Производные проекции

Если для ориентации и исследования необходимы тематические кластеры, дополнительные индексы или агрегаты, они должны:

• восстанавливаться из существующих данных;
• обновляться при изменениях источника истины;
• учитывать изменения состояния жизненного цикла;
• учитывать временную применимость;
• учитывать область доступа;
• иметь понятный механизм актуализации и восстановления.

Необходимо определить допустимую задержку обновления проекций и обеспечить корректную обработку устаревших результатов.

#10.3. Наблюдаемость

Добавить метрики, позволяющие оценить:

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

В логах нельзя раскрывать данные, недоступные пользователю, содержимое секретов или чувствительные сведения из других контекстов.

#11. Нефункциональные требования

#Производительность

• Операции должны иметь ограниченное время выполнения.
• Объём результата должен быть контролируемым.
• Графовые операции не должны приводить к неограниченному обходу.
• Сложные операции должны использовать существующие индексы и проекции, где это возможно.
• Целевые показатели задержки определить по результатам нагрузочного тестирования на реальных объёмах данных.

#Надёжность

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

#Безопасность

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

#Совместимость

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

#12. Тестирование

#12.1. Функциональные тесты

Проверить:

1. Ориентацию по приблизительному описанию предметной области.
2. Поиск знаний с альтернативными формулировками.
3. Раскрытие связей с ограничением глубины.
4. Восстановление происхождения и истории.
5. Сопоставление противоречащих утверждений.
6. Формирование досье со ссылками на источники.
7. Обнаружение пробелов и неполных результатов.
8. Работу с несколькими проектами и организационными контекстами.
9. Различение явных отношений и кандидатов на связь.
10. Сохранение корректной семантики жизненного цикла.

#12.2. Тесты временной корректности

Подготовить сценарии, в которых:

• утверждение было актуально в прошлом, но устарело сейчас;
• две версии относятся к разным периодам;
• новое утверждение не отменяет старое автоматически;
• время регистрации события отличается от времени действия знания;
• знание было инвалидировано или заменено;
• история содержит несколько переходов жизненного цикла.

Проверить, что поиск, сравнение и синтез не смешивают состояния разных временных срезов.

#12.3. Тесты доступа

Проверить:

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

#12.4. Тесты масштабирования

Использовать синтетический и, по возможности, обезличенный набор, отражающий эксплуатационные условия:

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

Проверить ограниченность потребления памяти, задержки и стабильность результатов при увеличении объёма данных.

#12.5. Сценарные испытания

Подготовить не менее нескольких воспроизводимых задач исследования, в которых точная формулировка нужного знания заранее не предоставляется агенту.

Примеры:

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

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

#13. Критерии приёмки

Задача считается выполненной, когда соблюдены все следующие условия.

#Функциональность

• Реализованы все шесть операций: orient, search, expand, trace, compare, synthesize.
• Операции используют существующую модель знаний и не создают параллельную систему памяти.
• Агент может начать исследование с приблизительного вопроса без идентификатора конкретного знания.
• Результаты содержат устойчивые идентификаторы и основания существенных выводов.
• Доступны переходы между найденными знаниями, отношениями и исходными событиями.
• Ограничения глубины, объёма и бюджета работают корректно.

#Корректность

• Явные отношения и кандидаты на связь различаются.
• Состояние жизненного цикла не интерпретируется как безусловная гарантия истинности.
• Сравнение учитывает временную и контекстную применимость.
• Отсутствие результатов не выдаётся за доказательство отсутствия факта.
• Ограниченные и частичные результаты явно маркируются.
• Все операции соблюдают права доступа.

#Интеграция

• Инструмент доступен через предусмотренный существующей архитектурой механизм агентных инструментов.
• Формат результата пригоден для дальнейшей обработки агентом.
• Существующие механизмы формирования и подтверждения знаний продолжают работать без нарушения контрактов.
• Для ключевых операций предусмотрены автоматизированные тесты.

#Качество исследования

• На согласованном наборе сценариев агент может обнаруживать релевантные знания по приблизительному запросу.
• Для найденных конфликтов доступны исходные утверждения и основания сравнения.
• Итоговый синтез не теряет ссылки на источники и явно обозначает неопределённости.
• Исследование ограничено по глубине и объёму и не приводит к бесконечному обходу связей.

Численные целевые показатели полноты поиска, задержки и стоимости должны быть определены после аудита текущей реализации и получения исходных измерений. Нельзя принимать задачу только по факту успешного выполнения нескольких демонстрационных запросов.

#14. Этапы реализации

#Этап 1. Аудит и проектирование

• Изучить актуальную реализацию Temporality.
• Зафиксировать существующие контракты и возможности.
• Определить минимальные недостающие компоненты.
• Согласовать схемы операций и результатов.
• Определить тестовые сценарии и метрики.

Результат: короткий архитектурный план с привязкой к реальным модулям репозитория. Аудит текущей реализации выполнен (таблица §3); этап закрывается согласованием схем операций и тестовых сценариев.

#Этап 2. Базовый исследовательский API

Реализовать:

• orient;
• search;
• expand;
• trace;
• compare;
• synthesize.

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

Результат: работающий инструмент, доступный агенту.

Статус реализации (Этапы 2–3, движок lexical-idf.v1):

• ✅ движок — observation.ExploreKnowledge (observation/explore.go): шесть операций над видимой базой, детерминированные тай-брейки по id, лимиты max_items (20/100), max_depth (1/3), бюджет обхода с флагом truncated, явное разделение explicit/candidate, ExploreAlgorithmVersion в каждом ответе;
• ✅ нормализация признаков — observation/features.go: сегментация идентификаторов (camelCase/snake/kebab, склейка v2/k8s/jwt2024), свёртка ё→е, лёгкий русский стемминг («миграция/миграции/миграцию» → один токен), стоп-слова с застеммленными формами, значимые короткие токены (go, c, r, v2); движок priming (contentTokens) не затронут — он настроен бенчмарком lexical-entity-topic.v3;
• ✅ API — POST /v1/observations/knowledge/explore (observation/httpapi): тот же путь видимости, что у остальных эндпоинтов знаний (gate → visible events → projection → фильтр scope), битемпоральные срезы as_of/known_at, строгая валидация (400/422/403);
• ✅ тул агента — knowledge_explore (KernelTools + handleKnowledgeExploreTool): составной, авто-апрув (policy-safe), project-scoped, ответ капится 6000 символов;
• ✅ тесты — движок (все операции, словоформы, идентификаторы, глубина/циклы, бюджеты, детерминизм), httpapi (happy/валидация/битемпоральность/403/аноним), kernel (коэрсция аргументов, HTTP-ошибки);
• ⏳ сценарные испытания на живых задачах и замеры задержек — Этап 3 остаётся открытой практической частью (числовые целевые показатели §13 ещё не определены);
• ✅ пользовательский Explorer (§9) — реализован (страница /knowledge, этапы 1–4 плана).

#Этап 3. Проверка качества

• Добавить автоматизированные тесты.
• Провести сценарные испытания.
• Проверить временную корректность и права доступа.
• Измерить задержки и стоимость.
• Устранить обнаруженные дефекты.

Результат: подтверждённая работоспособность исследовательского цикла на воспроизводимых задачах.

#Этап 4. Пользовательский Explorer

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

Не дублировать в интерфейсе бизнес-логику исследовательского API.

#15. Что не входит в первую версию

Без отдельного обоснования не реализовывать:

• новую независимую базу знаний;
• полноценную OWL-онтологию и универсальный редактор онтологий;
• автоматическое подтверждение или инвалидирование утверждений;
• автоматическое сохранение всех семантических связей как фактов;
• неограниченный обход графа;
• отдельную систему памяти агента, дублирующую Temporality;
• обязательную миграцию существующих знаний;
• автоматическую генерацию организационной классификации, заменяющей действующую модель доступа;
• автоматическое исправление конфликтующих утверждений без предусмотренного процесса подтверждения.

#16. Итоговый результат разработки

В результате Temporality получает единый механизм исследования знаний, который позволяет агенту или человеку пройти путь:

приблизительный вопрос → ориентация в предметной области → поиск понятий и утверждений → исследование связей → проверка происхождения и противоречий → компактное досье с доказательствами и пробелами.

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

При реализации необходимо опираться на актуальный код Temporality, повторно использовать существующие механизмы и избегать архитектурных изменений, которые не требуются для достижения этой цели.