# ТЗ Этап 2 — Retrieval Unit Shift для Assistant Mode

Дата: 2026-03-24  
Статус документа: рабочее ТЗ на второй этап развития бухгалтерского ассистента  
Назначение: перевод Assistant Mode от entity-heavy retrieval к problem-centric retrieval и problem-centric answer layer

---

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

Этап 2 — это первый по-настоящему архитектурный поворот после Foundation Hardening.

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

До этого момента система в основном живёт вокруг сущностей:
- контрагент;
- документ;
- группа операций;
- набор записей вокруг счёта или контура;
- агрегированный риск-профиль по entity group.

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

Поэтому задача Этапа 2 — не просто “улучшить retrieval”, а перевести систему от модели:

**вопрос → поиск сущностей → ranking сущностей → ответ**

к модели:

**вопрос → поиск candidate evidence → сборка problem units → ranking problem units → ответ по problem units**

Это означает, что в Assistant Mode появляется новый обязательный архитектурный слой:

## Problem Unit Layer

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

---

# 1. Исходная точка этапа

К началу Этапа 2 система уже должна иметь результаты Этапа 1:

- baseline `investigation_state`;
- усиленный `semantic_retrieval_profile`;
- `mechanism-aware evidence pack`;
- `answer_policy_v1_1`;
- `decomposition_guardrail`;
- accountant-facing eval metrics;
- broad-query guard для generic prompts.

Этап 2 **не переписывает** эти сущности, а использует их как фундамент.

Этап 2 стартует из состояния, в котором:
- retrieval уже не является чистым GUID-or-full-scan;
- narrowing по explicit accounting scope уже работает заметно лучше;
- evidence pack уже богаче, чем на MVP-этапе;
- но dominant retrieval unit по-прежнему часто остаётся counterparty-heavy;
- explanation всё ещё склонен строиться вокруг entities, а не вокруг механизмов дефекта;
- broad causal questions всё ещё могут приводить к ответу “кто шумит”, а не “что сломано и почему”.

Именно это состояние является точкой входа для Этапа 2.

---

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

На выходе Этапа 2 система должна уметь не только находить релевантные бухгалтерские сущности, но и формировать **problem-centric view**.

В user-facing и internal retrieval логике базовой единицей ответа для problem/anomaly/chain/period-risk запросов должна стать не только сущность, а один из problem unit типов.

## Базовые target units второго этапа

1. `document_conflict`  
2. `broken_chain_segment`  
3. `lifecycle_anomaly_node`  
4. `unresolved_settlement_cluster`  
5. `period_risk_cluster`  
6. `cross_branch_inconsistency_cluster`

После завершения этапа эти units должны стать first-class citizens в:
- retrieval output;
- normalized payload;
- ranking;
- answer composition;
- eval.

---

# 3. Что именно не устраивает в текущей архитектуре

## 3.1. Entity-heavy retrieval unit

Текущий dominant retrieval unit часто сводится к counterparty group, группе документов или aggregate-risk группе. Это допустимо для:
- quick ranking;
- первичного surfacing;
- общего operational scan.

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

Для этих вопросов entity-heavy top unit приводит к неправильному уровню abstraction. Пользователь получает:
- контрагента;
- счётчик документов;
- общие labels;
- общий risk summary.

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

## 3.2. Explanation по-прежнему слишком завязан на entities

Даже при наличии более богатого evidence answer layer склонен собирать narrative вокруг “кто оказался в top”, а не вокруг “что именно сломалось”.

В результате появляется ложная глубина:
- labels становятся богаче;
- текст становится длиннее;
- retrieval narrowing становится аккуратнее;
- но для бухгалтера всё ещё неочевидно, где именно problem node.

## 3.3. Нет промежуточного слоя problem assembly

Между retrieval и answer synthesis сейчас недостаточно оформлен слой, который из отдельных:
- документов;
- проводок;
- relation hints;
- lifecycle hints;
- anomaly patterns;
- linked entities

собирал бы **одну бухгалтерскую проблему** как отдельный объект.

Пока этого нет, answer composer вынужден работать почти напрямую по retrieval entities и агрегациям. Это и есть главный архитектурный предел текущего контура.

---

# 4. Цель этапа в одной фразе

**Этап 2 переводит Assistant Mode от поиска и ранжирования сущностей к поиску, сборке, ранжированию и объяснению problem units как самостоятельных бухгалтерских объектов анализа.**

---

# 5. Основная архитектурная идея этапа

Этап 2 вводит между retrieval execution и final answer composition новый слой:

## Problem Unit Assembler

Именно этот слой должен:
- принимать candidate evidence от route executors;
- группировать его в problem-centric узлы;
- определять тип problem unit;
- собирать mechanism summary;
- собирать affected documents / postings / accounts / counterparties / contracts;
- вычислять severity;
- готовить ranking inputs;
- передавать наверх уже не только entities, но и problem objects.

После этого answer composer должен строить narrative уже от problem unit.

---

# 6. Что сохраняем на Этапе 2

На Этапе 2 не ломаем базу Этапа 1. Сохраняются:

- `assistant loop`;
- `normalizer_v2_0_2` и его successors без полной переписки;
- deterministic routing summary;
- `investigation_state` baseline;
- `semantic_retrieval_profile`;
- `mechanism-aware evidence pack`;
- `answer_policy_v1_1` как базовый policy layer;
- debug plane / trace logging / session logging;
- broad-query guard;
- accountant eval layer.

Этап 2 — это **надстройка архитектурной глубины**, а не слом текущего assistive loop.

---

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

На этом этапе принципиально меняются следующие узлы:

1. retrieval output model;  
2. result normalization;  
3. ranking model;  
4. answer assembly logic for anomaly/chain/problem classes;  
5. evaluation model for quality of problem identification.

То есть меняется не только “что retrieval нашёл”, но и **что считается итоговым объектом поиска**.

---

# 8. Проблемные единицы (problem units): полная предметная спецификация

Ниже перечислены problem unit типы, которые должны стать first-class retrieval units на этом этапе.

## 8.1. `document_conflict`

### Смысл
`document_conflict` — это problem unit, в котором конфликт сосредоточен вокруг документа или набора документов, играющих противоречивую роль в ожидаемой бухгалтерской цепочке.

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

### Примеры в бухгалтерском контексте
- закрытие расчёта прошло документом, не соответствующим ожидаемому settlement path;
- по банку есть отражение движения, но расчётный документ, который должен был подтвердить closure, не найден или найден документ иного класса;
- документ реализации/поступления в цепочке присутствует, но не подтверждает ту роль, которую system expected based on flow;
- в period close задействована ручная операция, которая подменяет ожидаемую типовую связку.

### Какие сущности из 1С обычно участвуют
- `Document_*` объекты из snapshot;
- журнал документов;
- linked recorder refs;
- register-related movements;
- payment / bank statement documents;
- realization / receipt / invoice docs;
- manual operations / adjustment docs;
- posting evidence.

### Какие связи обязательны
- `document_to_posting`;
- `statement_to_document`;
- `contract_to_documents`;
- expected document class vs actual document class.

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

---

## 8.2. `broken_chain_segment`

### Смысл
`broken_chain_segment` — это problem unit, в котором проблемой является не единичная сущность, а разрыв или дефект в expected accounting chain.

### Когда возникает
- шаги цепочки подтверждены не полностью;
- одна связь в expected flow не подтверждена;
- документы, проводки и регистры существуют, но не собираются в непротиворечивый segment;
- движение денег отделено от расчётного закрытия;
- документ есть, проводка есть, но chain continuity не доказана;
- ожидаемый next step не найден.

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

### Какие сущности из 1С участвуют
- bank statements;
- settlement documents;
- postings;
- document journals;
- recorder refs;
- contracts;
- counterparties;
- associated registers.

### Какие relation patterns обязательны
- `payment_to_settlement`;
- `statement_to_document`;
- `document_to_posting`;
- `contract_to_documents`.

### Что должен уметь объяснить unit
- где именно chain breaks;
- какой шаг expected, но не найден;
- что подтверждено, а что нет;
- почему дефект относится к цепочке, а не к одной записи.

---

## 8.3. `lifecycle_anomaly_node`

### Смысл
`lifecycle_anomaly_node` — это problem unit для объектов, у которых ключевой дефект заключается в противоречивом, зависшем или неестественном жизненном цикле.

### Когда возникает
- объект завис между ожидаемыми стадиями;
- объект формально активен, но по смыслу уже должен был перейти дальше;
- жизненный цикл не завершён там, где ожидалось завершение;
- есть contradictory lifecycle signs;
- expected continuation missing.

### Ключевые бухгалтерские зоны
- `97` / расходы будущих периодов;
- ОС (`01/02/08`);
- авансы / расчёты;
- НДС / вычетный контур;
- period close affecting residual objects.

### Какие сущности участвуют
- object card / object-like document representation;
- amortization or writeoff signals;
- linked postings;
- document references;
- dates and period boundaries;
- close-related records.

### Примеры
- РБП живёт дольше ожидаемого срока списания;
- объект ОС принят, но следующий lifecycle stage не подтверждён или противоречив;
- начисления идут, а карточка/статус не подтверждают expected lifecycle;
- объект завис в промежуточной стадии перед close.

### Что unit должен уметь объяснить
- в какой стадии объект находится фактически;
- какая стадия ожидалась;
- почему это anomaly;
- чем это опасно для бухгалтера или close.

---

## 8.4. `unresolved_settlement_cluster`

### Смысл
Это cluster, в котором проблема живёт не в одном документе и не в одной записи, а в группе взаимосвязанных незакрытых, конфликтующих или спорящих settlement elements.

### Когда возникает
- несколько документов/платежей/связей претендуют на одно closure;
- есть незакрытая группа обязательств;
- payment path и settlement path расходятся на группе объектов;
- проблема повторяется в пределах одного контрагента, договора или расчётного участка;
- cluster нельзя корректно свести к одному document conflict.

### Где особенно важен
- расчёты с поставщиками (`60`);
- расчёты с покупателями (`62`);
- банковый и расчётный контур (`51/60`, `51/62`);
- прочие расчёты (`76`).

### Какие сущности участвуют
- counterparty;
- contract;
- payment docs;
- settlement docs;
- postings;
- bank statements;
- grouped residual/problem records.

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

---

## 8.5. `period_risk_cluster`

### Смысл
Это problem unit, в котором основным критерием значимости становится не просто anomaly, а влияние на закрытие периода и period-sensitive correctness.

### Когда возникает
- дефект затрагивает регламентные операции;
- есть residuals/разрывы, критичные для month-end;
- есть cluster, который не даёт корректно завершить period close;
- есть серия дефектов, которые individually невелики, но collectively опасны для закрытия.

### Какие сущности участвуют
- period close markers;
- closing operations;
- residual/problem records;
- deferred expenses;
- VAT-related records;
- unresolved settlements;
- lifecycle anomalies around period boundary.

### Что unit должен объяснить
- как именно эта проблема влияет на close;
- на какой период / boundary она ложится;
- это локальный хвост или systemic close risk.

---

## 8.6. `cross_branch_inconsistency_cluster`

### Смысл
Это cluster, в котором проблема проявляется как расхождение между соседними ветками учёта.

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

### Где это особенно важно
- банк / расчёты;
- ОС / начисления;
- НДС / документное основание;
- close / остатки / lifecycle-sensitive objects.

### Какие сущности участвуют
- минимум две ветки учёта;
- relation hints между ними;
- conflict evidence;
- documents/postings/register movements from both sides.

### Что unit должен объяснить
- какие ветки не согласованы;
- в чём именно противоречие;
- какая ветка говорит одно, а какая другое;
- почему это problem для бухгалтера.

---

# 9. Новый архитектурный слой: Problem Unit Assembler

## 9.1. Назначение

`ProblemUnitAssembler` — это обязательный backend-слой между route retrieval и final answer composition.

Его задача:
- принимать candidate evidence from executors;
- строить промежуточные problem hypotheses;
- агрегировать evidence в problem-centric объекты;
- нормализовать их в единый schema;
- передавать problem units в ranking pipeline и answer synthesis.

## 9.2. Почему нужен отдельный слой

Если просто попытаться “ранжировать problem units прямо в retrieval executor”, логика быстро расползётся:
- domain-specific heuristics смешаются с retrieval;
- answer layer по-прежнему будет видеть сырой payload;
- unit transition будет неполным;
- тестирование будет хуже.

Assembler нужен именно как отдельная ответственность:

- retrieval = найти candidate evidence;
- assembler = понять, какие evidence образуют одну проблему;
- ranking = определить приоритет problem unit;
- answer layer = объяснить problem unit бухгалтеру.

## 9.3. Входные данные assembler

Assembler должен принимать:
- normalized retrieval items;
- relation pattern hits;
- anomaly patterns;
- mechanism-aware evidence fields;
- selected route metadata;
- current `investigation_state` focus;
- ranking basis;
- confidence hints.

## 9.4. Выходные данные assembler

Assembler должен отдавать список `problem_units`.

Каждый problem unit должен включать:
- `problem_unit_id`
- `problem_unit_type`
- `title`
- `mechanism_summary`
- `business_defect_class`
- `severity`
- `confidence`
- `affected_entities`
- `affected_documents`
- `affected_postings`
- `affected_accounts`
- `affected_counterparties`
- `affected_contracts`
- `expected_state`
- `actual_state`
- `failed_expected_edge`
- `period_impact`
- `evidence_pack`
- `entity_backlinks`
- `requires_neighbor_check`
- `snapshot_limitations`

## 9.5. Базовая логика сборки

Assembler обязан работать в несколько шагов:

### Шаг 1. Candidate evidence clustering
Группировка candidate evidence по:
- общим документам;
- общим expected/actual mechanism patterns;
- общему settlement path;
- общему lifecycle defect signature;
- пересекающимся contracts/counterparties/accounts;
- period boundary.

### Шаг 2. Problem hypothesis detection
Для каждой candidate cluster assembler пытается понять, является ли cluster:
- document conflict;
- broken chain;
- lifecycle anomaly;
- unresolved settlement;
- period risk;
- cross-branch inconsistency.

### Шаг 3. Problem normalization
Cluster превращается в normalized problem unit.

### Шаг 4. Duplicate collapse
Разные evidence, относящиеся к одной и той же проблеме, должны быть collapsed в один problem unit.

### Шаг 5. Severity scoring inputs
На unit наслаиваются severity и ranking signals.

---

# 10. Схема данных problem unit

Ниже — обязательный target schema второго этапа.

```json
{
  "problem_unit_id": "pu_...",
  "problem_unit_type": "document_conflict",
  "title": "Платёж отражён, но ожидаемое закрытие обязательства не подтверждено",
  "mechanism_summary": "По цепочке payment -> settlement closure найдено отражение оплаты, но не подтверждён ожидаемый документный шаг закрытия",
  "business_defect_class": "wrong_closure_path",
  "severity": {
    "score": 0.0,
    "grade": "high"
  },
  "confidence": {
    "score": 0.0,
    "grade": "medium"
  },
  "affected_entities": [],
  "affected_documents": [],
  "affected_postings": [],
  "affected_accounts": [],
  "affected_counterparties": [],
  "affected_contracts": [],
  "expected_state": "closure by linked settlement chain",
  "actual_state": "payment reflected without confirmed closure edge",
  "failed_expected_edge": "statement_to_document -> payment_to_settlement",
  "period_impact": {
    "is_period_sensitive": true,
    "impact_class": "close_risk"
  },
  "requires_neighbor_check": true,
  "snapshot_limitations": [],
  "evidence_pack": [],
  "entity_backlinks": []
}
```

Эта схема должна быть реализована как first-class backend contract.

---

# 11. Ranking второго этапа

## 11.1. Общий принцип

Ranking больше не должен быть entity-first.

На этом этапе ranking должен отвечать на вопрос:
**какая problem unit важнее для бухгалтера**, а не **какая entity чаще всплыла**.

## 11.2. Базовые ranking factors

Для problem unit ranking обязателен набор факторов:
- mechanism severity;
- confidence of mechanism;
- period impact;
- repeatability;
- cross-branch involvement;
- number of affected documents/postings;
- unresolved state persistence;
- financial impact (не единственный и не всегда доминирующий);
- settlement criticality;
- lifecycle defect severity;
- manual intervention suspicion;
- cluster completeness.

## 11.3. Особое правило

Если пользователь explicitly спрашивает про:
- wrong document type;
- lifecycle defect;
- chain break;
- period close impact;

то ranking **не имеет права** доминировать по amount/frequency alone.

## 11.4. Mixed-unit transition policy

На втором этапе допускается mixed ranking:
- primary ranking unit = problem unit;
- secondary context = entity context (counterparty/document/account).

Но итоговый answer layer должен строиться от problem unit.

---

# 12. Изменения по модулям и слоям

## 12.1. `assistantDataLayer.ts` / route executors

### Что не меняем
- существующие route executors;
- semantic retrieval profile;
- retrieval narrowing logic как базу.

### Что добавляем
- обязательный output contract для candidate evidence;
- более жёсткую нормализацию relation pattern evidence;
- grouping-friendly identifiers;
- explicit expected/actual fields;
- normalized document references suitable for clustering.

### Что важно
Executors на этом этапе **не должны** превращаться в полноценные graph reasoners. Их задача — готовить candidate evidence, а не подменять assembler.

---

## 12.2. Новый модуль `problemUnitAssembler`

### Назначение
Собирает problem units из candidate evidence.

### Обязательные подфункции
- `clusterCandidateEvidence(...)`
- `detectProblemUnitType(...)`
- `buildProblemUnit(...)`
- `collapseDuplicates(...)`
- `scoreProblemSeverity(...)`
- `linkBackToEntities(...)`

### Что должно быть отдельно
Domain helpers могут быть вынесены в:
- bank/settlements;
- suppliers/customers;
- deferred expenses;
- fixed assets;
- VAT;
- period close.

Но core assembler должен оставаться общим.

---

## 12.3. `resultNormalization`

### Что меняем
Normalized payload должен научиться содержать два уровня:
- `raw_entities`
- `problem_units`

Для backward compatibility entity payload сохраняется.

### Новый принцип
Answer layer для определённых query classes работает прежде всего по `problem_units`.

---

## 12.4. `answerComposer`

### Что меняем
Composer должен получить новый режим сборки:

- direct factual / entity mode;
- problem-centric mode.

### Когда использовать problem-centric mode
- chain/anomaly questions;
- wrong-document questions;
- period-risk questions;
- lifecycle questions;
- cross-branch inconsistency questions.

### Новый narrative order
Для problem-centric mode answer composer обязан строить ответ в порядке:
1. problem unit;
2. mechanism;
3. affected documents/entities;
4. why this matters;
5. limitation / confidence;
6. next check.

### От чего отказываемся
От top-entity narrative по умолчанию для chain/anomaly/period-risk routes.

---

## 12.5. `assistantSessionStore` / session model

### Что меняем
`investigation_state` должен уметь хранить ссылки не только на entities, но и на `problem_units`.

### Что добавляем
- `active_problem_units`
- `resolved_problem_units`
- `problem_unit_backlinks`
- `investigation_focus.problem_types`

### Зачем
Чтобы follow-up мог продолжать анализ уже не по entities alone, а по problem structure.

---

## 12.6. Eval / benchmark harness

### Что добавляем
Новые метрики второго этапа:
- `problem_unit_precision`
- `problem_unit_recall_proxy`
- `duplicate_collapse_rate`
- `mechanism_coherence_score`
- `problem_clarity_score`
- `problem_first_answer_rate`
- `entity_leakage_rate`

### Новый benchmark suite
Канонические сценарии должны проверять, что top ответа — это problem unit, а не просто entity group.

---

# 13. Предметная привязка к данным 1С

Второй этап должен быть не абстрактным AI-слоем, а слоем, который структурно использует реальные сущности, забираемые из 1С snapshot/access contour.

## 13.1. Базовые типы данных, которые должны участвовать в problem assembly

### Документы
- банковские документы;
- платёжные документы;
- поступление товаров/услуг;
- реализация;
- счёт-фактура;
- корректировки;
- ручные операции;
- документы, связанные с РБП;
- документы ОС;
- close/period-sensitive docs.

### Проводки
- posting evidence;
- posting contexts;
- account hits;
- expected account-role vs actual account-role.

### Регистры
- VAT-related register records;
- accumulation/register evidence;
- other record types available in snapshot.

### Справочные сущности
- контрагент;
- договор;
- организация;
- ответственное лицо;
- объект ОС;
- object-like identifiers from snapshot.

### Периодные поля
- даты;
- boundary markers;
- period-sensitive groupings.

## 13.2. Как использовать эти данные

Нельзя ограничиться тем, чтобы просто передать их в answer layer.

Нужно:
- сгруппировать их в problem-centric clusters;
- определить, какая комбинация документов и проводок образует defect class;
- определить expected flow и actual flow;
- показать, как 1С-объекты подтверждают mechanism.

---

# 14. Реализация по классам бухгалтерских контуров

На Этапе 2 не надо покрывать всю бухгалтерию одинаково глубоко. Но нужно выбрать ключевые контуры, в которых problem-centric retrieval особенно нужен.

## 14.1. Банк / расчёты (`51/60`, `51/62`)

### Почему это P0-домен
Именно здесь чаще всего видны:
- wrong closure path;
- chain breaks;
- settlement inconsistencies;
- bank/document/posting divergence.

### Что должно появиться
- `document_conflict` по wrong closure type;
- `broken_chain_segment` для bank → document → settlement;
- `unresolved_settlement_cluster` по payment + closure mismatch.

---

## 14.2. Поставщики / покупатели (`60`, `62`, `76`)

### Что должно появиться
- clusters незакрытых расчётов;
- conflict groups, где несколько документов и оплат спорят между собой;
- problem units по repeated settlement issues.

---

## 14.3. `97` / deferred expenses

### Что должно появиться
- `lifecycle_anomaly_node`;
- period-sensitive risk cluster;
- explicit expected/actual lifecycle description.

---

## 14.4. ОС (`01/02/08`)

### Что должно появиться
- lifecycle anomaly units;
- cross-branch inconsistency between card/state and actual accounting behavior;
- period-sensitive risk where relevant.

---

## 14.5. НДС / tax-related cross-branch zones

### Что должно появиться
- `cross_branch_inconsistency_cluster`;
- problem unit between document basis and tax reflection;
- period-close-sensitive tax risk clusters where evidence supports it.

---

# 15. Порядок выполнения внутри этапа

Чтобы этап не расползся, он должен идти в строгой последовательности.

## Шаг 1. Спецификация problem units

Нужно зафиксировать:
- полный schema;
- типы units;
- базовые domain mappings;
- ranking inputs;
- answer requirements.

## Шаг 2. Candidate evidence contract hardening

Executors и normalization должны начать отдавать grouping-friendly evidence.

## Шаг 3. Реализация Problem Unit Assembler

Assembler должен появиться как отдельный backend service.

## Шаг 4. Mixed ranking

Переход от entity-first ranking к problem-first ranking.

## Шаг 5. Problem-centric answer mode

Answer composer должен уметь строить narrative от problem units.

## Шаг 6. Benchmarks и eval

Проверяем, что система реально стала problem-centric, а не только переименовала top entities.

---

# 16. Что не делаем на этапе 2

На этом этапе **не надо**:

- строить полный ontology graph;
- строить полный lifecycle engine с state machine по всем доменам;
- строить full investigation orchestrator;
- строить live verification bridge;
- охватывать абсолютно все бухгалтерские домены одинаково глубоко;
- превращать assembler в rule engine уровня полной онтологии;
- просто переименовывать entity groups в problem clusters без смены mechanics.

Особенно важно:

## Нельзя считать этап выполненным, если
- top retrieval unit всё ещё по сути entity-heavy;
- answer всё ещё строится вокруг counterparty/doc counts;
- problem cluster является только косметической группировкой;
- mechanism summary не лучше старых risk labels.

---

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

Этап 2 считается принятым только если выполнены все условия ниже.

## 17.1. Архитектурные критерии

- реализован отдельный `ProblemUnitAssembler`;
- существует backend schema `problem_unit`;
- normalized payload поддерживает `problem_units`;
- session state умеет ссылаться на active/resolved problem units.

## 17.2. Retrieval criteria

- для key domains retrieval output может быть assembled в problem units;
- duplicate entity evidence collapse работает;
- ranking problem units работает отдельно от pure entity ranking.

## 17.3. User-facing criteria

- на вопрос “что именно сломано” top ответа — problem unit, а не просто entity group;
- ответ показывает механизм дефекта;
- ответ показывает затронутые документы/цепочки;
- ответ показывает, почему это проблема, а не просто кто оказался в top.

## 17.4. Accounting-domain criteria

Минимум в ключевых доменах должны быть рабочие problem units:
- bank/settlement chain;
- supplier/customer unresolved settlements;
- deferred expense lifecycle anomalies.

## 17.5. Eval criteria

- внедрены problem-centric metrics;
- benchmark suite показывает снижение entity-heavy leakage;
- есть before/after evidence по canonical scenarios.

---

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

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

- richer wording;
- grouping by counterparty with prettier labels;
- расширение current evidence pack без assembler;
- top-entity answer с новым названием “problem cluster”; 
- новые шаблоны текста без смены retrieval unit.

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

---

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

После Этапа 2 система всё ещё не является финальным бухгалтерским copilot. Но она уже должна перестать быть ассистентом, который в основном знает “кто в top”, и начать быть ассистентом, который видит “что конкретно сломано”.

## На выходе этапа должно появиться:
- problem-centric retrieval;
- problem-centric ranking;
- problem-centric answer layer;
- problem-aware session continuity;
- measurable reduction of entity-heavy answers.

Это и есть первая настоящая архитектурная точка, после которой уже рационально переходить к:
- lifecycle formalization;
- ontology graph core;
- investigation engine.

---

# 20. Короткий итог

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

Без этого перехода дальнейшая формализация lifecycle и ontology graph будет подниматься наверх в виде всё тех же top-entities, а не problem reasoning.

Именно поэтому Этап 2 является критическим мостом между Foundation Hardening и взрослой бухгалтерской reasoning-архитектурой.
