Да, сейчас как раз надо **перевернуть логику** и идти **от целевой архитектуры назад**, а не от текущих латок вперёд.

Потому что по вашему же статус-репорту уже видно: текущая система — это не “почти готовый ассистент”, а **explainable routed assistant**, который умеет разбирать вопрос, запускать retrieval и собирать ответ, но ещё не является полноценным бухгалтерским investigation copilot. Главные потолки уже названы прямо: snapshot-only truth, неполный lifecycle, entity-heavy retrieval unit, отсутствие investigation_state, отсутствие итеративной оркестрации и live verification.

И ещё одна очень важная вещь из отчёта: доминирующий потолок — это **не слабые формулировки**, а **недостаточно структурированный причинный контекст до synthesis**. То есть лечить всё “ещё одной LLM” или “ещё одним промптом” — это тупиковый путь. 

Ниже дам тебе не просто roadmap, а именно **модель проектирования от идеального результата**.

---

# 1. Сначала фиксируем, что такое идеальный результат

Идеальный бухгалтерский ассистент для вас — это не чат, который “умеет отвечать на пару типов вопросов”.

Это система, которая умеет делать **три полноценных режима**.

## Режим A. Точечный причинно-следственный ответ

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

Пример:
“Какие проблемы по 51 счёту?”
Нормальный ответ здесь — это не список контрагентов и не абстрактные risk labels, а:

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

Для этого нужен не простой search, а **causal reconstruction**.

## Режим B. Многосоставной исследовательский вопрос

Пользователь задаёт сложный вопрос с гипотезами:

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

Это уже не single-shot answer.
Это мини-расследование.

## Режим C. Глобальный аналитический прогон

“Проведи полный анализ периода / зоны / класса рисков”.

Это уже не обычный ответ на чат-запрос, а **пакетное исследование**:

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

Для такого режима нужен отдельный execution mode, а не тот же самый lightweight pipeline, что и для короткого вопроса.

---

# 2. Отсюда вывод: у вас должен быть не один ассистент, а 3 архитектурных режима

Это очень важная развилка.

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

* короткий factual вопрос,
* сложный multi-intent вопрос,
* широкий audit / overview.

Так нельзя.
Нужно проектировать **три режима исполнения**, даже если внешне они живут в одном чате.

## Mode 1: Direct Answer

Для узких или средних вопросов.
Цель: дать сильный ответ быстро.

## Mode 2: Investigation

Для сложных вопросов с гипотезами, ветками и follow-up.
Цель: вести исследование, а не просто отвечать.

## Mode 3: Audit / Batch Analysis

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

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

---

# 3. Что должно быть в целевой взрослой архитектуре

Если идти от конца, то у вас в “высшей планке” должны быть **7 обязательных архитектурных слоёв**.

## Слой 1. Data truth layer

Система должна иметь доступ не только к плоскому снапшоту, но и к:

* документам,
* проводкам,
* регистрам,
* статусам,
* связям,
* live-подтверждению для high-stakes вопросов.

Сейчас у вас retrieval идёт из snapshot bundle, а live truth в assistant path отсутствует. Это сразу ставит потолок на достоверность.

## Слой 2. Accounting ontology graph

Нужен не просто набор labels, а типизированный граф:

* документ,
* проводка,
* движение регистра,
* счет,
* субсчет,
* контрагент,
* договор,
* ОС,
* РБП,
* НДС,
* период,
* закрытие,
* и связи между ними.

Сейчас semantic vocabulary есть, formal ontology graph нет.

## Слой 3. Lifecycle engine

Для большинства бухгалтерских аномалий важен не сам объект, а его жизненный цикл:

* создан,
* проведён,
* связан,
* закрыт,
* частично закрыт,
* завис,
* закрыт не тем документом,
* противоречит соседнему контуру.

Сейчас lifecycle у вас heuristic, а не formal state machine.

## Слой 4. Problem-cluster retrieval

Не entity-first retrieval, а retrieval по проблемным узлам:

* document_conflict
* broken_chain_segment
* lifecycle_anomaly_node
* unresolved_settlement_cluster
* period_risk_cluster
* cross_branch_inconsistency_cluster

Это прямо сформулировано в отчёте как следующий архитектурный переход. 

## Слой 5. Investigation state

Нужна не просто память чата, а память расследования:

* current focus,
* active hypotheses,
* checked branches,
* unresolved branches,
* evidence collected,
* confidence,
* next recommended checks.

Сейчас conversation memory есть, investigation memory model отсутствует.

## Слой 6. Iterative orchestration

Система должна уметь не только выполнять один route, а:

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

Сейчас pipeline в основном linear и route-driven. 

## Слой 7. Accountant-grade answer synthesis

Ответ должен строиться не по лейблам, а по механике нарушения:

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

Сейчас generic explanation ещё остаётся из-за broad retrieval unit и limited mechanism-specific fields.

---

# 4. Ключевая мысль: вам надо проектировать не “ассистента”, а бухгалтерический investigation engine

Вот здесь и есть разворот мышления.

Проблема не в том, что текущая система “простая”.
Проблема в том, что её базовая логика пока ближе к:

* normalize
* route
* retrieve
* synthesize

А целевая система должна быть ближе к:

* understand
* model
* investigate
* verify
* explain
* continue

То есть вы строите не просто retrieval assistant, а **engine исследования учётной причинности**.

И это означает, что ядром архитектуры должен стать не normalizer и не answer composer, а вот эта связка:

**ontology graph + lifecycle engine + problem-cluster retrieval + investigation state + orchestration policy**

---

# 5. Что делать дальше: реальная дорожная карта

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

## Этап 0. Зафиксировать, что дальше вы строите не чат-надстройку, а investigation architecture

Это организационный этап, но он критичен.

Нужно формально принять:

* есть 3 execution modes;
* есть архитектурные сущности, без которых потолок не пробить;
* LLM tuning больше не главный вектор;
* данные, ontology, lifecycle, retrieval unit и orchestration становятся основой.

Без этого вы снова утонете в “давайте ещё немножко улучшим ответы”.

---

## Этап 1. Закрыть фундаментальные дыры текущего слоя

Это не “идеал”, это санитарный минимум, чтобы было на что опираться.

### Что сделать

1. Дожать semantic retrieval hardening для broad/generic prompts.
   Сейчас даже в отчёте видно: constrained query narrowing работает, generic cross-entity — всё ещё слишком широкая. 

2. Добавить accountant-facing eval metrics:

* retrieval differentiation rate
* generic explanation rate
* accountant actionability score
* false confidence rate

3. Ввести baseline `investigation_state` в session model.
   Не полный engine, а хотя бы:

* focus,
* domain,
* period,
* hypotheses,
* checked objects,
* unresolved branches,
* last evidence pack.

### Критерий выхода

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

---

## Этап 2. Сменить retrieval unit

Это, по-хорошему, самый важный следующий технический шаг.

### Что сделать

Перестать считать `counterparty group` базовой единицей для chain/anomaly вопросов.
Оставить её как вспомогательную, но наверх выводить problem clusters.

### Нужные target units

* document_conflict
* broken_chain_segment
* lifecycle_anomaly_node
* unresolved_settlement_cluster
* period_risk_cluster
* cross_branch_inconsistency_cluster 

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

Только после этого ответы начнут переходить от:
“какие контрагенты шумные”
к
“что именно сломано и где”.

### Критерий выхода

На вопрос типа “что закрыли не тем документом” top-объектом ответа становится не контрагент, а **конкретный конфликтный узел**.

---

## Этап 3. Формализовать lifecycle

Без этого вы не сделаете хороший бухгалтерский reasoning.

### Что сделать

Для ключевых доменов ввести явные state models:

* bank/settlements
* suppliers
* customers
* fixed assets
* deferred expenses
* VAT
* period close

### Для каждого домена

Определить:

* допустимые стадии,
* допустимые переходы,
* типовые нарушения,
* бизнес-последствия.

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

Система сможет объяснять не “broken_lifecycle”, а:

* платёж дошёл, обязательство не закрылось;
* объект ОС принят, но переход в стадию эксплуатации/амортизации неконсистентен;
* РБП живёт за пределами ожидаемого срока списания;
* налоговый контур противоречит документному.

### Критерий выхода

Система умеет называть **тип поломки стадии**, а не просто общий risk label.

---

## Этап 4. Построить ontology graph

Это уже первый реально взрослый архитектурный шаг.

### Что сделать

Выделить typed nodes and edges:

* document
* posting
* register movement
* account
* counterparty
* contract
* asset
* deferred expense
* invoice
* VAT node
* period close operation
* etc.

И отдельно typed edges:

* created_by
* posted_to
* settles
* refers_to
* closes
* writes_off
* depreciates
* affects_period
* conflicts_with
* missing_expected_edge

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

1. Нормальный causal traversal
2. Нормальный cross-domain reconciliation
3. Возможность rule engine поверх графа
4. Сильный вход в LLM

### Критерий выхода

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

---

## Этап 5. Построить investigation mode

Это уже переход от ассистента к сопилоту.

### Что сделать

Поверх graph + lifecycle + retrieval unit ввести investigation engine:

* hypothesis registration
* branch tracking
* neighbor branch policy
* confidence-driven secondary checks
* stop criteria
* escalation to live drilldown

### Как это работает

Пользователь задаёт вопрос → система не просто отвечает, а открывает investigation state:

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

### Критерий выхода

Follow-up превращается не в “ещё один независимый вопрос”, а в продолжение одного расследования.

---

## Этап 6. Добавить live verification bridge

Для high-stakes ответов snapshot-only пути недостаточно. Это уже прямо отражено в статус-репорте.

### Что сделать

Добавить режим точечного live drilldown:

* по конкретному документу,
* проводке,
* объекту,
* текущему статусу,
* source-of-record.

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

1. Реальную актуальность
2. Меньше ложной уверенности
3. Возможность делать сильные выводы там, где snapshot устарел

### Критерий выхода

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

* вывод по snapshot,
* вывод, подтверждённый live.

---

## Этап 7. Развести execution modes в продукте

К этому моменту нужно уже не только архитектурно, но и продуктово развести 3 режима.

### Direct Answer

Быстрый ответ по объекту / проблеме / счёту.

### Investigation

Пошаговое исследование с ветками и накоплением доказательств.

### Audit / Batch

Долгий прогон по периоду/зоне с итоговым risk report.

Это можно оставить в одном UI, но внутри это должны быть три разных execution policies.

---

# 6. Как отвечать на твой главный страх: “мы очень далеко”

Да, вы далеко.
Но это **нормально**, потому что цель у вас не “добавить чат к 1С”, а построить довольно серьёзный reasoning layer над бухгалтерской реальностью.

По отчёту ваш текущий уровень — это действительно примерно:
**functional MVP+**, но не accountant-grade copilot. Это уже честно зафиксировано и там, и это правильная оценка.

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

Хорошая новость:
сейчас уже видно, **какие именно сущности отсутствуют**.
То есть вы уже не в тумане.
Вы уже можете перестать лечить симптомы и начать проектировать взрослую систему.

---

# 7. Чего точно не надо делать дальше

Это прям важно.

## Не надо:

* лечить всё промптами;
* надеяться, что более сильная LLM сама “додумает бухгалтерию”;
* продолжать делать entity-heavy ответы и просто украшать их текстом;
* считать длинную историю чата полноценным investigation state;
* пытаться одним execution loop закрывать и короткий factual вопрос, и долгий audit;
* строить perceived quality вместо реальной причинной глубины.

Это всё уже противоречит вашему же отчёту.

---

# 8. Если совсем коротко: что делать прямо сейчас

Если перевести всё в управленческое решение, то я бы сказал так.

## Ближайший обязательный пакет

1. baseline investigation_state
2. практические accountant-метрики
3. дожим generic narrowing
4. mechanism-specific fields в retrieval result
5. переход к mixed retrieval unit

## Следующий архитектурный пакет

1. lifecycle formalization
2. anomaly catalog accountant-grade
3. ontology graph core
4. problem-cluster retrieval default for chain/anomaly routes

## Стратегический пакет

1. investigation orchestrator
2. neighbor-branch policy
3. live verification bridge
4. product split на Direct / Investigation / Audit

---

# 9. Мой итоговый вердикт

Вам реально нужно **перестать мыслить от текущего pipeline** и начать мыслить от такой целевой конструкции:

**Бухгалтерский ассистент = accounting graph + lifecycle engine + problem-cluster retrieval + investigation state + iterative orchestrator + live verification + explanation layer**

LLM там важна, но она не центр системы.
Она — интерпретатор, планировщик, синтезатор и интерфейс reasoning.
А reasoning должен жить в архитектуре, а не только в модели.

Вот это и есть взрослая развилка.

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