# ТЗ Этап 6 — Live Verification + Product Modes для Assistant Mode

## 0. Назначение этапа

Этап 6 завершает переход от архитектурного прототипа бухгалтерского ассистента к зрелой продуктовой системе.  
Если предыдущие этапы строили внутреннюю способность системы понимать данные, поднимать problem units, формализовать lifecycle, работать через graph core и вести bounded investigation, то этот этап отвечает уже за другое:

- как ассистент работает в разных продуктовых режимах;
- когда он отвечает быстро, а когда запускает расследование;
- когда он может опираться на snapshot и inference, а когда обязан или должен рекомендовать live verification;
- как выполнять широкий audit / batch analysis, не превращая его в “очень длинный чат-ответ”;
- как формально различать уровни доверия к результату;
- как превратить reasoning-архитектуру в рабочий product contract.

Этап 6 не должен переписывать reasoning core.  
Он должен сделать уже построенные слои:

- Foundation Hardening;
- Problem-centric Retrieval;
- Lifecycle Formalization;
- Accounting Ontology Graph Core;
- Investigation Engine;

— **общим основанием для трёх разных режимов продукта**.

---

## 1. Смысл этапа

### 1.1. От какой проблемы идём

До Этапа 6 ассистент уже может быть умным и архитектурно глубоким, но всё ещё может оставаться системой, у которой:

- один основной conversational loop;
- один базовый execution path;
- разная глубина ответа, но не разные режимы работы;
- нет формальной границы между direct answer, investigation и wide analysis;
- нет штатного слоя live verification;
- нет жёсткой модели доверия к результату.

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

### 1.2. Что должен решить этап

Этап 6 должен решить три системные задачи:

1. **развести execution modes**;
2. **ввести live verification как штатный runtime capability**;
3. **ввести trust / provenance model**, чтобы пользователь и система одинаково понимали, какой именно тип результата выдан.

---

## 2. Целевая способность системы после этапа

После завершения Этапа 6 ассистент должен поддерживать три полноценных режима:

### 2.1. Direct Answer Mode

Для локальных вопросов:

- что не бьётся;
- где разрыв;
- какие документы участвуют;
- почему объект завис;
- какие проблемы по конкретному счёту/контрагенту/объекту.

Система должна:

- отвечать быстро;
- не запускать сложное расследование без веской причины;
- уметь ограничить глубину;
- маркировать уровень уверенности;
- уметь рекомендовать escalation в investigation или live verification.

### 2.2. Investigation Mode

Для многосоставных и гипотезных вопросов:

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

Система должна:

- открыть investigation case;
- вести ветки и гипотезы;
- выполнять bounded multi-step flow;
- различать доказанное и вероятное;
- при необходимости запускать live verification;
- завершать расследование по формальным stop criteria.

### 2.3. Audit / Batch Analysis Mode

Для широких запросов:

- проведи полный анализ периода;
- найди системные дефекты;
- покажи recurring patterns;
- собери зоны риска;
- сгруппируй problem clusters;
- дай приоритеты для дальнейшей проверки.

Система должна:

- запускать отдельный batch pipeline;
- обрабатывать расширенный scope;
- собирать много problem units;
- агрегировать результаты;
- выдавать отчётный итог, а не обычный чат-ответ.

---

## 3. Что сохраняем, а что меняем

### 3.1. Что сохраняем

Этап 6 **не переписывает** уже построенные reasoning-слои. Он опирается на них как на substrate.

Сохраняются:

- semantic_retrieval_profile;
- mechanism-aware evidence pack;
- problem unit model;
- lifecycle knowledge layer;
- graph core;
- investigation case / hypothesis / branch / step model;
- bounded orchestration policy;
- answer contract;
- accountant-facing eval framework.

### 3.2. Что меняем принципиально

На Этапе 6 меняются:

- execution governance;
- mode selection;
- runtime contracts для различных режимов;
- provenance/trust model;
- способ живой верификации;
- отдельный audit pipeline;
- user-facing result contracts в зависимости от режима.

### 3.3. От чего отказываемся

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

- быстрый factual вопрос;
- глубокое расследование;
- широкий аналитический прогон.

Это неверно.

Этап 6 официально фиксирует, что продукт имеет несколько execution modes, а не один loop с разной длиной ответа.

---

## 4. Архитектурная цель этапа

К концу Этапа 6 текущая система должна перейти из состояния:

**“сильный reasoning assistant с investigation capability”**

в состояние:

**“зрелый бухгалтерский copilot с явными execution modes, live verification и формальной моделью доверия к результату”**.

---

## 5. Главные сущности этапа

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

---

## 5.1. Сущность №1 — `execution_mode`

### Почему нужна

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

Если `execution_mode` не формализован, то система:

- отвечает одинаковым контуром на вопросы принципиально разной глубины;
- не может нормально управлять допустимой латентностью;
- не может формально различать allowed depth и stop policy;
- не может грамотно объяснять пользователю, почему в одном случае ответ быстрый, а в другом запускается расследование или audit.

### Что делаем

Вводим базовую продуктовую сущность `execution_mode`.

### Типы mode

- `direct_answer`
- `investigation`
- `audit_batch`

### Обязательные поля

- `mode_id`
- `mode_type`
- `allowed_depth`
- `allowed_branching`
- `allowed_secondary_checks`
- `live_verification_policy`
- `latency_profile`
- `output_contract`
- `stop_policy`
- `clarification_policy`
- `trust_display_policy`

### Что это даст

- система перестанет скрытно использовать один execution loop для всего;
- появится product-grade governance;
- можно будет жёстко различать не только ответы, но и внутреннюю стратегию исполнения.

---

## 5.2. Сущность №2 — `mode_router`

### Почему нужна

Semantic routing отвечает на вопрос: **по какому смысловому профилю искать и анализировать**.  
Но этого недостаточно.

Нужен слой выше, который отвечает на вопрос:

- это быстрый direct answer?
- это investigation?
- это audit?
- требуется ли эскалация?
- разрешена ли live verification?

### Что делаем

Вводим `mode_router` как отдельный runtime-layer над semantic routing.

### Входы в `mode_router`

- исходный user query;
- decomposition result;
- query complexity;
- breadth estimate;
- expected evidence volume;
- active investigation_state;
- user intent markers;
- explicit requests типа “полный анализ”, “проверь глубоко”, “разберись”, “проведи аудит”, “сделай обзор”, “проверь гипотезу”; 
- cost/latency policy.

### Выходы `mode_router`

- `execution_mode`
- `mode_confidence`
- `escalation_hint`
- `live_verification_allowed`
- `expected_output_contract`

### Что меняется по смыслу

До этого момента система в основном решала: **какой смысловой маршрут и какие retrieval constraints**.  
Теперь она решает ещё и: **какой тип исполнения вообще уместен для данного запроса**.

---

## 5.3. Сущность №3 — `mode_transition_decision`

### Почему нужна

Даже если mode выбран на старте, в реальной работе ассистент может дойти до точки, где исходный режим перестаёт быть достаточным.

Примеры:

- direct answer упирается в противоречие и должен перейти в investigation;
- investigation упирается в snapshot-неопределённость и требует live verification;
- audit находит кластер высокой важности и предлагает drilldown;
- direct answer понимает, что вопрос фактически batch-scale.

### Что делаем

Вводим сущность `mode_transition_decision`.

### Поля

- `decision_id`
- `from_mode`
- `to_mode`
- `reason`
- `triggering_evidence`
- `confidence_before`
- `confidence_after`
- `user_visible`
- `accepted_automatically`
- `requires_user_confirmation`

### Что это даст

- режимы перестанут быть статичными;
- появится управляемая эскалация;
- переходы между режимами станут объяснимыми и контролируемыми.

---

## 5.4. Сущность №4 — `live_verification_request`

### Почему нужна

До Этапа 6 reasoning почти полностью опирается на:

- snapshot;
- normalized accounting entities;
- graph/lifecycle inference;
- investigation.

Но для части high-stakes кейсов этого недостаточно.  
Нужен способ адресно проверять source-of-truth.

### Что делаем

Вводим `live_verification_request` как штатную сущность runtime.

### Поля

- `request_id`
- `case_id`
- `problem_unit_id`
- `source_entity_type`
- `source_entity_id`
- `verification_goal`
- `requested_fields`
- `verification_scope`
- `reason_for_verification`
- `urgency`
- `policy_basis`
- `status`

### Возможные цели verification

- подтвердить существование документа;
- подтвердить текущий статус;
- подтвердить наличие или отсутствие связи;
- подтвердить текущее состояние расчёта;
- подтвердить lifecycle stage;
- подтвердить периодную принадлежность;
- снять конфликт snapshot vs expected chain.

### Что важно

Live verification — это не новый способ reasoning с нуля.  
Это механизм **подтверждения, эскалации и повышения доверия** к уже построенному reasoning.

---

## 5.5. Сущность №5 — `live_verification_result`

### Почему нужна

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

### Что делаем

Вводим `live_verification_result`.

### Поля

- `request_id`
- `verified_at`
- `verified_source`
- `verification_status`
- `verified_values`
- `missing_values`
- `discrepancies_vs_snapshot`
- `confidence_delta`
- `impact_on_problem_unit`
- `impact_on_hypothesis`
- `impact_on_case`
- `next_recommended_action`

### Что это даёт

- live verification становится частью расследования, а не внешней справкой;
- можно объяснять пользователю, что именно подтверждено живыми данными;
- появляется обновление trust state по кейсу.

---

## 5.6. Сущность №6 — `audit_run`

### Почему нужна

Широкий анализ нельзя обслуживать тем же контрактом, что и direct answer.  
Он имеет другой scope, другой темп, другой тип результата.

### Что делаем

Вводим `audit_run` как отдельную сущность пакетного анализа.

### Поля

- `run_id`
- `requested_scope`
- `time_window`
- `included_domains`
- `included_accounts`
- `included_filters`
- `execution_status`
- `progress`
- `problem_units_count`
- `cluster_count`
- `top_patterns`
- `final_summary`
- `report_artifacts`
- `drilldown_recommendations`

### Что это даёт

- audit перестаёт быть giant-chat-response;
- появляется отдельный batch-mode contract;
- можно строить отчётную аналитическую логику поверх reasoning substrate.

---

## 5.7. Сущность №7 — `trust_state`

### Почему нужна

К моменту Этапа 6 система уже может выдавать результаты разной природы:

- snapshot-derived;
- graph-backed;
- lifecycle-enriched;
- investigation-supported;
- live-verified.

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

### Что делаем

Вводим `trust_state` как формальную сущность доверия к результату.

### Поля

- `trust_level`
- `evidence_basis`
- `snapshot_only`
- `graph_supported`
- `investigation_supported`
- `live_verified`
- `limitations`
- `confidence_components`
- `recommended_next_step`

### Уровни trust

Примерный набор:

- `snapshot_inferred`
- `graph_lifecycle_supported`
- `investigation_supported`
- `live_confirmed`
- `inconclusive`

### Что это даёт

- взрослая модель доверия;
- честность в ответах;
- контролируемое различение inferred vs confirmed.

---

## 5.8. Сущность №8 — `output_contract_by_mode`

### Почему нужна

Разные режимы не могут заканчиваться одинаковым ответом.

### Что делаем

Вводим разные result contracts для каждого режима.

### Для `direct_answer`

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

- краткий вывод;
- mechanism summary;
- ключевые документы/сущности;
- уровень доверия;
- ограничения;
- при необходимости — recommendation to investigate/live-check.

### Для `investigation`

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

- главную гипотезу;
- проверенные ветки;
- что подтверждено;
- что опровергнуто;
- что осталось неопределённым;
- trust state;
- нужна ли live verification.

### Для `audit_batch`

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

- scope анализа;
- grouped problem clusters;
- recurring patterns;
- top risk areas;
- impact areas;
- drilldown recommendations;
- provenance/trust summary.

### Что это даёт

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

---

## 6. Полная цепь изменений по архитектуре

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

---

## 6.1. Вход сообщения и mode selection

### Сейчас

До Этапа 6 система в основном определяет semantic meaning и retrieval/investigation path.

### Что меняем

Добавляется `mode_router`, который до semantic execution определяет:

- это direct answer;
- investigation;
- audit;
- возможна ли автоматическая live escalation;
- нужен ли mode transition later.

### Цель

Ввести execution governance как отдельный слой.

---

## 6.2. Direct Answer Path

### Сейчас

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

### Что меняем

Для `direct_answer` вводятся:

- ограниченная глубина анализа;
- ограниченное число secondary checks;
- явный отказ от неограниченного branching;
- явная политика эскалации в investigation/live;
- отдельный output contract.

### Цель

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

---

## 6.3. Investigation Path

### Сейчас

После Этапа 5 bounded investigation уже существует как reasoning capability.

### Что меняем

Теперь investigation mode становится полноценным execution mode с:

- case lifecycle;
- mode-aware orchestration;
- live verification policy;
- stop policy;
- investigation-grade output contract.

### Цель

Перевести расследование из внутренней возможности в продуктовый режим.

---

## 6.4. Audit / Batch Path

### Сейчас

Широкие вопросы ещё потенциально могут идти через перегруженный conversational flow.

### Что меняем

Добавляется отдельный `audit_run` pipeline:

1. scope expansion;
2. domain/account selection;
3. retrieval over larger dataset;
4. batch problem-unit assembly;
5. lifecycle/graph enrichment;
6. grouping and prioritization;
7. report synthesis.

### Цель

Сделать широкий анализ отдельным execution contour.

---

## 6.5. Live Verification Path

### Сейчас

Живые проверки либо отсутствуют как штатный assistant path, либо не встроены в формальный trust model.

### Что меняем

Вводится два слоя:

- `live_verification_request`
- `live_verification_result`

А также policy:

- когда verification разрешён;
- когда он обязателен;
- когда он только рекомендован;
- как verification влияет на trust_state.

### Цель

Сделать live verification штатным способом подтверждения результата.

---

## 6.6. Trust / Provenance Layer

### Сейчас

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

### Что меняем

Каждый результат получает provenance/trust classification.

### Цель

Сделать выводы системы честными и операционно интерпретируемыми.

---

## 7. Правила mode router

### 7.1. Когда выбирать `direct_answer`

Использовать, если:

- вопрос узкий;
- scope локальный;
- ожидаемый evidence volume ограничен;
- нет явного запроса на глубокий анализ;
- достаточно snapshot + current reasoning;
- вопрос может быть закрыт accountant-grade answer без investigation case.

### 7.2. Когда выбирать `investigation`

Использовать, если:

- запрос многосоставный;
- есть гипотезы;
- нужно проверить несколько веток;
- нужен branch traversal;
- требуется доказательное отделение подтверждённого от вероятного;
- direct answer почти наверняка будет недостаточен.

### 7.3. Когда выбирать `audit_batch`

Использовать, если:

- пользователь просит полный анализ;
- scope охватывает период/зону/класс рисков;
- нужен обзор по множеству problem units;
- ожидается групповая аналитика, а не один вывод.

### 7.4. Когда поднимать live verification

Использовать, если:

- кейс high-stakes;
- snapshot явно недостаточен;
- есть значимый конфликт snapshot vs reasoning;
- без подтверждения source-of-truth вывод нельзя считать надёжным;
- пользователь требует подтверждения актуального состояния.

---

## 8. Подробная модель доверия

### 8.1. Источники trust

`trust_state` должен опираться на:

- snapshot quality;
- graph support;
- lifecycle support;
- problem unit completeness;
- investigation completeness;
- live verification;
- internal contradictions;
- unresolved branches.

### 8.2. Что нельзя делать

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

### 8.3. Пример trust-логики

- если вывод опирается только на snapshot + basic retrieval → `snapshot_inferred`
- если есть graph + lifecycle + strong problem unit evidence → `graph_lifecycle_supported`
- если пройдён bounded investigation с подтверждёнными ветками → `investigation_supported`
- если ключевые точки подтверждены live → `live_confirmed`

---

## 9. Детальный разбор product modes

---

## 9.1. Direct Answer Mode — подробный смысл

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

### Что здесь важно

- не уходить в pseudo-investigation без причины;
- не скрывать ограничения;
- не делать вид, что direct answer доказал больше, чем реально доказал;
- явно рекомендовать investigation/live, если это нужно.

### Что является хорошим результатом

- короткий accountant-grade ответ;
- mechanism summary;
- документы и связи названы конкретно;
- trust level честно обозначен.

---

## 9.2. Investigation Mode — подробный смысл

Это режим, где система работает как bounded copilot for reasoning.

### Что здесь важно

- открытие investigation case;
- branch/hypothesis execution;
- evidence separation;
- explicit stop criteria;
- controlled escalation to live verification.

### Что является хорошим результатом

- пользователь видит логику расследования;
- знает, что подтверждено;
- понимает, что ещё не закрыто;
- получает recommendation on next step.

---

## 9.3. Audit / Batch Mode — подробный смысл

Это режим, где система превращается во внутренний аналитический инструмент.

### Что здесь важно

- отдельный execution contour;
- batch retrieval and assembly;
- группировка и приоритизация;
- итог не в форме “ответа на вопрос”, а в форме structured analytical output.

### Что является хорошим результатом

- зоны риска;
- problem clusters;
- recurring patterns;
- приоритеты drilldown;
- ясная граница между overview и detail.

---

## 10. Как не уткнуться в главный риск этапа

### Главный риск

Сделать режимы как UI-названия или разные “тона ответа”, но не как реально разные execution contracts.

Если:

- direct / investigation / audit отличаются только длиной ответа;
- live verification существует, но не влияет на trust_state;
- audit просто длиннее direct answer;
- investigation просто делает 2–3 retrieval вместо одного;

— этап не выполнен.

### Что делать, чтобы этого не произошло

1. У каждого mode должны быть собственные:
   - allowed depth
   - branching policy
   - output contract
   - stop policy
   - live verification policy
2. `mode_router` должен быть отдельным runtime-layer.
3. `mode_transition_decision` должен быть формальной сущностью.
4. `trust_state` должен быть обязательной частью результата.
5. `audit_run` должен быть отдельным execution artifact.

---

## 11. Что именно должно быть разработано в коде и архитектуре

### 11.1. Новый runtime слой

- `mode_router`
- `mode_transition_decision`
- `execution_mode` config

### 11.2. Новый live слой

- `live_verification_request`
- `live_verification_result`
- `live_verification_policy`

### 11.3. Новый audit слой

- `audit_run`
- batch execution pipeline
- aggregation / grouping / reporting logic

### 11.4. Новый trust слой

- `trust_state`
- provenance markers
- trust computation policy

### 11.5. Новый output contract layer

- direct answer contract
- investigation result contract
- audit report contract

---

## 12. Что переписываем, а что только расширяем

### Не переписываем полностью

- retrieval core;
- lifecycle core;
- graph core;
- investigation engine;
- problem unit model.

### Существенно расширяем

- execution governance;
- user-facing output contracts;
- trust/provenance;
- live source integration;
- batch analysis contour.

### Частично усиливаем

- current assistant orchestration;
- clarification/escalation logic;
- benchmark/eval suite;
- frontend presentation layer for result types.

---

## 13. Артефакты этапа

К концу Этапа 6 должны появиться следующие артефакты:

1. `execution_mode` schema and config
2. `mode_router` specification
3. `mode_transition_decision` schema
4. `live_verification_request` schema
5. `live_verification_result` schema
6. `trust_state` specification
7. `audit_run` schema
8. `output_contract_by_mode` specification
9. `live_verification_policy` document
10. `mode_eval_harness` specification

---

## 14. Критерии приёмки этапа

Этап считается выполненным только если:

### 14.1. По execution modes

- система реально различает direct / investigation / audit;
- у режимов разные execution policies;
- mode selection объясним и предсказуем.

### 14.2. По live verification

- live verification существует как штатная сущность и runtime path;
- live verification влияет на trust_state и итоговый результат;
- система умеет честно разделять verified vs inferred.

### 14.3. По audit mode

- batch mode запускается как отдельный контур;
- итог audit — это аналитический output, а не просто длинный answer;
- есть grouped problem clusters и drilldown recommendations.

### 14.4. По trust/provenance

- каждый результат имеет trust/provenance classification;
- разные уровни подтверждённости различимы пользователю и системе.

### 14.5. По продуктовой зрелости

- пользователь ощущает реальную разницу между режимами;
- ассистент умеет не только думать, но и жить как product system.

---

## 15. Что не считается результатом этапа

Этап не считается выполненным, если произошло что-то из этого:

- просто добавили переключатель режима в UI;
- investigation и audit отличаются только размером ответа;
- live verification не встроен в trust/provenance;
- snapshot/live-ответы звучат одинаково уверенно;
- audit не имеет собственного execution artifact;
- mode transitions не формализованы.

---

## 16. Идеальный результат этапа

После завершения Этапа 6 ассистент ещё не обязан быть полностью enterprise-scale системой, но он уже должен стать зрелым бухгалтерским copilot’ом, который:

- умеет быстро отвечать на узкие вопросы;
- умеет вести bounded investigation;
- умеет запускать широкий batch analysis;
- умеет подтверждать выводы живыми данными;
- умеет честно различать уровни доверия;
- живёт как продукт, а не как набор архитектурных слоёв.

---

## 17. Управленческое резюме этапа

Этап 6 завершает формирование взрослой продуктовой архитектуры Assistant Mode.

Это этап, на котором:

- reasoning превращается в product behavior;
- investigation превращается в официальный execution mode;
- audit перестаёт быть перегруженным чат-ответом;
- live verification становится штатным механизмом подтверждения;
- trust/provenance перестаёт быть неявной уверенностью модели и становится формальным контрактом результата.

Именно после этого этапа ассистент можно считать не просто технически сильной системой, а зрелым бухгалтерским copilot’ом.
