# ТЗ Этапа 5
## Investigation Engine для Assistant Mode

## 0. Назначение документа

Этот документ фиксирует архитектурно-техническое задание на Этап 5 развития бухгалтерского ассистента: **переход от problem-centric reasoning к управляемому режиму расследования**.

Документ описывает:

- зачем нужен Investigation Engine;
- какие ограничения остаются после Этапов 1–4;
- какие новые сущности вводятся;
- как эти сущности связаны с уже существующими контурами assistant runtime;
- как должен работать bounded investigation flow;
- какие домены и типы проверок должны поддерживаться;
- как не превратить этап в псевдо-агентный чат без реальной архитектуры проверки;
- по каким критериям считать этап выполненным.

Этот этап **не строит автономного агента общего назначения**. Он строит **управляемый investigation engine** поверх уже подготовленных слоёв:

- hardened assistant loop;
- mechanism-aware evidence pack;
- problem-centric retrieval unit;
- lifecycle formalization;
- accounting ontology graph core.

---

## 1. Архитектурный контекст этапа

К началу Этапа 5 в системе уже должны существовать и работать следующие слои:

1. **Foundation Hardening**
   - базовый `investigation_state`;
   - broad-query guard;
   - mechanism-aware evidence pack;
   - accountant-facing eval metrics;
   - tightened answer contract.

2. **Retrieval Unit Shift**
   - переход от entity-heavy retrieval к problem-centric retrieval;
   - problem units как рабочая единица анализа.

3. **Lifecycle Formalization**
   - доменные lifecycle-модели;
   - runtime resolution текущего состояния;
   - lifecycle defect typing.

4. **Accounting Ontology Graph Core**
   - typed nodes and edges;
   - graph-backed traversal;
   - graph-aware problem assembly.

Без этих слоёв Investigation Engine либо станет декоративным orchestration-слоем без опоры на реальные причинные связи, либо превратится в chat-style prompt chaining.

---

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

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

После Этапов 1–4 ассистент уже способен:

- удерживать фокус сессии;
- лучше narrow-ить broad prompts;
- извлекать mechanism-aware evidence;
- поднимать problem units;
- объяснять lifecycle defects;
- использовать graph core для причинных переходов.

Но даже при этом система всё ещё остаётся в первую очередь **answering system**, а не **investigation system**.

То есть в типичном режиме она всё ещё работает как:

`user question -> main retrieval pass -> explanation`

Даже если этот pass стал глубже и качественнее, он остаётся преимущественно **single-pass driven**.

### 2.2. Что должно измениться

На Этапе 5 система должна перейти к режиму:

`user question -> investigation case -> hypotheses -> branches -> steps -> evidence synthesis -> bounded conclusion`

То есть ассистент должен уметь:

- не только отвечать;
- но и **вести расследование**;
- не только находить проблему;
- но и **проверять версии её механизма**;
- не только собирать evidence;
- но и **разводить подтверждённое, неподтверждённое и вероятностное**;
- не только продолжать чат;
- но и **удерживать структуру аналитического процесса**.

---

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

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

**problem-aware explainable assistant**

в состояние:

**bounded бухгалтерский investigation copilot**, который умеет:

- открывать investigation case;
- формулировать рабочие гипотезы;
- заводить ветки проверки;
- проходить по 2–3 связанным веткам по правилам;
- принимать решения о secondary checks;
- честно останавливать расследование, если данных недостаточно;
- выдавать investigation-grade conclusion.

---

## 4. От чего сознательно отказываемся в этом этапе

Чтобы этап не расползся и не превратился в бесконечную агентную разработку, в Этап 5 **не входят**:

- автономный self-directed general agent;
- неограниченное exploration без stop criteria;
- полный audit orchestrator для тяжёлых batch-режимов;
- полная live-first runtime-архитектура;
- полная междоменная свобода без bounded policy;
- замена deterministic control policy на purely LLM-driven agent loop;
- автоматическое открытие неограниченного числа гипотез и веток.

Этап 5 строит **bounded investigation engine** с управляемыми правилами и жёсткими ограничителями.

---

## 5. Главная продуктовая идея этапа

Пользовательский сдвиг должен быть следующим.

### Было

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

### Должно стать

Ассистент способен сказать:

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

Это и есть первый настоящий режим **расследования**, а не только ответов.

---

## 6. Новые архитектурные сущности этапа

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

---

## 6.1. `investigation_case`

### Смысл сущности

`investigation_case` — это контейнер конкретного расследования.

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

### Зачем нужна

Текущий `investigation_state` из Этапа 1 позволяет удерживать фокус. Но для зрелого investigation mode нужен отдельный объект, который фиксирует:

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

### Архитектурная роль

`investigation_case` становится верхнеуровневым объектом orchestration layer.

Он связывает:

- user intent;
- focus context;
- hypotheses;
- branches;
- steps;
- evidence;
- conclusions.

### Минимальный состав полей

- `case_id`
- `session_id`
- `originating_user_message_id`
- `investigation_type`
- `title`
- `domain_scope`
- `account_scope`
- `period_scope`
- `status`
- `primary_focus`
- `opened_at`
- `updated_at`
- `confidence_level`
- `final_conclusion_summary`
- `open_questions`
- `requires_live_verification`
- `case_priority`

### Возможные значения `investigation_type`

- `causal_chain_investigation`
- `document_role_investigation`
- `lifecycle_defect_investigation`
- `cross_branch_consistency_investigation`
- `period_impact_investigation`
- `pattern_recurrence_investigation`

### Связь с бухгалтерским контекстом

`investigation_case` должен быть способен описывать расследование как в узком бухгалтерском домене, так и в междоменном контуре.

Например:

- проблема по 51/60;
- зависание по 97;
- ОС-контур;
- НДС и документный конфликт;
- period-close risk case.

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

Нельзя приравнивать `investigation_case` к обычной цепочке сообщений в чате. Это должно быть отдельное runtime-представление со своей жизнью и статусом.

---

## 6.2. `investigation_hypothesis`

### Смысл сущности

`investigation_hypothesis` — это формализованная рабочая версия, которую система проверяет в рамках кейса.

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

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

### Примеры гипотез

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

### Архитектурная роль

Гипотеза является главным объектом reasoning orchestration.

Через неё система:

- запускает ветки проверки;
- собирает supporting evidence;
- собирает contradicting evidence;
- меняет статус уверенности;
- фиксирует, подтверждена ли версия.

### Минимальный состав полей

- `hypothesis_id`
- `case_id`
- `statement`
- `hypothesis_type`
- `target_domain`
- `target_problem_units`
- `supporting_evidence_refs`
- `contradicting_evidence_refs`
- `status`
- `confidence_level`
- `created_from`
- `suggested_next_checks`
- `requires_neighbor_branch`
- `requires_live_confirmation`

### Возможные статусы

- `open`
- `supported`
- `contradicted`
- `inconclusive`
- `superseded`
- `escalated`

### Связь с бухгалтерским смыслом

Гипотеза должна формулироваться не в абстрактно-LLM-лексике, а в виде бухгалтерски интерпретируемой версии:

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

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

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

---

## 6.3. `investigation_branch`

### Смысл сущности

`investigation_branch` — это отдельное направление проверки внутри кейса.

Гипотеза — это формулировка версии. Ветка — это operational route её проверки.

### Зачем нужна

Одна гипотеза может требовать нескольких направлений проверки:

- пройти по цепочке платежа;
- проверить lifecycle continuity;
- проверить роль документа;
- проверить соседнюю ветку;
- проверить влияние на закрытие периода.

### Архитектурная роль

Branch становится основной единицей bounded multi-step execution.

Через branch engine система:

- запускает steps;
- фиксирует visited nodes / traversed edges;
- накапливает evidence;
- выносит частичный вывод;
- передаёт результат обратно в hypothesis evaluation.

### Минимальный состав полей

- `branch_id`
- `case_id`
- `parent_hypothesis_id`
- `branch_type`
- `branch_goal`
- `status`
- `visited_graph_nodes`
- `visited_problem_units`
- `visited_domains`
- `collected_evidence_refs`
- `branch_conclusion`
- `branch_confidence`
- `opened_from`
- `recommended_next_branches`

### Базовые типы веток

- `primary_causal_branch`
- `lifecycle_validation_branch`
- `document_role_branch`
- `cross_branch_consistency_branch`
- `pattern_recurrence_branch`
- `period_impact_branch`

### Связь с бухгалтерским контекстом

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

Например:

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

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

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

---

## 6.4. `investigation_step`

### Смысл сущности

`investigation_step` — это конкретное действие внутри ветки.

### Зачем нужна

Без step model branch превратится в нечитаемый контейнер, а система не сможет:

- логировать ход расследования;
- повторять логику;
- объяснять, почему пришла к выводу;
- управлять stop criteria.

### Архитектурная роль

`investigation_step` является минимальной единицей bounded execution внутри investigation engine.

### Минимальный состав полей

- `step_id`
- `branch_id`
- `step_type`
- `step_goal`
- `input_refs`
- `execution_mode`
- `result_refs`
- `status`
- `confidence_delta`
- `decision_after_step`
- `opened_at`
- `completed_at`

### Базовые типы шагов

- `trace_chain_step`
- `validate_lifecycle_step`
- `compare_expected_vs_actual_step`
- `check_document_role_step`
- `open_neighbor_branch_step`
- `check_period_impact_step`
- `check_pattern_recurrence_step`
- `collect_supporting_evidence_step`
- `collect_contradicting_evidence_step`

### Связь с бухгалтерским контекстом

Каждый step должен быть интерпретируем как реальное бухгалтерское действие проверки:

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

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

Нельзя превращать step model в технический execution log без смысловой классификации.

---

## 6.5. `investigation_decision`

### Смысл сущности

`investigation_decision` фиксирует, почему engine принимает то или иное управленческое решение внутри расследования.

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

Именно эта сущность защищает систему от псевдо-агентной “магии”.

Без неё LLM может просто продолжать что-то проверять, но не будет ясно:

- почему открыта новая ветка;
- почему кейс завершён;
- почему уверенность снижена;
- почему требуется live verification;
- почему нужна clarification.

### Минимальный состав полей

- `decision_id`
- `case_id`
- `branch_id`
- `step_id`
- `decision_type`
- `decision_reason`
- `evidence_basis`
- `confidence_basis`
- `resulting_action`
- `created_at`

### Базовые типы решений

- `continue_same_branch`
- `open_secondary_check`
- `open_neighbor_branch`
- `mark_hypothesis_supported`
- `mark_hypothesis_contradicted`
- `mark_hypothesis_inconclusive`
- `request_clarification`
- `recommend_live_verification`
- `finalize_case`

### Связь с бухгалтерским смыслом

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

---

## 6.6. `investigation_output_contract`

### Смысл сущности

Нужен отдельный итоговый формат user-facing результата для investigation mode.

### Почему он отдельный

Ответы investigation mode не должны выглядеть как обычный answer bubble.

Они должны отражать:

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

### Обязательные части результата

1. `investigation_focus`
2. `primary_hypothesis`
3. `checked_branches`
4. `confirmed_findings`
5. `contradicted_or_unconfirmed_findings`
6. `remaining_uncertainty`
7. `recommended_next_action`
8. `requires_live_verification`

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

Нельзя пытаться использовать для investigation mode тот же output contract, что и для обычного factual answer.

---

## 7. Доменные режимы Investigation Engine

Engine должен быть завязан на уже введённые бухгалтерские домены и problem units, а не работать “вообще”.

На Этапе 5 investigation support обязателен как минимум для следующих доменов:

### 7.1. Банк / расчёты / 51–60
Типовые сценарии:
- платёж отражён, закрытие не подтверждено;
- неправильный тип закрывающего документа;
- банк и расчётный контур расходятся;
- повторяемый settlement defect.

### 7.2. Покупатели / 62
Типовые сценарии:
- оплата не согласована с реализацией;
- дебиторская позиция живёт против логики движения;
- зачёт/закрытие не подтверждены.

### 7.3. РБП / 97
Типовые сценарии:
- объект живёт дольше ожидаемого;
- не подтверждено ожидаемое списание;
- lifecycle defect не локален, а серийный.

### 7.4. ОС / 08–01–02
Типовые сценарии:
- принятие к учёту / ввод / амортизация расходятся;
- объект ОС существует в противоречивом состоянии;
- проблема локальная или повторяется по классу объектов.

### 7.5. НДС / 19–68
Типовые сценарии:
- документная стадия не согласована с налоговым отражением;
- вычет/период/связка с первичкой противоречат друг другу.

### 7.6. Закрытие периода
Типовые сценарии:
- найденный defect реально влияет на close;
- влияние не прямое, а через соседнюю ветку;
- проблема локальная, но имеет period-impact.

---

## 8. Архитектурная схема Investigation Engine

### 8.1. Новое место в общей архитектуре

После Этапа 5 assistant runtime становится таким:

`user message -> intent / decomposition -> retrieval / problem units / lifecycle / graph -> investigation case open or reuse -> hypothesis formation -> branch execution -> step decisions -> evidence synthesis -> investigation output`

### 8.2. Роль LLM в этом контуре

LLM не должна быть единственным носителем логики расследования.

LLM разрешается использовать для:

- interpretation user question into investigation intent;
- controlled hypothesis wording;
- explanation synthesis;
- soft prioritization between allowed branch options.

LLM не должна единолично решать:

- сколько веток открыть без ограничений;
- как долго продолжать расследование;
- когда игнорировать отсутствие evidence;
- когда делать окончательный вывод без stop policy;
- как обходить bounded orchestration rules.

### 8.3. Роль deterministic policy

Детерминированный orchestration policy обязан управлять:

- ограничением числа гипотез;
- ограничением числа веток;
- допустимыми переходами между branch types;
- stop criteria;
- escalation to clarification/live verification.

---

## 9. Hypothesis Model

### 9.1. Общие правила

На кейс допускается ограниченное число рабочих гипотез.

Рекомендуемый baseline на этапе 5:

- 1 primary hypothesis;
- до 2 secondary hypotheses;
- 1 fallback hypothesis.

Это ограничение защищает от расползания расследования.

### 9.2. Классификация hypothesis types

- `document_role_mismatch`
- `broken_chain`
- `lifecycle_defect`
- `cross_branch_inconsistency`
- `pattern_recurrence`
- `period_impact_confirmed`
- `period_impact_not_confirmed`
- `insufficient_evidence`

### 9.3. Правила работы с гипотезами

- primary hypothesis должна быть открыта только при достаточном evidence basis;
- secondary hypotheses допустимы, если primary hypothesis не объясняет всю механику;
- hypotheses должны конкурировать или уточнять, а не дублировать друг друга;
- hypothesis без supporting evidence не может повышаться до `supported`.

### 9.4. Запреты

- нельзя хранить гипотезы как свободный текст без type system;
- нельзя считать summary phrase гипотезой;
- нельзя переносить generic explanation language в hypothesis model.

---

## 10. Branch Model

### 10.1. Общие правила

Ветка должна быть bounded и иметь:

- тип;
- цель;
- start condition;
- success condition;
- stop condition.

### 10.2. Branch start conditions

Ветка может быть открыта только если:

- есть связанная hypothesis;
- есть доказуемая причина для branch open;
- существует domain-supported traversal path;
- branch type разрешён policy-слоем.

### 10.3. Branch success conditions

Ветка считается успешной, если:

- собран достаточный supporting/contradicting evidence;
- branch conclusion может изменить status hypothesis;
- найден явный reason to continue elsewhere.

### 10.4. Branch stop conditions

Ветка должна закрываться, если:

- evidence sufficient;
- evidence contradictory but sufficient;
- дальше нужен live confirmation;
- branch traversal exhausted;
- uncertainty too high and clarification required.

### 10.5. Ограничение количества веток

На baseline Этапа 5 рекомендуется bounded policy:

- максимум 1 primary branch;
- максимум 2 secondary branches;
- максимум 1 neighbor branch;
- максимум 1 period-impact branch.

---

## 11. Step Execution Model

### 11.1. Общие правила

Каждый step должен быть:

- смысловым;
- логируемым;
- ограниченным;
- влияющим на confidence/hypothesis status/branch routing.

### 11.2. Категории steps

#### A. Evidence collection steps
- collect linked documents
- collect postings
- collect lifecycle transitions
- collect graph neighbors

#### B. Validation steps
- validate expected edge
- validate expected state transition
- validate document role
- validate period impact

#### C. Comparative steps
- compare expected vs actual path
- compare current case vs recurring pattern
- compare primary branch vs neighbor branch

#### D. Decision-triggering steps
- open secondary branch
- lower confidence
- escalate to live verification
- finalize supported hypothesis

### 11.3. Запреты

Нельзя превращать steps в неограниченный nested chain. Step engine должен быть bounded.

---

## 12. Orchestration Policy

Это один из центральных разделов этапа.

### 12.1. Основной принцип

Investigation Engine должен быть **policy-driven**, а не purely LLM-driven.

### 12.2. Что определяет policy

Policy определяет:

- какие branch types допустимы для данного investigation_type;
- когда можно открыть secondary branch;
- когда можно открыть neighbor branch;
- когда требуется clarification;
- когда требуется live verification;
- когда можно финализировать кейс.

### 12.3. Базовые policy transitions

#### Если primary evidence strong
- разрешено `mark_hypothesis_supported`
- разрешено `finalize_case`
- optional `period_impact_branch`

#### Если evidence partial but structured
- разрешено `open_secondary_check`
- запрещено strong final conclusion

#### Если evidence points to neighbor inconsistency
- разрешено `open_neighbor_branch`

#### Если uncertainty too high
- разрешено `request_clarification`
- запрещено pseudo-confident answer

#### Если snapshot insufficient for certainty
- разрешено `recommend_live_verification`

### 12.4. Stop policy

Case must stop when:

- bounded branch set completed;
- primary hypothesis supported enough;
- all open hypotheses inconclusive but no justified next branch remains;
- live verification required for further progress;
- clarification mandatory.

### 12.5. Что запрещено

- нельзя продолжать investigation только потому, что “модель хочет ещё подумать”;
- нельзя открывать новые ветки без явного decision record;
- нельзя скрывать неуверенность за длинным narrative.

---

## 13. Связь с graph / lifecycle / problem units

Investigation Engine не существует отдельно. Он должен использовать уже введённые слои.

### 13.1. Использование problem units

Investigation branches работают не по raw entities, а по problem units как по базовым узлам аналитики.

### 13.2. Использование lifecycle

Hypotheses и branches должны уметь ссылаться на lifecycle defects:

- missing transition;
- invalid transition;
- stale state;
- contradictory final state.

### 13.3. Использование graph core

Neighbor branch / chain tracing / cross-domain consistency должны выполняться через graph traversal, а не через ad hoc таблицы связей.

### 13.4. Использование mechanism-aware evidence pack

Step results and branch conclusions должны опираться на mechanism-specific evidence, а не только на abstract labels.

---

## 14. Investigation Output Contract

### 14.1. Новый user-facing формат

Investigation mode требует отдельного результата.

### 14.2. Обязательная структура

#### 1. Что расследовалось
- короткое определение focus

#### 2. Главная проверенная версия
- primary hypothesis in accountant language

#### 3. Что было проверено
- список branch conclusions

#### 4. Что подтвердилось
- confirmed findings

#### 5. Что не подтвердилось или осталось вероятностным
- contradicted / inconclusive findings

#### 6. Где ограничения
- snapshot-limited / insufficient evidence / neighbor branch still unresolved

#### 7. Что делать дальше
- recommended next action

### 14.3. Требования к стилю

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

---

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

Главный риск этапа — построить **псевдо-расследование**, а не реальный engine.

Ниже фиксируются анти-рисковые правила.

### 15.1. Нельзя подменять расследование длинной памятью чата

Conversation history != investigation engine.

### 15.2. Нельзя подменять гипотезы summary-фразами

Если hypotheses не typed и не имеют supporting/contradicting evidence, это не hypotheses.

### 15.3. Нельзя подменять ветки серией retrieval-вызовов

Если нет branch identity, goal, stop condition и branch conclusion, это не branch.

### 15.4. Нельзя подменять policy свободным LLM chaining

Если decisions не bounded, investigation превращается в расползание.

### 15.5. Нельзя считать этап успешным, если итог всё ещё single-pass

Если branch/hypothesis model есть формально, но user-facing result строится почти как раньше, этап не выполнен.

### 15.6. Нельзя запускать неограниченное число проверок

Bounded mode обязателен. Этап 5 — controlled engine, не free agent.

---

## 16. Изменения по слоям системы

### 16.1. Session Layer

Расширить `investigation_state` до полноценной связи с `investigation_case`.

### 16.2. Backend Runtime

Ввести:

- case manager;
- hypothesis registry;
- branch manager;
- step executor;
- decision recorder.

### 16.3. Retrieval Layer

Научить retrieval работать как step executor input, а не только как answer producer.

### 16.4. Graph Layer

Добавить traversal interfaces под branch types.

### 16.5. Lifecycle Layer

Сделать lifecycle resolution callable from branch execution.

### 16.6. Answer Layer

Добавить investigation-grade output contract.

### 16.7. Logging / Observability

Логировать:

- case open / close;
- hypothesis status changes;
- branch open / close;
- step results;
- decisions;
- stop reason;
- live verification recommendation reason.

---

## 17. Изменения в evaluation

Этап 5 требует нового eval harness поверх accountant metrics.

### Новые обязательные метрики

- `hypothesis_quality_score`
- `branch_relevance_score`
- `secondary_check_precision`
- `neighbor_branch_usefulness_score`
- `supported_vs_inconclusive_honesty_score`
- `investigation_output_clarity_score`
- `stop_policy_quality_score`
- `pseudo_agentic_behavior_rate`

### Канонические сценарии

1. 51/60: платёж есть, закрытие не подтверждено, проверить роль документа и соседний расчётный контур.
2. 97: подтвердить, что объект живёт за пределами ожидаемого окна списания.
3. ОС: проверить, где lifecycle defect локальный, а где системный.
4. НДС: проверить, действительно ли конфликт живёт в налоговом контуре, а не в документной стадии.
5. Period close: подтвердить, какие defects реально влияют на закрытие периода.
6. Pattern recurrence: установить, это единичный кейс или серийный паттерн.

---

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

Этап считается выполненным, если одновременно выполнены следующие условия.

### 18.1. Сущности введены не формально, а runtime-значимо

В системе реально существуют и используются:

- `investigation_case`
- `investigation_hypothesis`
- `investigation_branch`
- `investigation_step`
- `investigation_decision`
- `investigation_output_contract`

### 18.2. Система умеет вести bounded investigation

Хотя бы по ключевым доменам:

- открывать кейс;
- создавать primary hypothesis;
- открывать минимум 1–2 ветки;
- выполнять steps;
- собирать evidence;
- завершать кейс по policy.

### 18.3. Итоговый output investigation-grade

User-facing result показывает:

- что расследовалось;
- какая версия подтверждена;
- что ещё uncertain;
- что делать дальше.

### 18.4. Engine не расползается

Ветка и шаги bounded policy-слоем. Нет неконтролируемого branching.

### 18.5. Система честно различает supported / contradicted / inconclusive

Нет ложной уверенности, если evidence недостаточно.

---

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

Этап **не считается выполненным**, если произошло что-либо из следующего:

- появилась только более длинная память чата;
- появились только красивые summary про “проверили несколько веток”;
- появились только дополнительные retrieval passes без branch model;
- hypotheses не typed и не влияют на execution;
- decisions не записываются и не управляют engine;
- output не отличается от обычного answer bubble;
- investigation mode фактически остаётся single-pass.

---

## 20. Практический идеальный результат этапа

После Этапа 5 ассистент ещё не станет полностью автономным бухгалтерским исследователем, но он должен перестать быть просто “сильным answering assistant”.

Он должен стать системой, которая может:

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

---

## 21. Короткое управленческое резюме

Этап 5 — это переход от ассистента, который умеет находить и объяснять проблемы, к ассистенту, который умеет **проверять версии причины по нескольким связанным бухгалтерским веткам**.

Главный продукт этапа — не новый промпт и не новый retrieval, а **Investigation Engine** как bounded orchestration layer поверх problem units, lifecycle и graph core.

Именно после этого этапа становится рационально переходить к следующему уровню: live verification, разведению execution modes Direct / Investigation / Audit и полноценному product-grade copilot behavior.
